Serin timeout with WAIT - Parallax RF units
stamped
Posts: 68
I am using the Parallax RF modules and have run into a few issues;
The RF units appear to get a fair amount of interference. So I decided to use both a timeout and wait condition and wait for two "!!". This works fine except the timeout never occurs. It keeps waiting until it gets the "!!". The code I am using is as follows:
initialRX VAR Byte(3)
SERIN RxLine, 16468, 1000, checkCallsign, [noparse][[/noparse]WAIT("!!"), STR initialRX\3]
Given that the WAIT means that the above never times out and waits indefinately, I decided to go the more long-winded route and filter the control packets myself but it never receives the "!!" now:
initialRX VAR Byte(5)
' Note I am sending "!!ABCD" constantly from the matching TX via another BS2
SERIN RxLine, 16468, 1000, checkCallsign, [noparse][[/noparse]STR initialRX\5]
GOSUB checkCallsign
checkCallsign:
· DEBUG "check callsign", CR········· 'This is ouput in the Debug screen
·· IF(initialRX(0) = "!" AND initialRX(1) = "!") THEN
··· DEBUG "GOT DATA!", CR···········'This never gets fired
··· RxString(0) = initialRX(2)
··· RxString(1) = initialRX(3)
··· RxString(2) = initialRX(4)
··· noData = 1
·· ELSE
··· noData = 0
· ENDIF
RETURN
The initialRX(0) and initialRX(1) are never "!", they are always junk characters. I only get the "!" characters when I do an explicit WAIT in the SERIN, but I cannot have this stall the program and wait indefinately as I need to run other routines.
Can someone please point me in the right direction here. I am spending heaps of time trying to get past this. Many thanks.
The RF units appear to get a fair amount of interference. So I decided to use both a timeout and wait condition and wait for two "!!". This works fine except the timeout never occurs. It keeps waiting until it gets the "!!". The code I am using is as follows:
initialRX VAR Byte(3)
SERIN RxLine, 16468, 1000, checkCallsign, [noparse][[/noparse]WAIT("!!"), STR initialRX\3]
Given that the WAIT means that the above never times out and waits indefinately, I decided to go the more long-winded route and filter the control packets myself but it never receives the "!!" now:
initialRX VAR Byte(5)
' Note I am sending "!!ABCD" constantly from the matching TX via another BS2
SERIN RxLine, 16468, 1000, checkCallsign, [noparse][[/noparse]STR initialRX\5]
GOSUB checkCallsign
checkCallsign:
· DEBUG "check callsign", CR········· 'This is ouput in the Debug screen
·· IF(initialRX(0) = "!" AND initialRX(1) = "!") THEN
··· DEBUG "GOT DATA!", CR···········'This never gets fired
··· RxString(0) = initialRX(2)
··· RxString(1) = initialRX(3)
··· RxString(2) = initialRX(4)
··· noData = 1
·· ELSE
··· noData = 0
· ENDIF
RETURN
The initialRX(0) and initialRX(1) are never "!", they are always junk characters. I only get the "!" characters when I do an explicit WAIT in the SERIN, but I cannot have this stall the program and wait indefinately as I need to run other routines.
Can someone please point me in the right direction here. I am spending heaps of time trying to get past this. Many thanks.
Comments
When dealing with complex conditionals, sometimes it helps to use more parenthesis to ensure precedence is correct:
IF((initialRX(0) = "!") AND (initialRX(1) = "!")) THEN
Other than that, you are sure raw data is arriving more or less correctly? It will also help to decrease your baud rate to 1200 or 2400 as hgher rates are more prone to errors.
- Martin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
Personal Links with plenty of BASIC Stamp info
StampPlot - Graphical Data Acquisition and Control
AppBee -·2.4GHz Wireless Adapters & Devices
Post Edited (Martin Hebel) : 10/21/2006 2:18:58 PM GMT
If I output the data as it is read (after the timeout when not using WAIT) I am getting constant garbage such as:
data:
-Martin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
StampPlot - Graphical Data Acquisition and Control
AppBee -·2.4GHz Wireless Adapters & Devices for the BASIC Stamp & Other controllers·
I concur with everything that Martin mentioned, as it's far better to start at a lower baud rate, and then work your way back up, ESPECIALLY when there are multiple conditions, or a complex set of SERIN parameters.
We have no indication as to which Stamp model you are using, nor who or what is transmitting this data (a Stamp, a PC, something else?), to offer an intelligent diagnosis of the problem, but if I had to bet I'd say you have a bad baudemode parameter in your program; ergo one which doesn't match the incoming data strem or one which is inappropriate for the particular Stamp model you are using..
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
Bruce: The communication is from a BS2 to another BS2. Its essentially a simple modification of the test code supplied by Parallax with the units.
If I change the code to WAIT("!!") then it all works fine. If I try parsing it myself it keeps getting garbage characters constantly.
Does anyone have experience with these actual (433.92 Mhz #27980 & #27981) units?
I will try lowering the baud rate, that said one would think it would work just fine with the Parallax recommended rate.
-Martin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
StampPlot - Graphical Data Acquisition and Control
AppBee -·2.4GHz Wireless Adapters & transceivers·for the BASIC Stamp & Other controllers·
Though admittedly I'm stuck these days on using the XBee units I distribute which provide error checking, flow control so the BASIC Stamp can read at will, and addressing.
-Martin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
StampPlot - Graphical Data Acquisition and Control
AppBee -·2.4GHz Wireless Adapters & transceivers·for the BASIC Stamp & Other controllers·
' {$STAMP BS2}
' {$PBASIC 2.5}
' Receiver
temp VAR Word
RxLine CON 5 ' The BS2 port for the Receiver
Main:
SERIN RxLine, 16468, [noparse][[/noparse]temp.LOWBYTE, temp.HIGHBYTE]
DEBUG "data:", ASC ? temp
RETURN
Running this simple code, it constantly loops and outputs garbage information - it does not wait for even a second. The only way I can get the RF Rx unit to behave is to use the WAIT routine, but I cannot afford to have this wait indefinately.
There has to be some simple mistake. As mentioned the baud rate changes made no difference.
You can't use RETURN without a prior GOSUB. GOSUB's and RETURN's must always be paired. If you want to quit the program just use END.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
StampPlot - Graphical Data Acquisition and Control
AppBee -·2.4GHz Wireless Adapters & transceivers·for the BASIC Stamp & Other controllers·
' {$STAMP BS2}
' {$PBASIC 2.5}
' Receiver
temp VAR Word
RxLine CON 5 ' The BS2 port for the Receiver
Main:
GOSUB rxListen
rxListen:
SERIN RxLine, 16468, [noparse][[/noparse]temp.LOWBYTE, temp.HIGHBYTE]
DEBUG "data:", ASC ? temp
RETURN
The above loops outputting garbage information constantly. This is getting frustrating because it appears the RX unit only works if it is told to WAIT, otherwise it gets constant garbage data. The Parallax example code for the BS2 only has the WAIT condition. Maybe one of the Parallax guys has some ideas?
The issue is that SERIN should wait (until it hits a timeout) until it receives data. It should not constantly receive garbage data. Its like the RF unit gets terrible interference making it inoperable without the WAIT. If I do not have a WAIT, it gets constant garbage information and never gets the data from my BS2 and matching TX unit.
EDIT: As far as I know I have no 433mhz devices. I have a cordless phone which runs at 2.4ghz and·my PC has a wireless card (pretty sure that runs on 2.4ghz, that is about it.
Post Edited (stamped) : 10/22/2006 1:36:59 PM GMT
We're getting there, but we're not there yet :-)
In the folowing code you will "perform" (GOSUB) to the routine named rxListen:, then RETURN to the statement AFTER THE GOSUB, which is the rxListen: routine, essentially completing a never ending loop.
Do you want this program to run only once, or continuously? Once you make that decision, the program will need to be appropriately changed to reflect that decision. Since I don't know which way you want to do it, I leave you without a solution, only to avoid confusion for now. I'll be happy to chime back in.
Main:
GOSUB rxListen
rxListen:
SERIN RxLine, 16468, [noparse][[/noparse]temp.LOWBYTE, temp.HIGHBYTE]
DEBUG "data:", ASC ? temp
RETURN
- - -
I honestly have never used·any of the Parallax RF modules, thus the reason for my next question. IF you are using one power source for the Stamp, and another for the RF module, are the grounds connected in common as they should be?
Regards,
Bruce Bates
A couple things you may want to try are simply receiving data without transmitting. See if you are still getting garbage. If you are, then it's definately an interference problem.
Put a 500mSec pause before sending each transmission. The data may be coming in so quickly that without a clear break, the receiving BASIC Stamp doesn't know where the actual data starts and is picking it up in the middle somewhere.
-Martin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
StampPlot - Graphical Data Acquisition and Control
AppBee -·2.4GHz Wireless Adapters & transceivers·for the BASIC Stamp & Other controllers·
Although I've never used it, or seen the necessity of using it in a Stamp-to-Stamp application, is there any possibility that adding PACING to the RX side might help this application?
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
Yes, using the Pace modifier on SEROUT should help in identifying byte seperation, though reducing the Baud rate should have given significant enough delays itself.
-Martin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
StampPlot - Graphical Data Acquisition and Control
AppBee -·2.4GHz Wireless Adapters & transceivers·for the BASIC Stamp & Other controllers·
It's ok for the rxListen function to loop endlessly. The point is that it should not be constantly looping in that it should be waiting to receive data and not just getting a heap of garbage data constantly. By constantly I mean, continuiously. It never waits for even 1 second before outputting the DEBUG "data:" etc... This happens even when the TX is turned off. It makes me think that there are some serious hardware issues with the RX module rather than anything wrong with SERIN.
I have written a simple communication protocol, but that only works with WAIT. If we can't get past square one (stopping the RX from constantly getting garbage data even when the TX is powered down) then the protocol implementation will never materialize. So there is little point talking about SEROUT or CRC's, because even when the TX (BS2 with matching TX) is powered down, the RX (BS2 with matching RX) gets constant junk. I have written (see above) a simple filter that performs a similar function to WAIT, but it never gets the data from the TX as it is flooded with garbage data constantly.
Using the WAIT appears the only solution (which is not acceptable). It would be nice if someone from Parallax could drop by and explain why this would be happening or if this is a know issue with the RX unit. The RF units only arrived from Parallax a week ago.
Hopefully a Parallax moderator will reply when business hours open tomorrow, but it does sounds like your unit has issues.
I try to answer in the general here, but I think the XBee's I use would make your life much easier. They use 2.4GHz and an actual protocol with error checking and retries to ensure data delivery, and they have flow control so the Stamp can use RTS to quickly check for new data and go on about it's business without worrying that data will be missed, and all you need to worry about is a SEROUT, SERIN and parsing your data as you see fit. Since you are a member of Stamps in class, mail me off line and I'll send you codes for 10% off if you want to try them out. martin@selmaware.com. The same is true for other Stamps in Class members.
http://www.selmaware.com/appbee
-Martin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
StampPlot - Graphical Data Acquisition and Control
AppBee -·2.4GHz Wireless Adapters & transceivers·for the BASIC Stamp & Other controllers·
Confused?· Refer to this... http://www.rentron.com/Stamp_RF.htm
it doesn't use the Parallax RF units, but the idea is the same...
·
·· The only thing I can suggest is to use more than one character in both your header and in the WAIT modifier.· It is very possible when you’re picking up noise to get a single character that you’re expecting which itself may be noise.· Try using something like, “!RF” as your header byte and place that in the WAIT as well.· Also, try this at the lower baud rate…You said in one of your messages you had, but all posted examples still show 9600 bps.· Do you have a way to test this perhaps a few miles from where you are?· It is possible something in the area is interfering with the signal.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
·
·· One other thing I just thought of…Do you have more than one receiver?· If so you can see if you’re getting the same results from both.· If both exhibit the same symptoms it would be more likely there was local noise/interference since the likelihood of two receivers being bad is pretty low.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
Chris, thanks for dropping by. I have completed some more testing that has involved multiple boards (NX-1000 Stamp Works board from Parallax and BOE rev C), multiple BS2's (rev G and one with no rev on it) and two RF Receivers (#27981), different locations in my house and outside, but I have nothing but bad news. On both boards with different stamps and different RF units, different power supplies (but the same code - see below) they both constantly (meaning 1 byte every ~1/5th second) receive junk data:
The code I am using:
' {$STAMP BS2}
' {$PBASIC 2.5}
' Receiver setup
temp VAR Word
'RxLine CON 12 ' The BS2 pin for the Receiver (on the BOE I am using pin 2, on the NX-1000 I am using 12)
Main:
GOSUB rxListen
rxListen:
SERIN RxLine, 16468, [noparse][[/noparse]temp.LOWBYTE, temp.HIGHBYTE]
DEBUG "data:", ASC ? temp ' This line is output multiple times per second with garbage data (as listed in my previous post)
RETURN
I do not have RSSI or PDN connected to any BS2 pin. I have no wires connected to these as in the documentation where it shows nothing connected. The RF receivers are plugged directly into my solderless breadboards. I have the 5v going to the 5v output of the stamp. I have the GND going to the same GND rail as the BS2 and the data going to a BS2 pin.
Sometimes the stamp sits stable for 1-2 seconds when first powered on, but as soon as the first piece of interference occurs, from then onwards they constantly receive multiple junk bytes per second.
At first I thought this could have been something wrong with my code, or setup. But I am becoming convinced that there is an issue with these units. The fact that I have completely seperate gear and both sets behave exactly the same (same interference, different boards, stamps, RF receivers, different locations in my house, upstairs, downstairs, outside and driven 10 miles from my house using a LED to indicate a byte is received) has me convinced that this is an issue with the RX unit. It must be some on-board interference with the RX unit itself.
Can you please get hold of one of these exact units and run the code above and post the results. I am not keen on posting these units back (from Australia) as Parallax charged me $60 USD for postage to get them here. If it is determined that the unit is the problem, I will however post them back for testing.
Is there any hardware filtering I could try? Something between the Data or other pins of the RX?
There are still problems with your program. I suspect this is probably more like what you want:
Main:
SERIN RxLine, 16468, [noparse][[/noparse]temp.LOWBYTE, temp.HIGHBYTE]
DEBUG "data:", ASC ? temp ' This line is output multiple times per second with garbage data (as listed in my previous post)
GOTO Main
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
How frequent is the interference? Is there typically a glitch in the RF receiver's output every few seconds? We see that sometimes with networks of these devices because when two devices try to transmit at the same time the data gets corrupted.· The solution is the same regardless of whether the interference is coming from a network or an outside source. Provided the interference isn't a constant stream, packet communication should fix the problem. The transmitter should send a start character, the address, the message, and a cyclical redundancy check (CRC) code. To make life simple, the CRC can be the result of all the bytes XORed together.
crc = startByte ^ address ^ messageByte1 ^ messageByte2 ^...
The receiver should make the same calculation, and compare it to the CRC it received. If the information is correct, the receiver should use it; otherwise, it should discard it. In the situation where you are using transceivers, the receiver can send an ack or nack back to the transmitter. In unidirectional communication, the receiver can only keep or discard the packet.
One other note, make sure your transmitting module is sending a PULSOUT pin, 1200 command (BS2) before each packet.
Regards, Andy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andy Lindsay
Education Department
Parallax, Inc.
All talk of CRC's etc is not necessary, as the RX unit is not stable. It gets constant interference making it unusable without an explicit WAIT command in the SERIN (with WAIT it works fine, without WAIT it is completely unstable). Once we get the unit stable, then we can talk CRC's etc.. The TX is pretty much irrevelant. When the TX is not turned on, the RX constantly receives junk data multiple times per second (see above).
Can you please ask your support department for one of these (http://www.parallax.com/detail.asp?product_id=27981) Parallax RX units·to test the code I posted?? The time involved in sending it back to you guys (Chris has asked me to do this) is a real pain and will delay my project.
There's either a problem with the module, or something else transmitting on that band in your vicinity. It's time to get in touch with tech support directly, and they can also figure out how to deal with the postage problem. Please use the email button next to one of Chris Savage's posts to contact him directly.
Regards again, Andy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andy Lindsay
Education Department
Parallax, Inc.
I'll see if I can dig one up and test your code.
Andy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andy Lindsay
Education Department
Parallax, Inc.
I am in touch with Chris via email. Thanks again.
Even with our example code, I have to send a constant stream of messages to the receiver to keep it true. As soon as I turn off the transmitter, this current batch of receivers appears to pick up on some other source. This may be the same problem you are experiencing, but I won't be able to verify that until tomorrow morning. Reason being, there may be another 27980 transmitter locked in somebody's office that's pumping out data that my 27981 receiver is picking up when I turn off my test transmitter. We'll find out tomorrow morning and Chris will send you the verdict.
Regards, Andy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andy Lindsay
Education Department
Parallax, Inc.
I am having the same issue of constant interference. I was wondering if a solution to the problem has been found. Thanks,
Amish