emonGLCD / emonTX no communication

Hardware
1

Today I have assembled my emonGLCD kit but it fails to get data from emontx.

It can communicate to / from emonbase (get time and send temp value).
I have edited the emontx payload struct in the sketch to be compatible with data format as in emonhub (as indicated in other topic) and changed nodeid to 8 as in emonhub config file.

I have also edited the sketch to log any nodeid message it receives and I correctly get all 4 emonth devices and the emonbase in use.

The only communication problem is with emontx.

Can somebody help on this ? Thanks a lot

2

Have you also edited the GLCD receive payload to be compatible with the transmitted payload of the emonTx, and set the emonTx’s NodeID in the receiving part of the GLCD sketch?

This is necessary because I don’t think the emonGLCD sketch has been updated with recent changes to the emonTx sketch(es).

3

Yes I did it ; this is my editing

typedef struct {
int power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6;
unsigned long pulse;
} PayloadTX;
PayloadTX emontx;
…
if (node_id == 8) {
emontx = (PayloadTX) rf12_data; //Assuming 10 is the emonTx NodeID
last_emontx = millis();
}

Thanks

4

For completeness, I have an emonbase which is running latest Emoncms 9.8.10 | 2017.08.17 and an emonTx V3 - Electricity Monitoring Transmitter Unit - 433MHz which I received on Feb 2016 and that has never been updated (I do not know which firmware version it is running).

5

That could be your problem. The payload has changed over time, although I think it has not changed since V2.3 (November 2015).

If you connect your programmer to the FTDI port of the emonTx and press the ‘reset’ button, it should tell you the firmware version. I thought GitHub was supposed to keep all previous versions, but the earliest appears to be V2.6.

I think your best action will be to download and install the latest sketch - then you will know what you have.

[Edit]
Glyn has told me where the earlier versions are, and V2.3 is the same as what you have. But I still can’t find V2.2 The change notes say there was a change between V2.2 and V2.3 (the pulse count changed from what it doesn’t say to unsigned long).

[Edit 2]
Load this into your emonGLCD, it will show what is being received. It makes no attempt to fully decode the data, but as it displays the data as hex bytes, char, signed integer and unsigned long, you should be able to make a good guess as to what the format is. You will need to add
#define RF69_COMPAT 1
above
#include <JeeLib.h>
if you are using an RFM69CW radio. (My old emonGLCD has the RFM12B.)

emonGLCD_Debug.ino (9.2 KB)

Read the comments for instructions.
(If it misses a message, don’t worry - it does from time to time. I need to speed up how it writes to the display.)

6

Hi Robert
Thanks a lot for your extended support.

