Cheap 433MHz ASK modules in commercial applications. Pros and Cons

"Should/Can we use 433MHz for commercial applications?" IMHO this is mature tech.

I recall 433MHz keyfobs, for example, back in the late 1990's. These would've used Manchester encoding and used proprietary protocols and methodologies to allow the user to link a keyfob with a particular receiver. It was all closed shop... and that's the rub.

In my experience, I have found no open source or standardised/proven methods and additional middleware to handle data security etc. and how to link a particular transmitter with a particular receiver. This part you have to do/create yourself. Probably by now there is stuff on the internet but it is nothing standardised or elaborate like LoRa or BLE.

Hi Inderpreet,

Depending on your needs, you might find you can't do as much with the 433 MHz modules. The cheap modules can drift a lot, and can't offer multiple channels as easily, since they are not designed to channel hop. Personally I would be looking at other sub-GHz models, or as BigG says, BLE or some other 2.4 GHz protocol. There's commercial stuff using proprietary 2.4 GHz protocols too. Also Zigbee can be popular for certain industries, perhaps chosen because on paper it has a security layer although it's optional from memory. 

Consumer stuff still uses 433 MHz ASK modules, but sometimes it's dated designs (not because of the chosen frequency of course, but because perhaps radio wasn't a core area of expertise for the manufacturer. I think my home heating system uses such a module, and it's a pretty poor designed solution.

If you're designing a consumer solution then perhaps it may be the cheapest option admittedly, simply because it's so mature.

Depends on your priorities.

The choice of 433Mhz usually comes down to low cost. In return, you have a "noisy" channel with low reliability, potentially quite limited range due to power limits/poor receiver sensitivity/high noise floor, the potential for jamming by more powerful transmitters nearby (e.g. 70cm amateur radio band) and collisions with other transmitters on-channel (e.g. weather stations, wireless headphones, garage door remotes, other key-fobs). You also have to handle any error-checking and robustness measures yourself (e.g. retransmissions, checksums, choice of encoding - preferably DC-balanced and bit-rate). Modules can also vary, so replacing one 433MHz module with another may not produce the desired result (e.g. due to drift in their SAW resonators, reduced power output, bandwidth limitations on data rate). Implementing a single transmit-only unit eliminates the possibility of two-way communications which also means no possibility of acknowledge/retry type ARQ.

If you can spare the cost and complexity, perhaps it's worth looking elsewhere as most "silicon radios" can do a lot within the radio itself. If the choice of 433MHz is made for regulatory reasons or because you're not allowed to use other ISM bands (e.g. 2.4GHz, 5GHz, or 868/900MHz), you may still be able to benefit from silicon radios from say the Texas Instruments sub-GHz range which handle the link-layer for you (e.g. framing, error correction), use faster modulation with more accurate frequency tuning, higher receive sensitivities with two-way capabilities out of the box. If not 433MHz, you can use 868/900MHz depending on your intended country and their regulatory requirements.

But perhaps nowadays, 2.4GHz is the usual choice. Although it too is subject to interference, depending on your needs, perhaps you can get away with a "connection-less" Bluetooth Low Energy set-up where each are broadcasting packets at semi-regular intervals. This might even be lower-energy than going with more legacy solutions, although range may be impeded. Using a newer Bluetooth 5.0 LE coded-phy with a compatible endpoint will increase range dramatically, while cutting the data rate but still offering plenty more than 433MHz ever could. This is better than the "connection-oriented" regular Bluetooth where you have limits on number of devices per PAN. Wi-Fi is perhaps an option, but it is energy intensive and comes with a potential security caveat if the network is connected to anything else. Zigbee is another option, although development can get tricky, the home automation profile has provision for standard profiles for various types of sensors which can allow you to integrate it into a home-hub style system with the benefit of mesh-relay through powered nodes, extending your coverage.

If you don't want any of that, it's also prudent to remember that the Nordic Semiconductor nRF series are pretty much "software defined", so you can use them to brew your own 2.4GHz proprietary protocol with your choice of data rates/error correction/etc. Or you can use them to run standards-based communication protocols (e.g. BLE, ANT+, Thread, etc). Some are available as modules you can integrate, but you'll need to suss out the development side of things as I don't have any experience there.

