RF data transfer questions.

[Dubbie]

Hi all,

I need to make a small receiver type device that needs to be as cheap as possible and have a receive range of about 50m. I only need to send about a dozen bytes or so, and there are no unusual constraints around speed or timing. Frequency would be 433Mhz

I was planning to use an all in one Micrel IC to handle the radio reception and transmission and a small mcu to do something with the data.

Where I am a bit confused is with the best way to actually send the data. I will probably use FSK modulation, but what exactly do I feed into this? I haven’t been able to determine what is usually done in this situation for data encoding. There are tons of higher level protocols it seems like zigbee etc. but none that I came across for bare basic communication. Do I need to write some scheme from scratch using Manchester encoding (which I am willing to do if necessary) or is there something that people far smarter than me have already invented? Or do I just simply plug UART TX into my radio?

Thanks for any advice.

[pwlps]

You can check RF-modem modules like

https://www.rfsolutions.co.uk/radio-modules-c10/fm-zeta-transceiver-module-optimised-for-433mhz-p405
https://www.rfsolutions.co.uk/radio-modules-c10/alpha-trx-low-cost-high-performance-transceiver-module-p383

They work like modems i.e. they handle all the modulation/coding stuff, you just see a serial (SPI) IO.

[schratterulrich]

Once I successfully implemented a radio remote control in which I simply used the UART TX. I had no problem with the DC content of the signal with my Transmitter.
 
First transmit a few bytes 0101010... So the receiver can level its AGC and comparator for creating the logic levels from demodulator circuit to a correct level.
Then simply transfer the payload data and then at least 4 bytes checksum. (some kind of CRC or similar, keyword Hamming distance)

A trap can be that the receiver always receives data (noise) even if the transmitter is not transmitting at the moment. This means if we use a baudrate of 9600 than the 4 checksum bytes are received 300 times per second. With 32 Bits checksum the possibility is 1/4.294.967.296 that the checksum is coincidentally correct. This means further this happens once every 165 days. Maybe you should better use even more checksum bytes…

[Dubbie]

You can check RF-modem modules like

https://www.rfsolutions.co.uk/radio-modules-c10/fm-zeta-transceiver-module-optimised-for-433mhz-p405
https://www.rfsolutions.co.uk/radio-modules-c10/alpha-trx-low-cost-high-performance-transceiver-module-p383

They work like modems i.e. they handle all the modulation/coding stuff, you just see a serial (SPI) IO.

I was hoping to achieve significantly lower cost than those all in one type solutions.

my current thinking is to use this part:
https://www.silabs.com/documents/public/data-sheets/Si4356.pdf

it's cheap and supports the power range I am planning on using.

With that and a microcontroller, I am only at less than $2.50 in 1 of quantities.

[Dubbie]

Once I successfully implemented a radio remote control in which I simply used the UART TX. I had no problem with the DC content of the signal with my Transmitter.
 
First transmit a few bytes 0101010... So the receiver can level its AGC and comparator for creating the logic levels from demodulator circuit to a correct level.
Then simply transfer the payload data and then at least 4 bytes checksum. (some kind of CRC or similar, keyword Hamming distance)

A trap can be that the receiver always receives data (noise) even if the transmitter is not transmitting at the moment. This means if we use a baudrate of 9600 than the 4 checksum bytes are received 300 times per second. With 32 Bits checksum the possibility is 1/4.294.967.296 that the checksum is coincidentally correct. This means further this happens once every 165 days. Maybe you should better use even more checksum bytes…

thanks for the advice.

I hadn't ever really considered the innevibility of an accidental checksum reception!
I'll keep that in mind.

R

[MarkF]

What about these?

https://www.ebay.com/itm/433-LoRa-SX1278-Mini-Range-RF-Wireless-Transceiver-Module-SX1276-5Km-For-Arduino/142465838566?hash=item212ba02de6:g:R00AAOSwHOlcd0cG&redirect=mobile

There is also an Arduino library for them.

[Dubbie]

That’s actually pretty decent for the price. Problem is, I would still need another board for the rest of my electronics.

[Dubbie]

Actually that chip seems readily available.
https://www.semtech.com/products/wireless-rf/lora-transceivers/sx1276
The Lora scheme seems great for range with a non optimal antenna as well. I might look into that.
Thanks for the tip.

[JVR]

There are PicRF devices, as well as Atmel and TI devices that embed a sub-GHz radio and a micro into one chip. Plonk it and some passives on a PCB, and voila, you have a solution.

[MarkF]

If you are interested in the LoRa module, here is a comparison and range testing video

[DDunfield]

