- This topic has 3 replies, 2 voices, and was last updated 6 years, 11 months ago by
.
- Posts
I noticed my phone had downloaded a new app and firmware. I’m afraid that for me this is not working at all:
After FW installation I could not connect, and had to reboot both phone and meter. Then I could connect just once, and all subsequent attempts failed. The errors are alternately
“Connection failed. Status: 133”
and
“Initialization failed. Status: -1”.App 1.0.24(1849), FW 1466126223, Nexus 5 with Android 6.0.1
James, would you mind putting up a download of the APK for App 1.0.23 with FW 1466039460? This was working quite well.
Hi Tim,
Very interesting, thanks for the feedback. I rebuilt the apk directory on moosh.im, so you should be able to grab previous versions here now:
However: Looking at the changelogs between version 23 and 24, nothing BLE related in the app changed. Have you tried rebooting the phone? It may be Android that’s failing.
Let me know how it goes,
~JamesJames, Downloaded android app ver 024 and new FW 1466126223 from playstore. Installed with no problem (slow) on a different mooshimeter and different phone (android 4.4.4) compared to my comments on ver 023.
Looks like some improvement in the graphing. The graph flickering or blinking is fixed. OVERLOAD is changed to the more appropriate LOADING. However, in buffer mode, I still have the weird plot values every several seconds. Try 120VAC wall socket,manual 4000Hz, manual 256smpl. Logging (without app active) does not have this. Logging while in buffer mode, it is like the firmware cannot keep up. The first three log values are ok, then the timestamp is 15sec instead of 10sec and the values are not correct, then values for both channels are 0 for the rest of the file measure values.
Logged 120VAC house voltage and internal temp for a few hours. This time only one file and all measured values looked great. However, the file contained multiple headers at the beginning and one at the end of the file, all with no measured data. The headers recorded my app changes one at a time (0125Hz to 4000Hz, then 0064 to 0256) even though I made sure logging was off when making those changes. Also, based on the timestamps, the empty header at the end corresponds to the time I turned logging off before removing the SD card from the meter.
This is repeatable for me: Logging off, insert SDcard, change freq rate to different freq, wait a couple of seconds and the LoggingOFF temporarily changes to WRITE_ERROR), verify back to LoggingOFF, remove SDcard and observe empty header. Each time the freq is changed a additional new header is written to the same file, but only the first one gives the WRITE_ERROR indication in the app.
As done previously, logged overnight 3AA battery voltage on one channel and 1.8K resistor on the other channel . This time only one file and everything looked great.
Quick look says meter is stable. I had no lockups playing around with it in this configuration. Maybe it was due to different meter and different phone. Maybe you really fixed a few things :) Sure are lots of variables. – — Duane
Hi Duane,
Re: Buffer mode and logging not working at the same time: You’re right, this is an edge case that’s not handled in the firmware. When buffer mode is on, the meter skips calculation of the mean or RMS value, and those are the only values that the logging task checks. I think the right behavior for now is for the logging to go silent in buffer mode. If I get some more development time down the road I could probably make it spit the waveforms in to the logfile, that could be useful to some. But you’ve found another bug, thank you :)
Re: logfiles with headers and no content: I think I’ve addressed this and will be pushing the update ASAP (in upcoming release 25). In version 24 and prior, a new logfile is created as soon as the SD card is available, whether or not the user has activated logging. This is not a good behavior and has been changed.
Re: stability – your feedback has driven a lot of good changes, thank you again. “Sure are a lot of variables” – this is frighteningly true. The poor little 8051 core with 8k ram is being pushed to its limit. There are two other changes in the upcoming release that I think you’ll appreciate: first is that log settings are saved to nonvolatile memory, so that if the meter somehow accidentally reboots while logging, it will resume logging with the same settings as soon as it recovers. Second, I discovered that the waking of the SD card and the sleep/standby of the SD card could be out of sync. That might seem like a strange error, but it stems from the fact that the ADC and the SD card share a power supply. So the firmware bundled with release 25 should be even better.
Thanks again
~James
