- This topic has 0 replies, 3 voices, and was last updated 5 years, 3 months ago by
.
- Posts
Hi James,
I tried to do some logging today – connected and set it up, disconnected and left the meter running for a while. It was a disaster.
1) the meter crashes about every second time I start logging. Light keeps flashing, (curiously, it flashes for say 1 ms and 10 ms, randomly), but not possible to connect. It seems to help to format the card beforehand, but this only improves the success rate to about 75%.
2) I need to reset the meter with the button each time it crashes
3) The first time, the card had 99 .txt files on it, all 53 bytes, all created within a few minutes of each other, and also the CONV.PY file was empty. Later, the logging produced one .txt file per attempt
4) The logging interval seems to be wrong – I set 1 second, it logs every 2 seconds. I set it for 10 seconds, it logs every 1 minute. I set it for 1 second, it logs every minute. Perhaps I’m not setting it correctly, but there is a toast message saying “Applying Preferences” so I assume the message got through.
I have formatted the card, reset the meter, and tried applying the settings in every different way I can think of, but can’t find any correlation between these and the errors and crashes.
The logging is almost completely unusable at the moment – there’s no visual or app feedback that it is working, it only works 50% of the time, and the interval is impossible to set.
I love this little meter, but the cool features that distinguish it from my Fluke are not really working yet :(Is there anything I can do to improve this, any strict procedure to avoid the crash?
Will there be a firmware update to fully implement logging?
– Meter V.1 build 1426035947
– 512 MB SD card
– Android app version 1.0.11 (284) on a Nexus 4 with Android 4.4.4Hi Thomas,
I’m sorry to hear about this! You’re not the only user who’s reported some logging problems.
A few things to check:
Have you tried replacing the batteries in the meter? SD cards draw a lot of power when writing, I’ve seen cases where a meter with low batteries will brown out when it attempts to write to an SD card.
Regarding the logging interval:
I should rename this field. The logging interval is the length of sleep between samples, but it doesn’t take in to account the amount of time it takes to wake up and perform the sample itself. So if you set to 1s interval, the meter will wake up, wake the SD card, perform the sample, then set a 1s sleep timer and go to sleep. The wake->sample->sleep time can be quite long. Usually a 1s logging interval results in about 1.2 seconds between samples. If it’s taking 2 seconds that could be indicative of an SD problem. What’s the brand?
~James
Hi James, thanks for the reply. It’s taken me a while to get back to this.
I had a look at the batteries as you suggested, they seem to be fine, producing 5 amps on short circuit and reading 1.4 v while the meter is running. I cleaned the terminals and contacts, bent them a bit tighter, and put it back together. This might have improved things – while the logging is still quite buggy, the meter hasn’t crashed again.
I’ve figured out that a bright orange flash means that it’s logging, while a small orange flash is the beacon. This is good, allows me to see if it is logging or not.
It takes 5 or 10 seconds to start logging, after you disconnect. And while it’s logging, it’s difficult to connect, especially if it’s logging often, but you can get through to it.I tried several more logging runs on a freshly formatted Sandisk 512 MB card, and a Sandisk 64 MB card.
The 99 files problem is still happening, only on the 512 card (but not many data points to support that), I didn’t get all 99, but got several one-line files, when I always left it running for many log periods.
The 10-second logging, when it does work, produces a file with entries 5 seconds apart. I haven’t checked if they are just mis-labelled in time, or actually taken at the wrong interval.
Some strange things happen when converting them to CSV. Apart from the tab separator, which I’ve removed from my CONV.PY, I find strange incorrect column headers.
Logging with Ch1 temperature and Ch2 AC voltage, gives these columns:
123456Time[s] INT Temp[C] V Voltage[V] RMS INT Temp[C] RMS V Voltage[V]27628 23.025811 -0.000549 -271.530612 0'OK, this looks about right.But if I log with the top channel being AC mV, and lower being Temperature, I get this:Time[s] INT Temp[C] (blank) RMS INT Temp[C] RMS
28008.8 -0.236309 23.000874 0 -271.530`
Something strange going on here – the temperature column is now a small negative number, the real temperature is in a column with a blank heading, and the RMS is -271.5. What are the RMS columns on the right? Why does the termperature RMS come out as -271?For this problem, could you perhaps release a new version of CONV.PY, that produces the right column headers and things?
So my logging questions and requests are:
1a) Why the 99 files with one line in them? It’s particularly frustrating because it flashes that it’s logging, but is actually creating the 99 files and will soon run out of filenames.
1b) Is there a way to prevent this, a work-around or specific way of setting up or operating the meter, before the firmware update2) Logging timing is wrong, or it’s not being reported correctly
3) Strange headers in the CSV files, and strange columns
4) It would be nice to be able to set the time in the Android app…
5) It would be good to have positive confirmation that logging is taking place and working. A button in the app, saying Start Logging, that then switches to a new screen, staying connected, where it tells me “Logging at 10 second intervals. SD card free space 44 MB. 5 data points collected in this logging run. Measuring AC voltage and DC current.” When re-connecting to a meter that’s logging, I should see that it’s logging, see the last reading it took, and be offered the chance to stop logging to go back to real-time mode, or disconnect and leave it logging. This would be more workable.
Thanks for your effort so far, looking forward to some upgrades as we go along.
Argh! Wrong quotation mark.
Here’s the code section again, being a bit more careful with the ticks:Logging with Ch1 temperature and Ch2 AC voltage, gives these columns:
12Time[s] INT Temp[C] V Voltage[V] RMS INT Temp[C] RMS V Voltage[V]27628 23.025811 -0.000549 -271.530612 0OK, this looks about right.
But if I log with the top channel being AC mV, and lower being Temperature, I get this:
12Time[s] INT Temp[C] (blank) RMS INT Temp[C] RMS28008.8 -0.236309 23.000874 0 -271.530Something strange going on here – the temperature column is now a small negative number, the real temperature is in a column with a blank heading, and the RMS is -271.5. What are the RMS columns on the right? Why does the termperature RMS come out as -271?
Hi Thomas!
Oh my, you’ve given me a lot to chew on.
1a) Why the 99 files with one line in them? It’s particularly frustrating because it flashes that it’s logging, but is actually creating the 99 files and will soon run out of filenames.This indicates something is going wrong with the logging. Every time a logging error occurs (flash card doesn’t respond properly, some sort of error occurs), the Mooshimeter recovers by closing the old log file and starting a fresh one. So the fact that 99 log files are being created indicates that there’s some sort of intermittent fault with the SD card interface. This is a behavior I’m working on and will change in the next firmware update.
1b) Is there a way to prevent this, a work-around or specific way of setting up or operating the meter, before the firmware updateA few other users have reported a similar problem. If you don’t mind chewing up batteries, one work around is to log at the MAX rate. The SD card faults seem to come up when waking the SD card up from sleep, and logging at the MAX rate means the SD card never goes to sleep. It’s not elegant but it may make your life easier until I push new firmware.
2) Logging timing is wrong, or it’s not being reported correctlyThe field should be renamed in the app… a “1s interval” actually means that it will wait 1s between the end of one sample and the beginning of the next. Since a sample takes a few hundred milliseconds it’s a substantial difference. But getting 5s for a 10s interval? That’s odd, I haven’t heard that reported before. There is a 10s periodic timer running in the background that always gives a small blink, regardless of anything else that is going on. Maybe the logging blink and the periodic blink are out of phase and you are just observing a blink every 5s? Are the log entries 10s apart?
3) Strange headers in the CSV files, and strange columnsInternally, the meter is always calculating the DC (mean) and AC (RMS) components of the sample. Even for temperature. Since the units for temperature in the logfile are degrees C, the units of which are arbitrarily based on the characteristics of water, an absolute zero temperature is represented as -273C (or 0 Kelvin). Just ignore the RMS column when it doesn’t mean anything to you – it’s better to have the data and not need it than to need the data and not have it, at least that was the philosophy behind logging all the calculated data.
4) It would be nice to be able to set the time in the Android app…You’re right, sorry. On the to-do list! But the firmware issues are more pressing.
5) It would be good to have positive confirmation that logging is taking place and working. A button in the app, saying Start Logging, that then switches to a new screen, staying connected, where it tells me “Logging at 10 second intervals. SD card free space 44 MB. 5 data points collected in this logging run. Measuring AC voltage and DC current.” When re-connecting to a meter that’s logging, I should see that it’s logging, see the last reading it took, and be offered the chance to stop logging to go back to real-time mode, or disconnect and leave it logging. This would be more workable.The firmware has been overhauled and is being tested now – one of the changes is that the timing issues are sorted out and the meter can maintain a BLE connection and talk to the SD card at the same time. The fact that it had to do one or the other before is why there’s no feedback possible in the existing version of the app. So yes! I agree completely and the product is moving in that direction :)
Thanks Thomas, let me know if you have any more questions
~JamesHi James,
Thanks for the detailed reply.I’ve figured out the headers of columns – they make sense now.
I did a series of tests tonight, here are my records: https://www.dropbox.com/s/8y3ate7v8xr0nxw/MooshTests.docx?dl=0
The multiple log file problem seems to happen with the 512 MB card, and not with the 64 MB card.
But on the 64 MB card, it works better. The timing of the logging is half of the requested time, which isn’t a big deal, and sometimes not starting logging.
I look forward to the firmware update with the new features, time setting, etc, also true power and power factor measurements, thanks!
Hi James, some more results and questions!
Since ditching the 512 MB card, logging has been much more reliable.The time is still wrong, not a big deal, the 1-minute setting logs every 25 seconds or so.
I am seeing small glitches in the recorded temperature. In one log file, I found single sample downward jumps of 1.1 degrees C, 24 hours apart. In another log file, single sample jumps up, 0.11 degrees C, a bit more frequent. It’s too soon to say whether they occur regularly or at random.
There’s no jump in the other measurements at these times.
So it looks like a small bug in the temperature measurement / processing.Hi Thomas,
Thanks again for the detailed responses – you’ve crystallized a number of smaller bugs that have been popping up intermittently for me too. For example the temperature bug goes as deep as I can chase it – in the calibration process many meters fail because they think it’s freezing, but it’s an intermittent issue (the worst kind!) so I’ve largely been ignoring it because of higher priority stuff.
New firmware should be out this week… thanks again
~JamesHi,
This is a fairly old topic, but I am getting the same problem. I
received Mooshimeter a few days ago. Logging (temperature) to a 64GB SD card works for about a day before the meter crashes. Rapidly blinking led and unable to connect. Have to pull the battery to reset (a button would have been a big plus!) A couple of runs have had the same result.
This is using latest version of firmware.Another slight glitch, the forum clips the left hand column in Chrome on a phone (One plus 2) making editing a little hit and miss!
Martin
@mnf
There is a reset button. Right next to a memorycard. You dont even have to fully open the screws to access it.
Hi mnf,
I’ve seen another customer have this issue but haven’t been able to reproduce it myself. It’s tough because it seems to come up only after extended logging.
I have been working on this issue, here is what I’ve figured out so far:
The only place that a perpetual non-responsive blink is built in to the code is in the calibration routine, which is only supposed to run in the factory. It’s not even listed among the blink codes because a customer should never see it.
Under normal circumstances, the calibration routine will only run if the calibration data is blank. Since resetting the meter resumes normal operation, the calibration data is obviously intact. So something in the code is causing an erroneous jump to the calibration routine.
There are two true “threads” (ie. they have separate stacks) on the meter, one for talking to SD and one for everything else. My suspicion is that an unfortunate alignment of a bluetooth event and an SD card event is causing a stack overflow, resulting in an erroneous jump. Usually the meter can recover from this because the watchdog timer will elapse and reset the meter, but the special blink in the calibration routine specifically sidesteps this because in the factory we want to give the operator time to recognize the problem and address the issue before resetting the meter.
Anyway, sorry for the wall of text, this one is squirrely but I’m looking in to it. Thanks
~James
