Embedded From: [email protected] [mailto:[email protected]] On Behalf Of mungewell Sent: Wednesday, May 13, 2009 2:37 PM To: [email protected] Subject: [DSTAR_DIGITAL] Re: Compression/encoding on data-only transmissions
I'll have a look as D-RATS. So am I right in my understanding that a DStar 2m radio (such as IC-V82 + UT-118) will send (or can be made to send) unadulterated data over the voice+data channel? It's raw data, what goes in the serial port goes over the air. Does this mean whatever it receives on the serial port is sent out as additional data on voice+data more, or is there a comms protocol on the ICOMs to 'poke' data bytes into a message queue? The data will go out over the air either immediately or when the PTT is pushed, depending on radio settings. There is a little buffer that seems to vary dependent on the radio. Now for the big question.... :-) Q. How useful/important would it be for transmission integrity to include compression/FEC of 'simple data' on the voice+data link. Sure, DRATS does some of it now. Remember that this is not point to point data. It is broadcast. Whatever you send can be heard by any radio that hears you. The data follows the voice. Now don't forget to add in repeater and reflector operation when considering data protocols, they both add delays. The reason that I ask is that (in one of my other areas of interest) there is a scheme for compressing ASCII (binary, C40, etc) for use with IEC16022/ECC200 2D barcodes. Basically the data stream is encoded into a sequence of codewords and with FEC data appended to the end. Codewords/FEC lengths are predefine for different barcode geometries, but allow up to 3116 numbers in a single codeword sequence (more can be 'paged' together up to 16 pages). Sure, but don't forget that at ~900 bps throughput, 3116 numbers take a REALLY long time to transmit. (30s) It just struck me that this might be an obvious match for a modified D-Star scheme. It is pre-defined and there is open code for making it happen.... Compression ratios depend on source data and chosen mode, although it is possible to switch between modes with a little overhead. The C40, X12 and EDIFACT 'alphabets' also have a shift character where another character set can be obtained with an addition codeword. ASCII, ASCII character 0 to 127, 1 characters per CW ASCII extended, ASCII character 128 to 255, 0.5 character per CW ASCII numeric, ASCII digits, 2 characters per CW C40, Upper-case alphanumeric, 1.5 characters per CW TEXT, Lower-case alphanumeric, 1.5 characters per CW X12, ANSI X12, 1.5 characters per CW EDIFACT, ASCII character 32 to 94, 1.33 characters per CW BASE 256, ASCII character 0 to 255, 1 characters per CW Codeword+FEC sizes are dependant on message length, but range from 3+6 to 1558+620. I'd definitely recommend trying to keep the packet sizes less than a few D-STAR frames, which is pretty short. One of the sweet spots for D-STAR data is probably SMS type messages. Short and sweet. If we had a FEC mechanism for a SMS message, that probably would be nice. Cheers, Simon VA6SDW [Non-text portions of this message have been removed]
