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 ;)

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.

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

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

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

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

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

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

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

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 ;)

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