Shop OBEX P1 Docs P2 Docs Learn Events
I wonder is there any simple code to illustrate 2ways communication feature of 433MHz — Parallax Forums

I wonder is there any simple code to illustrate 2ways communication feature of 433MHz

NarinNarin Posts: 7
edited 2010-12-01 16:42 in Robotics
I wonder is there any simple code to illustrate 2ways communication feature of 433MHz RF Transceiver besides the given sample code from Parallax
(433Radio2WayRX-V1.2 and 433Radio2WayTX-V1.2).

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2010-11-30 11:07
    The sample code is provided on the webstore page for the product via links near the bottom of the page. Whatever's there is what's available although other products may have sample code in the various tutorials as well.

    What are you looking for that is not illustrated in the existing sample code? What are you trying to do with the wireless transceivers?

    I believe the CRC examples on the webstore page use bidirectional signalling, but I could be wrong.
  • NarinNarin Posts: 7
    edited 2010-11-30 12:29
    Hi Mike,

    I have two devices: Transmitter (Joystick) and Receiver (Boe-Bot). Each device has one BS2 and one 433MHz Transceiver.

    The transmitter (Joystick) controls the movements of the receiver (Boe-Bot). While that happens, at the receiver end (Boe-Bot), I have also built an IR object detector such that it gives a 1 (no object detected) or a 0 (object detected). Then, I would like to send this 1 or 0 to the Transmitter (Joystick). Basically, I would to have a 2-ways communications between Joystick and Boe-Bot.

    *Joystick - transmitting and receiving
    *Boe-Bot - receiving and transmitting.
  • Mike GreenMike Green Posts: 23,101
    edited 2010-11-30 13:12
    You will need to designate one end or the other as the "master". The master always sends first, then waits for a response from the "slave". Say the BoeBot is the master. It will first do the sync pulse needed, then send a character indicating whether there's an object detected ("D") or not ("N"). The PC or whatever is controlling the joystick would start by listening for a "D" or "N" from the BoeBot. Once it receives that, it would send a character or several characters indicating the joystick position(s). You didn't say what kind of joystick or what kind of data is produced by it. For redundancy, the PC should send the joystick data twice. The BoeBot would wait for this (with a timeout on the SERIN statement to help catch errors), compare the two copies and ignore the data if it's not the same both times. Use the sample code as your framework.

    After the BoeBot sends its data it would reverse the direction (transmit / receive). The PC end would do the same (receive / transmit) and, when it switches to transmit, would have to put out its own sync pulse as described in the Transceiver documentation.

    If you don't want to use a PC on the joystick end, you'll have to have some kind of microcontroller like another Stamp on the joystick end.
  • NarinNarin Posts: 7
    edited 2010-11-30 19:28
    This is a test code that I have so far. It seems like the IR sending a 1 or 0 to the transmitter side, but it's not stable.

    Transmitter Side:
    ' {$STAMP BS2}
    ' {$PBASIC 2.5}
    '
    [ I/O Definitions ]

    TxEnable PIN 14 ' Transmitter(27982)TR pin
    Tx PIN 15 ' Transmitter(27982)DATA pin
    Yaxispin PIN 7

    '
    [ Constants ]


    T9600 CON 84
    Inverted CON $4000 'Value for inverted serial format
    Baud CON T9600+Inverted '9600 baud, 8,N,1 inverted

    '
    [ Variables ]

    rcYtime VAR Word
    irDetectLeft VAR Bit
    irDetectRight VAR Bit



    LOW Tx 'Initialize transceiver interface
    LOW TxEnable 'Disable transmitter

    Main:
    DO
    HIGH Yaxispin
    PAUSE 2
    RCTIME Yaxispin,1,rcYtime
    StartTransmitting:
    HIGH TxEnable 'Enable transmitter
    PULSOUT Tx,1200 'Send sync pulse to radio
    SEROUT Tx, Baud, ["UUUU!", rcYtime.LOWBYTE, rcYtime.HIGHBYTE]
    LOW TxEnable 'Disable transmitter

    GetIRResponse:
    SERIN Tx,Baud,600,StartTransmitting,[irDetectLeft,irDetectRight]
    DEBUG CRSRXY, 2, 3, BIN1 irDetectLeft,
    CRSRXY, 9, 3, BIN1 irDetectRight 'See the value stored in irDetectLeft and irDetectRight
    LOOP 'Start at the beginning


    Receiver (Boe-Bot):
    ' {$STAMP BS2}
    ' {$PBASIC 2.5}

    '
    [ I/O Definitions ]

    TxEnable PIN 14 ' Transmitter(27982)TR pin
    Tx PIN 15 ' Transmitter(27982)DATA pin


    '
    [ Constants ]


    T9600 CON 84
    Inverted CON $4000 'Value for inverted serial format
    Baud CON T9600+Inverted '9600 baud, 8,N,1 inverted

    '
    [ Variables ]
    rcYtime VAR Word
    rcXtime VAR Word
    irDetectLeft VAR Bit
    irDetectRight VAR Bit
    '
    [ EEPROM Data ]


    '
    [ Initialization ]


    '
    [ Program Code ]

    Main:
    LOW Tx
    LOW TxEnable
    DO
    ' Wait for preamble, then receive data and crc value
    SERIN Tx,Baud,[WAIT ("U!"),rcYtime.LOWBYTE, rcYtime.HIGHBYTE]

    DEBUG HOME, "RCxtime = ", DEC5 rcXtime, CLREOL, CR,
    "RCytime = ", DEC5 rcYtime, CLREOL
    '===================================================

    FREQOUT 10, 1, 38500
    irDetectLeft = IN11
    FREQOUT 8, 1, 38500
    irDetectRight = IN9

    DEBUG CRSRXY, 2, 3, BIN1 irDetectLeft,
    CRSRXY, 9, 3, BIN1 irDetectRight
    '=================================================


    IF (irDetectLeft=0 OR irDetectRight=0) THEN
    HIGH 1
    HIGH 0
    HIGH TxEnable
    PULSOUT Tx,1200
    SEROUT Tx, Baud, ["!"]
    SEROUT Tx, Baud, [irDetectLeft,irDetectRight]
    PAUSE 2
    LOW TxEnable
    ELSE
    LOW 1
    LOW 0
    ENDIF
    LOOP
  • Mike GreenMike Green Posts: 23,101
    edited 2010-12-01 16:42
    Simple transceivers like the ones you have are not very reliable in terms of data transfer. That's why a CRC or other error checking is often used. With the Stamps, you also have the issue of timing. When a Stamp is not executing a SERIN statement, it's not receiving serial data. If one Stamp starts to transmit data and the other Stamp is doing something other than listening, the data will be ignored. Sometimes the receiving Stamp will misinterpret the data and start receiving incorrect data in the middle of a transmitted byte and not get back in sync until the next transmit attempt. For best results, transmit slowly (less than 9600 Baud) and use error detection and retries. Alternatively, use a device like an xBee or Bluetooth transceiver that takes care of error detection and correction for you.
Sign In or Register to comment.