Them pesky cheapo 433Mhz transmitters!

Status
Not open for further replies.

Yeah dude, using the USART of a micro is a very convenient way, but it can also make it a hassle to 'decode' at the receiver end, since USART modules generally don't sync using bytes, but rather a single start bit. That said there are various techniques for that, most of which can be found in datasheets for various 'smart radios, like the NRF905, CC1101, SI4432 etc.. Using purely software bit banging opens thinks up a bit, also, using an SPI port drops the start and stop bits meaning you can just spit out consecutive bytes, with less overhead. Even so there is a huge range of possibilities, anything from sending 24 bits with PWM' as many simple remote control encoders use (PT2262), all the way to forward error correction, long preambles, sync patterns, CRC etc.. I guess its down to what data you're sending, how often, power requirements... the list is almost endless :/

On the subject of overhead, Manchester encoding is often used, but I found this unnecessary for short packets. Long packets, it because remarkably simple, split the byte into two nibbles, and have a 16-entry lookup table for it. I've made simple 1-4 channel remotes using 8-pin PIC's, all the way to 4Mbps two way links - but always relied on a lot of hardware support from intelligent transceivers Unless one is doing a production run, for one-off hobby based projects, its well worth the extra few bucks to save one getting more grey hairs.

This thread was really just trying to get to grips with the cheapest, dirtiest RF modules, their shortcomings, and benefits (of which there appear to be none!). I've been meaning to make a website to collect all these rants... as its kind of unfair to spam the forum with stuff others have said many times before, but hey ho... hopefully it'll help someone..
 
Just remembered this if anyone is interested... referenced it as part of my uni project:
**broken link removed**

Its an old microlinear app note about using a UART for baseband. Has a nice 'trick' for synchronizing a UART at the receive end by sending four bytes - acts as both preamble and sync.
 
Hi,

I have thought about this myself as i was a little interested in this too.

First, humidity is not good for radio circuits because the moisture can detune and load circuits more than they are supposed to be. The circuits are very sensitive.

But more to the point of touching a component to see the transmitter working, one strong possibility is that the onboard oscillator is simply not starting until you touch a component associated with the circuit, or even not associated with it if the finger injects a signal that boosts the power to the oscillator momentarily. Oscillators will oscillate sometimes even though they will not start up automatically, and one possible reason is because the power supply voltage does not come up fast enough.
To test for this i think you can simply measure the DC power supply current to the board. When the oscillator is not running it will probably draw less (or more) current than when it is not running, depending on how it starts up and what state it happens to be stalled in. So connect a DC meter (preferably analog) and check the DC current. If the DC current rises or falls when the finger is applied, it could very well mean the oscillator is not starting without a kick of some kind.
A more practical kick may come in the form of a higher power supply voltage momentarily, or just trying to get the power up faster as with a lower impedance power source.
It would be an interesting test to measure the current, and try to find another solution to get the transmitter to start normally. Switching a switch on and off a few times may even get it to start. Disconnecting a circuit component and then reconnecting it again (such as a coil) may get it to run, as long as it doesnt damage the circuit.
 
hassle to 'decode' at the receiver end,
Not having any 'RF' knowledge I wanted a remote link for my greenhouse controller / monitor , 433 was widely available. bear in mind I was coding in assembler at the time , so no real hassle in sync for the receiver, just turned on the RX waited for the byte sequence , I found a third RX module connected to PC ( hyperterminal) as a extra monitor was needed to see through the 433 fog. comm errors happen , but having message numbers allows a request to re TX . In my case just Temperature in/out , Humidity , and pump status.
 
Yes, I'm bringing back this old thread again

Blueteeth (or maybe someone else) - have you managed to understand how these cheap RF modules work?
I would like to know what job is doing components L1, L2, C1, C2 and R1?
If I understand correctly L1 is filtering any spikes from VCC and also not allowing alternating current flow back to VCC? Then C2 is for antenna coupling (don't let DC through)? But what about L2, C1 and R1?

For testing purposes I purchased all necessary components for Transmitter (433,92 MHz SAW resonator, 2SC3357 transistor, S8050 transistor, air coils (2,5T and 7,5T) and a couple of capacitors and resistors (non-SMD)). I placed these components on a breadboard together with ATtiny85 and DHT22 sensor and guess what - it works Even with breadboard's parasitic capacity and inductance I can transmit temperature and humidity over to the receiver hooked to ATmega328 and receive correct data.

However, I did some testing with SDR (Software Defined Radio) and original Chinese RF transmitter module. It is sending signal and I can see its frequency in SDR application (GQRX for Mac and SDR# on Windows). But if I use my transmitter on breadboard, I can't see clear frequency in which it is sending data. I will still make tests and I want to find out how to tune frequency. Also I noticed - if I add C1 capacitor as in this schematic:



then receiver is not receiving data anymore. Also in that schematic is incorrect resistor values and C2 must be something like 2pF.

<Mod edit: changed image link to visible image>
 
Last edited by a moderator:
The Tx freq must be within a few hundred kHz of 433.5MHz to match the super-regen receiver. I'm very surprized that you were able to get the home-brew Tx close enough to work. At 400MHz, everything you do pulls the freq, every parasitic, every pcb/wire trace, capacitor tolerance, the proximity of your hand, scope probes, everything... Maybe the SAW device is good enough to resist being pulled by parasitics.

When you can buy these Tx for ~$2, why bother building one?
 
Last edited:
MikeMl - yes, I tested different TX modules and they differ in frequency just a little bit, as you said a few hundred kHz difference.

Why bother building one? Well firstly - it's curiosity. How this simple schematic works and maybe a little bit of "just because I can" stuff But secondly - why waste space on a PCB with 2x2 cm TX module if it could be great to build transmitter from known components on my own PCB?
 
I KNOW this is an old thread but I got here when troubleshooting five non-working FS1000A transmitters. Having found a cure (at least for the one I've now got in service) I thought it would be good to share...

Simply, the tx wouldn't transmit unless I squeezed the board between two fingers. A bit of playing resulted in the addition of a 3p9 capacitor in the vacant C1 position (marked '7pF' in the thread diagram). 6p8 doesn't work! I guess there must be a production spread and the use of really cheapo components won't help. However, when paying £6 for three transmitters and three matching receivers, what can anyone expect?
My suggestion for troubleshooting is to solder two insulated wires to the C1 pads and twist them until it transmits. I had a capacitor of the right value but just leaving the twisted wires in situ will probably be OK.
 

I have the same problem like you (finger problem) . I lost a lot of time trying to solve it and I think I found a solution (at least it works for me). I connected a capacitor in parallel with the coil L1 and tried values between 3pF and 150pF. For my module, it works very well with 47pF. The reception is stable anywhere inside my house. Give it a try and tell me how it goes.
 
Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…