Home › Forums › Mooshimeter Support › Build 1460332895 + Android app 1.0.21 (1811) Logging weirdness
- This topic has 0 replies, 2 voices, and was last updated 7 years ago by
admin.
- AuthorPosts
Anonymous
InactiveI’m still testing this to see if I can isolate the different possible variables but I’ve encountered some weirdness with microSD logging.
Some times, it would not log at all and other times, it logs for a short period and it stops.
And the data it collected seems “odd”
I’m logging AC (range was set manually to 600V) as ch2 (ch1 is internal temp fyi) and a quick sample of the data for ch2 is:CH2 VOLT AC
1.159262E002
1.157865E002
4.410860E005
4.410341E005
4.408862E005
4.393721E005
4.408824E005
4.401352E005The first two data points are okay but the others are out of normal (over 44100VAC?!)
CH1: DEGC 60C
CH2: VOLT 600V
SMPL: 0256 4000HzAdditional header data:
PCB: 008
ASM: 000
LOT: 00000
FW: 1460332895Anonymous
InactiveSo I did a test again.
I let the app auto range ch 2; it correctly picked Voltage AC and 600V range.
I turn on logging, note that the LED on the meter is blinking with activity and I hit the home button.After a while, the blinking on the meter turns off (aka it stops logging).
I pull up the app again and the meter screen is “frozen” (not getting updates.
I back out to the list of meters to see the meter in “disconnected” status.
I select that meter again and additional weirdness: Ch2 is set to “Voltage DC”, range autos to 60V, and logging is “off”.
When I changed the range to 600V (manual) and then go to select “Voltage AC”, the app bumps the range back to “auto” (which then overloads since it goes to 60V).I’ll check to see what it logged in just a moment.
On a side note, is there a way to tell the meter (independent of app) to start logging and type/range with a config file on the microsd?
Anonymous
InactiveSo from the log file, 684 entries, roughly 4min 32seconds
And AC data logs a few 115VAC but lots of 44KVAC for some reason.The log file (slightly processed in libreoffice calc to get readable datestamp and calculate runtime)
http://pastebin.com/5A7CjCzR
admin
KeymasterHi MoFoQ,
Downloaded your logfile from pastebin. That’s very strange. The fact that the numbers are that incredibly far off would usually make me hunt for some kind of conversion error, but the fact that it’s correct some of the time, and that the error mode shows some analog noise makes this a bit of a head scratcher.
I’m setting up a logging experiment over here to see if I can isolate the issue. Thanks for bringing this to my attention. This is why we beta test!
Best
~JamesAnonymous
InactiveI was reading up on the blog posts about AC RMS calculations you had up earlier.
Could it be caused by processing lag?
I did leave the cycle and sample to auto, not sure how many sample points are needed for the logging function to work.Is there a way to have it dump the untouched/processed 24bit data it gets from the other chip when logging?
Also noticed that the batteries are now down to 50%.
Is it possible to buy just the shell (I’d like to make a non-AA powered adapter of sorts)admin
KeymasterCould it be caused by processing lag?
I did leave the cycle and sample to auto, not sure how many sample points are needed for the logging function to work.Can’t say for sure right now. I ran a test since my last post and have reproduced the issue on a meter with more debugging instrumentation attached.
Is there a way to have it dump the untouched/processed 24bit data it gets from the other chip when logging?
Unfortunately no. I can get those numbers with some effort through my debug setup, but it’s not accessible through the app.
Also noticed that the batteries are now down to 50%.
Is it possible to buy just the shell (I’d like to make a non-AA powered adapter of sorts)Email me at james@moosh.im with shipping information. You’ve been extremely helpful here so I don’t mind sending you some extra shells free of charge.
Anonymous
InactiveWhat about the issue where it stops logging when the app on the phone is no longer in the foreground? (might be related w/ the forced disconnect though it did run for over 4 minutes before it stopped logging)
I don’t mind having to do post-processing of the data logged if it would improve the accuracy and ability to log that much.
Neat, thx (re: cases).
On a side note, perhaps in a future revision, magnets in the case would be nice (some DMMs already have this) as well as ability to power it externally and snap-case or thumbscrews (…anodized aluminum w/ embedded magnets? :D )Anonymous
InactiveI finally got around to test the new firmware (1462564395) and the corresponding app version 1.0.22 (1820).
The weirdness I saw previously is no more. yah!
And I was able to log at least 9minutes (after closing app and going in to airplane mode just to be sure).
I did have difficulties reconnecting afterwards (status: -1) but eventually it reconnected.admin
KeymasterThanks again MoFoQ. Glad to hear logging is getting better.
Status=-1 means one of the connection operations (connection or characteristic discovery) timed out. This happens a rather frustrating amount to me as well even when testing, but it’s related to bugs in the Android stack. It varies from handset manufacturer to handset manufacturer though. Sorry I can’t say anything more informative here… I don’t have a magic bullet for that one :)
Thanks again for all the great feedback. Best
~James
- AuthorPosts