New Firmware Update Release
Dear Reader,
I’m happy to announce the release of a new version of firmware.
How to Update Your Firmware
For iOS
With the latest version of the app, the process should be automatic next time you try to connect to your Mooshimeter with the most recent update of the app [Note: At the time of publication (March 11 2015) the iOS app shown is still waiting for Apple review]. The process should take about a minute.
Bug report: After the process completes, swipe the scan screen again to update the firmware version numbers stored in the app. Otherwise the app will try to initiate a new firmware download. (Thanks Sean)
For Android
There are some bugs in the Android BLE stack that make the firmware update process different. To update firmware on Android, do the following from the most recent version of the app:
- Scan for your meter
- Push the reset button on your meter
- While the LED is blinking slowly (5 second window) connect to the meter from the app.
- If you miss the 5 second window and are taken to the meter view page, don’t worry. Just disconnect from the meter and try again.
- If you connected in the 5 second window you will be taken to the firmware upload page. Press the “Upload firmware” button and wait. Unfortunately on Android the firmware upload process takes about 8 minutes.
Technical Details
Why is a manual reset necessary for Android?
In the Mooshimeter there are actually 2 separate firmware images – the Bootloader and the Application. The Bootloader’s sole purpose is to update the Application. When the Mooshimeter is rebooted, the Bootloader turns on for 5 seconds and waits for someone to connect to it to update the application. This is when the LED is flashing slowly. If nobody connects to it in that time, it checks the Application firmware for validity and then boots it. Both the Bootloader and Application firmware advertise their BLE connectivity using the same hardware MAC address. There’s a bug in the Android BLE stack – it makes an erroneous assumption that a BLE device will always offer the same services, so Android only asks for those services the first time it connects to a device. On subsequent connections, it reads the available services from a cache. This is a major problem for the Bootloader, because it offers completely different services from the Application! Thanks to Miguel on StackOverflow there’s a hack to force Android to empty the services cache. But it really is a hack and it does some screwy things to the Android BLE stack when you quickly disconnect and reconnect.
On top of this bug, disconnect events seem to take a very long time to reach the Android app code, so when the Android App tells the Application firmware to reboot in to OAD, the Android BLE stack freezes for a few seconds until it registers the disconnection, usually missing the 5 second window. So right now the most reliable way is to have the human handle the timing. Not elegant but it works.
Why is firmware upload so much slower on Android?
In short, another Android BLE bugs. BLE connections work by having the two devices swap packets at a fixed interval (dictated by the smartphone – typically 30ms). The amount of data you can shove in to one transaction limits the data rate. On iOS you can easily shove 4 frames worth of firmware data in to one transaction (64 bytes), and get all 4 frames confirmed in the next BLE transaction. On Android this has been very flaky, and the only way I’ve found so far to get firmware transmission to be reliable is to send the firmware one frame at a time and acknowledge every frame. This means instead of 4 frames and 4 confirmations per transaction, it’s doing a frame in one transaction, a confirmation in the next, etc., cutting the data rate by a factor of 8. I may be able to get around this, but the inconsistent implementation of the BLE stack across different Android devices makes me hesitant.
What’s Changed?
Power Consumption Bug Fix
In hammering out the logging feature I found a nasty bug that was causing excess current draw in standby mode. The bug raises the quiescent current draw from <10uA to about 300uA. This bug lowers the expected battery life of the meter to less than a year. So performing a firmware update is highly recommended! Technical explanation: The bug was one of the oldest in the book. There is an IO line with a 10K pulldown resistor on the MCU that was being driven high and not reset when the MCU goes to sleep.
Drumroll…Logging!
The new firmware adds SD card logging. After uploading the new firmware to the device, logging works as follows:
- Open the back cover and insert an SD card until it clicks in to place.
- Any SD card under 32GB formatted with the FAT filesystem should work. The FAT filesystem is the default most cards ship with, so if you don’t know what a filesystem is, you’re probably fine.
- Close the back cover.
- Physically connect the meter to the hardware you want to log data from.
- From the app, set up the meter to be measuring the values and range you want.
- The meter will not auto-range when logging, so be sure to set the range so it encompasses the entire expected value of the thing you’re measuring.
- (Optional) Change the logging interval.
- The meter will take a reading, write it to the SD card, and sleep for one interval time before waking again. The default interval time is 1 second. On the configuration page you can set the log interval to be longer or shorter. A longer interval means longer battery life, but less data in the log.
- Press the “Logging” button on the meter view page. It should turn green.
- Disconnect from the meter.
- You can do this by pressing the back button in the top left of the mobile app to return to the Scan page. If the SD card is correctly initialized, the meter will blink every time it takes a sample. So if you set the sampling interval at 1 second, the meter should blink once per second.
The above will be ported in to the support resources soon. To retrieve the log:
- Disconnect the meter from what you’re measuring.
- Open the back cover.
- Remove the SD card and connect it to your computer.
- Run the conversion script CONV.PY
- The l0gs are stored in a binary format native to the meter. For convenience, the meter will write a conversion script in Python to the SD card that will convert the data to a CSV (comma separated value) format.
- Python is an extremely popular scripting language which is probably already installed on your computer. If you don’t have python installed it is available here.
- Open and process the CSV files in your favorite spreadsheet application.
Technical Details
I’ve alluded in the forums to “timing issues” that were bugging this feature up and slowing development. I’ll try to elaborate on what made this feature difficult to implement. At the heart of the Mooshimeter is a CC2540 from TI. It’s a marvelous little MCU and BLE radio in one. However it has some limitations that aren’t immediately apparent until you are developing with it. The biggest of these limitations from a firmware development perspective is that the codebase provided by TI does not react well when any single process uses the processor for more than roughly 100ms continuously. Even though the radio interrupts are the highest priority and should be able to grab the processor from a lower priority task, the radio interrupts drive a framework that relies on the OSAL (operating system abstraction layer, a task-scheduling system provided by TI) not running any long tasks. If an OSAL task running too long only caused the BLE to disconnect that would be one issue, but it causes the BLE stack to fail entirely such that the device is no longer connectable until a reboot. It’s hard to tell exactly what’s going on because the radio stack itself is closed-source, and provided only as a binary that must be statically linked in.
A quick aside: I think TI has recognized this limitation is a major drag on developers. Their successor to the CC2540, the CC2640, is radically different and has a totally separate core running the timing-critical aspects of the protocol stack, leaving much more of the main processor free for application code. Also the processor is a major upgrade – it’s a 32-bit ARM3 instead of a puny 8-bit 8051. Math becomes so much easier… doing RMS calculations on buffers of 24-bit data with an 8-bit processor is painfully slow. The CC2640 datasheets were only released a few weeks ago, and I can tell you I’m excited to try it out. It’s a very strong candidate for the core of Mooshimeter 2.0. Nordic Semi also has some handsome chipsets with advantages over the CC2540. But one thing at a time…
Talking to an SD card involves a lot of waiting around. SD cards are slow to initialize and to write, with larger cards generally being slower. After powering up an SD card, the host must command it to leave the idle state, which can take hundreds of milliseconds. After every read and write operation to the card, the host must wait until the SD card is ready again before sending the next operation. Since the SD card has no IRQ, this means polling the card.

