Wireless communication with Arduino (433MHz) and inconsistent pulselengths. - Page 1
Forum section: electronics / general

author: LarsT
author_rank: Contributor
timestamp: March 28, 2017, 10:57:45 pm
content: I've encountered a strange problem while attempting to interract with 433MHz devices, and communications with these devices in general. In one experiment I used two Arduinos each connected to a transmitter and a receiver respectively. The 433MHz modules seem to work fine if I use the Arduino to transmit pulses with constant pulsewidths (e.g 200us HIGH, 400 LOW), I can check both the pin on the transmitting Arduino and the receiving Arduino with an oscilloscope and all pulses match exactly and are consistent within a couple us. But when I attempt to transmit pulses of varying length, such as wireless devices usually do (e.g 200us HIGH, 400us LOW, 200us HIGH, 800us LOW etc), then the pulse durations are way off, by more than 100us.This also occurs at far longer pulses.What are the reasons for this?

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: March 28, 2017, 11:30:21 pm
content: In order to give any useful comments, you should provide at least some code and hardware setup. Otherwise we would have to stick to answers like: "That is a natural phenomenon often being observed in closed loop systems, due to variabilistic propability-mechanics interacting on a metaphysical basis of ethereal oscillations in copper atoms."

author: ludzinc
author_rank: Unknown
timestamp: March 28, 2017, 11:37:55 pm
content: If the Rx module uses a 'data slicer', you get this behaviour.Either use a protocol that's slow enough, or symmetrical enough, or use a different Rx.https://www.maximintegrated.com/en/app-notes/index.mvp/id/3671

author: LarsT
author_rank: Contributor
timestamp: March 29, 2017, 08:18:13 am
content: Quote from: frozenfrogz on March 28, 2017, 11:30:21 pmHardware setup is as follows:Scenario 1:Arduino #1 is connected to Transmitter via 5V, GND and D8 (data). Oscilloscope is connected to D8 and GND.Arduino #2 is connected to Receiver on 5V and GND for power. Oscilloscope is connected to Receiver data output and GND.code:void setup(){pinMode(8, OUTPUT);}void loop(){digitalWrite(8, HIGH);delayMicroseconds(200);digitalWrite(8, LOW);delayMicroseconds(200);}The signals on oscilloscope from TX and RX matches exactly the timings in the sketch.Scenario 2:Arduino #1 is connected to Transmitter via 5V, GND and D8 (data). Oscilloscope is connected to D8 and GND.Arduino #2 is connected to Receiver on 5V and GND for power. Oscilloscope is connected to Receiver data output and GND.code:void setup(){pinMode(8, OUTPUT);}void loop(){digitalWrite(8, HIGH);delayMicroseconds(200);digitalWrite(8, LOW);delayMicroseconds(200);digitalWrite(8, HIGH);delayMicroseconds(200);digitalWrite(8, LOW);delayMicroseconds(400);}The signal on oscilloscope from TX matches exactly the timings in sketch, but on the RX the HIGH pulses are far longer while LOW pulses are shorter. The periods seems to be the same however.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: March 29, 2017, 10:03:23 am
content: Come on Dude! Give us something to work with hereWhat transmitter/transceiver units do you use? Is it the cheap MX-05V + MX-FS03V / FS1000A labeled one-way type, HC-12, RFM12B, or something totally different?Specs and datasheet please.Usually you would not just write pins HIGH and LOW randomly, but use something like bi-phase, or Manchester encoding to transmit data, because: Reasons.Regards,Frederik

