Has anyone been able to get their emon to output data similar to an oscilloscope? I know I can't Serial.print that fast, but I wonder if I were to output a single measurement at a set time like 1ms more than cycle speed. (21ms for 50hz, 17 or 18 for NA 60hz.) I want to compare with an actual Oscope to verify readings are as expected. Does anyone have any experience having done that? I am afraid that my ability to search the forums here hits the snag of too many common words.
Second, I was trying to see if I could report "numberOfSamples" but it seems to be undeclared in this scope, despite my efforts to declare it. Is this A) a useful number for me to see how many times realpower is being calculated? and B, is there a better way?
Details on my project are North American, 120/240 whole house monitoring, aiming for 14 circuits of measurements, and using a spark core as a collection and uploading system. (Kind of like the emon pi shield) .
Since the spark.io unit has a few interesting implementation details I want/need to retrace some development steps from the start to see if I am having any problems. One fun and interesting feature of Spark development is that I can set the output on any Digital or Analog pin so that with a jumper it can be read as an input on another pin. It is an easy way to check that main functions are working. And this can be done while I am at the office and the Core is sitting at home.
Re: Double Checking Emon Measurements and speed.
I've had no trouble printing numberOfSamples to serial, but you have to customise emonLib to do it, because it's local to calcVI( ). (So if you declared it as a global, you'd have two quite independent variables both called "numberOfSamples".) It's useful to see how many samples per cycle you're actually getting, and that in turn is useful when looking for ways to optimise the calculations. But that's all I've used it for, except that this knowledge is useful for answering forum questions about the sample rate.
Writing a value to an unused analogue output might be useful in some circumstances, but it would naturally slow the code and of course change the numberOfSamples. I'm not an Apple user so I can't comment further about Oscope. But am I missing the point? I can't see the purpose of outputting a quantity (which quantity?) in analogue form at 58.82 Hz. What do you have in mind and why?
Or are you looking for something like Robin's Tools?
Re: Double Checking Emon Measurements and speed.
I got number of samples to display (logging to emoncms), but I wonder if you could help me with the details of its output?
I grabbed that # of samples (from "Post Loop Calculations") but no matter the reporting cycle, from 2 seconds up to 30 it just reports back 1484. Maybe I should be grabbing another variable? There is a whole lot of good stuff in Robin's Tools, thanks for sharing that link.
Re: Double Checking Emon Measurements and speed.
Hmmm. "There is a whole lot of good stuff in Robin's Tools, thanks for sharing that link. " You haven't read the 'stickies' at the top of the forums, have you?
I'm afraid you're all mixed up. The code you quote is from calcVI( ), yet the number of samples you're reading is the fixed value from calcIrms( ). You're looking at the wrong piece of code.
CalcVI( ) calculates the real and apparent powers, rms voltage and current over a fixed number of cycles. CalcIrms( ) calculates the rms current over a fixed number of samples (1480 is the default).
I get 530 or 531 from calcVI( ), which is much closer to the expected value of 53 samples per cycle, and represents 2650 sample pairs per second. That's 188 μs per sample and includes all the per-sample processing.
Re: Double Checking Emon Measurements and speed.
You sure have a sweet way with words. Possibly the code is all mixed up. I am using this lib adapted for Spark, and a modified NanodeRF sketch. I am going to start integrating with the emontxV3 to try and stay close to the original project. My code is here.
If you notice how the calcIrms Number_of_Samples is leaking into numberOfSamples I would love to hear where that is happening.
Re: Double Checking Emon Measurements and speed.
No, I normally wouldn't look at much in the general section of a forum. I did find it now and also see that my posts are not showing up so I guess that means I have been flagged for moderation.
*edit - Since this post was not flagged I guess it was the links included in the other post that caused it to be auto flagged.
Re: Double Checking Emon Measurements and speed.
"If you notice how the calcIrms Number_of_Samples is leaking into numberOfSamples I would love to hear where that is happening."
I can't see where that is happening, but at the same time I can't see "samp" either. So I'm not looking at the same code that you posted earlier. So the links to GitHub aren't helping.
But it seems a very strange coincidence that you're reading the number that I would expect at the end of calcIrms( ), when you have calcVI( ) calculating over the same number of cycles as I was and I got 530 sample pairs in 200 ms. 1480 sample pairs tends to imply sampling for 558 ms (assuming the same ADC and clock frequency), and that's a lot more than 10 cycles. Your system frequency would need to be 18 Hz - what is it?
I think you need to write a stripped-down-to-the-bare-minimum sketch to see if you get a sensible number and establish just how many sample pairs you see per cycle. If that's successful, you can start adding bits back and see where the corruption - if indeed that's what it is - is happening.
Re: Double Checking Emon Measurements and speed.
Shoot, I need to add a dev branch to my copy of emonlib for this sort of thing.
I am working with 60hz.
Backing off to almost nothing and then adding thing in bit by bit might be what I have to do. And something I should do as am not clear how things like the PLL work.
Also different hardware will make things interesting. And is a good reason to break thing back down to bare bones to verify data.
Re: Double Checking Emon Measurements and speed.
https://github.com/officeboy/EmonLib/tree/dev-counts/firmware
Re: Double Checking Emon Measurements and speed.
If you're using (or going to be using) a different processor and ADC, all bets are off regarding speed, etc. The core algorithms will of course work without any serious changes.
But which PLL are you referring to? Neither EmonLib nor the basic demo "DiscreteSampling" sketch, on which I think yours is based, use a PLL. The "continuous monitoring" sketches are interrupt-driven, but that's still not the same thing as a PLL. As far as I'm aware, only "Solar PV power diversion with emonTx using a PLL, emonGLCD and temperature measurement" by Martin Roberts, and its derivatives, use a PLL.