Maybe I am wrong on what Andy was saying, but I got the impression that he did not want criticism of a specific hardware device, to wit:
"The comment summary is that the product is good hardware device for most common digital modes but may not work with ALE and AMTOR ." I would hope that discussion of on-going timing issues is not avoided since it really is rather important for those of us involved in digital modes. The idea being to separate fact from fiction so that we have enough information to make an informed decision. Can you truncate the beginning of an ARQ transmission and get good throughput? I am skeptical that you would not notice this when attempting to use a given mode. When the checksum is calculated, it will throw out the packet unless that packet is complete, or uses advanced concepts such as memory ARQ to "build" a good packet our of several damaged ones. But you would immediately see that throughput is much too low, wouldn't you? I asked myself, whether or not our technology impacts any current modes, even relatively fast ones, and there does not seem to be much, if any, impact of commonly used sound card modes. With the testing that I have done, I have not seen any noticeable difference, whether using VOX keying of a rig, VOX keying with detached hardware, software rig control, or hardware PTT keying. I have not measured the keying time, since I am not sure that I have that capability, but I can tell if signals are not getting through if I know exactly what was sent and exactly what was received. If there was a discrepancy, I could determine if something was truncated, at least with text. This morning I replicated a test with the RFSM2400 software sound card modem using several types of base modulation on a clear frequency. This software does not work with Microsoft Vista, thus I borrowed my wife's laptop that we use for public service/emergency use when mobile/portable since it is a Microsoft XP machine. It was connected to an outboard VOX keying interface device to my ICOM IC-7000 (simulating portable use) and for what would normally be my home station rig which is an ICOM 756 Pro II using an emachines XP tower interfaced through a low cost hardware interface that has both audio and an optoisolator PTT circuit. This allows me to simulate two nearby stations sending and receiving and perhaps at least as importantly, using different keying methods. The RFSM2400 modem sends a beep tone with each transmission similar to what Rudd had mentioned earlier as a suggestion for the beginning of the transmission and I think that I was able to hear this on the receiving end for all data packets. The following RFSM 2400 test results are delineated as HP Laptop and emachines tower to distinguish the two rig setups sending a standardized text document: 6 METER SSB - non-standard .3 - 2.7 kHz bandwidth emachines tower - sent 20 secs @ 578 bps HP Laptop - received 14 secs @ 825 bps Although I did not expect the wider standard bandwidth to work, it seems to work well 6 METER SSB - standard .3 - 3.3 kHz bandwidth emachines tower - sent 17 secs @ 675 bps HP Laptop - received 12 secs @ 960 bps I then tried 6 METER FM HP Laptop - sent 13 secs @ 910 bps emachines tower - received 8 secs @ 1485 bps and switched with the emachines tower sending the same file emachines tower - sent 17 seconds @ 678 bps HP Laptop - received 12 secs @ 965 bps Notes and additional comments: - the programs indicated about +12 to +21 dB S/N - the time and bps was taken from the program's information upon completion of the file transfer. The calculation is done differently for the TX vs the RX station, but I would consider the RX to be the number to use. - for short files (my standard Gettysburgh Address) which RFSM2400 shows as 1493 bytes but is just over 1400 according to my count, including spaces and punctuation), - initially the software selected the short 500 protocol - longer files will attempt longer protocols such as 3200 Long , (probably based on conditions) but I stayed with relatively short files. - The audio bandwidth is very likely wider than with SSB, thus the improved throughput on FM. - I am not sure about the difference in throughput depending upon which rig is selected as the sending station, but I did not run multiple trials. Since the HP Laptop which is connected to the ICOM 7000 had almost the same TX and RX, could this may be the limiting link in the chain? - The CPS rate is faster than 1/10 of the bps throughput, so the fastest speed . With compression, this could nearly be doubled. - Although I do not plan on using this modem in the future, due to discontinuance of further development, it was interesting to see the throughput potential under pristine conditions. Also, I have tested it on HF, with previous reports and it is was very limited due to not having a fall back position for weak signals. This is a MIL-STD 188-110 design so it could have this feature added. The newer RFSM8000 modem has a fee associated with the product, so I have not continued further testing due to the availability of other programs that work better on HF and can still have good speeds on VHF, although not in the 1000 wpm range that can be possible with very good signals with RFSM2400. 73, Rick, KV9U Rud Merriam wrote: How come you are discussing a topic the moderator asked us to drop? I will repeat my assertion that VOX operation can be done without any changes to the protocol. All that is needed is for the IMPLEMENTATION that supports the protocol, i.e. the software, to generate a tone. The tone triggers the VOX either in the rig interface or the transmitter. During the keying period of the transmitter the tone continues. After the keying delay expires the IMPLEMENTATION starts sending the actual protocol. The receive might hear some milliseconds of the tone before it begins to hear the protocol. No changes needed there, either. Nothing changes in the protocol. Nothing is required of the protocol. Nothing of the protocol is damaged. Nothing of the protocol is thrown away. Actually the tone could be useful as a marker. The receiver could use it to tune into the transmitted signal. Rud Merriam K5RUD ARES AEC Montgomery County, TX http://TheHamNetwork.net -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of expeditionradio Sent: Friday, August 29, 2008 2:06 AM To: [email protected] Subject: [digitalradio] Fast ARQ Hardware It has been argued by several in this group that the first part of a digital mode transmission may be deleted by faulty transmit hardware without any problems in the reception on the other end. In other words, the first part of a transmission may be thrown away or discarded, and the message will still get through. 73 Bonnie VR2/KQ6XA
