Mr.Nasty 433 MHz noise-source

From Electriki
Jump to navigationJump to search


Fig.1: Mr.Nasty in action! Power comes from lab PSU through the clippers, and the white wire connects RF-transmitter to the MCU-board.
Fig.2: A corrupted serial message. Above is a transmitted serial message at about 684 bps (3 frames); below is what comes out of an UART at the receiving end.
Fig.3: Disturbance-bursts as seen on raw receiver output. One potmeter controls burst-interval (here set to about 110 ms).
Fig.4: A burst of pulses. The other potmeter controls the number of pulses in a burst, apparently 14 in this case.
Fig.5: Burst, up-close. How interesting. A pulse is about about 500 Hz, 50% DC, which is transmitted very well (i.e. duty-cycle deviates only slightly from what was transmitted).

Why do wiki-pages get shorter every day?

Why indeed. Here's why: to win the !CBA Contest (is that still going on..?) whilst still maintaining CBA.

What is this?

In itself, not so very spectacular; while toying with cheap(ish) Conrad 433 MHz transmitter/receiver pairs, I wanted to see the effect of overlapping transmits on the received signal. In such scenario, one (or more) node(s) would typically play actual transmitter(s) of some useful signal, while one or more nodes would just interfere - that's where Mr.Nasty comes in.

How it works

An ATtiny13 generates bursts of 500 Hz pulses, controlled by 2 potmeters (one for burst-interval, the other for burst-duration), not quite unlike the FanControl on this wiki.

The pulses go to the 'data in' pin of the simple 433 MHz AM transmitter. Mine happens to be an OOK transmitter, which means that if no signal is present at its input, no carrier is generated.

Disclaimer: I have near-zero clue on anything RF-related, nor have I ever worked with other types/brands of 433 MHz transmitters/receivers/transceivers. Some people say the transmitted signal should be DC-balanced (I am guessing this applies more to transmitters using 'normal' ASK instead of OOK), and/or the receiver needs time to start receiving from idle state, requiring either preamble-bytes prepended to the actual payload, or keeping the line busy with dummy-data in between actual transmissions. But none of that here.

How is it used (now)

This transmitter/receiver pair behaves OK with non-DC-balanced signals, and needs no preambles of any sort to stabilise the receiver before the actual payload comes in. I am lazy, so instead of bitbanging and decoding, I use an UART on both ends.

The actual transmitter (not Mr.Nasty) sends messages of 3 frames (0xaa, 0x00, 0xff or similar) out of an Atmel MCU's UART, connected to a similar 433 MHz transmitter as used by Mr.Nasty. The transmitter's input is the yellow pattern on the topmost scope-pic.

The receiver sends its output-signal (a digital pattern) into the UART on the receiving end, and a busy loop stuffs anything it receives back in to the receive-UART. The frame coming out of the receive-UART doesn't re-enter any transmitter, but is only used for measuring. This is the blue pattern on the topmost scope-pic.

I verified first that when not jamming transmission, frames appear 100% correct on the other side, i.e. are actually received OK by the receiver-UART. However, for these devices, TTL output of MCU's UART has to be inverted (i.e. 0V when idle) in order to get anything accross; it takes a couple of 100 ms for the receiver to start receiving properly again in case the transmitter's input was high when idle.

In fact, I verified/tested a shitload more, but that's not interesting here - perhaps on another page :-)

The reason for using only 500 bps, is that I found that transmitting at higher rates affects the duty-cycle of the received signal too much. When transmitting a 500 Hz 50% DC signal, the DC of the received signal varies no more than 10%. Apparently, this is enough stability for the receiver-UART to grasp.

So much for sending/receiving undisturbed. In fact, that's the only interesting bit of background here - Mr.Nasty simply adds noise/corruption to this signal. It's a tool. Perhaps it will be used in the future (by me), perhaps not.


Have fun -- Michai