This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

nRF Master Control Panel for Android crashes when displaying details of fast advertising peripheral

Dear Nordic team,

I've seen very much reproducible crashes of your Android nRF Master Control Panel app when trying to see details (button "MORE") of particular Peripheral device. When I use aggressive advertising intervals (down to 20ms for connectable beacon) and dynamic advertising data (altering at least couple of bits to have each ADV_IND packet unique) it works only if I go to "MORE" menu at the very early stages of scanning. It seems to me that once number of logged points exceeds certain limit (internal buffer?;) it crashes completely and app must be restarted.

I'm using latest nRF MCP version from Google Play Store (V3.4.1) and Nexus 5 running Android 6.0 but I've seen this on other devices and Android versions as well. I believe that it's OK to drop some parts of the log instead of uncontrolled crash...

Thanks Jan

Update on 3-February-2016

The latest Google Play upgrade (version 4.0.3) fixes the crashes, great work! Thanks for the testing. I'd still change the behavior of manual scan option, also note that for this "dynamic" beacon you don't display any advertising interval - probably because the data are different - but you obviously link reports by Adv. Address so you could easily add the timing estimation as well. But these are rather change requests and end user feedback which is up to you to add to your backlog or not;)

Cheers Jan

  • Hi Jan,

    Thanks for the bug report. I'll try to fix it. Indeed there is a limit in data I can send from one activity to another and your way of advertising is on a very good way to exceed this limit. I'll try to fix this issue in a next release, hopefully.

    Thanks for using the app!

    Best Regards, Aleksander

  • Thanks Aleksander, the app is actually great, please keep fixing and evolving it! Cheers Jan

  • Hi @afnowakowski, I've just upgraded to MCP 4.0 on my Android phone running 5.0.2 (so low end device not Nexus 5 as in previous report) and it looks that bug persists (app shuts down immediately if you want to open "MORE" menu on particular advertisement which generates too much traffic). Otherwise new features and improvements are great, please just let me know if the issue is supposed to be addressed in this release or if it still on TODO list?

    Btw. I'm using basically just "manual" scanning mode and it's extremely annoying that going back from any activity (connection or viewing details in observer role) stops the scan and I need to restart it aging (= ultimately leaves a gap of "silence" so in case that advertisement is dynamic I'm missing some information). Is this supposed to be feature or bug?

    Thanks Jan

  • Hmm.. The first issue I thought I've "fixed". I now show only the 200 most recent different packets in the details screen. It may still crash if summer of them has a lot of equal packet (I save the Rssi and timestamp of each of them), but 200 worked fine in my testing (the device was changing packet every 1-2 packets sent). I'll have a look into it again. As for the second, I scan only on the Scanner tab. If you switch the tab, or open MORE or any item from the navigation menu, I stop. It's not a bug or a feature, it's like that by design. It was easier for me like that. Maybe in the future it will change, keep pushing ;) For now you may also use 2 phones if it's a blocker...

  • I will be able to test new MCP on Nexus 5 in January but current phone is running almost mint Android 5.0.2 on Snapdragon 400 with 1GB RAM so it should be representative gadget. I can help you to modify beacon example from SDK to use connectable advertisement with 20ms interval and rolling 32-bit counter placed into Major&Minor Version fields if necessary to reproduce.

    Regarding second topic: I was expecting this implementation logic but wouldn't be better to "remember" in what state manual scanning was? Why should be scanning stopping all the time when user explicitly sets "manual" mode so he remembers that he started scanning and kind of expects that app will do what it should do?;) Just an idea. I obviously don't use MCP as ultimate validation app, there are better sniffers for that so I luckily don't need to juggle with several phones;)

    Thanks Jan

Related