433 RF Transceiver Module Help

ccreinhart · 2012-04-07 22:00

I am using the Transceiver RX.spin, Transceiver TX.spin, RF_Transceiver.spin, and CRC_polynomial_oneshot.spin posted by Beau Schwabe and it "appears" to be working (it transmits and receives messages and prints them on the PST) but...

When I modify the TX to change values sent each time through the loop as thus
RF.Initialize(PacketLength)
data := 0
repeat

if (data//2 == 0)
outa[0] := 1
outa[1] := 0
repeat msg from 0 to PacketLength - 1
RF.PutTX(msg,PacketLength - msg)
RF.Send
else
outa[0] := 0
outa[1] := 1
repeat msg from 0 to PacketLength - 1
RF.PutTX(msg, msg)
RF.Send
data := data + 1

either 1) it does not actually change the transmitted data or 2) the RX (which has not been changed from what was posted) only receives the first message. That is, it appears that the PutTX method call does not change the TX buffer. I've tried adding waitcnt() calls in various spots thinking maybe the TX was too fast for the RX but it is consistent, nothing changes. I've also played around in the RF_Transceiver object (removed double buffering, removed CRC calculation, and a few other things) but to no avail.

Any help would be greatly appreciated.

Craig

Beau Schwabe · 2012-04-07 22:35

Post your entire code as an attachment. Also the indents are lost if you don't use the [code][ /CODE] qualifier.

ccreinhart · 2012-04-08 18:01

Files are attached. TX/RX are both on pin 24 (two separate boards), Mode select is on pin 25.
If the variable select (in TX) is set to 0 (without toggling) it always transmits/receives 10..1.
If select is set to 1 (without toggling) it always transmits/receives 0..9. Putting in the code to
toggle select each time through the loop transmits/receives 10..1 when select is initialized to 0.
When select is initialized to 1 with the toggle in place the transmit/receive is 0..9

I have every reason to believe that the toggle is taking place in the TX code. I've tried placing
the RF.Initialize(PacketLength) call inside the loop (prior to each transmit), have tried various
waitcnt() statements, multiple RF.Send calls, etc. to no avail.

Thanks (in advance) for any insight you can provide.

Craig

Beau Schwabe · 2012-04-08 22:41

I'm not sure I follow...

The code below is just a simple debug, and the behavior you describe based on the code you have is correct.
The only other thing that I can think of, is that the double buffering nature of the received packets might cause an issue. Try sending twice. i.e in the Transmitter where you have RF.Send, just enter that line twice.

CON

  _CLKMODE = XTAL1 + PLL16X
  _XINFREQ = 5_000_000

  PacketLength  = 10             'Total Number of data BYTES


OBJ

DEBUG   :       "FullDuplexSerial.Spin"

                                                                       
PUB TX_Main | msg, select

    DEBUG.start(31, 30, 0, 38400)                       '' Initialize serial COMM to PC

    select := 0
    
    repeat
      if (select == 0)
        repeat msg from 0 to PacketLength - 1
            DEBUG.dec (PacketLength - msg)
            DEBUG.str(string("-"))
        select := 1
        DEBUG.tx(13)
      else
        repeat msg from 0 to PacketLength - 1
            DEBUG.dec (msg)
            DEBUG.str(string("-"))
        select := 0
        DEBUG.tx(13)

ccreinhart · 2012-04-09 08:44

When you say "behavior you describe based on the code you have is correct" what exactly do you mean by "correct"? Are you saying that is
1) what the code is supposed to be doing or 2) you have been able to recreate the incorrect behavior of the code. I suspect the later since you have
also provided a suggestion which I will try next. I too suspected the double buffering issue and actually disabled it in the RF_Transceiver object
(at least I think I did) but did not try the double send.

Also, could this have something to do with the CRC calculation maybe going to an incorrect buffer? I tried removing that calculation but not sure
if I got it completely removed.

Beau Schwabe (Parallax) wrote: »
I'm not sure I follow...

The code below is just a simple debug, and the behavior you describe based on the code you have is correct.
The only other thing that I can think of, is that the double buffering nature of the received packets might cause an issue. Try sending twice. i.e in the Transmitter where you have RF.Send, just enter that line twice.
CON

  _CLKMODE = XTAL1 + PLL16X
  _XINFREQ = 5_000_000

  PacketLength  = 10             'Total Number of data BYTES


OBJ

DEBUG   :       "FullDuplexSerial.Spin"

                                                                       
PUB TX_Main | msg, select

    DEBUG.start(31, 30, 0, 38400)                       '' Initialize serial COMM to PC

    select := 0
    
    repeat
      if (select == 0)
        repeat msg from 0 to PacketLength - 1
            DEBUG.dec (PacketLength - msg)
            DEBUG.str(string("-"))
        select := 1
        DEBUG.tx(13)
      else
        repeat msg from 0 to PacketLength - 1
            DEBUG.dec (msg)
            DEBUG.str(string("-"))
        select := 0
        DEBUG.tx(13)

ccreinhart · 2012-04-09 08:54

Please see code posted above.

Beau Schwabe · 2012-04-09 09:04

"When you say "behavior you describe based on the code you have is correct" what exactly do you mean by "correct"?" ... based on the code that you provided and your description of the code operation, it appears that the behavior you are observing is what you programmed it to do.

You shouldn't have to mess with or disable the double buffering. Unfiltered RF is basically very noisy, the CRC check attempts to make sure that your data remains intact. The double buffering is used to ensure that the buffer allowed to be read has a valid CRC against that buffer.

Note: Because of the noisy nature of RF, it is necessary to send the same data several times to make sure that the buffer contains a valid packet.

ccreinhart · 2012-04-09 09:22

The double send makes a difference. I works as desired some of the time (which is better than never which is what I got in the first place). So this tells me I will need
to go to a more elaborate protocol between the two devices to ensure proper communication.

Thanks for your help. You've provided tremendous insight.

Beau Schwabe (Parallax) wrote: »

"When you say "behavior you describe based on the code you have is correct" what exactly do you mean by "correct"?" ... based on the code that you provided and your description of the code operation, it appears that the behavior you are observing is what you programmed it to do.

You shouldn't have to mess with or disable the double buffering. Unfiltered RF is basically very noisy, the CRC check attempts to make sure that your data remains intact. The double buffering is used to ensure that the buffer allowed to be read has a valid CRC against that buffer.

Note: Because of the noisy nature of RF, it is necessary to send the same data several times to make sure that the buffer contains a valid packet.

ccreinhart · 2012-04-09 09:31

FYI, doubling up on the RF.Receive call helps too.

ccreinhart wrote: »

The double send makes a difference. I works as desired some of the time (which is better than never which is what I got in the first place). So this tells me I will need
to go to a more elaborate protocol between the two devices to ensure proper communication.

Thanks for your help. You've provided tremendous insight.

433 RF Transceiver Module Help

Comments