EmonTX v3 taking a walk

Hardware emonTx
21

No not really, All that short clip shows us is that for 2mins 20secs there were no valid transmissions received from node 10, but that isn’t conclusive as if you look at the previous “working” log you posted the emonTx seems to be posting every 6secs which isn’t a standard interval time and there is a period of 25 secs between 2 frames so some packets are being lost even during “good times”.

(taken from the “working” log)

09:17:03,931    OK 10 127 11 4 12 25 4 205 3 26 47 0 0 0 0 0 0 0 0 0 0 0 0 1 0 (-59)
09:17:28,264    OK 20 23 0 122 1 254 0 0 0 (-56)
09:17:28,497    OK 10 115 11 219 12 17 4 173 3 2 47 0 0 0 0 0 0 0 0 0 0 0 0 1 0 (-55)
09:17:34,662    OK 10 184 7 27 9 37 4 187 3 27 47 0 0 0 0 0 0 0 0 0 0 0 0 1 0 (-54)
09:17:39,645    OK 21 0 0 28 2 205 0 206 0 246 0 (-60)
09:17:40,877    OK 10 164 7 215 7 25 4 217 3 26 47 0 0 0 0 0 0 0 0 0 0 0 0 1 0 (-54)
09:17:46,956    OK 10 153 7 181 9 16 4 196 3 40 47 0 0 0 0 0 0 0 0 0 0 0 0 1 0 (-55)
09:17:53,185    OK 10 96 11 82 13 21 4 198 3 14 47 0 0 0 0 0 0 0 0 0 0 0 0 1 0 (-55)
09:17:59,271    OK 10 163 7 219 7 21 4 193 3 37 47 0 0 0 0 0 0 0 0 0 0 0 0 1 0 (-59)

(taken from the latest log)

12:17:12,081    OK 21 0 0 157 1 228 0 235 0 250 0 (-64)
12:17:45,478    OK 21 0 0 163 1 229 0 236 0 249 0 (-67)
12:17:53,633    OK 20 23 0 156 1 235 0 0 0 (-63)
12:17:57,480    OK 19 219 0 0 0 195 1 26 0 (-35)
12:18:18,873    OK 21 0 0 166 1 228 0 236 0 248 0 (-63)
12:18:49,814    OK 20 22 0 158 1 235 0 0 0 (-63)
12:18:52,227    OK 21 0 0 164 1 229 0 236 0 248 0 (-66)
12:18:55,608    OK 19 219 0 0 0 195 1 26 0 (-31)

nodes 19 and 20 seem to be updating every minute and node 21 every 30secs is that correct?

Is this latest log the very last bit of log or is it a random snippet?

Is there absolutely no node10 packets beyond this point?

How long ago since the last node 10 packet?

How regular were the packets immediately prior to the last recorded packet?

What was the RSSI of the last few node 10 packets?

There is no evidence of bitslip in this short clip of log, but there isn’t really any strong evidence of anything.

I still recommend loading the latest firmware to node 10 to eliminate any known and fixed issues before anything else and also check the posting regularity over a longer period.

22

Ok, so I finally tried loading up the latest version. After four trips to the garage, it seems a bunch has changed between the v1.8 that I’ve been running and the 2.9 that is current that I need to figure out. When I initially changed only the calibration values to match what I had been running, it started reporting as node 8 (instead of 10). I looked again and found that the node in the latest version was set to 8, rather than 10 like in 1.8. Changed it to 10, but then it appeared to be reporting as node 9 but no data. Upon looking at more, I noticed that it seems that between 1.8 and 2.9, the pins for ‘DIP_Switch1’ and ‘DIP_Switch2’ were swapped - in 1.8, 1 is 8 and 2 is 9, in 2.9, 1 is 9 and 2 is 8 (well, actually, the swith to pin is the same, but what they do is swapped). Swapped them and I was still not getting proper data.

So I’ll have to sit down and figure out what’s changed and how to make it report the same.

Also I noted that when compiling the 2.9 sketch, ArduinoIDE was complaining about ‘Low Memory, stability problems may occur’. Any thoughts on that?

23

If i recall correctly the change in node id was to indicate a change in packet format in the form of an additional 2 bytes when the “pulse” was changed to a 32bit unsigned long, from a 16bit signed int.
Assuming your node 10 conf in emonhub.conf was like so

