- This topic has 11 replies, 3 voices, and was last updated 7 years, 5 months ago by
.
- Posts
Updated Android app today with version 1.0.18(993). Was prompted for firmware update, finally got that to work after many attempts*. What I’m seeing now is a problem in buffer mode. After doing 2-3 refreshes, the display continues to show the spinning circle, even after switching back to trend mode. Returning to the numeric display, both channels show overload. I have kill the app to get it back to normal operation.
This problem is 100% repeatable on 2 different devices: a (2013) Nexus 7, running Android 6.0.1, and an LG Leon running Android 5.1. The previous version of the app never had this particular problem.
*Not sure how I finally got the firmware to DL, tried with both of above devices, scan found the bootloader but hung on connecting. I eventually tried toggling BT off at the Android system level and then got the DL screen. FWIW, the firmware update was 6-7 minutes (not in legacy mode).
Unfortunately this problem seems to make buffer mode rather useless for the time being, so this update is pretty disappointing.
Hi Peter,
I’m very sorry it broke buffer mode for you… we’ll test this again. Thank you for testing this, it’s why we do beta releases! Can you revert to the production release of the app until we push another version?
Most of the changes in this release were under the hood, trying to address why firmware updates from Android fail so frequently. I wrote a blog post about it here:
https://moosh.im/2015/12/android-swapping-ble-packet-payloads/
We’ve been focusing on improving the firmware update process because there is a major firmware update in the pipeline. Honestly though with the number of issues that seem to come up working with Android both in the device discovery process and in the upload process we’re considering dropping firmware uploads from the Android app entirely and forcing users to borrow an iOS device. It would be a small, fixed amount of pain rather than a highly variable amount of pain depending on your device, Android version, etc. Do you have any thoughts on this?
Sorry again for the trouble, we’ll revisit the buffer mode in the beta and push a new version soon. Happy Holidays!
~JamesJames, thanks for the prompt response. Yeah, I know it’s beta, which is why I tried to get/give as much info as possible. Being a dev with a background in data com, I have an appreciation for sketchy protocol stacks and undocumented “features”. Still, I would be very disappointed in an ios only firmware update. I have a house full of Android devices and no access at all to ios or any Apple devices. As a matter of fact, I was hoping you’d extend the Android Bluetooth functionality to allow the app to manage the sd card data, with at least the ability to clear and DL log files. I work a lot (hobby) with battery driven boats (not models) and would love the ability to get at the data without disassembling the unit. I may otherwise just hack the case, but that’s not ideal, especially in a saltwater environment.
Thank you Peter – yes, I admit I also don’t like the idea of removing firmware update from the Android app. It’s just such an awkward position to be in – having a feature in a production app that fails for a significant subset of Android users. We will probably settle for adding a warning to the Android firmware upload that says “This feature is in beta – if it fails here please try an iOS device” or something like that.
Remote log file retrieval is something we’re working on… I hope to have an update on that for you in the next few weeks.
Would you be willing to email a few pictures of the Mooshimeter in use? We’re always looking for new testimonials.
Thank you!
~JamesSInce it’s winter here in Boston, my boating season is done, unfortunately. I may be setting up some solar panels to with battery charging sometime. If I do, I’ll try to get some pictures and a testimonial.
I’m really interested in monitoring SOC & dynamic power on my sailboat auxilliary electric motor, also getting rpm (brushed motor), and logging solar charging during idle periods, but that will have to wait until spring.
This winter I’d like to do some analysis on my (old) home wiring and see what I can see. If that works well, I’ll try to do a write up. Both would be interesting applications for the Mooshimeter.
I have a similar story to Peter’s : I had great difficulty getting the download to run (it mostly got stuck ‘connecting’ or ‘autoconnecting’) and only got it to work when I saw Peter’s report and tried turning the BT off and on again.
The download then worked well, taking 2 minutes. But afterwards, the app wouldn’t believe the meter was back in normal mode despite the led indicating that it was. Again, cycling the BT in the phone setup allowed it to work.
It’s now mostly working, but I can confirm the problem Peter reports with buffer mode. It will refresh once or twice and then gets stuck.
Regarding downloads on Android devices : how about putting the update code on an SD card and installing it from there ? They’re much cheaper than an iOS phone !
This is helpful, thanks! I assume you’re using android 4.4 or 4.3? It sounds like on some android phones, the BLE services are being cached incorrectly and only get refreshed when bluetooth is turned off and on again. There’s a firmware update in the works that should make this problem go away, expect it in january. It should also fix the buffer mode failures, which are due to android packet drops.
Regarding firmware updates from SD card – this would require an overhaul of the bootloader itself, which can’t be changed once it’s installed. So I’m afraid it’s a feature I can’t add…
Happy New Year!
JamesIt’s actually Android 5.1.1, on a moto G version 3. I assume this is why the bootload itself worked OK, though there still appears to be some caching problems.
I also had difficulty swapping between apps running on the moto G and a Nexus 7 (2012), also running 5.1.1 (and with a patch app that enables the unsupported BLE). I had difficulty releasing the mooshimeter from one device so that it could be seen by the other.
If you were to update the bootloader for later production units, what would be needed to replace it on older devices ? The CC2540 is quite widely used and the CC debug adapters available cheaply, if that’s what’s needed.
I stand corrected! Thanks, good to know the caching issue exists on 5.1.
Regarding updating bootloader: on the bottom of the pcb there are 5 pads that run to the debug interface of the CC2540. It would be possible to for a user to update firmware through that interface, but the calibration data is also written in the flash memory and may have to be wiped. I can’t remember off the top of my head if the CC2540 lets you change the flash page locks without a full chip erase. The other factor is that the code necessary to read from SD is actually pretty large, including it in the bootloader image may requine reducing the space for the application image, which means changing the flash map, which means all previous versions of firmware become incompatible with the new bootloader.
In short I really like the idea of loading firmware from SD, but it’s got some challenges associated that could quickly become a support nightmare, so I need to think about the tradeoff some more.
Are you an EE using the CC2540? The firmware isn’t open source but I’m happy to answer questions about it.
Best
JamesOK, thanks, I see it’s not an easy fix. Another thought is to look at the Nordic BLE software – they’re offering OTA updates and although I’m not suggesting changing to their devices, their code might show workarounds for the android problems.
I’m an EE and embedded software engineer. It’s a shame that the firmware isn’t open source, but at least the apps and protocol are, and that’s probably the most useful area. I did look at some other wireless meters but your idea of putting two channels in is really good. I bought it with a particular application in mind – a windpowered artwork that has all the electrical parts spinning and a need to monitor power consumption and battery charging. I probably should have built wireless monitoring into it but a ready-made device is great.
Hi Artag,
I looked at the Nordic implementation – unfortunately they don’t have to fight the same issue with Android because they don’t do attribute “writes” and “notifies” simultaneously on the same channel. I’ll read some more of their source though, they may have some other tricks… thank you.
If you put any of the art online please drop a link here, I’d love to see it.
Best
~James
