[solved] emonTH transmitting, emonBase not receiving

Hi all.

I just tried to setup a new emonTH.

I assembled it (if I had known it was so easy, no soldering and all, it would have been done a long time ago...) and I stuck two rechargeable AA batteries in it.

Unfortunately, the base does not seem to receive anything.

I plugged the UART <-> USB cable and here's the output :

emonTH
OpenEnergyMonitor.org
Node: 19 Freq: 433Mhz Network: 210
Detected DHT22 temp & humidity sesnor
No DS18B20 detected
DHT22 Temperature: 22.50C, DHT22 Humidity: 70.30%, Battery voltage: 2.60V
DHT22 Temperature: 22.40C, DHT22 Humidity: 70.60%, Battery voltage: 2.60V
DHT22 Temperature: 22.30C, DHT22 Humidity: 70.80%, Battery voltage: 2.60V

This confirms the frequency is 433 and the sensor is detected.

In the gateway, the config is :

[[RFM2Pi]]
    type = OemGatewayRFM2PiListenerRepeater
    [[[init_settings]]]
        com_port = /dev/ttyAMA0
        port_nb = 50012
    [[[runtime_settings]]]
        sgroup = 210
        frequency = 4
        baseid = 15
        sendtimeinterval = 0

Both emonTH and gateway codes are a bit old. I was sent the TH in February. Ultimately, I may load a newer code, but I don't think it should make any difference, should it ?

The base receives the signal from a TX in another room through two walls, whereas the TH is sitting two meters away in direct sight.

Before changing the firmware, I was wondering : is that 2.6 V voltage enough ?

The screenshot in the emonTH page shows 2.90 V.

The RFM12B page says 2.2-3.8V.

Thanks.

 

Jérôme's picture

Re: [solved] emonTH transmitting, emonBase not receiving

I just found a pair of non-rechargeable batteries. The voltage is higher, and still no result.

emonTH
OpenEnergyMonitor.org
Node: 19 Freq: 433Mhz Network: 210
Detected DHT22 temp & humidity sesnor
No DS18B20 detected
DHT22 Temperature: 21.70C, DHT22 Humidity: 74.40%, Battery voltage: 2.80V

With the voltage issue ruled out, I suppose I need to try loading a new firmware.

Jérôme's picture

Re: [solved] emonTH transmitting, emonBase not receiving

I recompiled the latest emonTH firmware version but no luck.

emonTH - Firmware V1.2
OpenEnergyMonitor.org
Node: 19 Freq: 433Mhz Network: 210
Detected DHT22 temp & humidity sesnor
No DS18B20 detected
DHT22 Temperature: 22.40C, DHT22 Humidity: 72.10%, Battery voltage: 2.80V
DHT22 Temperature: 22.30C, DHT22 Humidity: 72.10%, Battery voltage: 2.80V
DHT22 Temperature: 22.40C, DHT22 Humidity: 72.00%, Battery voltage: 2.80V

Still nothing coming in.

 

Robert Wall's picture

Re: [solved] emonTH transmitting, emonBase not receiving

For what it's worth, I've had an emonTH working to a NanodeRF over 30 m (clear line of sight) at 868 MHz on two rechargeable cells.
Have you checked that you really have a 433 MHz transmitter? All "433 Mhz" means is the sketch is set to that, it does not mean the hardware is correct.

Jérôme's picture

Re: [solved] emonTH transmitting, emonBase not receiving

Hi Robert.

I had checked in the shipping list but I didn't know how to check physically. Thanks to your link, I could check it is indeed a 433 MHz.

Robert Wall's picture

Re: [solved] emonTH transmitting, emonBase not receiving

Probably not much help, but a pair of 868 MHz units, emonTx and GLCD, both set in software to 433 MHz, can communicate over 200 mm only.

Jérôme's picture

Re: [solved] emonTH transmitting, emonBase not receiving

I just checked the soldering of each pin of the RF module with the ohmmeter: one wire on the motherboard, one wire on the RF board, to check the current passes through (not obvious by visual inspection, the SMT soldering is very thin (compared to my dirty hand solderings...)). All pins are fine.

pb66's picture

Re: [solved] emonTH transmitting, emonBase not receiving

Hi Jérôme.

​see http://openenergymonitor.org/emon/node/5819 for a "similar" issue except in that case the emonTH did manage to get some packets through although not as effectively as the emonTX.

Although you have ruled out the batteries if it were me, I would have the emonTH powered by FTDI lead and sat right next to the rfm2pi until I got it working and then work back.

In the emonTH sketch the LED pulse is also commented out, for testing I would have the LED enabled, in fact I would have the "send" code within the led code ie ledpin high -> send data -> ledpin low. if the led flashes rather than staying on or off I could probably assume the "send" code ran, I would also reduce the interval between sends whilst testing.

With this done if it still doesn't work I would try switching off the emonTx temporarily to check for clashing or blocking, assuming of cause that the led is flashing on the emonTH without a corresponding flash at the rfm2pi.

You could also try switching off quiet mode on the rfm2pi to see if anything is being received in time with the emonTH sends, that maybe being discarded as it's incomplete or corrupt.

Paul

Jérôme's picture

Re: [solved] emonTH transmitting, emonBase not receiving

Oh boy.

I'm just realizing I changed the bitrate a while ago on both the base and the TX because I had range issues.

(I use the lowest possible. I never took the time to try all of them and see if I could pick a higher one.)

I even checked the bitrate recently as I was planning to use the emonTH, and then I totally forgot about it.

No wonder I was getting nothing at all...

Anyway, if someone has the same kind of trouble, the debugging steps proposed by Paul make perfect sense.

Thanks.

Sorry for the noise...

Jérôme's picture

Re: [solved] emonTH transmitting, emonBase not receiving

I'm wondering if the bitrate should be added as a parameter, like Node ID and all. And reported in the logs.

I'd like to do it for myself and propose a pull request. But maybe it brings too much confusion and serves too few people.

 

Jérôme's picture

Re: [solved] emonTH transmitting, emonBase not receiving

Confirmation: I modified the bitrate in the emonTH sketch and it works as expected.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.