[[10]]
    nodename = emontx1
    [[[rx]]]
       names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
       datacode = h
       scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
       units =W,W,W,W,V,C,C,C,C,C,C,p

the payload from the new emonTx sketch should be node 8 by default and uses this default configuration

[[8]]
    nodename = emontx3
    [[[rx]]]
       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
       scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
       units =W,W,W,W,V,C,C,C,C,C,C,p

which you will need to alter the node id for so that is marries up with your existing emoncms data like so

[[10]]
    nodename = emontx3
    [[[rx]]]
       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
       scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
       units =W,W,W,W,V,C,C,C,C,C,C,p

The data should still get through even without this edit though, but I would recommend doing this up front if you log RSSI as using the new emonTx payload without this edit will result in the “pulse” long being decoded as 2 16bit ints, the second of those will land on your current “RSSI” input in emoncms and a new input will be created with the RSSI value.

I was not aware of any issues with the DIP switches so I cannot really comment on that, I’ve not heard any other reports along these lines though.

Nor was I aware of the “low memory” warning, I’m guessing it’s the more recent additional serial prints for use with the emonESP that has pushed the memory use up, you could try commenting out all those extra prints if you are concerned, but the warning doesn’t usually mean a problem is imminent.

Are the leds on the emonTx and the emonBase still flashing (albeit slightly slower at 10s intervals) ? Is anything logged in emonhub?

24

Quick update on my wayward EmonTx…
Things have warmed up here, and it’s back to hanging up periodically - roughly once a week.
I am now running it on batteries (and removed JP2), but it just hung up again - so perhaps not power supply issues?
Thanks,
Sandy

25

What sort of emonTx are yours - V3.2, V3.4 or V3.4.1?

26

Looks like it’s a ‘3.4.1 Mar 2015’. Shipped 17-Jun-2015, firmware hasn’t been updated.

27

How warm?

28

Around when the high started reaching 25C

29

That, on its own, shouldn’t be causing the problems. I think it’s time to ask [email protected], and mention this thread.

30

Hi Robert,
I’m not too worried about mine, resetting it isn’t that big a deal. My initial comments were rather just in support of Dave - but it’s sounding like our issues might be different. Next time I order something from the store, I was indeed thinking I’d get a replacement.
It’s a little strange, I had a emonTH go out on me a year or so ago; also spontaneously, but rather more fatally (replaced already). Climate here certainly runs hot & cold, but it’s typically quite dry - so not too electronics unfriendly, at least until you start poking at them with electrostatic fingers!
Thanks, Sandy

31

I Sandy,

I see you’re in Salt Lake City. (I’m in SW Oklahoma)
Having worked temporary assignments (2-3 weeks) at Dugway PG and The Knolls, I’m somewhat familiar with the area, but don’t have any long term experience there.

I’m curious, do you get any salt driven corrosion from the lake and flats?
(for the UK readers - flats refers to the Bonneville Salt Flats vice dwellings)

32

It might sound stupid, but I assume it’s not being interfered with by the local wildlife?

But if it’s only one out of the four, that are all in much the same environment, it looks like a manufacturing quality problem, and the shop/developers should at least be aware of it.

33

Hi Bill,
There are a couple of days a year when the winds blows in from the Lake (and beyond that the flats) & the city drains dept. gets calls from half the town about the bad smell! But usually not an issue, not heard of it being blamed for corrosion anyway. The snow plows in winter on the other hand drop enough salt to kill anything trying to grow too close to the street - and the cars.

Robert,
The Tx’s are in an enclosed garage (with the breaker box), so “wildlife” like spiders, certainly possible - but I checked & didn’t see any evidence. I have seen the birds go after one of the outdoor (but sheltered) THs - but not the one that died!
Thanks,
Sandy

34

Where are you seeing this emonTx “not working” is it just in the graphing?

Have you checked the led on the device (not when battery powered)?

Do you check the emonhub.log?

Can you post some emonhub.log?

In your original post you say the 4 emonTx are “sharing an AC-AC power supply”, can we assume you are also using a 5v AC:DC power supply to power them all too (until you moved this one to battery) and not powering them all via the AC:AC?

Do you have any attached temp sensors? Do any unused temp sensors report 0 degC or 300 degC?

