Archived Forum

I get similar occurrences with the v2 e.g my rain tipping bucket which just sends 0 or 1 suddenly a large negative value is received.

Hmmm, thanks.

I have now programmed up my emonGLCD to record these silly values. If the Pi still gets silly numbers, when the emonGLCD doesn't then suspicion must fall on the RFMPi gadget.

Thanks for the reply.

I'd be interested in your findings, I've had a couple more instances and I've noticed it can effect more than one sensor on a node when it occurs but of course it could still be the sensor/arduino or radio transmission. I also frequently get data from 'ghost nodes' which don't actually exist but more often than not the data is recognisable as being from an actual node so the node id has got garbled somehow in the transmission.

The probem is it seems to be very rarely that I get silly values. What appears to happen more often is that I get the bursts of the RFMPi trying to be helpful with its' command summary help. e.g.

Oct 30 02:30:07 (none) user.info syslog: monitor: Unknown packet Available commands:
Oct 30 02:30:07 (none) user.info syslog: monitor: Unknown packet   123 x      - Toggle configuration change protection, 1=Unlocked
Oct 30 02:30:07 (none) user.info syslog: monitor: Unknown packet   <nn> i     - set node ID (standard node ids are 1..26)
Oct 30 02:30:07 (none) user.info syslog: monitor: Unknown packet   <n> b      - set MHz band (4 = 433, 8 = 868, 9 = 915)
Oct 30 02:30:07 (none) user.info syslog: monitor: Unknown packet   <nnn> g    - set network group (RFM12 only allows 212, 0 = any)
Oct 30 02:30:07 (none) user.info syslog: monitor: Unknown packet   <n> c      - set collect mode (advanced, normally 0)
Oct 30 02:30:07 (none) user.info syslog: monitor: Unknown packet   ...,<nn> a - send data packet to node <nn>, with ack
Oct 30 02:30:07 (none) user.info syslog: monitor: Unknown packet   ...,<nn> s - send data packet to node <nn>, no ack
Oct 30 02:30:07 (none) user.info syslog: monitor: Unknown packet   <n> l      - turn activity LED on DIG8 on or off
Oct 30 02:30:08 (none) user.info syslog: monitor: Unknown packet Current configuration:
Oct 30 02:30:08 (none) user.info syslog: monitor: Unknown packet 79 i15 g210 @ 433 MHz  Lock: 0
 

This is what my program dumps to /var/log/messages when it doesn't recognise the first few non-whitespaces as a valid node number. I might get this stuff several times in a burst of 3 or 4 secs, and then nothing for a few days.

Anyway, nothing to report on differences between the receiver in emonGLCD and the RFMPi yet, and no silly numbers received at all.

Source code for  with RFM12Pi V1 with  be found ATtiny84 can found here: https://github.com/openenergymonitor/Hardware/blob/master/RFM2Pi/firmware/RFM2Pi_RF12_Demo/TinySensor_RF12_Demo/TinySensor_RF12_Demo.ino

I remember some bugs in the software serial implementation on the ATtiny, this is why we switched to using the ATmega328 on the V2.

Pre-compiled hex is also on github: https://github.com/openenergymonitor/Hardware/tree/master/RFM2Pi/firmware/Pre_compiled_ATtiny84_RF12_Demo_hex

Happened again last night, massive amount of negative rainfall overnight along with large negative values for temperature from 2 seperate sensors as well as extreme winds, but all running on the same node. It seems to only happen with nodes that are transmitting multiple data items (i.e larger packets) so I'm very much suspecting garbled radio transmission/reception which would indicate the RFM12Bs are not error checking correctly (if at all). It appears only 1 packet of data was affected but it's difficult/impossible to correct/eliminate the errant values in Emoncms

I think I have found the problem causing my silly values.

Yesterday I received some more - the first time in months.

It was at night. emonGLCD was showing 0W being generated, and the LEDS were off.

Suddenly, the lights the LEDS came up bright green - that woke me up & generation was showing 1.3MW.

It coincided with someone slamming a door close a metre or so from the consumer unit - where the current clamps are.

I am now running with the theory, that if the current clamps move - by vibration from slamming door; then the reading is going to be silly. That make sense doesn't it ? Movement, in the Earths magnetic field, is going to cause current.

That could be the problem right ?

1.3MW is a lot of watts!

I just happened to have one of my 333mV CTs on the calibrator when I saw your post.  I had the calibrator set to 2A, so I gave the CT a serious shake/slide/twist (serious abuse) on the wire it was clamped around and noted the readings for Irms:

1.99805
1.99764
1.99766
1.99781
1.99751
1.99882
1.99744
1.99780
1.99722

When I'm not shaking it around, it's stable all the way down to the mAs, i.e. the 1.997 is rock solid, with the bottom 2 digits bouncing around.  So the fact that I was able to get it up to 1.998 suggests there is some effect but it's very small (1-2mA).

Now if I open the CT clamp, then the current drops right away, but none of that really explains how you'd get such a massive reading.

Maybe you have a loose connection or a poor solder joint?

Yes, possibly, maybe I do have a dodgey connection somewhere. You are measuring RMS, I'm no expert on Atmel stuff. I guess I need to look at the datasheet for the 328 and see if I can explain it away.

Tonight I'll have a go at slamming the doors myself, and if the plaster doesn't fall off the walls, maybe I'll be able to confirm cause and effect.

You are measuring RMS

While I didn't report it, I was actually measuring Vrms, Irms, RealPower and ReactivePower throughout the CT abuse.  The calibrator was set to 230V, 2A, 60 degree phase shift, so had the channel been freshly calibrated, the correct result would have been:

230   230   -398.4   2

You can see below there was very little variation in any of the numbers during the CT abuse, so my conclusion is you can't easily change the CT's amplitude error or phase error by shaking it around.  I use a different CT from you guys, but the principles should be the same.

Vrms     Real(W)  React(VAR)  Irms
230.028  228.7   -398.6       1.99805
230.014  228.8   -398.6       1.99764
230.016  228.8   -398.5       1.99766
230.015  228.8   -398.6       1.99781
230.016  228.8   -398.5       1.99751
230.015  228.9   -398.7       1.99882
230.015  228.7   -398.6       1.99744
230.017  228.8   -398.5       1.99780
230.017  228.7   -398.5       1.99722

I have to agree with you.

I spent a few minutes last night slamming doors, and hitting the various electronic bits and pieces, but could not replicate the problem.

Bit of a coincidence though, a door slamming for the 1st time in months, and spurious readings for the 1st time in months.

I think you disturbed a dodgy connection or a dry joint - the movement was enough to shift it onto and off a bit of oxide and normal service was resumed. Until next time. I once spent 2 years trying to find a fault due to a dry joint - the slightest movement 'cured' it for a month or two, then it would come back. It was only after it got bad enough to stay while I took the covers off the equipment that I managed to get close enough to actually find it, then 5 s with a soldering iron and it was permanently cured.