The SD card interface on the Mooshimeter is based on elm-chan’s FatFs module, which is a wonderful free library but not designed to run asynchronously. Since the long polling delays cause the BLE stack to crash unrecoverably, chunks of the library had to be redesigned to run asynchronously. It still needs more work before it can talk to an SD card while maintaining a BLE connection, but it can run without delaying so long it borks the stack.
What’s Next
First: The top priority for the next few days will be improving documentation and website resources, both for support and for development.
Second: The apps are improving but there are still a few missing features that would increase utility. Actual numerical power factor display is still missing. Logging in the app itself (instead of to SD card) has been requested and would be very useful – basically just something to save your entire multimeter session to a log file on the phone itself.
Third: Obviously having to remove the SD card to retrieve the logs is a hindrance and cuts down on some useful embedded applications. The next firmware goal is to get the logs streaming out over the wireless connection. This is difficult because it involves having the SD card and the BLE connection active simultaneously, which is quite difficult because of the timing issues above. It’s achievable but it involves rewriting more of the filesystem and disk access code to be asynchronous.
Finally: Word has been spreading about the meter and there is a decent stream of orders coming in. That’s very encouraging because there’s been no marketing, it’s all word of mouth. So calibrating, packing, and shipping is still happening in the background.
I’m a little behind in the forums, I’ll make a pass through shortly. Sorry, it’s been a tight debugging loop trying to get around the logging issues. Thanks for reading!
James,
Great work on the update. Is there a link to the python script?
It’s not online, it’s baked in to the firmware and will be written to the SD card (you don’t need to download it). I can put it up if you’re interested in having it online.
The linke to the python above is broken.
Error 404 – Page not found!
The page you trying to reach does not exist, or has been moved. Please use the menus or the search box to find what you are looking for.
Good catch, fixed!
Running iOS8.2 on an iPad Air with the testflight of 1.4 (102); every single time I connect it was asking me to upgrade the firmware. I’d hit OK, and it’s start the upgrade, show the progress bar moving, the red LED goes mostly solid, then it’d pop up and says “Firmware upgrade complete: Firmware upgrade was successfully completed, device needs to be reconnected”. Pressing OK dropped me back to the device listing screen (still showing the old firmware). Tapping to reconnect makes it run the firmware upgrade again. To make it quit doing that, I had to swipe down to force a manual rescan, and then it saw the new firmware revision and was good to go. Just a comment about the process you may want to document. I’m now running 1426035947. Works fine afterwards and hibernate/re-awaken by shorting resistance works fine, as expected. No card handy to test with so that’ll be tonight :)
Doh! You’re right, I know what the issue is but won’t have access to a mac until tonight. Thanks for catching that, I added a note to the blog post.
James,
I was able take some measurement and import the data into excel Version 10 but there is a problem plotting the data. The time stamp appears to be ASCII but the AC voltage seems to be a unicode in behavior and reports less than 1 for a 120 volt measure. The numbers display fine but when I try to modify them I get strange behavior. Is there a trick to importing the *.CSV file? I tried saving the file as ASCII in note pad but that did not work. Please let me know what I am doing wrong here?
James,
Setting up the logging is a hit or miss operation. If you log at 1s intervals or less you cannot tell if you are in logging mode. If you think you are taking data and you find that the data is not on the SD card this could be very frustrating especially if the test if of long duration. I suggest a difference sequence of led blinks to verify that you are really logging. Possibly a long LED blink (10 seconds) to start the Logging process and a similar blink to end the logging. We need to have some method of determining if the logging is working.
@Boyd: Change the .csv file extention to .txt. Open the file in excel. The text import wizard will pop up. Click next. Check “comma” (“tab” should already be selected). Click finished. For some reason, the tabs are causing execel to think the numbers are not numbers.
Awesome work, James! I had a terrible issue with the last firmware version that whenever I was on AC Voltage measurement, the meter would crash and the app would kick back to the scan screen. Glad to see that bug is gone :)
I still see the issue where I rotate the iPhone 6 screen counter-clockwise, and the graph window comes up, then flips 180. So basically I have to flip the phone clockwise in order to get the graph right-side up… :)
Thanks for the update! Keep up the great work :D
MaxAmp,
That did not solve the problem. The data comes in and displays correctly but will not plot correctly on a scatter plot (i.e. Y vs X) in Exel version 2010. The time plots correctly but the RMS voltage only displays zero when hovering over any of the data points. Whin I type over the cell data point with the same value the data displays correctly on the plot. When I try to edit the number by deleteting the decimal point and put it back in “121.33104” I get “12.331042”. When I sum the numbers up in a function I get a sum equal to zero. So there is something wrong with the number format.
Solved the Excel 2010 by inporting the data file as a Macintosh data file which converts to unicode.
The new firmware (1426035947, written from my Android phone) looks great. I’ve developed for 8051 in the past so I’m aware of its limitations. I also tried logging the temperature in my fridge as an experiment (see http://www.rulingia.com/~peter/p1.svg, http://www.rulingia.com/~peter/p2.svg and http://www.rulingia.com/~peter/p3.svg). The voltage scale is the output from a type-K thermocouple plugged into the meter.
At least using Python 2.7, I didn’t have any unicode issues with the output from the conversion program (I double-checked the output after reading the comments above).
OTOH, I did run into one regression: The battery state reading has disappeared. This was useful to know when the battery needed replacing.
And two bugs: 1) Although I had logging set to 10s, it wrote samples at 1s – this wasn’t a problem this time but it could be. 2) The timestamps were based on some arbitrary point (possibly set to 0 when the firmware was downloaded), whereas your sample above shows epoch seconds – it looks like there’s some time initialisation code missing somewhere.
I also have a couple of feature requests:
1) Could you please document the raw binary format so we can use alternative tools to process it.
2) Could you please document the logging volume (based on the python, it’s a 13 byte header, followed by 20 bytes per sample).
3) Could you please document how to stop logging.
4) The python script assumes that the log file has an upper case name. Whilst this doesn’t matter on FAT, when I copied the file onto my Unix box, it wound up with a lower-case name so the script couldn’t find it. Would it be possible to adapt you script to look for upper or lower case names?
5) How difficult would it be to add support for reading temperatures using a thermocouple? So I can plug a type-K (or some other common) thermocouple into the voltage or Ohm input and get a reading in °C.
Peter,
Max Amp was correct there is a tab charactor that is interfering with the import into Excel Ver10. The solution is the include the tab character into the inport options and also the comma character. Once imported delete the columns created by the tabs. I do not understand why there are hidden tabs?
Peter,
Max Amp was correct that there are tab charactors that is interfering with the data import into Excel Ver10. The solution is the include the tab character into the inport options and also the comma character. Once imported delete the columns created by the tabs. I do not understand why there are hidden tabs?
flummoxed. downloaded the latest android beta update, when connecting I am advised to update the device firmware but the options are “continue without updating” or “view update instructions”, there is no option to actually update the firmware.
I think I now have the latest beta software, but not the updated firmware, and I’m crippled.
PS: how do we check and verify the current hardware firmware? What is the current firmware version, what is the beta firmware version?
Hi Joel,
You’re right that there’s no option to start the update from the dialog box you’re presented. It’s confusing, but there are annoying technical reasons why you can’t force the meter to reboot and reconnect to it from Android, so the user must do it manually (see the instructions page you’re linked to for information on that).
The beta app should still be able to connect to legacy firmware – is it not working for you?
Also – the firmware version is visible in the page where you scan for meters.
Hope this helps, let me know if you have other questions.
Reviewed the firmware update video (https://www.youtube.com/watch?v=tRRV7ARttbE), and tried doing the bluetooth device scan AFTER pressing the Mooshimeter RESET button- this gave me the “Bootloader” connection option, and the “Start Programming” option.
A little non-intuitive, but it finally worked for me.
Note for beta testers: The new Android software will work with the old firmware, roughly but not seemlessly. If you update to the beta software, you should also update the firmware.
PS: Thanks James for the response- I did get it working (see my previous).
I like the update generally- esp the “Manual Scaling” option for graphing (more on that later). Looking forward to bluetooth transfer of logging data- I think that will be the most important update possible for this device.
I really like the Mooshimeter, it’s a game changer for tinkerers like me- You guys have done a great job on this so far.
As someone who has used control & display software at major astronomical observatories for over 30 years, I can also say that the user interface is absolutely critical to real success- if it’s not easy and intuitive, then the device will never be used to its fullest capabilities, and will not be adopted by all the users that might otherwise benefit… A great device is not useful without a great user interface. At our observatory, I am always pushing for more software support- physicists and hardware guys always seem to believe that great hardware is sufficient, but the reality is that the user interface is as important as the hardware- if you can’t use it easily & efficiently, you will never get the full benefit.
My too sense.
6/10/2016 update:
I’m seeing voltage measurement errors since updating my software & firmware to the latest beta- testing on a 12v battery, with all probes connected to the same terminals, I am seeing 13.37v on two different Fluke DVMs, but 13.8v on the Mooshimeter.
The new software includes a “Zero” function, so I have tried clicking “Zero” while connecting the Mooshimeter probes together, but this did not help, in fact the Mooshimeter displayed voltage changed from 13.8 to 13.9 vdc (even further from the correct 13,37v as indicated by the Flukes)
I’m wondering whether there is a bug in the “Zero” function in the new firmware? I think the Mooshimeter agreed well with my Fluke meters, until I upgraded software & firmware to the latest beta.
joel.