Shop OBEX P1 Docs P2 Docs Learn Events
433MHz RX Noise — Parallax Forums

433MHz RX Noise

John BoardJohn Board Posts: 371
edited 2015-04-12 03:03 in Accessories
G'day,

Recently purchased a pair of el'cheapo transmitter/receivers from Jaycar to toy with.

http://www.jaycar.com.au/p/ZW3102
http://www.jaycar.com.au/p/ZW3100

There appears to be a ton of these around on the market in one form or another.

Hooked up the wiring as indicated on the PCBs, and as expected I got a ton of garbage on the RX line. When I pull the TX line of the transmitter up, the RX line of the receiver stays high, but when I drop the TX line low, the RX line floats between 0 and 1. Played around with pulldown resistors - with no avail (when I say no avail, I mean it pulls down successfully, but doesn't go back up again when I pull TX high. Experimented with many different values).

Because of this noise, obviously I have been unsuccessful transmitting raw serial across the line.

A lot of guides and docs that I see about these things say to only use them for short, sharp burst transmissions. They almost always use a checksum too. My guess is that I need to write some code that'll spam-tramsit a packet in the form of the preamble-data-checksum and so when there is a lapse in noise, it'll get through, and when the checksum is right, it executes the sent message.

Am I going down the right track? Is there anything I can do to help with this?

-John

Comments

  • Duane DegnDuane Degn Posts: 10,588
    edited 2015-04-06 22:07
    I've read a bit about those. They don't just pass through highs and lows, they need to be sent within certain bit rates.

    I couldn't get the set I purchased to work (though I didn't try very hard).

    I decided to stick with nRF24L01+ modules since they work well and are very inexpensive (and offer two-way communication). I have information about these cheap modules in most #1 of my index.

    Having said that, I know there are a lot of people using the cheap modules you mentioned. There are lots of YouTube videos about them but I haven't seen any videos about using the transmitters with a Propeller.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2015-04-06 22:17
    I think the noise you're seeing is normal behavior. These OOK (on-off-keying) receivers use a "bit slicer" that adjusts the input threshold to the average value of the RF at the antenna input. If there's no transmission, the input threshold is set to the average noise amplitude, and you get noise output. To transmit data, you need to send a longish "mark" (high) level first so the receiver can readjust its input threshold. Then send the data. As long as there's a pretty good balance between 1s and 0s in the data stream, the input threshold should remain set at a usable value.

    To filter out the noise on the receiver end, wait for the long mark before starting to receive data. And use a transmission protocol that flags the end of the transmission, so the receiver knows that what's coming next is just noise and that it can just wait for the next long mark.

    -Phil
  • John BoardJohn Board Posts: 371
    edited 2015-04-06 22:56
    Duane: Thanks - might put in an order for a few of those modules.

    Phil: Cheers, that clears things up a bit. Will experiment with what you are saying.

    Since first posting I've been experimenting with the threshold noise, at 2400 over 5 seconds. Over 5 seconds I get a set of 12,000 bits. I've been processing that set with python to figure out how many gaps of no-noise there are, and how long those gaps are. So far the longest gap is 19 bits (at 2400bps), with there being 147 gaps being longer than 8 bits.

    I'll experiment with sending the high long mark.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2015-04-07 08:24
    Ideally, for these receivers, you would use a transmission method that maintains an equal number of highs and lows. This keeps the receive threshold halfway between "mark" and the noise level. An example would be Manchester coding.

    -Phil
  • John BoardJohn Board Posts: 371
    edited 2015-04-07 18:20
    Ideally, for these receivers, you would use a transmission method that maintains an equal number of highs and lows. This keeps the receive threshold halfway between "mark" and the noise level. An example would be Manchester coding.

    -Phil

    Thanks, I'll check that out. I've had medium success last night. I got it filtering out most junk, and sending checksumm'ed messages, but there were still a few problems, and it wasn't all that reliable.

    When you say I need to bring the TX high for a period of time, how long would you suggest?
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2015-04-07 19:14
    Some years ago over on the picaxe forum there were lots of experiments with these modules. To summarise some rather long threads:

    1) they work at telephone frequencies, ie300 to 3000Hz, and so 1200hz (or baud) is the middle of this range. 2400 baud works as well. I think 1200 went a bit further.
    2) Need to bias the DC at zero, and the practical way to do this was to send lots of 010101010 bits at the beginning of the packet. ASCII capital "U" is 01010101 so this worked by sending about 10 "U"'s to startup
    3) A little start header worked - for the picaxe "ABC" worked fine. The Rx will be hearing noise most of the time and you need a way to distinguish an actual packet, and the odds of ABC arriving is pretty low. So just discard bytes until this string arrives.
    4) In theory the number of 1s and 0s need to be about the same. But what we found was you could get away with sending raw bytes so long as the packets were short - 10 bytes or so. So a packet might be UUUUUUUUUUABCHelloWorldn where n is the checksum (checksum of A to d, but not including any of the U characters)
    5) We did some experiments with manchester coding, and a poor man's manchester coding is to send each byte, then send the inverse of the byte. So the "H" for Hello is ascii hex 48 which is 01001000 so then send 10110111 whatever that character is (use an inverse instruction, or subtract the value from 255). However, it seemed to work fine with the string of Us and then the short data packet, even when the ascii value was (binary) 00000000 or 11111111. Sending text works because text will roughly have the same number of 0s and 1s. So in the end manchester coding wasn't needed.
    6) Use an antenna of the correct length. A bit of wire will do fine.
    7) free space around the antenna
    8) if you have a cro, test how far they can go by sending a 1200 hz tone, and take the tx some distance away, and look at the waveform on the rx. At maybe 20metres or so you can see the waveform get more corrupted. Anything near the rx or tx antenna will also corrupt the waveform, especially bags of water ie an arm, or a body :)
    9) if you don't have a cro, connect the rx to an audio amplifier and just listen to the tone. You can hear it develop hash and pops and crackles as the distance increases.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2015-04-07 19:32
    'Good advice from the Doc. I particularly like the character/inverse-character idea, as it would obviate the need for Manchester coding, which is easy to send, harder to receive.

    BTW, Doc's cro stands for either "ceramic resonator oscillator" or "coaxial resonator oscillator" -- not sure which he meant, but I suspect the latter.

    -Phil
  • John BoardJohn Board Posts: 371
    edited 2015-04-11 03:03
    Dr_Acula wrote: »
    Some years ago over on the picaxe forum there were lots of experiments with these modules. To summarise some rather long threads:

    1) they work at telephone frequencies, ie300 to 3000Hz, and so 1200hz (or baud) is the middle of this range. 2400 baud works as well. I think 1200 went a bit further.
    2) Need to bias the DC at zero, and the practical way to do this was to send lots of 010101010 bits at the beginning of the packet. ASCII capital "U" is 01010101 so this worked by sending about 10 "U"'s to startup
    3) A little start header worked - for the picaxe "ABC" worked fine. The Rx will be hearing noise most of the time and you need a way to distinguish an actual packet, and the odds of ABC arriving is pretty low. So just discard bytes until this string arrives.
    4) In theory the number of 1s and 0s need to be about the same. But what we found was you could get away with sending raw bytes so long as the packets were short - 10 bytes or so. So a packet might be UUUUUUUUUUABCHelloWorldn where n is the checksum (checksum of A to d, but not including any of the U characters)
    5) We did some experiments with manchester coding, and a poor man's manchester coding is to send each byte, then send the inverse of the byte. So the "H" for Hello is ascii hex 48 which is 01001000 so then send 10110111 whatever that character is (use an inverse instruction, or subtract the value from 255). However, it seemed to work fine with the string of Us and then the short data packet, even when the ascii value was (binary) 00000000 or 11111111. Sending text works because text will roughly have the same number of 0s and 1s. So in the end manchester coding wasn't needed.
    6) Use an antenna of the correct length. A bit of wire will do fine.
    7) free space around the antenna
    8) if you have a cro, test how far they can go by sending a 1200 hz tone, and take the tx some distance away, and look at the waveform on the rx. At maybe 20metres or so you can see the waveform get more corrupted. Anything near the rx or tx antenna will also corrupt the waveform, especially bags of water ie an arm, or a body :)
    9) if you don't have a cro, connect the rx to an audio amplifier and just listen to the tone. You can hear it develop hash and pops and crackles as the distance increases.

    Thanks for all this information, it's incredibly useful! I haven't been able to revisit this up till now, but if I can stay awake long enough, I'll see if I can start experimenting on this tonight...

    What method do you use to checksum the message? Do you just XOR the characters together?
    'Good advice from the Doc. I particularly like the character/inverse-character idea, as it would obviate the need for Manchester coding, which is easy to send, harder to receive.

    BTW, Doc's cro stands for either "ceramic resonator oscillator" or "coaxial resonator oscillator" -- not sure which he meant, but I suspect the latter.

    -Phil

    Ahh thanks, yes, I was wondering what CRO stood for!

    Floating around somewhere I have an RTL-SDR - would this work in place of the CRO for checking the waveform?
  • John BoardJohn Board Posts: 371
    edited 2015-04-12 03:03
    I successfully implemented a minimum viable product of the code - the transmitter has a byte counter going from 0 to 255 (and then back to 0), the receiver then receives the data and displays the relevant information.

    It is not uncommon for numbers to get skipped, but for my purposes this is fine. For a time I noticed that at ~3 second intervals there appears to be a lapse in transmission reliability. I wonder whether there are other 433 transmissions at 3 second intervals in the area - need to crack out the ol' SDR and take a peek.

    I've got the receiver hooked up to a speaker also so I can hear the signal being received.

    When the transmitter is unplugged, no valid signals are being received by the receiver, meaning the presend of ASCII "AB" and the checksumming works. Very rarely there I receive an invalid number (jumping from whatever the current count is to something way out), but as this happens very rarely, and is often easily identifiable, I don't imagine it'll be a problem.

    My current code can be found on github.

    https://github.com/boar401s2/JaycarTXRX
Sign In or Register to comment.