Archived Forum

This sketch appears to be based on one that I have supplied for use with the emonTx V3.  I say this because my name appears at the top!   Although voltage samples are "continuously" taken, they are only used for the purpose of calculating Real Power.

To display Vrms would require additional processing of the voltage samples which is not included in this code.

Thanks very much for your reply. Voltage was a nice to have reading.

I'll put this in the way to hard basket at the moment seeing as it's not readily available in the code!

What values would you like to be transmitted, along with the RMS voltage?  Specifying exactly what data needs to be transmitted, and how often, seems to be every bit as elusive as writing the code for it.

Although this sketch is monitoring continuously, much of the data that it collects is not being used.  If data is only to be transmitted every 10 seconds, then each measurement window should be 10 seconds too.  Otherwise data will be overwritten before being sent.

I'd like RMS voltage and temp from DS18B20, basically the functionality the non watt hour sketch had.

I can probably handle adding the code for the temperature sensor back in. I changed the RF send to every 5 seconds in an attempt to display power changes quicker in emonCMS & my local display.

Actually how about power factor and frequency? could be interesting.

If you're looking for the full range of measurements, Martin Roberts' PLL sketch might be worth considering (with the diverter logic removed if you wish - or just ignore it). (You're OK with that, there's a 60 Hz version elsewhere for those that need it.)

The logic is somewhat complicated as Martin didn't use the library calls due to the overhead they carry, but I've explained most of it in the 'Guide' article about energy diverters.

I can probably handle adding the code for the temperature sensor back in.

As this sketch is based on my code for taking continuous measurements, temperature sensing has never been included.

Taking temperature measurements when nothing else is happening is straightforward enough.  But in a "continuous monitoring" sketch, such as the one we're discussing here, the situation is rather different.  If the standard library routines for measuring temperature are used, the flow of V and I data ceases to be continuous.  Gaps are caused while the OneWire routines run their course.

Martin's PLL-based code does appear able to perform both continuous measurements of its V and I sensors, and also provide temperature measurements - but not using the standard library routines.  If anyone can explain to me how this mechanism actually works, I would be most grateful.

"If anyone can explain to me how this mechanism actually works, I would be most grateful."

Deviously!

Thanks for the information. You've convinced me to not got tampering with the continuous sketch :) I'll have a look at Martin's PLL sketch. 

Regards

Martin's PLL sketch was designed for energy diversion, which means it has two current inputs only. It should be possible to extend it if you need to use all 4 current inputs. Dan Woodie certainly extended it to 3 at 60 Hz (http://openenergymonitor.org/emon/node/2624 and http://openenergymonitor.org/emon/node/2679).

Expanding on my "deviously" answer above: The library routines for measuring the temperature cannot make any assumptions about the state of the sensor, and they must therefore set it up completely each time assuming nothing, and wait for the measurement to be done and only then they return with the value, while that is happening the processor must wait. Martin was able to sidestep all the reconfiguration that the library does because he knew nothing had changed between readings, and he was able to split the reading process into two and sidestep the wait while the sensor does the measurement. First he requests a reading and then the sketch does other things while the sensor gets the temperature, converts it and stores it in its buffer memory. He then comes back and gets the answer from the buffer. This makes not the slightest difference in practice as the temperature changes only slowly compared to the time to execute the main loop in the sketch.

Thanks for the explanation, impressive stuff! I'm using 3 current inputs at the moment.

I'll hold off on trying to extend the sketch till my skills are up to the task.

I've certainly learnt a lot since embarking on my house monitoring project. I find it very rewarding. The support available on OEM makes anything seem possible, some very bright cookies are involved with this project.

I now understand why developers love Linux. It's awesome what you can do with a few shell commands. I'm in the process of configuring emonCMS on the Raspberry Pi purchased last week with help from the OEM forums of course :)

Thanks again.

Thanks, Robert, for your comprehensive explanation about temperature sensing. 

I look forward to trying this out in my own code ...

So, there no way for get voltage from this sketch?