Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

Digital Radio Interface

  1. Oct 26, 2004 #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 web site at:

    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.
  2. jcsd
  3. Oct 30, 2004 #2
    Has anyone worked with these Renton Radio Modules in any context???
  4. Oct 30, 2004 #3


    User Avatar
    Science Advisor
    Homework Helper

    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.
  5. Oct 30, 2004 #4


    User Avatar
    Staff Emeritus
    Science Advisor
    Gold Member

    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.
  6. Nov 1, 2004 #5
    Just stopped in to 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 exhange 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.
  7. Nov 1, 2004 #6


    User Avatar
    Science Advisor
    Homework Helper

    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: Nov 1, 2004
Know someone interested in this topic? Share this thread via Reddit, Google+, Twitter, or Facebook

Have something to add?