Has anyone connected a parallax transceiver to a ZX-24n?
http://www.parallax.com/Portals/0/Downl ... r-v1.1.pdf
Before you ask,... I know there are tons of other transceiver, but I have a box of these and would like to use them if I can.
Any experiences would help. It seems like it should be straight forward, but I am not having much luck. I am trying to use COM 3, but all I get is tons of noise. I am looking for a sync string, but I never see it... all I get is a ton of noise (which is expected in the 433MHz range).
Thanks in advance...
T.
parallax rf transceiver
I've never used that particular transceiver but I have had a great deal of experience using other RF receivers (and transmitters) with BasicX, ZBasic, BasCOM AVR, PICs, etc.
I do not like using RS232, preferring to use other protocols but for those who want to use RS232 I always suggest sending the equivalent of a BREAK signal to set the receiver AGC circuits before sending the sync string & payload.
These webpages may be of help...
http://davehouston.org/RFTipsTricks.htm
http://davehouston.org/rf-noise.htm
http://davehouston.org/learn.htm
See the RS232 discussion towards the bottom of the first page. And above that, there's a link to some PicBasic Pro code about 1/3 of the way down the page. It includes RS232 example code which should be fairly easy to understand... http://davehouston.org/PIC-RX-TX.TXT
After the BREAK, you need a brief silence followed by the sync & payload.
I usually use $5 superregenerative receivers and these techniques work well with them. I have not tried them with a superheterodyne receiver but they should help with that type, also.
You can find more tips by reading the Linx Technologies datasheet for the transceiver chip. There is a brief discussion of received noise...
It is important to note that the transceiver does not provide hysteresis or squelching of the DATA line when in receive mode. This means that, in the absence of a valid transmission or transitional data, the DATA line will switch randomly. This is a result of the receiver sensitivity being below the noise floor of the board. This noise can be handled in software by implementing a noisetolerant protocol as described in Linx Application Note AN-00160. If a software solution is not appropriate, then the transceiver can be squelched.
I do not like using RS232, preferring to use other protocols but for those who want to use RS232 I always suggest sending the equivalent of a BREAK signal to set the receiver AGC circuits before sending the sync string & payload.
These webpages may be of help...
http://davehouston.org/RFTipsTricks.htm
http://davehouston.org/rf-noise.htm
http://davehouston.org/learn.htm
See the RS232 discussion towards the bottom of the first page. And above that, there's a link to some PicBasic Pro code about 1/3 of the way down the page. It includes RS232 example code which should be fairly easy to understand... http://davehouston.org/PIC-RX-TX.TXT
After the BREAK, you need a brief silence followed by the sync & payload.
I usually use $5 superregenerative receivers and these techniques work well with them. I have not tried them with a superheterodyne receiver but they should help with that type, also.
You can find more tips by reading the Linx Technologies datasheet for the transceiver chip. There is a brief discussion of received noise...
It is important to note that the transceiver does not provide hysteresis or squelching of the DATA line when in receive mode. This means that, in the absence of a valid transmission or transitional data, the DATA line will switch randomly. This is a result of the receiver sensitivity being below the noise floor of the board. This noise can be handled in software by implementing a noisetolerant protocol as described in Linx Application Note AN-00160. If a software solution is not appropriate, then the transceiver can be squelched.
Thanks for the hints....
As you indicate, I am using a serial port (com 3). It "sort of" works... Occasionally it misses the sync string I am sending to the Zx-24n ("UUUU!"). I attribute this to the fact that ZBasic does not have a conditional serial port reader routine. PBasic has serin() which has a conditional argument that says read the complete serial when some string is found in the buffer.
On the Zx I am reading the serial port continuous and filling a local buffer, 1 byte at a time until I find the sync string, then I read the next 8 bytes (my messages are only 8 bytes long) proceeded by a sync string.
Thanks again for the hints...
T (from Pittsburgh... I see you are from Cleveland)
On the Zx I am reading the serial port continuous and filling a local buffer, 1 byte at a time until I find the sync string, then I read the next 8 bytes (my messages are only 8 bytes long) proceeded by a sync string.
Thanks again for the hints...
T (from Pittsburgh... I see you are from Cleveland)
Re: Thanks for the hints....
It should not be all that hard to handle. If you cannot set the input to the TX high to create the BREAK, use 3-4 Chr(255) followed by a brief silence (about half as long as the BREAK). In effect, this applies squelch from the TX end.lattanze wrote:PBasic has serin() which has a conditional argument that says read the complete serial when some string is found in the buffer.
RS232 makes things a bit harder - I usually just check each pulse until I see the BREAK, then branch to my read routine. You could even monitor the RSSI output (if Parallax makes it accessible) to do this.lattanze wrote:On the Zx I am reading the serial port continuous and filling a local buffer, 1 byte at a time until I find the sync string, then I read the next 8 bytes (my messages are only 8 bytes long) proceeded by a sync string.
Actually, I'm just across the Ohio River from Cincinnati - a bit further south.lattanze wrote:T (from Pittsburgh... I see you are from Cleveland)
Great Hints...
Thanks! These are great hints... I like the idea of monitoring TX for a break,... it seems like that is what the author of that code snipit URL that you sent in your first post. I do have access to RSSI on the parallax transceiver, so I can give that a try as well.
I realized you were from Cleveland after I sent the mail,... sorry... I do some consulting work up on Cleveland at the NASA Glenn facility... must have been stuck in my head.
T.
I realized you were from Cleveland after I sent the mail,... sorry... I do some consulting work up on Cleveland at the NASA Glenn facility... must have been stuck in my head.
T.
Re: Great Hints...
That's because I wrote the code snippit.lattanze wrote: it seems like that is what the author of that code snipit URL that you sent in your first post. I do have access to RSSI on the parallax transceiver, so I can give that a try as well.
The RSSI pulse may not be high enough to trigger an input pin w/o amplification. I don't recall whether the ZX-24n has a comparator that you can access - with PICs, I've used built-in comparators like a dataslicer circuit to give me 5V whenever the RSSI is greater than its average.
30+ years ago I did a little work with DARPA (@Wright-Patterson - Dayton) in conjuction with Battelle Labs (Columbus).lattanze wrote:... I do some consulting work up on Cleveland at the NASA Glenn facility...
Re: Thanks for the hints....
Sending a "break" via a software serial channel (Com3 through Com6) is easy - just set the TxD pin to the opposite of the idle state for the desired period. Here is some example code which assumes non-inverted data (meaning that the idle state is high)dlh wrote:If you cannot set the input to the TX high to create the BREAK ...]
Code: Select all
Const chan as Byte = 3
Const txPin as Byte = C.2
...
' wait until all data has been transmitted
Do While(CBool(StatusCom(chan) And &H04))
Loop
Call PutPin(txPin, zxOutputLow)
<wait a while using Sleep, Pause, etc.>
Call PutPin(txPin, zxOutputHigh)
- Don Kinzer
And the Parallax datasheet recommends more or less the same.
Synchronization
When initiating communication between two RF Transceiver modules, a sync pulse should be sent to reestablish the radio connection between the modules. Sending several characters can accomplish this, however sending a pulse (which maintains a high state during the synchronization) is more efficient:
√ For BS1s the following code line sends an appropriate sync pulse:
PULSOUT 0, 300
√ For BS2s the following code line sends an appropriate sync pulse:
PULSOUT 0, 1200