EmonGLCD does not read time nor Power

Hardware
21

I do not see any Green LED flashing at all. Could you resend me your test sketch? … just in case …

22

Just for information, I have attached my current sketch (not the Debut one) which receives the EmonPI time, EMonTH data.HomeEnergyMonitor_Hoplite2.zip (5.8 KB)

23

That sketch (HomeEnergyMonitor_Hoplite2) should not receive data from your emonTx, because the receiving structure does not match the equivalent in the emonTx - which you have not changed because your emonPi works.

You have
typedef struct { int power1, power2, power3, Vrms; } PayloadTX;
It does not have the temperatures nor the pulse count. Even though you might not want to use and display those, they must be included, because otherwise the checksum fails and the data is rejected. That is one reason why it does not receive the emonTx. There might be other reasons also.

Here is
emonGLCD_Debug.zip (3.2 KB)
You must change
#define RF69_COMPAT 0
to
#define RF69_COMPAT 1
to suit your RFM69CW.

24

Thanks for the new DEBUT sketch.
It works well and I receive the Node 5, 19 and 26. In otehr words, the EMONPI, and my two EmonTH’s but never the EmonTx is mentioned (node 8).

25

What is the distance, in a straight line, between the emonTx and the emonGLCD?
What lies between them?

26

about 3meters. But my EmonPI and my GLCD are just near each others. Also I have tryed to put the GLCD close to the TX without any success either.

27

The TH is even further away between walls.and the reception is perfect for it.
Could it be we have a packaet colision ie at teh same time each time? - if so I cannot get why the EmonPI would get the data.

28

It is possible then, that the signal is too strong, or that the emonGLCD is being swamped by electrical noise from the emonPi. Can you try moving the emonGLCD away from the emonPi?

I do not think anyone else had reported that as a problem. I think the only way that could happen is if the emonPi transmitted the time at the same time as it was receiving data from the emonTx, and that is impossible - it can only do one thing at a time. If it was anything else causing the collisions, then because each has its own clock, they would eventually drift out of synchronism and the data would get through.

There is a very small possibility that this could happen, if the emonPi was shielded from the interfering signal and the emonGLCD was not. The interfering signal need not necessarily be from your equipment.

29

I have tried to move the GLCD away from the EMonPI and also close to the Tx, no change.
May I ask you the Sketches for the EmonTx V3 and I would upload the Sketch again … just in case.

If the Sketch is the same, I should see no difference at all but it is the only thing which I have not yet tried.

30

The emonTx sketch is available on GitHub:

I recommend you do not change the emonTx sketch. The emonPi is receiving it correctly, and the emonGLCD is, or should be, receiving the very same radio transmission.

Your emonTx data structure should be:

typedef struct {
  int power1, power2, power3, power4, Vrms, temp[6];
  unsigned long pulseCount;
} PayloadTX;

You wrote that your emonPi config. is:

names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
datacodes = h,h,h,h,h,h,h,h,h,h,h,L

Both represent 11 integers and one unsigned long integer, so they are consistent. The only thing that can be wrong is your emonGLCD.

What I do not understand is how the emonPi can receive from the emonTx and the emonTHs, but the GLCD, especially with the debug sketch - which will receive anything from any node - cannot receive from the emonTx when it can from the emonPi and the emonTHs.

31

You could try compiling the emonGLCD sketch with an earlier version JeeLib.

The current emonPi, emonTH and emonTH sketches are all compiled with outdated JeeLib

When the emonPi firmware is compiled with a later JeeLib it fails to receive emonTx packets (Or least that used to be the case, see Emon TXs not updating after Emonpi update - #12 by glyn.hudson)

[edit - also see “emonTx Node Communicates to one RFM69Pi, but not another” for a similar issue with a RFM69Pi recompiled with a later JeeLib, and again here “Recompiling RFM69Pi firmware - #6 by adpeace”]

32

@Hoplite

@pb66’s post just made me remember the problems we had when the receiver and transmitter clocks lost synchronism while a long series of zero values - the temperatures - was transmitted. But it cannot be that - your unused temperatures report “300”.

33

Hello.
I’ve just changed the jeelib library as proposed earlier by pb66.
I have then run the DEBUG sketch and I can now see my EMonTX perfectly well.

Many thanks for your help Guys! Very appreciated.

Laurent

2 Likes