[aprssig] More efficient use of channel capicity throughshorterpackets
scott at opentrac.org scott at opentrac.orgThu Oct 12 16:24:54 UTC 2006
- Previous message: [aprssig] More efficient use of channel capicity through shorterpackets
- Next message: [aprssig] More efficient use of channel capicity through shorterpackets
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> baud FSK, the detection of the tones is fairly quick, but > does the modem > actually deliver good data immediately? Or does it need to > see multiple > bits fly by before its local bitclock is sync'd, and it can reliably Depends on the clock recovery used in the receiver. Normally that's a DPLL that has to be synced to the incoming bit rate, and loop bandwidth affects how fast it can be synced. Sending a bunch of zeros (alternating high/low in NRZI) gives the greatest number of transitions and makes it easier to lock on to the signal. I think most receivers should be able to lock on in 0-10 bit times. My Tracker2 prototypes do pretty well in that respect - I've implemented a kind of fuzzy clock recovery scheme that at least outperforms the KPC-3. Hook up the output of a KPC-3's demodulator to a T2 and (at least with my test corpus) it'll decode 1-3% more packets than the KPC-3 itself. Of course, generally speaking you've got to set your TXD high enough to work with the slowest TNC around. > With 9600baud modems which use more complicated encoding > schemes, I > suspect this modem clock recovery/bitclock sync time may be longer as > well. I think it depends a lot on implementation, and the specific scheme used. I haven't worked with higher baud rates much myself, but I'd expect that an old hardware-based linear feedback shift register is going to take a lot longer to sync up to a scrambled signal than a properly written software equivalent would. > Another short-packet data application, the ubiquitous credit card > authorization terminal, is still using 300 baud modems to > this day, simply > because the handshake/lockup time on the faster codecs adds > more time than > is saved during the data-transfer phase. Excellent example. You can force faster modems into shorter negotiation sequences if they're configured right, though I haven't tried that since my days of exchanging BBS message bundles at 14.4k and trying to shave as much as possible from the long distance bill. For something like credit card authorization, you only have to exchange tens of bytes. A 300 baud modem can get the job done before a 28.8 is halfway through its negotiation. Scott N1VG
- Previous message: [aprssig] More efficient use of channel capicity through shorterpackets
- Next message: [aprssig] More efficient use of channel capicity through shorterpackets
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
