Menu
Index

Contact
LinkedIn
GitHub
Atom Feed
Comments Atom Feed



Tweet

Similar Articles

01/01/2014 11:37
PICing up 433MHz Signals for OSS Home Automation - Part 4
06/12/2013 18:30
Owl Energy Monitor Protocol (CMR119)
19/04/2014 09:42
PICing up 433MHz Signals for OSS Home Automation - Part 6
07/12/2013 14:13
STATUS Remote Control Socket Protocol (RCS-K09/RCT-08)
08/06/2014 10:30
PICing up 433MHz Signals for OSS Home Automation - Part 7
15/12/2013 10:34
PICing up 433MHz Signals for OSS Home Automation - Part 1

Recent Articles

23/04/2017 14:21
Raspberry Pi SD Card Test
07/04/2017 10:54
DNS Firewall (blackhole malicious, like Pi-hole) with bind9
28/03/2017 13:07
Kubernetes to learn Part 4
23/03/2017 16:09
Kubernetes to learn Part 3
21/03/2017 15:18
Kubernetes to learn Part 2

Glen Pitt-Pladdy :: Blog

PICing up 433MHz Signals for OSS Home Automation - Part 3

Things are gradually getting closer to a usable system. Transmitting arbitrary sequences is comfortably working under host control. At this point the work is more about capturing and decoding signals from the ether.

Hardware mods

Power Supply Noise / Power Switching

As it turns out the +5V supply from USB is quite noisy (about 20mVp-p of ~1KHz noise) and the cheap 433MHz RX module is extremely sensitive to noise on it's supply. After some experimenting with a 100R/3300uF filter which improved but not fixed the situation I had a look at what I could do to regulate the supply.

The simple approach I came up with was to change to switching power with a BC337 and add a 10uF filter cap to the base. This gives ~0.6V drop (Vbe) but heavily filters (1.6Hz) the switching signal, however that give good enough regulation to completely remove the power supply noise related switching that was occurring on the output.

433MHz RF Module Power Switching with Noise Filtering

One further refinement I may make is to put some speed-up diodes round the RC0 resistor to avoid the slow switching, but still allow the filtering in steady state (diodes out of bias).

433MHz RX Module

I've been having a lot of problems with tiny (so brief the output doesn't even slew fully) glitches, particularly when idle, or shortly after a signal was captured. These are so narrow (~15us) and come in bursts (obviously as DC levels settle) that they cause overruns, and hence lost data.

Examining the XD-RF-5V RX Module circuit I've noticed that there are a number of things that are not optimal about the output conditioning. The RX module is using an LM358 (very basic dual op-amp) for baseband gain and as a comparator. There are a number of things that are not good about this part of the design:

  • GBW of 0.7MHz combined with the gain of ~320 gives about 2.2KHz of bandwidth... that's very poor and results in slumped edges.
  • There is no filtering (despite the fairly high gain) other than on the input of the gain stage (about 9kHz). This means that a lot of HF muck is reaching the comparator stage and causing it to switch frantically.
  • At first glance it looks like there is ~100mV of hysteresis on the comparator stage, but on closer inspection it's actually applied to a large capacitor which means it's more of a slow bias shift... which explains the bursts of noise seen after receiving a packet.

Relevant part of the circuit:

XD-RF-5V 433MHz RX Module Before Modification

I've decided to clean up the circuit somewhat with the addition of a 22k resistor and a 100p cap resulting in:

  • A ~8KHz LPF between the gain and comparator stages. This cleans up the noise significantly and reduces glitches.
  • Real hysteresis is now happening so we get more clean transitions and less flapping
  • Bias doesn't shift significantly so the circuit is much more in a "ready to go" state and doesn't produce the previous bursts of noise

Updated circuit:

XD-RF-5V 433MHz RX Module After Modification

Before someone points out... yes, I know it's far from perfect, but it's "good enough" for now with only minimal changes and no need to chop tracks. I may revisit this again later to refine it more if need be.

NOTE: This has now been refined in a later article with cleaner filtering and hysteresis.

Firmware / Software

Necessary refinements

We're doing pretty well with the basic implementation in place, but it would still be sensible to add a firmware de-glitch and host side overrun recovery to cope with all eventualities. It's best that the de-glitch threshold is configurable so that it can be set appropriately for the protocols being decoded.

Plug-in infrastructure

I've started work using Perl (widely available and already used in home automation tools) with a Plug-in approach similar to ulogalnalyser. Additionally I've been creating classes to decode the necessary bit patterns which then can be shared between multiple Plug-ins.

Each Plug-in also specifies it's required de-glitch, timing resolution and timeout (Timer overflow) values so that the the best overall configuration can be automatically chosen for all active Plug-ins.

Data order peculiarity

One thing that has me puzzled at this point is that I'm getting different symbols coming through out of order as shown by the counter byte, as well as some being duplicated. This is most odd since these are all sent in the ISR and as such should not result in any duplication or re-ordering. This needs further work to determine if it's being messed up on the host or in the PIC and exactly what the mechanism is.

The counter was intended more as a means of detecting overruns (send buffer full) but has revealed this unexpected situation.

Hooking up to to a signal generator has revealed some interesting results. This problem is definitely related to data rate, and running the host side in a VM is definitely a bad idea with the reliable reporting rate falling to to around 1KHz where directly on the VM host I can sustain >8KHz.

That's not great still, so I experimented a bit with forcing larger transfers by not running putUSBUSART() until at least 16 bytes were buffered. That was a big improvement and increasing to 32 bytes improved things a little more still. At this point it can sustain >13KHz.

