Hi There - I just received my emonTx v3 (pre assembled) in the post. I hooked it up to the UK AC-AC adapter and fired it up with a single CT connected to CT 4.
I'm using the Rasp pi as the base station reporting to emoncms. Everything was working great, I am getting CT power readings and Vrms was reporting ~ 240-245V
Then, all of a sudden Vrms (Input #5 on emoncms) reported 0.00. I logged into the Pi and re-ran the script to show output and Input #5 was reporting 0.00
2014-03-20 11:30:09,976 DEBUG Data string: &node=10&json={1:0,2:0,3:0,4:104,5:0,6:0}
2014-03-20 11:30:09,979 DEBUG URL string: http://emoncms.org/input/post.json?apikey=[removed]&node=10&json={1:0,2:0,3:0,4:104,5:0,6:0}
2014-03-20 11:30:09,982 INFO Sending to emoncms.org
2014-03-20 11:30:10,738 DEBUG Send ok
I hooked up my USB to UART adapter and connected via serial. It successfully detects the AC-AC adapter but reports Vrms as 0 :(
OpenEnergyMonitor.org
CT 1 Calibration: 90.90
CT 2 Calibration: 90.90
CT 3 Calibration: 90.90
CT 4 Calibration: 16.60
RMS Voltage on AC-AC Adapter input is: ~185V
AC-AC adapter detected - Real Power measurements enabled
assuming powering from AC-AC adapter (jumper closed)
Vcal: 276.90
Phase Shift: 1.70
CT 4 detected
Unable to detect DS18B20 temperature sensor
RFM12B Initiated:
Node: 10 Freq: 433Mhz Network: 210
2846 0.00
140 0.00
103 0.00
104 0.00
Can anyone help me on why Vrms suddenly stopped working in the emonTX v3? No amount of power cycling it has seemed to resolve the issue.
Just to be clear, it worked for ~5minutes before it then started reporting 0. Brand new emonTX received yesterday powered on first time today.
Thanks,
James
Re: New emontx v3 - suddenly stopped reporting Vrms
Hi James,
There is a bug in the version of the emonTx firmware which was shipping on your unit which requires CT1 to be connected in order for Vmrs calculation to work.
This has now been fixed, if you like you can download the latest firmware for GitHub and compile and upload via the Arduino IDE, or you can just download the pre-compiled hex and upload via avrdude.
https://github.com/openenergymonitor/emonTxFirmware/tree/master/emonTxV3/RFM12B/emonTxV3_RFM12B_DiscreteSampling
http://wiki.openenergymonitor.org/index.php?title=EmonTx_V3#Uploading_Arduino_Firmware
Alternatively the issue could be fixed by just inserting a blank 3.5mm jack plug into CT1, it just requires a plug in there, it does not need to be a CT.
Very sorry about this,this issue was just brought to our attention yesterday.
Re: New emontx v3 - suddenly stopped reporting Vrms
Thanks Glyn that seems to have done the trick! I mustve moved the CT from 1 to 4 without equating it to Vrms stopping. Just wondering see on my emontx serial session the very first output from CT4 is huge and messes up my emoncms graphing and calcs - is this related to the same issue?
Thanks again for your help
Re: New emontx v3 - suddenly stopped reporting Vrms
No, that is the software filters settling. The RF output is inhibited for a short time at start-up, but not the serial output. However, looking at the sketch, I don't think FILTERSETTLETIME is enough at 5 s because the filters don't actually get going until a little more than 22 s in, so (having got a NanodeRF out to check) I think FILTERSETTLETIME should be at least 25000 - 25 s (which gives enough iterations of the filter as there is no delay while the RF is inhibited - after which the filter is sensibly stable).
That algorithm (inhibit the RF for a few seconds) was OK for the emonTx V2, which did not have the protracted start-up sequence. I think there may be a better way to handle it for the V3.
Re: New emontx v3 - suddenly stopped reporting Vrms
Thanks guys! Bit of a learning curve right there but I setup the Arduino env following the wiki guides and downloaded the updated 1.2 Discrete Sampling ino that resolved the Vrms issue. I also updated the FILTERSETTLETIME variable to be 30000 and can report that the initial high readings are not being uploaded to emoncms and Vrms is reported correctly even with CT 1 disconnected.
So far so good! Thanks again
Re: New emontx v3 - suddenly stopped reporting Vrms
I have also lost VMRS but oddly it seems to have coincided with the upgrade of my RPi to emoncms 8.3.2. I have also gained a node 0 which has numbers in but which I have no idea of where the data is coming from? I am running an emontx v3.2 bought at the end of 2013 if that helps. I think I may need to update the firmware as my temperature sensor bought and installed today also does not give a readying?
Re: New emontx v3 - suddenly stopped reporting Vrms
My VMRS feed is now back. I had noticed that the recorded feed power in Watts had gain about 30 W recently with no obvious reason. So I:
I then observed the expected LED flashes and the 10 seconds pulsed light which had been absent since the whole VMRS/temperature sensor thing.
I then checked my power and it is back to how I would expected it to be. WHAT FUN. I missed from the list - did a little "please work dance".
Re: New emontx v3 - suddenly stopped reporting Vrms
Sorry to dig up this old thread but I've just had the same thing happen to me as my previous post. I noticed my power usage had gone up by ~30 W more than the norm. On finally getting around to checking my feeds I found the VMRS value to be 0. I followed my own advice as described above and it fixed the issue (for now at least) very odd.
The only things I can think of causing issues are:
I've rebooted my Pi &
I've turned on my iRobot electric vacuum cleaner.
I've also noticed there is data showing up in nodes 9, 16, 24, 25, 26 and 28 there is a lot of data on the nodes some are 28 lines long?
Very odd.
Anyone else had random VMRS loss without unplugging the CT1 cable.
Re: New emontx v3 - suddenly stopped reporting Vrms
I don't quite see how unplugging CT1 cable can affect the voltage measurement. The emonTx senses the voltage at startup, so you would need to remove the ac adapter input and restart the emonTx using the USB, programmer or battery power for it to believe that there was no ac adapter.
The rogue data seems to indicate that you have interference, and at best that will confuse the issue. The interference needs to be traced and eliminated.