HELP communication between 2 arduinos with Parallax 27982 transceivers

Projects General Guidance
1

Hello forum!

I'm scratching my head trying to finish my senior project. I'm trying to program a robot controlled by 2 arduino UNO's with Parallax 27982 433 Mhz transcievers, one on the controller and the other on the robot. I have programmed everything up to the RF point. It was recommended to use the "Virtual Wire" for the use of these transcievers but not sure if this is true. There is feedback too so i will be using Bi-directional communication. Wondering if anyone has experience that could be of help....

http://www.parallax.com/Portals/0/Downloads/docs/prod/rf/27982-433MHzRFTransceiver-v1.1.pdf

the issue i'm having is that the 27982's only have 1 "data" pin... whereas the arduinos have seperate TX and RX

I understand that i need to set one side start in RX and the other to Tx. How to I switch between states, say if feedback occured on the robot that would need to be sent to the controller?

-NissanTracker

2

You might (and I stress that it is only might) be able to use NewSoftSerial() with the same pin number for send and receive. Try it and see what happens.

3

I think that if you put a resistor (1k?) between the Transmit pin an the radio you can then hook the Receive pin directly to the radio. That should allow the Transmit pin to send when the radio is set to send and the Receive pin to receive the data when the radio is set to receive.

You will have to implement your own protocol to tell the remote radio when to send data. Expect some random garbage characters whenever you switch directions. You will need some kind of frame around the data so you can tell it from garbage and error detection to filter out glitches.

Good luck!

4

johnwasser:
You will have to implement your own protocol to tell the remote radio when to send data. Expect some random garbage characters whenever you switch directions. You will need some kind of frame around the data so you can tell it from garbage and error detection to filter out glitches.

Good luck!

I would assume that the protocol would be implemented in the "virtual Wire" or "NewSoftSerial" libraries... is that true?

-NissanTracker

5

I would assume that the protocol would be implemented in the "virtual Wire" or "NewSoftSerial" libraries... is that true?

The virtual wire or NewSoftSerial instances manage sending the data. What to send is defined by the protocol. So, no the protocol is independent of the means for getting the bits from point A to point B.

6

PaulS:

I would assume that the protocol would be implemented in the "virtual Wire" or "NewSoftSerial" libraries... is that true?

The virtual wire or NewSoftSerial instances manage sending the data. What to send is defined by the protocol. So, no the protocol is independent of the means for getting the bits from point A to point B.

So the libraries only provide a means of tranmitting and receiving... but I would still need to provide the means for detecting errors and grabbing the correct byte stream?

-NissanTracker

7

but I would still need to provide the means for detecting errors and grabbing the correct byte stream?

By, jove! I think you've got it!

8

So i have them working with one end always in TX and the other always in RX. The tricky part comes when i need to have a feedback signal from one MPU get sent over to the other MPU.... The problem now is how do i switch modes so the feedback signal gets over.... if the parallax is half duplex?

So far i've put both of them in Rx mode... tagged it as "listening". The parallax running one arduino will go into TX when ever a single button is pressed. Then goes back into Rx. Thats fine and dandy... but i'm sensing a "sync" problem.... should i be using some sort of delays, sync-sync-ack signals?

-NissanTracker

9

I'm sure that half-duplex communication has been done before. Perhaps you should look for historical implementations and emulate one of them.

10

I just got a pair of the 27982's myself, with the idea of communicating between a Arduino Duemilinove on the robot, and another Duimilinove with the laptop.

The thing should be possible, as you're able to change input/output states on single digital pins, example using the Parallax PING))), since the digital signal is fed to a single pin, then I/O state changed to receive the return blip.

The 433Mhz transceivers also have two other pins, which would aid in the 'Traffic cop' modes. RSSI, which is essentially your "Incoming Signal" alert, which could be used as an interrupt, and the RX/TX pin which is your PTT (Push To Talk), to send the data.

Mind you, these radios were designed around the Parallax Basic Stamp MCU's, which, I already got my tail feather singed for daring to say in the parallax forums, the PIC on the stamp wasn't running PBASIC specific (It still isn't running native, in my opinion. The Host system (PC, MAC, etc.) is a compiler, sending machine code to the device. But, I got corrected, it runs an interpreter..) Yet, any pin can be assigned digital, serial or analog. (which, I'm sorry to say becomes a limit to the Arduino, assigning specific pins specific tasks, when all pins should be variable. But, running I2C tasks through the analog pins should be a example that it can be done!)

A re-work of the softserial, would be to monitor the interrupt (the RSSI pin) for a signal. If it detects something, go into "Receive" mode, and wait a period before timing out. (I hooked one up, as a standard radio receiver, outputting the data pin through a capacitor, to a piezo speaker, there is quite a lot of RFI noise! Most of it is random analog according to a DSO-Nano O-scope.) and a LED to the RSSI pin.. it does pick up a lot of stray RFI! My Laptop's LCD screen is a major source!) If data is ready to be sent, and there is no signal detected, the RX/TX pin is toggled, the data pin is held high for a few ms, (same as push to talk, wait a second, THEN speak, so everything gets through.) then send the data in a packet like ZModem or Xmodem (good-grief! Did I just date myself in the computer world?) toggle the RX/TX pin, and wait for a response from the receiver. (acknowledge receipt, or request to resend.)