I can see that some digital modes would not work very well for ARQ that is decoded in real time. MT-63 and MFSK16 both have latency due to their design. I am surprised that MFSK16 was considered, but perhaps this was due to being the most narrow mode that also can work very deep into the noise?
Olivia is so very slow relative to the bandwidth, that I would not think of it as a good candidate. The one mode that seems to be a ready made mode for this kind of communication is FAE400 since it already is an ARQ mode and is reasonably narrow for its throughput. This is the best mode I have ever used for an ARQ sound card solution, especially considering how narrow it is for the sensitivity and speed. Alternatively, couldn't the ALE400 mode be incorporated into the NBEMS system since it would then become an ARQ mode, although would work differently than FAE400 and perhaps not as fast? One thing I don't follow completely with Skip is the idea that you need all these signals on one waterfall. I would never tune in a signal very far off from my sweet spot on my rig (varies depending upon rig design) and normally want digital modes to be centered on 1500 Hz in order to be able to use the filtering available to me. It can make a big difference in difficult conditions or when very strong signals or splattering signals are close in. If we had an emergency situation, it seems to me that you would not be having multiple streams of different stations sending data. Especially not for e-mail capability. It may be difficult to even find more than one or two stations that you can connect to and who have a computer interfaced with their rig with the NBEMS program suite installed and know how to use it. Once you were able to find someone, you would likely want to work with them (assuming a savvy operator, no different than other modes), and route your traffic in that manner. They could coordinate with others outside the disaster area and have them come up on frequency as needed for relief. One thing that has concerned me here in the U.S., is the near total lack of interest in developing some method of using voice intermixed with text data, the very thing we most need for emergency communications. While we can legally do it under the Part 97 rules on 160 meters and on 6 meters and up, the bandplans do not reflect that. Why do so few support this capability? It is used everyday by the SSTV and hams doing large data transfers of this type. Maybe we could at least use it on VHF? But I have not found a common frequency in the bandplans. As far as the wide bandwidth and faster modes such as RFSM, this could work under some conditions. Tremendously faster than the NBEMS system, although it does not have the fall back to the weaker signals and requires better signals than what is normally required for very weak SSB. Has anyone done any further testing on VHF with RFSM? It is completely legal to do so here in the U.S. on 6 meters and up. As Andy points out, there are times when the ARQ text digital modes don't work at all, but with FAE400 this seems like much less of a problem considering that it may be able to perform better than PSK31 without ARQ. 73, Rick, KV9U Andrew O'Brien wrote: > > NBEMS is the software package, not an actual mode. It includes PSK31, > PSK63, PSK 125, PSK250, MFSK16 and RTTY. MT63 and Olivia are not > offered. One primary goal for this software is "high" speed message > transfers on VHF and UHF where something like PSK250 can be used with > good outcome. On HF, the noise level does not usually support the > higher speed PSK operations but PSK31 and PSK63 do quite well on HF. > The software uses ARQ ... the message is sent, the other stations > sends an acknowledgment from time to time. If there was a error (due > to no decode of a weak signal for example) the section of the message > would be repeated until the station acknowledges receipt. Thus the > transfer rate can be slow but the text/copy will be 100% if the files > xfer is successful. > > While Olivia and MT63 are vastly superior to PSK31 under most weak > signal situations, the ARQ aspects of NBEMS will make it more reliable > if accuracy is what you desire. > > ALE 400 and RFSM-8000 offer alternatives . ALE-400 is available in > Multipsk but is not widely used. RFSM is even less used and some baud > rates are not legal for USA amateurs to use. I believe the authors of > NBEMS had a goal of facilitating the accurate transfer of messages via > methods widely used by hams in everyday application. Thus PSK and > RTTY, very commonly used. While they will not perform as "well" as > ALE 400, RSFM 8000, Winlink, Pactor II, III, in some circumstances, > the expectation is that a PSK based NBEMS system will make up for it's > lack of sophisticated modulation schemes via its accuracy and > simplicity. > > One observation to keep in mind...when I have used NBEMS and have been > receiving files via PSK31 ARQ , the received text in VBdigi (without > ARQ) is almost always as good as the ARQ PSK via FLARQ. Most of the > digital modes under average conditions will give you the ability to > send a highly accurate message. NBEMS, ALE 400 and RSFM offer the > "comfort" that it will be 100% accurate if the file transfer is > completed. Thus, in theory , if that emergency message you intercept > says "my latitude is 40.0446" and Olivia decodes it as 49.0046 , we > have a problem. The error correction in NBEMS and ALE400 will ensure > it is accurate. The dilemma: Under bad conditions you might get > perhaps 70% of a message in Olivia with several errors, while under > the same bad conditions you may only get 30% using PSK, ALE 400 or > RSFM (hypothetical numbers) and not enough to complete the file transfer. > > > >
