Some 9600 baud packet radio theory:
There are a couple of things you need to look out for when attempting to use a radio for 9600 bps. First with AC vs DC coupling, you can get yourself into trouble both ways. With AC coupling, you have to make sure that the transient across the coupling capacitor(s) dies out before the preamble is done and the receive modem has locked up. If not as the coupling capacitors charge or discharge on transmitter turn on, you will be pulled off frequency. This is most often the reason that people have to use a wide band receive filter. The transmitter slops around due to the charging or discharging of the coupling caps. This occurs on both the receiver and transmitter side. It can cause weird stuff like the link working only in one direction.
If you use full DC coupling for both Tx and Rx, then you have to make sure that the DC levels are set and stable. Any DC level change and you will see this as a frequency offset. Any DC drift will show up as a frequency drift.
The proper solution is to put something along the lines of a DC restorer circuit in the Tx an Rx paths, or better yet throw away the Tx modulator and use and IQ modulator directly at RF or IF. For the receive a DC tracking and restore circuit works well. I know of no 9600 modems that do this in the amateur world. But I am dated for 9600. The only modem that was used in the amateur world that did that right was the WA4DSY 56K modem.
Another thing you should do is run a couple of 9600 radios back to back on the bench. With a good S/N you should get zero errors! If you get any, you have a problem in the system. With a good link with no multipath, your bit error ratio (BER) should be way better than 10e-06. That means if you do 100 pings of 1K packets, you should have no errors, that is approximately 10e06 bits sent. If you have any errors you are deluding yourself that things are working, they will not get better when you are on the air over a marginal link, only worse.
If you choose to use TCP/IP via AX.25 UI frames (standard stuff in NOS or Linux), if you don't have a BER better than 10e-06, your link will stall and die when you try to run any TCP services on it. TCP will will not see the ACK and retransmit, it will also back off it's transmission timer assuming that the link is congested. It has no knowledge of the radio link quality. TCP will continue to back off until the link essentially stalls. You either need a very good link or build a protocol around the radio link so that TCP doesn't do the retransmissions, the radio link protocol does.
Anyway, just my $0.02 worth.
Dennis, AC7FT.
If you use full DC coupling for both Tx and Rx, then you have to make sure that the DC levels are set and stable. Any DC level change and you will see this as a frequency offset. Any DC drift will show up as a frequency drift.
The proper solution is to put something along the lines of a DC restorer circuit in the Tx an Rx paths, or better yet throw away the Tx modulator and use and IQ modulator directly at RF or IF. For the receive a DC tracking and restore circuit works well. I know of no 9600 modems that do this in the amateur world. But I am dated for 9600. The only modem that was used in the amateur world that did that right was the WA4DSY 56K modem.
Another thing you should do is run a couple of 9600 radios back to back on the bench. With a good S/N you should get zero errors! If you get any, you have a problem in the system. With a good link with no multipath, your bit error ratio (BER) should be way better than 10e-06. That means if you do 100 pings of 1K packets, you should have no errors, that is approximately 10e06 bits sent. If you have any errors you are deluding yourself that things are working, they will not get better when you are on the air over a marginal link, only worse.
If you choose to use TCP/IP via AX.25 UI frames (standard stuff in NOS or Linux), if you don't have a BER better than 10e-06, your link will stall and die when you try to run any TCP services on it. TCP will will not see the ACK and retransmit, it will also back off it's transmission timer assuming that the link is congested. It has no knowledge of the radio link quality. TCP will continue to back off until the link essentially stalls. You either need a very good link or build a protocol around the radio link so that TCP doesn't do the retransmissions, the radio link protocol does.
Anyway, just my $0.02 worth.
Dennis, AC7FT.
