Topic | Measuring watt-hours

Home Forums Mooshimeter Support Measuring watt-hours

Viewing 22 reply threads
  • Author
    Posts
    • #15296 Reply
      Anonymous
      Inactive

      Can it measure accumulated energy over a period of time? (i.e – watt-hours).
      If so, is the calculation done by post processing logged data, and/or can the meter perform the calculation in real time?
      What is the maximum sampling rate for either/both methods?
      Once the app has started a long term measurement, can the phone be disconnected, with the meter running on it’s own?

    • #15299 Reply
      Anonymous
      Guest

      Dead batteries just after real logging gig

      There I did measure what some freezer and fridge takes. 10 sec intervals, then calculated in spreadsheet that every value would represent 10 seconds (which it basically does) and got “price” for hour.

      I’ll try to write some more in a while, but i have to go now, before my car battery dies.. Finland = -22C outside and webasto heater running to go for groceries ;)

    • #15300 Reply
      Anonymous
      Inactive

      Thanks. :) Do you know whether it can do the calculations in the meter, in real time, and just display the current total watt-hour value from when the test was started?

    • #15302 Reply
      Anonymous
      Guest

      I’m pretty sure that there is not such feature.. And @admin has told that there is no space left for more code in the meter, so probably no new features anymore, or at least it would be very difficult.

      Phone-app has almost no restrictions for growing, but in my opinion, long time energy measurements would have to go through logging. Which is not that much of a deal, as we now have ability to transfer logs over bluetooth. So it should be possible, now we only need someone willing to write that code, as app:s are open source.

    • #15304 Reply
      admin
      Keymaster

      Hi Greg,

      Ville is correct on all counts but I will try to give quick answers as well:

      If so, is the calculation done by post processing logged data, and/or can the meter perform the calculation in real time?
      The meter can’t do this in real time, you’d have to log it and do the math in post processing (like excel).

      What is the maximum sampling rate for either/both methods?
      The maximum sample rate for logging to SD card is in the hundreds of Hz. The meter fills a sample buffer of X samples at the rate Y (where X and Y are the settings you control through the app), then performs math on the buffer (mean for DC analysis, RMS for AC analysis), then writes the result of the calculation to the SD card.

      Once the app has started a long term measurement, can the phone be disconnected, with the meter running on it’s own?

      Long term logging is done to an SD card on the meter, the phone can be disconnected and the logs retrieved from the SD card later (either over BLE or by physically retrieving the SD card).

      Hope this answers your questions, let me know what else comes up, best
      ~James

    • #15306 Reply
      Anonymous
      Inactive

      Thanks James (and Ville).

      James – your answer seems a bit vague. What I want to know is this:
      What is the maximum sustained DC *measurement* rate that can be logged, with each measurement consisting of two DC readings – voltage & current, and each measurement being accurate to at least 0.5%, and each measurement being spaced apart by a precise and equal time. Don’t worry about buffers – that’s an implementation detail that I don’t care about – I want *you* to factor that in when you give me the high level answer that I am seeking. ;^)

    • #15307 Reply
      admin
      Keymaster

      If you set the buffer depth to 32 and sample rate to 4000Hz, then leave it to log, you’ll see a sample rate of just under 125Hz in the log. Is that what you’re looking for?

      Best
      ~James

    • #15308 Reply
      Anonymous
      Inactive

      Well, I’m not sure. Are you saying that 125Hz is the maximum measurement rate? If so, yes, that’s the answer I am looking for. Do the 32 samples in each buffer have to be averaged in order to meet the stated DC accuracy of 0.5%?

    • #15309 Reply
      admin
      Keymaster

      Hi Greg,

      Short version: Yes, 125Hz is the max rate at which you can configure to write to the log before the signal gets noisier than specs.

      Sorry, I’m an engineer first and a customer service guy second, I have trouble getting my head out of the implementation details. Let me know if you have other questions :)

      Best
      ~James

    • #15310 Reply
      Anonymous
      Inactive

      Thanks. Just out of curiousity, what would be the accuracy if the samples are *not* averaged? I.e – if the buffer size is set to 1, and each of these 1-sample buffers were logged separately – what then would the accuracy be, and does the accuracy depend on the frequency at which these single-sample measurements are taken?

    • #15312 Reply
      admin
      Keymaster

      Hi Greg,

      So this gets pretty far in to implementation details but I’ll try to give a concise answer –

      The Mooshimeter is built around an ADS1292 24-bit ADC. The datasheet for that part is here. Table 1 gives the effective number of bits as a function of sample rate. When you configure the sample rate in the app, you are setting the ADS1292’s sample rate. The way the Mooshimeter is set up it, it only uses between half and a quarter of the ADS1292’s input range (depending on what input is selected), so taking the value from table 1 of the datasheet and subtracting 1 or 2 gives you the ENOB you can expect from a single reading at the sample rate.

      Example: at 8kHz table 1 shows 12ENOB, so you can expect between 10 and 11 ENOB depending what input you have selected.

      Oversampling increases the ENOB by .5 bits per power of 2. So oversampling 4x adds 1 bit, oversampling 16x adds 2 bits, etc.

      Hope this sheds some light on the subject :)
      Best
      ~James

    • #15313 Reply
      Anonymous
      Inactive

      Thanks. Just a small suggestion – to make it easier for customers, make the Mooshimeter specifications more complete. I.e – add information to the product specs about how the accuracy varies with sample rate, and state whether it’s %FS or %RDG + digits etc – like is normal for multimeters & data acquisition equipment. Include the info about sample averaging too.

      Looks like an excellent product, anyway – thankyou for making it!

    • #15314 Reply
      Anonymous
      Inactive

      (just placed an order)

    • #15315 Reply
      Anonymous
      Guest

      At first, I was after crazy accuracy and fast sampling too, but in real life you can crash spreadsheet programs with few 10k lines of log..

      Then there are 86400 seconds in a day and most of us use ~fullhd monitors, so 1920 pixels for your graph to see on one go. That makes 45 seconds per pixel (for a day). There might be some cases when you are willing to zoom in to your results, but mostly even that 10 sec interval is way more than i need (but as libreoffice calc can work with it, i wont be changing to 1 min ;) )


      @GregS
      : Is your example normal DC measurements or something like PWM or other “spiky” stuff? Some random spikes wont really add up to Wh and PWM would get averaged, so if the Wh value at the end is the thing youre looking for, you should be ok.. Or i am completely wrong and your experiment is measuring how much energy you would get from lightning bolts and your values would be either zero or infinity ;) .. Even then, mooshimeter is right tool for you, as you can be BLE-range away (or anywhere with teamviewer-setup etc) if you happen to be watching live values when it hits your experiment ;D

    • #15316 Reply
      Anonymous
      Inactive

      Ville,
      I don’t know what you would classify as “normal”. The reason I am interested in higher than typical (typical seems to be about 3Hz) sampling rate is because I would like to measure the energy consumed by electronic *equipment* which, yes, may have high frequency fluctuations in power consumption. I agree with you that over a long enough time, it would average out, but I want the flexibility of measuring with a higher sampling rate – and the higher sampling rate will be more useful for shorter tests rather than very long tests, HOWEVER, even in long tests, it would be useful to be able to zoom in on any events of interest. Just FYI, I notice that Adafruit use a power meter from Monsoon that does appear to have a high sampling rate, but it’s about 6 times the price of the Mooshimeter, and seems to be dedicated to low voltage & power equipment. (I’d much rather get something more versatile like the Mooshimeter)

      Regarding spreadsheets crashing, well, that’s one reason to consider allowing the meter to do the accumulation, rather than offloading it – if all one is interested in is the final watt-hour reading, it’s a bit of a hassle to have to post process the log. Pretty minor issue though – it’s trivial to write a bit of code if required.

      EDIT: There’s no need to try and sell me on the Mooshimeter – I’ve already ordered one, as I said before. :)

    • #15357 Reply
      Anonymous
      Inactive

      In the above, I was thinking about DC measurements only. How about AC? Do I just log instantaneous VI and post process, or do I configure the meter to compute power factor & real power etc, and get it to log that?

    • #15364 Reply
      Anonymous
      Inactive

      Mooshi-app is able to calculate real power, apparent power and power factor (+k-type thermocouple) in phone, but mooshimeter itself wont log those.

      You can log two channels of basic multimeter stuff / internal temperature. With timestamps at millisecond precision. And that is basically all we get, as there is no space left for any major additions..

      There has been little buzz about “free math-channel(s)” to be added to app, where we could set up strange ratios for current transformers or shunts, or do some more complicated live processing of our data.. I wish we could have those math-channel formulas saved to log-headers, so it would be easier in post processing to get to same values that you have seen when setting things up.. I hope that something like that would fit in the mooshimeters memory budget..

      Someone also wanted to log directly with phone, which might give us bit more options.. Like ability to get unprocessed sample buffers (bursts by the rate mooshimeter is able to record + transfer over ble) –> process with zillion-core-phone-processor –> profit. That is all on the app-side of things, so open source and it is just waiting for someone with skills for coding and need for great logger :D

    • #15366 Reply
      Anonymous
      Inactive

      So I may be off the road and in the shoulder here, but could there be some middle ground???

      I understand the meter is what I would refer to as a “pre-scaler” or data acquisition interface. The actual Moosimeter by itself is more of an interface than a true measurement device in some words

      So it is discusses to output the data to a spreadsheet and perform calculations, but phones and tablets are smart and how power, how about being able to do some of the translations and calculations within the App on the phone or tablet??

      I head James saying he is an Engineer by nature, BUT we need some sort of Application Specialist that can bridge between the raw Engineering side and the End User. No disrespect to James, but I have been in these circles for years.

      I would have to assume the MAJORITY of the Mooshimeter purchasers do not really want to car to read the chipset Data Sheets and understanding how all the sampling is processed, BUT I do think the end users like myself need to know the Max Sample rate in milliseconds and does it differ between AC and DC Voltage. A simple, single page spread sheet/cheat sheet with some meter settings and showing the sampling rate vs meter setting and Voltage measurements would be very useful.

      I do a lot of Automotive related work and research and I need fast sampling rates usually for short periods line during engine start up, but then I have situations where I need to monitor for Parasitic Draw over weeks and a 10 second or even 1 minute Sampling rate would be all I need.

      I see we have other end users that deal with Solar systems they need to monitor and even may have integrators or installers that will use the meter.

      Lets think about what can be processed in the phone/tablet even while data may be written to the SD card because the phone or tablet can buffer and display Peak and Min values along with a running Average and other useful data points. In the automotive field I really need Max & Min points displayed on the App, but I can also to back into the .CVS Log file to look at a specific Voltage behavior for example when the engine is started.

      Lets think outside the box, but inside the phone/tablet App!

      j

    • #15369 Reply
      Anonymous
      Inactive

      Ville wrote:
      You can log two channels of basic multimeter stuff / internal temperature. With timestamps at millisecond precision. And that is basically all we get, as there is no space left for any major additions..

      Ok. I’d prefer to pay a bit more and have the meter be able to do more processing on board. It does seem a *little* odd to have to log discrete time samples of an AC waveform, if all we want is a long term log of true power for a slowly varying load.

      Btw, I’m surprised that the “measuring power” page in the Wiki has only a link to a solar panel setup – no mention whatsoever of AC power.

    • #15372 Reply
      Anonymous
      Inactive

      James wrote:
      Short version: Yes, 125Hz is the max rate at which you can configure to write to the log before the signal gets noisier than specs.

      This implies that it is possible to configure the Mooshimeter to log measurements at a rate above 125Hz. The only way I can see to achieve >125Hz would be to use a sample rate of 8kHz, because the minimum buffer size appears to be 32 samples – correct?
      However, I read in another thread (sorry no link at the moment) that 8kHz sampling is not reliable. Is that correct? If so, it appears to me that the maximum usable logging rate at the moment is 125Hz.

      If it is true that 32 samples is the minimum, why is that the case? Why can’t we set it lower, if we don’t mind more noise in our measurements?

    • #15392 Reply
      Anonymous
      Inactive

      About 8kHz sampling.. If i remember correctly, it was default rate for ac and generated spikes to logs at random. Might happen every minute, or might go for hours between noticeable errors (at 10sec intervals, probably appears hell of a lot more at max rate). And it (mostly) affected both channels at the same time (and in my case, always in different directions), so it was “easy” to spot from graphs. If you are logging only one channel, set other one to internal temp, so you have something to compare, where every spike has to be an error.

      So it is possible to use 8kHz, if you know what you are measuring and know how to filter those errors out. I believe that is the reason James still left it as selectable option, if someone wants that precision and is willing to double check their results..

      And when trying to max out mooshimeters measuring rates, its good to remember it was never told to be an oscilloscope ;)

    • #15393 Reply
      Anonymous
      Inactive

      Thanks for the info – much appreciated. Of course I know it was not meant to be an oscilloscope, and I have EVERY right to “max out” the instrument to it’s specifications.

    • #15423 Reply
      admin
      Keymaster

      Hi Greg and Ville,

      Happy to see such a lively discussion – I hope I can contribute on a few points:

      Greg: regarding your question on why you can’t set number of samples below 32 – I answered this in the other thread but it was basically a simplification decision (one that I may now be regretting).

      Regarding sample rate of 8000: I still see the occasional spurious reading at 8kHz that I don’t see at any of the lower sample rates. I’ve considered removing 8kHz as a selectable option and simply downgrading the specs, but I do still find it useful for buffer-mode analysis of signals despite the occasional spike, so I left the option in there.

      Hope this answers some questions!
      ~James

Viewing 22 reply threads
Reply To: Measuring watt-hours
Your information:




This site is protected by reCaptcha and the Google Privacy Policy and Terms of Service apply.

The reCAPTCHA verification period has expired. Please reload the page.