Serial wireless transceiver

[aaronik19]

Dear all,

At the moment i am making a project concerning wireless transceiver and i am using the serial connection HC-11 and i am really happy with the performance. The only issue i have is that if the network is busy, it will not try to resend the message again, and it will lead to miscommunication. Is this a hardware specification, or i need to take care of it in the software?

I was thinking of something acknowledgement system from the receiver??

[newguy]

That's 100% software and up to you. If you want to ensure that each message gets through 100% of the time, you definitely need a return channel so that the intended receiver can ACK each message successfully received. If the transmitter doesn't receive an ACK within a reasonable period of time, then it should automatically retransmit the last message.

[aaronik19]

Thanks for your reply. What do you mean by channel? A physical channel? For example my module can be set from channel 0 up to 127.

[Ttelmah]

No.

The 'connection' is a channel. In this case it is carried over a radio channel, but that is immaterial. He is referring to having the ability to transfer data in the opposite direction, which inherently requires a second link of some form.

This could be on the same radio channel, and 'time multiplexed' (so one radio transmits, then another), or using a separate radio channel.

At the end of the day, you have to decide on the nature of likely failures, the costs involved in re-transmission, and how your system is going to cope.

So (for instance), the 'picture' links from spacecraft like Voyager, are designed to 'get through', even if a lot of data is lost. So you transmit the data, plus a lot of error correcting information, and break the packet layout up, so that whole packets can be lost, and yet you can still reconstruct useful data. This is done, because for these craft, the time needed for any sort of reply is greater than the ability of the craft to actually store the data, so no request for re-transmission can be done.

More generally, where the reply time is a lot shorter, but still significant, you instead mark the packets, with sequential numbers, and then if one is lost, you can request for this one to be retransmitted. This is how things like TCP/IP handle the data. This is done so that instead of having to acknowledge every packet in turn, the other end of the link can just request ones that are damaged/missing.

For a simpler link, sending smaller amounts of data, you can simply reply with an 'acknowledge', and have the sending device automatically send again, if this is not received.

There are literally dozens of variants of approach, and how much data has to be lost before re-sending is required.

Now one comment seems to apply. You talk about losing data if the connection is 'busy'. Typical solutions to this are things like always testing the network before sending, and also monitoring what is actually sent (if there is radio interference, the transmitter if it also has a receiver, will see this as well), which allows at least a knowledge of a 'likely good' transmission, without needing a reply.

It is possible to buy radio systems that will automatically error check, correct, and re-transmit as needed, but these are _expensive_. Hence you are probably going to have to design your own system.

[aaronik19]

Hi friends thanks for your reply. At the moment i am very enjoying the wireless network that i am creating this is my first experience. I came up with an idea and i would like your comments to see if it is good or not. Can i use rs485 and then interface to wireless module? I came up with this idea to let rs485 to take care of acknowledgment. What do you think?