433 RF Transceiver Module Help
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
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
Comments
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
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.
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.
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.
to go to a more elaborate protocol between the two devices to ensure proper communication.
Thanks for your help. You've provided tremendous insight.