author: LarsT
author_rank: Contributor
timestamp: March 29, 2017, 11:56:21 am
content: Quote from: frozenfrogz on March 29, 2017, 10:03:23 amYes, two of the modules I've tried are the MX-05V + MX-FS03V. The other pair I'm unsure of, but behaves identically.The pulses in the sketch was just as an example. When I look at signals received from other wireless devices the same thing happens, the high pulses are longer and low pulses shorter. I want to be able to use the arduino to interract with the wireless devices both as tx/rx.After digging around a little, I've come to understand that the problem I'm encountering is due to the fact that the "average signal" is not half that of a single pulse, and that makes the device not able to correctly differensiate between a low and a high signal. That the "average" signal is sort of a reference value?When I changed the pulses in the sketch so that the lows perfectly equalizes the highs the receiver picks up the correct lenghts, but that is not the case with the wireless devices I have (as for instance wireless devices that works on the Nexa protocol (http://tech.jolowe.se/home-automation-rf-protocols/), so I will have to figure out a way for the arduino to compensate for this in code somehow.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: March 29, 2017, 12:33:56 pm
content: I am not familiar with these Nexa remotes, but there seems to be quit some input on thePlayground, including a library to work with.Also, this blog might give you some interesting pointers:Cosa Arduino- if you don't already know about that.

author: Seekonk
author_rank: Super Contributor
timestamp: March 29, 2017, 02:00:13 pm
content: http://www.romanblack.com/RF/cheapRFmodules.htmtalks about AGC problems.

author: Mechatrommer
author_rank: Super Contributor
timestamp: March 29, 2017, 02:27:33 pm
content: Quote from: LarsT on March 28, 2017, 10:57:45 pmmy suspicion is transmitter carrier power decay. try observing the carrier in your scope and see how its decaying in time. try not to transmit too long HI signal, i'm advising not too long than 200us (or shorter than 100us), even if you managed to transmit longer (or shorter) than that, radio range will be greatly degraded. otoh, too long LO signal will reset Rx AGC to full gain requiring re-preambling. ymmv, good luck.

author: Buriedcode
author_rank: Super Contributor
timestamp: March 29, 2017, 06:46:26 pm
content: Not one to jump on the bandwagon but.. the Roman Black site explains this beautifully.I too had issues using these modules, and without a decent scope it can be very hard to debug because almost all issues relating to RF or the channel coding you use all create the same problem - extremely limited range. Mine turned out to be the channel coding I was using (PWM, similar to the PT2262) where my receiver was far too strict on detecting pulse widths, and transmitters had oscillator drifts of +/- 10%. The solution was to use the first 16-bits (falling edges) to train the receiver to the symbol rate/bit rate, and only sample 3 times per bit. The cheapy modules now happily cover 100m, and everywhere within a large house.As far as I am aware, the VirutalWire library for Arduino implements something similar:https://www.pjrc.com/teensy/td_libs_VirtualWire.htmlBut can still be rather strict on pulse width, thereby limiting range.The cheapy receivers also have quite a wide bandwidth, and will often spew noise when no picking anything up. This is generally a bad thing, but can mean you won't need to do much 'tuning' - it'll pick up everything the 433/434 band easily, and about 30MHz either side of that.

author: LarsT
author_rank: Contributor
timestamp: March 29, 2017, 06:55:21 pm
content: Quote from: Buriedcode on March 29, 2017, 06:46:26 pmThe range seems quite good actually, and as long as I transmit a pulse train where the low time is exactly the same as the high time (e.g Manchester encoding), the pulses are received correctly with no noise at all, even through two floors and from the opposite side of the house. The problem seems to be that when the transmitted signal at average has different duration of "high pulses" than "low pulses" that this somehow skews the threshold for detecting the edges. Someone with more knowledge may perhaps comment on this.

author: Buriedcode
author_rank: Super Contributor
timestamp: March 29, 2017, 08:51:07 pm
content: So you mean signals with a DC bias? Manchester (or biphase) coding, and many others have zero DC offset by keeping the average high and low times the same, allowing them to be AC coupled. The sorts of signals used by very cheap 'remote controls' uses either PPM - pulse position modulation, or PWM, where a bit is either 1/3 bit-period high, 2/3 bit-period low, or 2/3 high, and 1/3rd low. That can also have zero DC offset, but can depend on what bits are sent.As suggested, the Roman Black article linked above does a very good job of explaining what happens to pulses at the receiver, and suggests ways to deal with, or even abuse this property. If you are using your own form of encoding it will prove useful. If you are using a standard form of encoding, then please state which one.