868Mhz 4G interferences no data when 30cm from main receiver


few years ago, I buy a set of emonth an emontx and an extension card for wireless reception of data all in 868mhz.

Everythings works well during few years, then we move to a new flat.

I reinstall everythings from scratch, with success but have a lot of trouble to get my node data.

It work well when node are very close to raspberry pi receiver. But if I move them to more than 30cm I don’t receive any more data !

It seems that there are trouble with mobile 4G see :
The threat from LTE (4G) to 868MHz alarm systems.

In my new flat I have a very good 4G reception on my mobile device, it was not the same in my previous flat.

Is there any knows related trouble ?
Is there any work around like flashing all my firmware to patch them…?



I just see this thread : rfm12pi-change-mhz.
as my flat is ‘really small’ :wink: it should work for me.
I will try.

So I just change in my : emonhub.conf

frequency = 868

to :

frequency = 433

Now it works perfectly from every where in my flat.

But a question, I wanted to add some new node to my setup, what should I get 433 ou 868 Node ?


I just notice someting ‘strange’.

Before my frequence change, I was full of these type of log in emonhub.log :

2017-09-23 18:48:38,321 WARNING  emoncms    emoncms couldn't send to server, HTTPError: 406

I thought it was from a miss configuration from my apache server because when I tried to send data to emoncms.org I don’t have them.

Since I switch from 868 to 433 Mhz I don’t have them any more.

I also had in the same log file a lot of :

2017-09-23 21:58:48,230 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 3 103 129 162 47 71 198 54 53 3 43 81 226 246 225 27 196 1 152 192 123
2017-09-23 21:58:53,395 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 10 22 2 0 1 0 0 0 0 60 100 0 0

But not any more else.

Those are messages where the checksum is incorrect. Probably, it is trying to understand 4G. Now that the receiver is working at 433 MHz, those signals are not received.

If you do not want to send data to emoncms.org, then in emonhub.conf, in the [interfacers] part, [[emoncmsorg]], change:
senddata = 0           # Enable sending data to Emoncms.org

The OEM Shop now only sells 433 MHz as standard. If you think you might move house again and go back to using 868 MHz, you should buy 868 MHz. You can buy units without the RF module so that you can fit your own 868 MHz module if you decide to remain with 868 MHz.
If you are not likely to go back to 868 MHz, your new unit will transmit better at 433 MHz if it is a 433 MHz one. You might damage a RFM69CW module if you use it at full power on the wrong frequency.

I do not recommend that you try to change the RFM12B / RFM69CW modules on your old emonTx and emonTH. To do that without damage, you need the correct professional de-soldering equipment.

I’m not sure to understand.

If I keep using my 868 Mhz hardware at 433 Mhz on long distance I will damage it ? Or even on short one !?

In fact I just change the EmonHub setting (rapsberry pi one), so the node will still work at 866 Mhz…

I really don’t know how hardware will operate in fact …

The application notes for the RFM69CW used to warn that the transmitter output stage might be damaged if the transmitter is operated at or near maximum power without a correctly matched antenna. That would include operating at 433 MHz with a 868 MHz antenna, or vice versa.
This does not apply (as far as I know) to the RFM12B, which is a lower-power transmitter.
Link to identify your radio module.

Is there any possibility your kit is 433MHz and not 868 as you recall?

If ALL you did was change the setting in emonhub.conf from 868 to 433 without uploading new “433” firmware to the emonTx and emonTH, then the receiver would be listening on 433MHz whilst the nodes were still transmitting on 868MHz and you would receive no data.

Alternatively if you have uploaded new “433” firmware’s and also changed the emonhub setting so all your devices are 868 hardware, reconfigured to use 433, then that’s pretty impressive that they work when both ends are running incorrect frequencies, normally configuring a device to run at the wrong frequency is to match another device(s) so only one tends to be “wrong” rather than both the transmitter and receiver.

Can you confirm the frequencies of the hardware as well when you identify the module as Robert suggests?

I’m not entirely sure where that setting has come from.

If you do not want the facility to send to emoncms.org the correct thing to do is to comment out either the whole [[emoncmsorg]] block of settings from the conf (more intuitive) or just comment out the type = line so that the interfacer instance doesn’t exist (shortcut - just one hash does the trick). All that setting appears to do is not send the data it collates and holds in memory, to emoncms, a sort of “pause sending” rather than disabling the redundant interfacer.

The original emonhub code had pause input and pause output functionality for every interfacer inbuilt, I think that got stripped away with the emonpi variant of emonhub as it wasn’t wanted, strange it was partially reintroduced under a different name…

Thanks for clarifying that, Paul. It came from emonhub.conf (RPi version) so in the absence of full and explicit documentation, I took it to do what it said “on the tin”. I’ve put your explanation in my personal FAQ file.

Note: the RFM modules do appear to work on a harmonic (i.e. the ends at different frequencies), but the range is extremely limited, 10 - 20 cm. I’m not sure which way round they work. They certainly work better when both ends are at the same frequency, even when that is not correct for the hardware.

That’s open source for you.

Exactly, the fact that’s what he had prior to changing the setting in emonhub.conf and all is great since changing it, might suggest he was trying to run a 433 at 868 to start with and now he’s running 433 at 433, the range is as expected rather than performing spectacularly for what was believed to be deliberately ill-configured devices.

But the first line of Nomad’s first post says he has all 868 MHz hardware. I was believing that, especially as it was bought a few years ago - presumably before the shop dropped the 868 MHz range. As you say, it seems that it might have been a mix of frequencies all the time.

Since 868 MHz is very close to the second harmonic of 433 MHz, the 433 device will perform MUCH better at 868 MHz, than an 868 MHz device forced to work at 433 MHz. (No harmonic relationship in that scenario)

If memory serves, the specific frequency the 433 radio operates at is 433.92 MHz,
which yields a 2nd harmonic of 867.84 MHz.

I’m quite sure to order 868Mhz, I have to check my bill for that.

But till I had trouble with one node in my first setup several years ago cause by several interferances, I remenber to have check carrefuly my hardware.
That time it came from electric cable and washing maching with induction motor.

All my antena are the same… long one and white.

The thing that point to what Paul says is maybe my RaspberryPi Module is a 433Mhz with a 868Mhz antena or something like that because under the 433Mhz case is check.

I have this one.

I will check again this afternoon.

Please do that. The RFM12Pi can have either the 433 MHz or the 868 MHz radio fitted. The picture shows a 868 MHz version. The wire antenna is 165 mm long for 433 MHz or 82 mm long for 868 MHz.

Look carefully at your RFM module, and look for the capacitor marked with an arrow in the pictures here. That is how you know the frequency of the RFM itself.

sorry for the very long time before my answer.
So in fact you are right I’m in full 433Mhz
I just load a bad old config that came from my first setup…

The thing that confuse me is a real marking error that show I have a 866Mhz but it’s a 433…

I find an old mail discution I have with Aled in december 2013.
> On the print invoices inside the box, you write by hand that the Bundle
> is a 433Mhz as expected …
> But under the emonTX, the case 868 Mhz is check


Glad you got it sorted.

I suggest you correct the label so you do not get caught out again next time :slight_smile: