On Mon, 11 May 1998 20:23:53 -5:00 Henry Carl Ott writes: > Back to the f84, > If all you had to handle was the ID (or other short strings), >and since >the transmitter has to be hooked up to proprietary software to program >anyway, >why not pre-generate the id string on the pc and just program the >eeprom with >the packed dots and dashes. No tables in the pic. The trade off is >eeprom >locations versus program space. I think the worst case scenario is >two bytes >per character. That's what I did in my F84 repeater controller (seems like everyone gets to write a repeater controller at some time or another). I used two bits per Morse element in the following code: Encoding Tone 00 00 (char space) 01 0000 (word space) 10 10 (dit) 11 1110 (dah) For example, the letter 'A' is stored 101100, and transmitted 10111000. It's real easy to write the state machine to turn the tone on and off since the first bit tells whether to send a tone or not and the second bit tells whether the element is 2 or 4 time periods long. Two 00's in a row marks the end of the message. Long spaces can be encoded using repeated 01 maybe with 00 in between. The user can enter the code into EEPROM in decimal via the DTMF receiver when a "setup" jumper is closed. I used decimal rather than hexadecimal since one of the objectives was to be able to use the controller with a 12-button DTMF keypad. The repeater is for 6m and we only have a few 6m radios with DTMF, let alone with 16 buttons. Overall the controller is very similar to the one that was in QST a couple of years ago, only it adds features that I consider important (eveyone has their own opinion on that too). > >> What's the protocol look like for POCSAG? > > Pretty straight forward. The basic codeword is 32 bits. 20 >bits of data, >11 bits BCH ECC and one parity bit. You also have to generate sync >words and >idle words. Sync words and idle words are actually just two of the possible 20-bit data words. The ECC and parity codes are the same. The main problem I see with transmitting POCSAG (which would be a very useful feature I agree) is that the time slot when the data is transmitted is part of the address. In order to page more than one pager per transmission, you need to organize the paging data into blocks of 16 codewords (about 48 bytes before ECC). It would be pushing the RAM space in the 84. A special-purpose transmitter that doesn't pack multiple pages into one transmission would be much simpler, since all the non-applicable words would just be "Idle" words. > >One online pocsag specification is available at: >ftp://ftp.demon.co.uk/pub/ham/scanners/POCSAG.TXT > > Another necessity is the ability to transmit true fsk (approx >+/- 4.5 khz). >Does the agrelo transmitter allow this? Some synthesized transmitters >use >phase modulation techniques that make them unsuitable for pocsag. Yes, it is hard to do approximately DC modulation on simple synthesized transmitters because the PLL will fight it. I converted a synthesized scanner into a POCSAG test transmitter (by placing the pager near the scanner, it will receive the LO). In order to make it work, I modified the loop filter to have a very long time constant. It took about 30 seconds to lock onto frequency. Once locked, any modulation added after the loop filter would directly FM the oscillator and the PLL couldn't do anything about it other than control the long term average frequency. Of course it was on the air all the time. A more practical, but complicated, technique could FSK the reference oscillator as well. Maybe it's possible to reprogram the PLL for +- 5 KHz on the fly, but there'd likely be a lot of problem transients that would go out of the channel bandwidth. (A paging transmitter with a dirty signal? Never heard of that!) _____________________________________________________________________ You don't need to buy Internet access to use free Internet e-mail. Get completely free e-mail from Juno at http://www.juno.com Or call Juno at (800) 654-JUNO [654-5866]