Re: [digitalradio] Signals on 3584 + audio
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
Re: [digitalradio] Signals on 3584 + audio
The problem with knowing where to tune any signal can be solved completely by use of RS ID (as in MultiPSK, PocketDigi etc). It amazes me we have had this technology for over a year now and very few people seem to realize the potential of this. Even with s/n ratios down around -15dB MultiPSK will successfully lock on to the center frequency of any mode and also switch to the correct mode/parameters. In the real world there is always going to be some mis-tuning and although the IFK modes have excellent tolerance in respect to this if someone is 500Hz away they aren't going to decode your transmission, especially if they can't see it on the waterfall. Sending an RS ID before will get them on frequency instantly. 73, Sholto KE7HPV.
Re: [digitalradio] Signals on 3584 + audio
At 08:49 AM 5/14/2008, kh6ty wrote: 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. Skip, One thing I have found is that when the sound card can be configured for a 12000 Hz sampling rate, the offsets are not present in most sound cards. It seems that when 11025 is used that the offsets are noticeable in many sound cards. I am not sure how an 8000 Hz sampling rate performs, but just thought I would mention this observation. 73, Mark N5RFX
Re: [digitalradio] Signals on 3584 + audio
Hi Mark, I think G3PLX recently mentioned the same thing, with regard to USB sound cards, as he found they have the biggest offset problems. However, in dealing with the masses, if we can find a way to nullify the offset's effect long enough to complete the ARQ transfer, it will work with anyone, and I think using DEX is the answer, but MFSK16 still appears to be the best mode when there is no static problem, and there is QSB taking the signal below the noise threshold. DominoEX can be mistuned up to 200 Hz and has a 200 Hz drift tolerance, without AFC, so that should take care of most situations. I know that DominoEx16 can be mistuned +/- 100 Hz and still keep printing, because I have tested that multiple times on our 2 meter net. BTW, that brings up another issue - drift tolderance. NBEMS has to deal with transceiver at 2 meters with no TCXO, and transceivers with a TCXO. The drift of the FT-897, for example, is about 50 Hz from start of transmit to about 5 seconds after, and with PSK63, I always lose the initial text from the station without a TCXO, but with DominoEx16, I never lose one character - same as the station with a TCXO, so we think we will replace PSK63 with DominoEX16 for our 2 meter net, after two more weeks of tests to see how it performs with multipath reflections. I'll include mention of the sample rate to use in the Help file. Thanks for the tip! 73, Skip KH6TY - Original Message - From: Mark Miller To: digitalradio@yahoogroups.com Sent: Wednesday, May 14, 2008 1:23 PM Subject: Re: [digitalradio] Signals on 3584 + audio At 08:49 AM 5/14/2008, kh6ty wrote: 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. Skip, One thing I have found is that when the sound card can be configured for a 12000 Hz sampling rate, the offsets are not present in most sound cards. It seems that when 11025 is used that the offsets are noticeable in many sound cards. I am not sure how an 8000 Hz sampling rate performs, but just thought I would mention this observation. 73, Mark N5RFX -- No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.16/1432 - Release Date: 5/14/2008 7:49 AM
Re: [digitalradio] Signals on 3584 + audio
That is interesting that they are going to name a new mode DEX that is similar to, but not the same as DominoEX. I liked using DEX as the acronym for DominoEX. But the creator gets to pick the names. I am very pleased that Murray is helping to develop a mode for NBEMS and I am sure many of us will be quite interested when this gets to the point that we can try it out. Same for DSX. We have got to make this simple to use and I hope that there will be more interest on digital modes for public service. Nothing much happening in our area and I do promote it as much as I can. Pactor 2 is the mode to beat since it is has so many good attributes for its bandwidth. It would be great to see some comparisons between P2 and the newer sound card modes. Thanks to all of you for so much work to develop these new modes. 73, Rick, KV9U kh6ty wrote: 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
Re: [digitalradio] Signals on 3584 + audio
You know what? I have not used RS ID much as of late and it never even entered my mind to use this last night. But then again, both stations need to use Multipsk for that to work. Are any other programs going to be adding the technology? 73, Rick, KV9U Sholto Fisher wrote: The problem with knowing where to tune any signal can be solved completely by use of RS ID (as in MultiPSK, PocketDigi etc). It amazes me we have had this technology for over a year now and very few people seem to realize the potential of this. Even with s/n ratios down around -15dB MultiPSK will successfully lock on to the center frequency of any mode and also switch to the correct mode/parameters. In the real world there is always going to be some mis-tuning and although the IFK modes have excellent tolerance in respect to this if someone is 500Hz away they aren't going to decode your transmission, especially if they can't see it on the waterfall. Sending an RS ID before will get them on frequency instantly. 73, Sholto KE7HPV.