The fix for packet loss due to bitslip caused by unused temp sensors was added in Oct '15 as was the fix for the send interval of >10s causing “apparently” missing data in fixed interval feeds, so I would definitely try a firmware update before writing off the hardware.

The issue may still be linked to temp as you suspect as component tolerances and RF behaviour can be affected by temp, so maybe something like “bitslip” could be more evident at certain temps perhaps.

35

Hi Paul,
When it stops, the LED doesn’t flash, the time since last data on the input & feed pages keeps increasing - and yes, no data in the multigraphs!

I looked at the emonhub.log when it started a year or two ago - and I didn’t see anything (though my looking may not mean much!). Next time it happens I’ll try to save the log (looks like I have to get to it in about 30 mins before it gets overwritten).

No, I really did mean all sharing a single AC:AC power supply! I know this can do wonders for the accuracy, and I was mildly suspicious - which is why I tried the batteries. I figure that normally, if there’s only 1 TX active at a time, then the idle draw for the other 3 should be fairly minimal. And if 2 of them do go active at the same time, then the radio signals are likely to get garbled anyway. Accuracy seems reasonable; I’m measuring input usage, and also individual branch circuit usage - and the sum of the branches matches quite nicely to the measured total.

One of them does have a single external Temp sensor - but not the one that’s having problems.

Oct '15 - so yes, I won’t have that one. OK, I’ll give the new firmware a try before giving up on it!

Thanks!
Sandy

36

When all four are running from the same AC:AC adapter, assuming it’s a fairly mainstream one, I would expect a very poor wave form to be seen by all 4 emonTx’s, if not all the time, then certainly at random intervals as the emonTx’s are not synced.

If 2 attempt to transmit at the sametime’ish the trailing device should not transmit until it see’s a clear opportunity to do so, that is the leading device should block the trailing device from transmitting until it’s finished transmitting. During that time you will have 2 RFM devices powered up and from experience with the RFM2Pi’s I suspect the rfm69 device to brownout before the emonTx’s, if that one emonTx has a slightly lower tolerance than the others, it could be locking out the rfm69 when ever it clashes with any other device.

The move to batteries might rule that out, but I do not think it is conclusive, there simply isn’t enough users using battery powered emonTx’s to be sure of the edge cases, especially if the batteries are not 100%, bear in mind the battery life in the emonTx’s at 10s intervals isn’t great. I would recommend trying a 5v PSU too, even if just to rule it out.

The best way to have your 4 emontx’s set-up is one AC:AC for sensing only and one 5v AC:DC adapter to power all the emonTx’s via the programming header or the screw terms, removing all the JP2’s, this will almost certainly improve accuracy and performance, whilst still using half the “normal” number of AC adapters.

Also do you have any pulse counters attached? We recently learnt that the emonTx doesn’t perform as expected with a pulse counter connected when running on batteries, whilst it would normally manifest itself as too many rather than a shortage of sent packets, in this instance it would also increase the power consumed, eating into battery life and/or increasing the odds of clashing with another emonTx significantly.

A known good solid power supply and a firmware update are definitely worth trying IMO.

37

I certainly support Paul’s recommendation to use a 5 V d.c. supply to power all four emonTx’s, and a single a.c. adapter to provide the reference voltage. The Wiki clearly states:

“Important note regarding powering with AC: powering via AC is recommended only for standard emonTx operation without auxiliary sensors (apart from a maximum of 4 DS18B20 temperature sensors) or equipment (e.g. relay modules) connected. Correct operation via the AC supply is critically dependent upon using the correct AC-AC adapter. If you are using the recommended AC-AC adapter and the current draw exceeds 10 mA and the mains supply is below the minimum allowable, then circuit operation will be impaired, adversely affecting the accuracy of the emonTx.”

38

Hi Paul, Robert,
Yes, I did see that, and I do know that my power situation is a little “iffy”!
I put it together initially as a “quick & dirty” to get things going - and it seemed to work, so I left it!! Accuracy was reasonable (branches added up to total). But I’ll give this a try too.
Thanks,
Sandy

39

Sorry I’ve been hit or miss - time has flown. Just a little update, since I tried the newer firmware and then re-loaded the previous firmware, knock on wood, so far, it hasn’t dropped off again Rather strange. But with the release of the IotaWatt, I think I’m going to upgrade to that.