How Can I Improve the Reliability of My Low-Cost Digital Radio Interface?

Click For Summary
The discussion focuses on improving the reliability of a low-cost digital radio interface designed for robot communication. The user experiences instability at baud rates lower than 1200, often receiving complete garbage instead of partial messages, suggesting issues with radio modulation. Suggestions include increasing stop bits, implementing checksums, and using acknowledgment protocols to ensure message integrity. The user suspects that the AM modulation may not be suitable for the timing requirements of serial communication, prompting considerations for alternative modulation methods. Overall, the conversation highlights the need for better electronic circuit design and modulation techniques to enhance communication reliability.
NeutronStar
Messages
419
Reaction score
1
Hi, I'm trying to design a low-cost digital radio interface to communicate with a robot. I'm not interested in exchanging a lot of data, or doing it at high speeds. This design will work well if I can get even 300 baud out of it since I never exchange more than about 1K bytes during a conversation.

Although I've had fair success up to 1200 baud. Unfortunately the system doesn't seem to be real dependable and I'm wondering if anyone has any ideas of how I might change my simple circuit to make it more dependable.

I'm designing around the following low-cost receiver and transmitter modules:

Receiver: http://www.rentron.com/remote_control/RWS-434.htm
Transmitter: http://www.rentron.com/remote_control/TWS-434.htm

I have a schematic of my own simple circuit on my website at:
http://www.csonline.net/designer/

I'm using RS-232 serial connectors to connect a standard IBM type PC to my transceiver circuit. Then I have an identical transceiver circuit at the robot end which uses an 8051 Microcontroller.

So far the thing works but doesn't seem to be stable. I send repeated characters at the beginning of each message for sync. Like A5A5A5A5A5A5 and that seems to help but doesn't solve the problem completely. It seems to be an asynchronous timing problem. Once it's on track it seem to work fine. But often I just get garbage because it gets off by a bit or two at the beginning of the run it seems. I thought that the MAX232 chips would take care of all that timing. I use one at each end. Maybe I need some kind of buffers between the MAX232 chip and the I/O of the transmitter and receiver modules?

Any suggestions (whether hardware or software) would be welcome.

Thanks in advance for any responses.
 
Last edited by a moderator:
Engineering news on Phys.org
Has anyone worked with these Renton Radio Modules in any context?
 
Couple of thoughts.
Increase the stop bits.
Start each message with a particular character byte
Make each message a constant length or second byte is length.
Use a simple checksum (last message byte is sum of all other message bytes.)
Acknowledge valid message or request resend on error.

Serial is prone to the type of error you have.
So if it has to be correct you need some way to tell if it is or not.
 
Are you sending any parity bits? Those'll get rid of any single bit errors.

I don't think it's got much to do with your problem, but I had a problem with my code the first time I programmed a radio controlled car because I overloaded the serial port. I was trying to resend the same command over and over again to override any erronious 'stop' commands (00000001), and ended up sending new commands before the previous signal got sent through the serial.
 
Just stopped into thank everyone so far for replies.

I thought I'd also mention that the serial interface works just fine when connected up directly with a cable. I'm using Visual Basic on the PC, and a program that I wrote in machine language for the 8051. Although, just to test the radio interfact I currently just have to PCs talking to each other via the Visual Basic programs.

Like I say, if I connect the two computer together directly with a standard serial cable the communication is flawless and 100% dependable. It's only when I try to communicate via the radio link that I am having problems. So I don't think that the problem is related to stop bits, or software problems where the computers are out of sync. I think the problem is in the radio modulation of the serial bits.

Usually the communication either works, or it doesn't. In other words, when it works I get all of the characters perfectly. When it doesn't work I get complete garbarge. I never get only a partial communication. It's either all or nothing. I am sending actual words (short sentences of 5 to 10 words). I can see the communcation taking place on the computer screens as I have the Visual Basic programs print each character to the screen as they come in. Ironically it seems to work best around 1200 baud. Lower baud rates are actually worse. I thought they'd be better and I could easily get by with 300 baud if I had to but that doesn't help. The best performance right now is around 1200 baud.

When I use a hard-wire cable I can exchange information flawlessly at all baud rates. So this has to be a problem associated with the radio link. I've also tried using every combination of stop bits, and transmission modes. The hardwire cable works with everything. The radio link likes 12 baud, but it's still not perfectly dependable even at that rate.

I'm thinking that it all has something to do with the fact that the transmitter is AM modulated. Maybe the pulse widths of the serial COM aren't wide enough for good AM modulation? If that's the case is there anything I can do to better the situation?

I think this is going to turn out to be an electronic circuit design problem with my RF circuit and the Renton radio modules.
 
Never tried this on pure AM. No wonder you are having problems. The required timing is too critical.
Usually digital over radio is frequency shift keying (FM) with a pll to recover the data.
It can be done on AM by frequency modulating (say a 1kHz audio tone) and again using a pll to extract data (basically an old 1200 baud computer modem).
Or another way is to skip the com ports and scan the individual bits out triggering a tone generator like the old cassette recorder scheme(real slow but simple).

You might be able to use a modem. Hook the modem output to the transmitter. You need another modem on the reciever.
 
Last edited:
Thread 'I thought it was only Amazon that sold unsafe junk'
I grabbed an under cabinet LED light today at a big box store. Nothing special. 18 inches in length and made to plug several lights together. Here is a pic of the power cord: The drawing on the box led me to believe that it would accept a standard IEC cord which surprised me. But it's a variation of it. I didn't try it, but I would assume you could plug a standard IEC cord into this and have a double male cord AKA suicide cord. And to boot, it's likely going to reverse the hot and...

Similar threads

  • · Replies 2 ·
Replies
2
Views
2K
  • · Replies 10 ·
Replies
10
Views
4K
Replies
138
Views
26K
Replies
10
Views
4K
Replies
2
Views
3K
Replies
4
Views
3K
  • · Replies 7 ·
Replies
7
Views
3K
  • · Replies 11 ·
Replies
11
Views
4K
  • · Replies 3 ·
Replies
3
Views
4K
  • · Replies 13 ·
Replies
13
Views
5K