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.

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:

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:

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.