Hi Rick, FYI, our tests last night indicate that MFSK16 still copies the best at low S/N, but only when there are no static crashes, but DEX16 or DEX11 have much fewer errors when there are static crashes. The problem with MFSK16, as you found, is the mistuning tolerance. For messaging, when there is a fast series of ARQ exchanges, if one station has uncompensated offset between RX and TX (NBEMS must work with untrained and inexperienced operators to be successful for emcomm), and if the offset exceeds 4 Hz, which is not so unusual, eventually it will not be possible to decode MFSK16, and therefore the ARQ requests or confirmations may be missed.
This is different from using MFSK16 in a QSO, because in a QSO, it is possible to retune with the mouse after each turnover if necessary, but not very practical in a series of fast ARQ exchanges. We were also testing "DSX", which is a variant of DEX, so you would not have been able to decode that. "DEX" is the name Murray, ZL1BPU, who is working with us to develop the best mode for NBEMS, and is the desiner of MFSK16 and DominoEX, suggested for the new mode, which is NOT compatible with the current DominoEx modes, but uses the same IFK technology so tuning is not critical and static crashes have minimal effect. When we switched to MFSK16, it was to compare very weak reception on one station where there were no static crashes at all. Whereas DEX11 and DEX16 outperformed MFSK16 under the high static conditions, MFSK16 was best when signals were the weakest and there was no static. For NBEMS, we have to compromise between weak signal performance, static crash performance, and transfer speed, and we are still trying to determine which mode to use as a default mode, because it is just not practical to present an untrained operator with a huge selection of different modes for different conditions and ask him, under the pressures of trying to get emergency messages out, to figure out which one to use! Of course, generally, the slower we go in speed, the more robust the mode for a given bandwidth, and there is always a point where a faster mode fails, but a slower one succeeds. In very adverse conditions, when messages tend to be short, such as, "We are safe in a shelter at the local school", or "The Red Cross has just arrived", any mode that will get the message out, no matter how slowly, is the one that must be used. Connection time tends to be much longer than the message transfer time. Two days ago, a line of severe thunderstorms passed us, and spawned a tornado which touched down about 15 air miles from here, and on 80m, I still have a static level of S9 +10 with strong static crashes almost every second - definitely very adverse conditions! Under these conditions, the new DEX modes are working the best, but at the same time, on 2 meters, there are only occassional weak static crashes, so whenever possible, using VHF is still the best band to use for up to 100 miles. Under these conditions, the PSK modes are quite adequate and also give the fastest transfer speeds. Which PSK speed to use is usually only dependent on the necessary S/N to overcome path loss. I am hoping that most EOC's will install point-to-point VHF circuits for their use rather than relying on 80m and 40m NVIS HF, which is prone to static interference and propagation changes, depending upon the time of day. The advantage to using a relatively narrowband mode on HF is that there is more room for more stations to take traffic simultaneously, which greatly shortens connection time, so the overall time from attempted connection to completion can be much less than having to wait in line to access a few wideband stations. Pactor-II is probably the most efficient ARQ mode developed so far, but it is easy to tell how often connections are not made by observing the number of times client stations come on and never connect, probably because of the small handful of reachable, or available, forwarding stations. I think overall, when we have done all we can to improve our new mode, that in a real emergency, when many stations need to pass traffic at the same time, the throughput of NBEMS will exceed that of other HF systems on the ham bands. We hope to release our latest new mode for beta testing in about two weeks and then everyone will have a chance to try it under all sorts of conditions. 73, Skip NBEMS Development Team