I am running your sketch (with #define RF69_COMPAT 1 and #define DEBUG enabled) and I can see all RF nodes (emonth devices (nodeid 23, 24, 25) and emonbase (nodeid 5)) in my system EXCEPT emontx.

Here is serial debug log :

emonGLCD Debugger
openenergymonitor.org
RF received - Node 24
Val1=167, Val2=0, Val3=660, Val4=26, Val5=1, Val6=0 
RF received - Node 23
Val1=186, Val2=0, Val3=596, Val4=28, Val5=1, Val6=0 
RF received - Node 5
Val1=3584, Val2=51 
RF received - Node 25
Val1=189, Val2=0, Val3=567, Val4=28, Val5=1, Val6=0 
RF received - Node 24
Val1=166, Val2=0, Val3=657, Val4=26, Val5=1, Val6=0 
RF received - Node 23
Val1=186, Val2=0, Val3=596, Val4=28, Val5=1, Val6=0 
RF received - Node 25
Val1=188, Val2=0, Val3=567, Val4=28, Val5=1, Val6=0 
RF received - Node 24
Val1=166, Val2=0, Val3=657, Val4=26, Val5=1, Val6=0 
RF received - Node 23
Val1=186, Val2=0, Val3=596, Val4=28, Val5=1, Val6=0 
RF received - Node 25
Val1=188, Val2=0, Val3=567, Val4=28, Val5=1, Val6=0

Instead I confirm that emonTX and emonBase are communicating correctly. Sort of radio incompatibility between emonTX and emonGLCD.

Do you suggest to flash latest firmware onto emonTX ?

7

Are all your units operating on the same radio frequency? (Look at Learn > Electricity Monitoring > Networking > Which radio module)

According to the GLCD, there is nothing transmitting as Node 8. (The original sketch would not have shown the emonTx if the payload was wrong, the debugger sketch shows all that it receives.)

Can you confirm that your emonTx is being received by the emonBase, and that it is Node 8?

8

emonTX, emonBase and emonGLCD have the same radio module : RFM69CW - 433 MHz. They all have the extra capacitor but no gold and green spots.

Yes, I confirm that emonBase is receiving radio packets from emonTX. Here is an abstract from emonHub log from emonbase :

2017-11-09 16:58:56,393 DEBUG    RFM2Pi     47 NEW FRAME : OK 8 5 2 233 255 2 0 250 255 197 96 186 0 184 11 184 11 184 11 184 11 184 11 1 0 0 0 (-27)
2017-11-09 16:58:56,397 DEBUG    RFM2Pi     47 Timestamp : 1510243136.39
2017-11-09 16:58:56,398 DEBUG    RFM2Pi     47 From Node : 8
2017-11-09 16:58:56,399 DEBUG    RFM2Pi     47    Values : [517, -23, 2, -6, 247.73000000000002, 18.6, 300, 300, 300, 300, 300, 1]
2017-11-09 16:58:56,400 DEBUG    RFM2Pi     47      RSSI : -27
2017-11-09 16:58:56,401 DEBUG    RFM2Pi     47 Sent to channel(start)' : ToEmonCMS
2017-11-09 16:58:56,401 DEBUG    RFM2Pi     47 Sent to channel(end)' : ToEmonCMS

I also confirm that emonBase is sending time value to emonGLCD correctly after enabling the “interval” option in emonhub configuration.

To summarize EmonTX → EmonBase → EmonGLCD radio communication is ok but no EmonTX → EmonGLCD. I also moved the emonGLCD a few centemeters from emonTX to avoid problems with weak power signals but still no success.

9

There is only one really noticeable difference with the emonTx payload, it’s size is considerably bigger than any others.

If you are comfortable experimenting with sketches, I would suggest trying to comment out that string of 6 unused temp sensor readings which will half the payload size.

It shouldn’t matter, but If I recall correctly, the emonGLCD stack struggles a bit, so putting 2 and 2 together to make 5, perhaps the big payload is just a tad too much for it?

Or perhaps you could try removing the rf12_crc == 0 && from line 133 of Roberts GLCD test sketch, which I believe would then print payloads that fail the CRC checks (currently anything thaty fails CRC is discarded)

10

Hi Paul
I am at ease with programming so I can make any suggested sw changes.

Do you suggest to comment the 6 temp value in the payload struct at the trasmitter side (emonTX) or receiving side (emonGLCD) or both ?

Before placing my problem in the community forum , I made several changes to the emonGLCD sketch trying to isolate and solve the problem .
At first I was fearing I soldered the kit wrongly and that there was a hw problem with the radio module. For this reason
I changed the sketch to log all RF message nodeIDs that were received before any CRC check and before any payload decoding as you suggest as in the following code :

if (rf12_recvDone())
{
Serial.println(); Serial.print(“RF12 pack received”);
int node_id = (rf12_hdr & 0x1F);
Serial.print(" - From node "); Serial.print(node_id); Serial.println();
…

Similar to the output of Robert’s sketch, in the serial console I get all nodeID trasmitting on air except nodeID = 8

…
RF12 pack received - From node 23
RF12 pack received - From node 24
RF12 pack received - From node 25
RF12 pack received - From node 23
RF12 pack received - From node 5
RF12 pack received - From node 25
…

So I am rather sure I assembled the emonGLCD correctly (the radio module is working) but no communication with emonTX.

11

Checksums etc decree that you must have the same payload length at each end, else the message will be rejected, and the correct structure too for it to be decoded correctly. So the answer is both - for the standard sketch with all the checks. My debug sketch is not concerned about the length, it shows the value from the message header, so if Node 8 appears in the GLCD debugger when you do that, or when you delete the check as Paul suggests, it’s proven to be a bad checksum, so probably a loss of sync between transmitter and receiver.

How far apart are the emonTx and GLCD? If they are close, move them apart by a few metres, just in case the problem is overloading.

I agree there.

12

NodeID 8 does not appear. If we cannot solve this any test about crc, payload etc can be postponed

The LCD has been installed about 10 meters from emonTX but I moved it near the emonTX just for checking if problem was signal power: result is no communication in any case.

13

Robert, Paul
I have a question for you experienced users in order not to solve the problem but to get the power reading in the LCD : is it possible to use the emonbase as a relay to send the payload received from the emonTX ?

I know how to enable emonbase to trasmit time value correctly to the LCD but I have no idea how to send power readings as well .

Thanks

14

Did you remove the CRC check as Paul suggested

and did Node 8 (or anything new) appear?

This is really confusing. I cannot think of any more reasons why the GLCD will not receive the emonTx. You have proved it is receiving the emonBase and the emonTHs, you have proved the emonTx is transmitting because the emonBase receives it, and unless it was in a “dead spot” where there was no signal and you moved it to another dead spot with no signal (which is extremely unlikely), then we think the signal is getting there, but it is not being decoded.

15

Yes, that’s very strange. I am running out of solutions.

Could you help me explaining if emonbase could be use to transmit other data in addition to time ?

Right now emonbase trasmits a payload with a time value; if I could add the power readings this would let me display FV production and home consumption on the emonGLCD.

Thanks again

16

I can’t help you there, but I think Paul @pb66 will be able to.

This is certainly the first time I have heard about this problem.

@Martin_Harizanov Have you ever come across anything like this?

17

Pre-emonpi variant versions of emonhub could, I have no idea how intact that code is currently without a lot of digging.

You can search the old forum for examples involving the old packetgen module (now retired) and the emonGLCD.

This would have been a simple config edit if emonhub had continued on the path it was on.

However, This seems a very complex way around the issue.

The debugging isn’t complete and I do not believe your emonGLCD has something against that particular emonTx. If emonhub can see all your nodes, assuming they are all within a close proximity, the emonGLCD should have no reason to not receive from the emonTx.

Try reducing the size of the emonTx payload.

Try changing the emontx node Id.

You could even try loading a emonTH sketch to the emonTx and set it’s node Id to one that your emonGLCD is known to receive. (obviously remove the batts from the emonTH you have cloned).

If when sending the same size data frame from the same node id, the emonGLCD still refuses to listen to the emonTx then that would indeed be odd.

Remember to remove the crc checks whilst doing these tests, you are not interested in whether the payload is intact, you only want to know if the payload can be seen at all at this stage.

18

Paul
your suggestions are straight and clear.

Could you just confirm me that emontx3/src.ino at master ¡ openenergymonitor/emontx3 ¡ GitHub is the right sketch for my emonTX V3.4 433MHz ?

I will keep this thread updated with results of suggested tests.

Thanks a lot for your support.

19

To my knowledge that is the current FW yes. I do not think you have yet confrimed what version your emonTx is running so I cannot be sure if it is what you already have, yours maybe the same or slightly earlier than v2.9, although it shouldn’t matter. It would be nice to know what you have to start with. Just incase you find all the tests are ok and when you reinstall the correct firmware, if it works, we will know if it is the same FW version reinstalled or an updated FW.

[edit]

if just changing node ids, be aware of the dip sw settings, as you may not get out the node id you put in.

20

My current version is “emonTx V3.4 Discrete Sampling V2.30 RFM69CW”