File transfer protocol for Radio Links

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

Reply to
esamsalah
Loading thread data ...

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.

Reply to
BobG

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

Reply to
James Meyer

Try Kermit...

formatting link

Reply to
John Smith

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

Reply to
Iwo Mergler

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

Reply to
Allan Herriman

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

Reply to
Wim Ton

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

Reply to
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
Reply to
Luhan Monat

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

Reply to
Michael Black

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.....

Reply to
BobG

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

Reply to
Guy Macon

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

--
  Keith
Reply to
keith

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.