2400 Baud FFSK
Posted: Sat Oct 22, 2011 9:12 am
For some time now I've been meaning to test the sending of GPS data at the alternative speed available to Simoco radios. As well as data at 1200 baud, they can also send and receive at 2400 baud which sounds like a good thing but proved trickier than I expected.
The programming operations needed to achieve the switch are change 1200 to 2400 in the programming software. Easy you might think but unfortunately it doesn't quite work. Although data can be sent and received by making only this change, the operating range is very much shorter than when using 1200 baud. The residual data noise heard through the speaker before the radio decides it's receiving data and so needs to mute the audio, is reduced to a tiny chirp, almost a click. The reduction in noise is disproportionate to the fact that the transmission rate has only been doubled. This alone made it worth pursuing.
As I've already spent many many hours fiddling with the various settings that are user programmable in Simoco radios, I was fairly certain that the lack of range issue was down to timings or one of the other settings I can adjust. In fact this turned out to be the case and it was possible by changing some of the settings associated with the Lead In Delay (LID) to increase the operating range of the system when using 2400 baud. In theory, the effective transmitted range of FFSK data is slightly less than that of a normal voice transmission. This is largely down to the fact that the human ear deciphering the spoken word is infinitely more efficient than a computer trying to decode data sent via a radio link. However in practice, we've never noticed any difference in the ranges of the two modes. If you can hear them at all then both voice and data appear to be received at all operational ranges once the timing settings are correct.
In the case of 2400 baud however, this definitely wasn't the case. The range achieved with a voice signal doesn't change of course but the data range dropped off very noticeably. The initial testing was from my own vehicle directly back to home as I drove around the Kendal area. The testing wasn't carried out on UKSAR channels as no other team base would have made any sense out of data at 2400. It does work but the rejected data packet count markedly increases and far more GPS position reports fail than when using 1200 baud. This has to be taken in context as the American Navsat system isn't itself faultless and on quite frequent occasions it does give position reports that are complete rubbish or send unintelligible data. Even taking this into account, the performance at 2400 baud was demonstrably not as good as at 1200.
Finally I tested the system through a variety of repeaters ranging from simple cross-connected vehicle radios to the excellent Simoco TSF2025 which is a full blown commercial repeater. Very briefly, even the local amateur radio repeater was used as these are usually fairly well set up. The results were the same but somewhat more pronounced, range dropped off markedly as far as the GPS data was concerned and it was possible to clearly hear that the data wasn't being recognised by the receiving radio correctly. Even extracting the GPS data at the repeater itself didn't help the problem and the final conclusion I came to was that, easily at least, the use of 2400 baud for GPS data transmission isn't practical for us. The fact that it works, is accepted but the degree of settings adjustment that appears to be required looked like taking longer than I have left on this earth. Unfortunately there are no guidelines for doing this beyond those given to set up a system on 1200 baud so I may have been in error in following the same route using the higher baud rate but I don't think so.
Bottom line is that although as far as FFSK noise reduction goes when data is sent on a voice channel, there is an obvious advantage in using the 2400 baud rate, the difficulties encountered in setting it up outweighed these advantages making it a less than attractive proposition for most of us. It probably can be done but it wouldn't be anywhere near as simple to set up for all users as is 1200 baud.
The programming operations needed to achieve the switch are change 1200 to 2400 in the programming software. Easy you might think but unfortunately it doesn't quite work. Although data can be sent and received by making only this change, the operating range is very much shorter than when using 1200 baud. The residual data noise heard through the speaker before the radio decides it's receiving data and so needs to mute the audio, is reduced to a tiny chirp, almost a click. The reduction in noise is disproportionate to the fact that the transmission rate has only been doubled. This alone made it worth pursuing.
As I've already spent many many hours fiddling with the various settings that are user programmable in Simoco radios, I was fairly certain that the lack of range issue was down to timings or one of the other settings I can adjust. In fact this turned out to be the case and it was possible by changing some of the settings associated with the Lead In Delay (LID) to increase the operating range of the system when using 2400 baud. In theory, the effective transmitted range of FFSK data is slightly less than that of a normal voice transmission. This is largely down to the fact that the human ear deciphering the spoken word is infinitely more efficient than a computer trying to decode data sent via a radio link. However in practice, we've never noticed any difference in the ranges of the two modes. If you can hear them at all then both voice and data appear to be received at all operational ranges once the timing settings are correct.
In the case of 2400 baud however, this definitely wasn't the case. The range achieved with a voice signal doesn't change of course but the data range dropped off very noticeably. The initial testing was from my own vehicle directly back to home as I drove around the Kendal area. The testing wasn't carried out on UKSAR channels as no other team base would have made any sense out of data at 2400. It does work but the rejected data packet count markedly increases and far more GPS position reports fail than when using 1200 baud. This has to be taken in context as the American Navsat system isn't itself faultless and on quite frequent occasions it does give position reports that are complete rubbish or send unintelligible data. Even taking this into account, the performance at 2400 baud was demonstrably not as good as at 1200.
Finally I tested the system through a variety of repeaters ranging from simple cross-connected vehicle radios to the excellent Simoco TSF2025 which is a full blown commercial repeater. Very briefly, even the local amateur radio repeater was used as these are usually fairly well set up. The results were the same but somewhat more pronounced, range dropped off markedly as far as the GPS data was concerned and it was possible to clearly hear that the data wasn't being recognised by the receiving radio correctly. Even extracting the GPS data at the repeater itself didn't help the problem and the final conclusion I came to was that, easily at least, the use of 2400 baud for GPS data transmission isn't practical for us. The fact that it works, is accepted but the degree of settings adjustment that appears to be required looked like taking longer than I have left on this earth. Unfortunately there are no guidelines for doing this beyond those given to set up a system on 1200 baud so I may have been in error in following the same route using the higher baud rate but I don't think so.
Bottom line is that although as far as FFSK noise reduction goes when data is sent on a voice channel, there is an obvious advantage in using the 2400 baud rate, the difficulties encountered in setting it up outweighed these advantages making it a less than attractive proposition for most of us. It probably can be done but it wouldn't be anywhere near as simple to set up for all users as is 1200 baud.