It would appear that what may be happening is with a high enough rate overruns are happening in the USB stack between host and device (not clear which side is to blame). At the available data rate the amount of time spent in the ISR is getting excessive also, so short of some code optimization pulling things back we are nearing practical limits anyway.

At this point it's probably acceptable to mop this up in de-glitch code since we can probably call anything <100us a glitch and avoid excessive edges. Since the narrowest pulse I've got currently is the STATUS socket at 300us I think that's a safe bet.

Comments:

Zescientist Image  03/03/2014 17:19 :: Zescientist

Hi,
I'm interesting in your receiver LPF tweak. It seems that you change the 200K resistor place with the new 22K resistor? Could you confirm it please?
Then, a 8Khz is good, but as the receiver seems to work at 4Khz max, seems like something around 6Khz LPF with a 130pF capacitor would be better.
Thank you.

Glen Pitt-Pladdy Image  05/03/2014 07:45 :: Glen Pitt-Pladdy

I don't modify the existing LPF, just I add a second one with juggling components around. I'm not sure where you get the 4kHz thing since it doesn't match either the maths or my observations, but keep in mind that you are not dealing with linear signals here so applying approaches for linear signals will yield a simple but wrong answer. Also keep in mind we are dealing with first order here so more than "ball park" accuracy is going to gain nothing significant, but the pass band losses are going to be significant still.

Zescientist Image  05/03/2014 16:26 :: Zescientist

In fact, my question is about your schematics. On first, 200K resistor is connected to V-, but then, on second, this same 200K resistor is connected to V+, so I'm getting little confused.
So, if you have photography of this tweak or a little more explanation for this, could you send me it please?
By mixing part of VirtualWire's pll and a home-made protocol, I'm getting a 15 meter range and connection quality (using ACK) but I want to improve it and LPF will be a good solution.
Thank You.

Glen Pitt-Pladdy Image  05/03/2014 21:29 :: Glen Pitt-Pladdy

I honestly have no idea what you are looking at in the circuit. The 200k does move from doing a bad job of bias to providing a combination of filter and hysteresis, be it in a crude way. As stated, this mod is only to address one specific problem (overruns) between transmissions with my particular design. It may even reduce performance depending on your protocol and overall system design but that's up to you to work that out for your particular case.

Dominique Sebille Image  28/08/2015 14:57 :: Dominique Sebille

hello Glen
very good, synthetic comment and HW tweak !
I faced the same problem than you when I first used my RX module. I am wondering how other guys are managing this; to me getting rid of this parasitic bursts is a must for reliability of transmission.
I will try the PS noise reduction and I'll let you know how it comes out.
other pb with the RX module is that when powered up at 5V the output amplitude go down to somewhat like 4V I am wondering if it'll work with the Arduino with another 0.6V drop we'll see.
As far as the TX module I did not face any pb so far

Glen Pitt-Pladdy Image  28/08/2015 18:52 :: Glen Pitt-Pladdy

I think a lot of the impact of the noisy edges will depend on the what you are doing after - if the decoder detects and edge, processes for a while (during the noisy) and then starts looking for anther edge (now the signal is stable again) then no problem, but if triggering hardware timers etc. then this is definitely a major problem.

I don't know much about Arduino as I've always used far more bespoke processors in the past, but most 5V logic will be fine with this sort of input range, especially as it's common to have Schmitt input buffers with a lot digital inputs to micros etc.

Antonio Sánchez Image  08/10/2015 21:25 :: Antonio Sánchez

Hi Glen,
I am currently building a garage door controller using this TX-RX pairs & have come across random switching caused by the noise storms following data transmission. I am trying to understand how you implemented the LPF without breaking the track that connects the opamp output with the 1uF capacitor, & it also seems the 200k resistor is swaped with the new 22k resistor? Sorry if I got it all wrong but I don't quite get it, could you clear it up please? Thanks in advance & congrats for your web, it's been a great find.

Glen Pitt-Pladdy Image  11/10/2015 10:06 :: Glen Pitt-Pladdy

Hi - Check out the later linked article "cleaner filtering and hysteresis" which is a further improvement on this. All I did was lift one end of the relevant components off the board rather than cut tracks. This is surface mount so requires a little skill and a good soldering iron, but once they are standing up off the board it's easy to wire in the rest with small leaded components.

yk12345 Image  01/11/2015 16:06 :: yk12345

Hi there, just want to ask, why you choose to use the filter with the value of 100R/3300uF ? How do you calculate that ? isn't the formula for low pass filter is 1/2*pi*R*C ?

Glen Pitt-Pladdy Image  01/11/2015 16:25 :: Glen Pitt-Pladdy

Yes and no - it's a supply filter. That means I need an "R" that won't drop significant "V" across it with the "I" pulled by the receiver module - 100R was fine for a few mA. The C depends on more than just the 100R resistor since the module has an impedance as well and may pull varying current (eg. when switching rapidly). That isn't taken into account with the conventional RC formula. Also consider the stop-band attenuation required.

In my case for the sake of an initial experiment I just grabbed the nearest large-value cap I had which will give me a decent (theoretically ~60dB) attenuation. That's why I then moved onto a more refined circuit where the "I" would be much lower and I could use more sensible component values and isolate the filter from the varying "I" pulled by the circuit as well as any other impedances.




Are you human? (reduces spam)
Note: Identity details will be stored in a cookie. Posts may not appear immediately