A trap can be that the receiver always receives data (noise) even if the transmitter is not transmitting at the moment. This means if we use a baudrate of 9600 than the 4 checksum bytes are received 300 times per second. With 32 Bits checksum the possibility is 1/4.294.967.296 that the checksum is coincidentally correct. This means further this happens once every 165 days. Maybe you should better use even more checksum bytes…

It's not as bad as that, because you would only be testing checksums at that rate if you were receiving nothing but checksums (checksums of what?)

You should always have a Start-of-message sequence, especially on a radio link. A single byte isn't great when there's idle noise, 4 bytes isn't bad (and easy to test with a 32 bit shift register). Then you would have a length (unless fixed length messages), and at least one data byte (unless you make zero-length messages mean something). This  means:
  165 days to see a false SOM
  and a length that just happens to lead to a CRC which is exactly right.
  So counting a data byte (6 bytes min), the maximum effective sample rate is 200times/sec
  5 bytes have to match up, which leads to 63629 days, times the original 165 day trigger
  or approximately 29k years. 1/2 of that for a mean time.

Dependency of above on length==1 makes the math a bit loosey-goosey, but all other variations are lower effective sample rate so longer time.

This is also assuming your idle noise is pure unbiased random noise. If you know the characteristics of the receiver you can choose you encoding, SOM sequence and CRC algorithm/encoding to lower the probability of false hits.

And there's always chance (albeit very low) that the false transmission hit could occur in the first 5 mins. Robust comms protocols are fairly easy... 100% bulletproof ones not so much.

Dave

[schratterulrich]

A trap can be that the receiver always receives data (noise) even if the transmitter is not transmitting at the moment. This means if we use a baudrate of 9600 than the 4 checksum bytes are received 300 times per second. With 32 Bits checksum the possibility is 1/4.294.967.296 that the checksum is coincidentally correct. This means further this happens once every 165 days. Maybe you should better use even more checksum bytes…

It's not as bad as that, because you would only be testing checksums at that rate if you were receiving nothing but checksums (checksums of what?)

You should always have a Start-of-message sequence, especially on a radio link. A single byte isn't great when there's idle noise, 4 bytes isn't bad (and easy to test with a 32 bit shift register). Then you would have a length (unless fixed length messages), and at least one data byte (unless you make zero-length messages mean something).

I totally agree.

[vk6zgo]

You could have a squelch on your receiver--- no signal received, no output.

[DDunfield]

You could have a squelch on your receiver--- no signal received, no output.

Often not as practical as you might think. It can work if you know you will have a strong signal and the background in-band noise floor is quite low, but usually low power radio links (and most anything using open low power bands) have significant background noise from distant on-channel transmitters, squelch "chatter" can be more of a problem than the original problem. For data links (where you don't have to hear it in the shack all day :-) a robust communication protocol is usually the best solution.

Dave (VE3DRD)

[Dubbie]

Thanks for all the thoughts guys. I can’t seem to find a combo radio+mcu for less than around $4
That silabs part seems like the winner so far. It is cheap, needs few passives and is really simple.

[hagster]

Does 50m refer to miles or meters?

What do you mean by cheap? In what volume? Using pre certified modules save engineering effort. Using lowest cost OOK transmitters wont give the biggest range for input power.

[Dubbie]

50 to 100 meters is my target.

There will be one transmitter where the cost doesn’t matter, and a bunch of receivers - maybe 20 to 50 - per system.

The receivers need to be so low cost so the BOM for that many doesn’t blow out my target pricing for the whole system.

I will probably use a pre certified module for the transmitter for obvious reasons. And I figure my receivers don’t need certification as they are RX only.

[TK]

RFM69HCW is a simple and powerful RF transceiver that can be used with an Arduino type board.  There is a library that reduces the learning curve significantly

[Dubbie]

RFM69HCW is a simple and powerful RF transceiver that can be used with an Arduino type board.  There is a library that reduces the learning curve significantly

I have looked at this one. unfortunately, it blows my budget somewhat. Also, I don't need TX, only RX.

[Dubbie]

As a follow up to this. I ended up going with a Hope-rf part. They are great budget-wise at $1 each in small quantities. They also have an onboard decoder. I just need to read out the fifo via SPI.

Thanks to everyone who chipped in ideas.

[Wigo]

Could you post a link to the parts you used?

[Dubbie]

https://www.hoperf.com/ic/rf_receiver/CMT2219AW.html

Thats for the RF RX.
uC is just an Attiny404.

I haven't used an 8 bit MCU for a few years now. I forgot how easy it is to code AVRs! With the datasheet in hand you can blaze through it.
Complete opposite to ARM Cortex