This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1101: WMBus 868 - trouble receiving at short range

Part Number: CC1101
Other Parts Discussed in Thread: WMBUS

First, let me preface this by mentioning that I am not experienced with the CC1101 (or any of the siblings for that matter), so my question is possibly really dumb - please bear with me.

My project is a WMBus receiver based on the open source project found here (this is just the fork I used):

https://github.com/chester4444/esp-multical21

The CC1101 module is the same one shown there, and what I have done is to refactor the code a bit to my own liking, and also added support for a different meter type (which has nothing to do with the radio part, it is just the payload that is different).

My CC1101 register settings are the same as can be found in the WaterMeter.h file (which seems to closely match appendix D in application note AN067)  from the above mentioned repository:

https://github.com/chester4444/esp-multical21/blob/master/include/WaterMeter.h

My project is actually working brilliantly for the most part, and if my receiver is placed at a reasonable distance (and perhaps also with walls in between) from the water meter (which is the transmitter), it will receive and decode more or less 100% of the messages sent from the water meter (there is one message sent each 96 seconds, approximately).

However, my preferred placement for the receiver is pretty close (around 50 cm or so) to the water meter (there's a power outlet there), and with that placement I am losing quite a few of the telegrams (maybe 10-20% or so), which is annoying. I am not sure how to figure out why this is, but one guess is perhaps that the signal strength is somehow too high, and thereby confusing the CC1101. The antenna is just a coil, and was supplied with the module (which was purchased from one of the many AliExpress suppliers), so it is all very simple. I assume the schematic is just a reference design, but I haven't tried tracing it out to verify.

My question is whether there are any register changes I could try (for example to the AGC registers) to improve on the situation when the receiver is at close range, assuming that the signal strength might be too high, or if there is no point in trying. Any suggestions for things I could try is appreciated, but in the end I can of course move the receiver to some location further away if need be.

  • No, I hadn't seen that document, so thank you for the pointer!

    I did a quick test by just setting the attenuation to max as outlined in that document (I didn't bother making it dynamic as described, as my receiver is only ever going to receive data from that one transmitter), but it doesn't seem to make much of a difference. I have two receivers running now, one that is in the close position, and one that is in another room, separated by one wooden wall (distance around 2-3 meters). Both receivers runs the same code, where the attenuation in FIFOTHR.CLOSE_IN_RX[1:0] set to max (18 dB), and the receiver that is farthest away is barely losing any telegrams, while the closest one still loses quite a few.

    I have made changes that allows me to see some debugging info (by telnet), and it does appear that a fair amount of the lost telegrams are in fact received, but have errors in them that causes the CRC check to discard them (which is of the right thing to do). This does not happen to the other receiver (or at least extremely rarely), which is odd.

    I also added a readout of the RSSI register after receiving a telegram, but I don't know if that will accurately reflect the RSSI of the frame that was just received or not. I'll have to read up on that. Early indications seems to show that after receiving a successful message, this register reads as somewhere between 17 and 25 (decimal), while for the ones that fails the CRC check, it is above 28. The receiver that is farthest away seems to have less variance in the value of this register, and it is typically between 17 and 22.

  • Ok, it seems I found the problem. Next to the water meter there is a valve (to close the water supply to the house), and on that valve I have mounted a Zigbee-controlled servo motor that enables me to close the valve remotely in case of emergency. This servo has a power supply that is plugged into the same outlet as the power supply for my receiver, and the receiver itself is also sitting right next to the outlet.

    If I unplug the power supply to the servo, receiption becomes magnitudes better, and essentially packet loss goes more or less to zero. The RSSI indication now stabilizes at a value of around decimal 80 (with the aforementioned attenuation still set to 18 dB).

    Zigbee in itself should not be of any issue here I think, as it operates at 2.4 GHz (and my receiver also uses 2.4 GHz WiFi to send MQTT messages with the received data from the water meter). However, it is of course possible that the Zigbee radio in that servo is emitting loads of RF noise, but I rather suspect it is the power supply that is the culprit. I'll try to temporarily use an extension cord on that to move it away from my receiver (so the Zigbee radio in the servo is operational), and if the issue then goes away, I'll know it is the power supply. If it is still there, then the the Zigbee radio might be the problem, but that would surprise me.

    I removed the attenuation for the receiver that is farther away, and the RSSI for that one now sits around decimal 50.

  • Do you have a bead on the CC1101 3V power?

  • No, I don't. It is powered directly from the D1 Mini, and I didn't think to add a bead there. I'm not sure I have enough space to add one now, so the final solution is probably to get some more distance between that (presumably) noisy power supply and my receiver.

    What is also weird, is that now that I temporarily unplugged and replugged the power supply to that servo, the problem is not as severe as it was. I am sure it will return, beacuse I do recall that this issue has come in waves also in the past.