File transfer protocol for Radio Links

Feb 17, 2005 12 Replies

What is the most suitable file transfer protocol when using HF,VHF radio link with a digital modem.



I tried the Zmodem with crash recovery in MS Hyper Terminal to transfer relatively small files but the transmission fails at the first bad packet



But I should restart the transfer every time



I think that Zmodem is a full duplex protocol and digital radio modems operates on a half duplex manner



So Zmodem times out waiting ....



Any advice or suggestion is welcomed



Essam Salah


Over on avrfreaks, the opinion is that rs232 style NRZ encoding has a DC bias/average DC level per character that messes up the receiver threshhold detector. They claim that manchester encoding has a zero dc level, so long runs of 000 or FFF dont confuse the receiver.

On 17 Feb 2005 02:01:59 -0800, snipped-for-privacy@gmail.com wroth:

You don't have to restart the whole transfer for a single failed packet. Make up your own protocol. Divide the file up into packets that aren't too long. Add a message number and a packet number to the front of the packet and calculate a checksum for each packet and send that at the end. Wait for the receiving end to acknowledge each packet. If the packet gets corrupted, then the receiving end sends a nak or negative acknowledge. If you don't get anything back or if you get a nak, then you re-send the packet until it gets through.

Jim

Try Kermit...

formatting link

You could try PPP and run any flavour of Internet protocol over it. They all do checksums and sequence numbers and TCP based ones (FTP,HTTP,etc) handle lost packets.

I'm not using MS Windows myself, but I believe somewhere among the internet stuff you have everything you need to set up a computer-to-computer PPP link. If not, you can most definitely download some PPP software for free.

Kind regards,

Iwo

For a (noisy) radio link, it might help to reduce the MTU to perhaps a few hundred bytes. Normally, this would hurt throughput, as more packets are needed to send the same information. But when the BER gets bad (say, 1e-3), the shorter packets will have a much better chance of getting through than the regular 1500 byte packets.

Regards, Allan

You may also think of Forward Error Correction. With an error correction code (ECC), you can correct a number of bit errors, depending on the code. Look for keywords like Reed-Solomon, BCH, Turbo codes

It makes the packets larger, but saves you retransmission of a whole packet if only a few bits are corrupted.

One step further is to use to use an ECC over the datablocks, and then send a few bits of each datablock in one transmission block , also with ECC. Even if a whole transmission block it lost, it will only affect a few bits in each datablock, which then can be corrected. This process is called interleaving and I have seen it in some military radios.

To increase efficiency of Ack/Nack protocols like ?modem or Kermit, look at the windowed versions. I suppose there will be a lot of literature covering an optimimum combination of packet size and window length for a given error rate.

Wim

None of the protocols for 'wire line' file transfers will -- typically -- work well over radio links. Of course, if you're close enough and have a really good signal, you can use whatever protocol you want and you'll be fine, but as a rule of thumb most on-air protocols are designed with the expectation of raw bit error rates in the ballpark of ONE IN ONE HUNDRED. This is orders of magnitude worse than what wired proocols expect; realistically you're either going to have to resign yourself to very short distance links or find a protocol aimed at on-air applications. The amateur radio guys have a wide number to choose from (e.g., Pactor, Olivia, etc. -- avoid the older stuff like RTTY, it gives up tremendous amounts of speed because it doesn't use error correction).

Although nowhere near as complex as some cell phone protocols (where carriers are trying to jam as many possible channels into the spectrum they paid literally millions of dollars for), even the amateur radio protocols are a lot more sophisticated that Kermit, X/Y/Z-Modem, etc.

---Joel Kolstad

Hi,

Thats the crux of the matter. The best you can do with one-way communication is to attach checksums to to blocks of data and at least know when you receive a bad one. Anything more gets real complicated.

Luhan Monat (luhanis 'at' yahoo 'dot' com) "The future is not what it used to be..." http://members.cox.net/berniekm

Track down what they used on AlohaNet in the early seventies in Hawaii. First packet radio.

A few years later, one of the people connected with it, or maybe it was just influenced, I forget, had a position with the DOC here in Canada, and decided packet radio was what amateur radio needed. Hence the first display of amateur packet radio here in Montreal back in May of 1978.

So look up amateur packet radio. It's been around all these years.

Michael

Why not send every byte 3 times and take the one that gets received 2 or 3 times? Of course, that doesnt give much of a clue of what to do if you send 3 bytes and get 3 different received bytes.... maybe send 3 bytes with parity? Yeah... that might work.... 200% overhead, but reliable.....

Better to send the entire message three times. Radio interference tends to come in bursts which would wipe out several bytes in a row.

Or stir the bits before sending. All ECC methods must be tailored for the expected failure modes.

Keith

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required