Another option could be running LoRA if you're looking for longer range but low data rate - modules are now available in 433/868/915MHz bands as well..

- Gough

Gough Lui  wrote:

 

But perhaps nowadays, 2.4GHz is the usual choice. Although it too is subject to interference, depending on your needs, perhaps you can get away with a "connection-less" Bluetooth Low Energy set-up where each are broadcasting packets at semi-regular intervals.

Although off topic, I thought to add to this is a very interesting point. With the new contact tracing app, this congestion/interference issue for broadcasting packets may have grown somewhat. Basically every phone with the contact tracing app installed is broadcasting an advertisement package approximately every 250ms. So in a busy place that is quite a bit of BLE data being pushed out by phones that was not around a year ago.

Otherwise, specific analysis is required on which is the best radio frequency for the application (433MHz propagates/penetrates better in certain environments than say 2.4GHz). Then suggest evaluating modulation type, transmit power, receiver sensitivity, and then what middleware support is provided for connection detection, whether it only provides open or it offers closed broadcasting of data and what security features are provided to prevent hacking etc.

To be honest, the congestion issue is a bit of a strange one. You're probably more likely to suffer from environmental noise from competing 2.4Ghz band users instead.

But lets say you have people all broadcasting the maximum length BLE standard advertising packet - 31 byte payload, 47 byte physical length frame. That is 376 bits. BLE PHY rate is 1Mbit/s but with the "unsynchronized" access, generally speaking, 40% capacity is usually a good figure to take (as Ethernet/Wi-Fi experience usually shows). Above this figure, congestive collapse is usually the result. This tells me that 1063 advertisements could feasibly pass in every second, or about 265 people could co-locate and I'd still expect about 90% of the packets to be received from all.

In reality, many times broadcast packets are sent many more times than necessary. Contact tracing apps are not going to care about a lost packet here or there, so feasibly all they might need is to hear one packet every 10s (i.e. 1 in 40) to log a contact. So I don't think the apps would break due to overload of the channel. Also consider compliant devices usually broadcast on three channels in a staggered fashion so a collision on one won't necessarily cause the loss of the packet.

However the side effect that may hurt is the signals from radios further away that aren't as strong being trounced on, causing reduction in SNR and range of all channel users.

Of course, there is the LE 2Mbit/s PHY which increases data rate by double, at the cost of needing better signal. That will alleviate congestion where range is not a priority. But depending on your application, I would argue that using LE Coded PHY for an 8:1 increase in robustness with associated reduction in data rate assuming compatible endpoints is probably going to beat many 433MHz ASK modules hands down. I've heard of some line of sight LE Coded PHY links reaching about 1km!

- Gough

That's a very good assessment. No, I was thinking more along the lines where you have your own custom application, which requires a BLE central device to still scan for advertisements but in this case we're talking about non-contact tracing advertisements. In this case the data received from each scan will be much larger than before as it will have detected all the phones transmitting the exposure notification service, which then has to be ignored/filtered out. So depending on the BLE central device firmware, this may mean that more memory resource will be required by the central device to cope with the larger device list + advertising packages returned through the scan process.

433MHz can do FSK as well. There are lots of commercial applications for 433MHz, but I think there are restrictions on the amount of data and air time, so if you are monitoring continuously, there may be compliance issues.

Enocean may be another alternative to consider.

Thanks all!

The inputs are appreciated and here are my takeaways.

1. 433MHz is mature.

2. They are cost effective

3. They may tend to drift.

4. Offer unidirectional communication ergo features such as acknowledgement as well as collision detection cannot be implemented.

5. Need protocol stack to make them useful.

6. May have compliance issues.

7. Used in older tech any may be the only way for certain applications.

8. SiLabs has an offering to be considered.

Alternative tech to be considered:

1. BLE - 2.4GHz and good for short range.

2. LoRa - Longer range albeit lower data rate.

I have opted to go with LoRa as the modules are cheap, inherently low power and readily available. They are easier to work with as well in contrast to some BLE SOCs where the software stack configuration presents undesired configuration. The nRF51822 is a module I will experiment with on the side in the BlueFruit feather wing format but its not something for today.

Thank you again for all the inputs.

I appreciate it.

Regards,

IP