On Wed, 13 May 2009 18:37:18 -0000, "mungewell" <[email protected]> said:
> 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? Probably not the IC-V82 + UT-118. That rig has no serial port, AFAIK. It's just a commercial HT with an add-on board. To do the low-speed data you need one of the later rigs with a serial port on it. > 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? Data and Voice are continuously sent in the D-STAR specification. If no data is being "fed into" the rig... those are just "wasted" bits in the on-air protocol. 4800 bps, 2400 voice encoded via the AMBE CODEC, 1200 FEC for the voice only, 1200 data... all the time throughout every transmission. If you feed serial data into a rig while it's transmitting, that same serial data is present at the serial port of all radios receiving your transmission. Does that make more sense? > 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. Adding FEC to an application using the serial port would up the reliability of the data reception when signals are weak, but requires "stealing" bits out of the already horrendously slow 1200 bps stream available for data. > 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. Compression and FEC aren't the same thing. Adding compression to the data might get you back some of the lost effective throughput of FEC. > 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). Numbers only? > 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.... There's nothing "obvious" about it to me, really -- it's an option. The D-STAR rigs are just a non-error-corrected 1200 bps "pipe". There's a bejillion ways to utilize something like that. D*Chat uses it as a simple text chat system. D-RATS is layering on some packetization of things to handle retries when conditions are poor, but is NOT doing FEC... just retransmission of lost packets. And who knows what D-STAR TV is doing with their SSTV conversion to ASCII data. By the way, at least one developer has pointed out that they had to play with the serial connection to learn which characters are NOT supported/allowed through the port. This may or may not be documented somewhere, but many of the "extended ASCII" characters aren't passed, I hear. Haven't tried it myself, but it's easy to test with a little test application that sends everything in order, and another that receives them... > 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. YAES. :-) (Yet another encoding scheme.) Yawn. :-) Not trying to sound negative, but it really doesn't matter how anyone encodes it... it's just a bit pipe. If you personally happen to like this particular "bar code" thingy... you could try to get a developer to put it into one of the applications, or write an app to do something with it. The on-air encoding won't matter at all to the end user other than something with built in FEC will certainly help in bad signal conditions versus something that does not. Something as simple as retransmission with a CRC check or Manchester encoding, etc... is going to be "fine" for most of these applications. Right now, in either D*Chat or D-RATS... you can hold a voice conversation with someone on the "fringe" of repeater coverage, but as soon as they try to send a text message to you, it's garbled/trashed. Remember, voice has FEC DONE BY THE RADIO, and low-speed data does not. I'd PERSONALLY prefer that the applications themselves do some sort of FEC at least as well as the voice so the users aren't so surprised that they can TALK, but they can't play along on data. Non-technical users get REALLY frustrated when you tell them you can copy their voice traffic, but they're on the fringe and need a better signal for data. (It also shows how spoiled we all are with FM repeaters and noisy crappy HT signals... our brains are the FEC/DSP there.) BUT... the trade-off is that effective throughput is going to drop to something like 650 bps... which is terribly slow. There could be a smart protocol that says "if I missed the packets from the far side X number of times, I'll switch to slow-heavily-corrected-mode", perhaps. But it ties up a lot of air time. If you REALLY need to move a lot of data, you REALLY need to buy an ID-1 and just do it over 128 Kb/s half-duplex converted in the rig to Ethernet. The low-speed data "system" overall is too slow for doing large files, pictures, etc... if you also have a busy Voice net on the same frequency. Nate WY0X -- Nate Duehr [email protected]
