I appreciate the further information from both Ralph, ZL1TBG and John, VE5MU.
PSK125 would not be a very robust mode compared with most other digital modes, due to the high baud rate and no FEC. It seems from John's comments that although 141A is not quite as fast, it is more robust than RFSM2400. I do not consider 141A to be all that robust and at -4 dB S/N the sensitivity is not competitive with slower baud rate modes from my testing experience. 141A would just stop operating with no throughput when other modes, particularly MFSK16 and DominoEX11/FEC (or slower) would keep working through low band QRN. 141A is amazingly similar in "feel" to working with Clover II from more than a decade ago and the ability to have quasi duplex operation. The one problem with 141A, wide Olivia, and RFSM2400 is the extreme bandwidth needed. The curious thing is that we have fairly sensitive and robust modes that are at, or even well under, 500 Hz in width, that are not possible to scale with greatly increased speed when they are broadened. I don't understand the technical reason for that, but have observed this with many of the narrow modes. If we get such good speed to bandwidth ratios from a narrow FEC type like MFSK16 or DEX/FEC couldn't there be multiple streams to get the faster speeds with the greater bandwidth? And still keep the sensitivity? The computers many of us have are fairly powerful DSP boxes. They have to be in order to run MS Vista. HI HI. If we can have a mode such as PSK63F that has Viterbi coding, a baud rate of ~63 and a bandwidth of ~140 Hz, with a character speed of 42 wpm, why could not this be scaled up say, 10 times, with multiple tones to 2000 Hz (with some guard bands?) and then you might expect speeds of 4000 wpm? OK, this might be more processing than we now have available but couldn't it be at least doubled or quadrupled? Same thing using other modulation schemes and coding or FEC such as DEX and MFSK. 73, Rick, KV9U zl1tbg wrote: > Rick, > > Performance compared to other modes: > > In terms of throughput on low power (5 watts) NVIS path tested on > 80M and 5MHz, > > RFSM2400 (nonstandard, 2.7 KHz) was faster than PSK125 and allways > completed the session. PSK63 was difficult due to tight frequency > tolerance (despite commercial spec. gear). The 3KHz hamDrm (50 watts) > was not reliable. I have not tried WSJT modes, undoubtedley they > will get through noisy bands better but will they deliver the speed? > This will allways be a compromise, the most adaptable mode will win. > > In terms of functionality of the protocols: > > RFSM2400 by far the simplest to set up and operate. > It does support com port ptt control, Also would probably work VOX > radios ok. The project I'm working on requires robustness and > automatic recovery for power loss etc. at the server, minimum > throughput around whats achievable now (PSK125 rates) and no > proprietary hardware to buy. That cuts Pactor3 out of the choices. > > My tests with PSKmail have slowed somewhat with the changeover to > fldigi and the extra bells & whistles that have prevented me getting > a stable reliable distro to run. We have had successful sessions but > the difficulty of monitoring the status of the connection is a > factor that makes it less suitable for the role. It does what its > designed for well, and I'd use it if I had an RV (assuming I can't > get RFSM2400 to provide the same functions). Using a linux PC is no > problem, I just got a small HD and swapped out the existing HD. I > have not been able to set it up to completely autostart and operate, > though, which RFSM2400 does. I also use an autoanswer SKYPE on the > same PC, for remote radio monitoring, and that co-exists with the > same soundcard as RFSM2400 without problems. > > Ralph > > > Comments from John, VE5MU: > "We have tried RFSM 2400 and it is in our opinion not quite as robust as 141A, which at the same time is not quite as fast as RFSM 2400. Bit of a compromise I think. Both seem better than PSK63, and both are ARQ modes so that the message does get through eventually despite rotten conditions." >
