Author Topic: Problem with multiple Simblee devices, one phone  (Read 2477 times)

RBerteig

  • RFduino Newbie
  • *
  • Posts: 12
  • Karma: +0/-0
  • Engineer and Magician
    • View Profile
Problem with multiple Simblee devices, one phone
« on: November 02, 2016, 05:43:43 PM »
I'm finishing up a small project built around a Simblee device using SimbleForMobile, and have run in to some friction now that I'm moving off my benchtop breadboard and into the first of two deliverable finished units. I'm using the current release of the libraries in the current Arduino IDE, and exercising the hardware with the For Mobile app on Android (Nexus 5 running 6.0.1 Marshmallow).

If I flash the same firmware into two Simblee devices, they both appear in the app's list showing identical device name and advertisement. That makes it fun to guess (based on RSSI and distance) which is which device. So I added some code to modify the advertised device name based on a hash of the nRF's factory assigned DEVICEID computed at run time. That works like a charm, and now I have "Block B" and "Block J" and can tag the two blocks easily.

Except that the phone app is now only talking to one of the boards. If I flush the app's data and cache, I can then talk to the other board, and not the first. Having the Arduino IDE reflash a board also seems to make that board be the working board. Until "something" happens.

I'm specifying deviceName, advertisementData, domain, and baseline. For a while it looked like adding domain and baseline was the trick, but after my latest build, that isn't doing it any more.

I just tried again with the SimblyForMobile Temperature example, and it has the problem.

To reproduce, do some of the following:

  • Load Temperature in a Simblee
  • Verify that works from Android, touch the chip and see the temp rise
  • Switch that Simblee to battery
  • Verify it still works from phone
  • Load Temperature in a second Simblee
  • Separate the two by several feet so you can tell them apart
  • Note phone shows two Simblees, one near, one far.
  • Access the far one. Touch the chip to verify.
  • Access the near one. Touch the chip to verify.
  • Repeat...

At some point, the phone says "Unfortunately For Mobile has stopped."

Clicking OK takes you back to the list of Simblees screen. The other Simblee will still work.

I don't know if the iOS app has the same problem. This is obviously a problem for anyone needing to have multiple units within BLE reception range that contain the same firmware. I can't tell at this point whether the problem is firmware of phone. Either way, I'm feeling frustrated.

RBerteig

  • RFduino Newbie
  • *
  • Posts: 12
  • Karma: +0/-0
  • Engineer and Magician
    • View Profile
Re: Problem with multiple Simblee devices, one phone
« Reply #1 on: November 02, 2016, 06:10:43 PM »
Sometimes, after a rebuild and upload of the firmware, the App says "The connection request to the Simblee timed out. Please try again."

Trying again does not help.

tolson

  • Global Moderator
  • *****
  • Posts: 854
  • Karma: +20/-0
    • View Profile
    • Thomas Olson Consulting
Re: Problem with multiple Simblee devices, one phone
« Reply #2 on: November 02, 2016, 07:50:18 PM »
Hmmm! Interesting. I've asked for someone from RFdigital to chime in on this issue.

RBerteig

  • RFduino Newbie
  • *
  • Posts: 12
  • Karma: +0/-0
  • Engineer and Magician
    • View Profile
Re: Problem with multiple Simblee devices, one phone
« Reply #3 on: November 03, 2016, 12:13:28 PM »
Some additional notes from my probing at this issue.


I'm using the SparkFun SimbleBLE Breakout boards which have an LED. I've set that pin to OUTPUT, then implemented SimbleeForMobile_onConnect() and SimbleeForMobile_onDisconnect() to turn the LED on while the board is "connected". Whether or not the app failed, the LED turns on when I click that Simblee's box in the list of Found Simblees.

That LED makes it easy to see at a glance that I connected to the board I thought I did. The Android Simblee For Mobile app seems to shuffle the list of found Simblees freely, so you can't even click the third item in the list again and expect it to be the board you just talked to.

Because Murphy's Law says nothing is easy, when I flashed my third Simblee, I discovered that the trivial hash (XOR all nybbles of DEVICEID to a 4-bit value added to 'A') I used to get a unique letter to add to the device name had a collision and my three boards are named J, B, and J. Oops. I switched to computing an 8-bit hash and appending it as two HEX digits to the device name.

In a case where it did the "Simblee timed out" thing where I happened to have a Serial Monitor window open on that board, a sonar print at the top of ui() printed repeatedly, indicating that the Simblee side was hearing a connection start. That printing continued until the timeout appeared.

 

tolson

  • Global Moderator
  • *****
  • Posts: 854
  • Karma: +20/-0
    • View Profile
    • Thomas Olson Consulting
Re: Problem with multiple Simblee devices, one phone
« Reply #4 on: November 03, 2016, 12:57:40 PM »
I think you need to upload a minimal working sketch that people can use to see what you are seeing.

RBerteig

  • RFduino Newbie
  • *
  • Posts: 12
  • Karma: +0/-0
  • Engineer and Magician
    • View Profile
Re: Problem with multiple Simblee devices, one phone
« Reply #5 on: November 03, 2016, 03:13:11 PM »
The SimbleForMobile Temperature example provokes it unmodified.

But to make it easier to see what is going on, make the advertised device name distinct, and if you have an LED to flash, turn it on on connect and off on disconnect by adding code like this:

Code: [Select]
// SparkFun SimbleeBLE Breakout LED pins
const int Pin_LED = 2;

// compute a device name returned in a static string that includes
// a hash of the factory provided unique device id.
char *getDeviceName(void) {
  static char devName[16];
  uint32_t sn = NRF_FICR->DEVICEID[0] ^ NRF_FICR->DEVICEID[1];
  sn = sn ^ (sn >> 16);
  sn = sn ^ (sn >> 8);
  snprintf(devName, sizeof devName, "Simblee %02X", sn & 0xff);
  return devName;
}

Add to the top of setup() to configure the LED pin and compute the device name from the chip's serial number:

Code: [Select]
void setup() {
  // Configure onboard LED
  pinMode(Pin_LED, OUTPUT);
  digitalWrite(Pin_LED, LOW);

  // set the advertised device name
  SimbleeForMobile.deviceName = getDeviceName();

  // ... rest of setup from the example goes here
}

Extend the example's connect handler, and add the disconnect handler to wiggle the LED:

Code: [Select]
void SimbleeForMobile_onConnect(void)
{
  first_sample = true;
  digitalWrite(Pin_LED, HIGH);
}
void SimbleeForMobile_onDisconnect(void)
{
  digitalWrite(Pin_LED, LOW);
}

With these changes, you can tell the Simblee boards apart in the For Mobile app, and you should see that the app will display the temperature screen for the first board you touch, and fail for all others. Until something happens to reset the situation.

One way to reset the situation is the clear all app data for the For Mobile app in Android.

I observe the failure with the current version [EDIT: 1.1.0] in the app store on a Nexus 5 phone running Android 6.0.1 fully patched and current. I don't happen to have access to other Androids at the moment, but I will attempt to try it in an LG this evening. I have not tried any iOS devices, we are an Android shop so I would have to pester a friend...
« Last Edit: November 03, 2016, 03:53:20 PM by tolson »

tolson

  • Global Moderator
  • *****
  • Posts: 854
  • Karma: +20/-0
    • View Profile
    • Thomas Olson Consulting
Re: Problem with multiple Simblee devices, one phone
« Reply #6 on: November 03, 2016, 04:53:09 PM »
Hi RBerteig,

I took a simpler route to narrow down the issue. I just used the temperature sketch and added the line
SimbleeForMobile.deviceName = "unit1"
And in the second one called it unit2.

I added the LED definitions and added turning it on during onConnect() and off during the onDisconnect()

The app on Android 6.0.1 sees both unit1 and unit 2. Albeit the color of the items in the chooser randomly and often turns red and back to grey. That would seem to indicate something with SFM Android is unstable. This happens a lot with all kinds of applications. It is normal for the change to red when the device is connected to another phone. It because the advertizement goes away when connected. But when nothing is connected to Simblee, the choosers should not be toggling to red and grey repeataly or randomly. (Everything is in close proximity so it not a loss of signal due to distances).

At any rate, tapping on unit1 lights the LED on unit1 and likewise tapping on unit2 light the LED on unit2. And they go out when disconnecting. Some of the time the thermometer is displayed. The interesting thing, though, is a lot of the time after choosing either unit1 or unit2 the SFM Android pops up an alert stating "Unfortunately, For Mobile has stopped" "REPORT" "OK"....
BUT, the LED on the correct unit is ON.  Clicking on the OK returns to the chooser menu and the LED on the corresponding unit turns OFF. HMMM!!! Hopefully this is a hint to someone who know the inner workings of the Simblee For Mobile code.

Now onto Android 5.1.1... sees both unit1 and unit2. There is no random red choosers. Selecting unit1 or unit2 lights the correct units LED. And exiting from the app turns off the correct LED. I can go back and forth rapidly with no problems.

Now onto iOS 9.3.5 on iPOD touch.. also sees both unit1 and unit2. No random red choosers. I can go back and forth rapidly with no problems.

Conclusion... Something with Android 6 is flakey.

Can some other people try it out and chime in with their experience with their devices.


RBerteig

  • RFduino Newbie
  • *
  • Posts: 12
  • Karma: +0/-0
  • Engineer and Magician
    • View Profile
Re: Problem with multiple Simblee devices, one phone
« Reply #7 on: November 03, 2016, 11:03:04 PM »
Quote
The app on Android 6.0.1 sees both unit1 and unit 2. Albeit the color of the items in the chooser randomly and often turns red and back to grey. That would seem to indicate something with SFM Android is unstable. This happens a lot with all kinds of applications. It is normal for the change to red when the device is connected to another phone. It because the advertizement goes away when connected. But when nothing is connected to Simblee, the choosers should not be toggling to red and grey repeataly or randomly. (Everything is in close proximity so it not a loss of signal due to distances).

Same Android version as my phone... I'm not seeing the status flickering like that, but I have occasionally had a unit disappear from the list entirely. Then reappear.

When I connected a second phone, it did show red. I rechecked that just now.

Interestingly, that second phone (an LG G4 running Android 6.0.0) was able to switch back and forth between my devices without issue. And now that my Nexus 5 has been shamed by a friend, it just did the same. But that didn't last, and now it fails again.

Quote
At any rate, tapping on unit1 lights the LED on unit1 and likewise tapping on unit2 light the LED on unit2. And they go out when disconnecting. Some of the time the thermometer is displayed. The interesting thing, though, is a lot of the time after choosing either unit1 or unit2 the SFM Android pops up an alert stating "Unfortunately, For Mobile has stopped" "REPORT" "OK"....
BUT, the LED on the correct unit is ON.  Clicking on the OK returns to the chooser menu and the LED on the corresponding unit turns OFF. HMMM!!! Hopefully this is a hint to someone who know the inner workings of the Simblee For Mobile code.

That is exactly the condition I'm seeing. It is clearly a bug somewhere. The question is where.

Just now I clearly hit a different timing window, with the phone app "stopped" but the board left in a connected state as my LED is still lit. I don't see any affordance to cure that other than my reset button or power switch.


Quote
Now onto Android 5.1.1... sees both unit1 and unit2. There is no random red choosers. Selecting unit1 or unit2 lights the correct units LED. And exiting from the app turns off the correct LED. I can go back and forth rapidly with no problems.

Now onto iOS 9.3.5 on iPOD touch.. also sees both unit1 and unit2. No random red choosers. I can go back and forth rapidly with no problems.

Conclusion... Something with Android 6 is flakey.

Or possibly 6.0.1.

Thanks for confirming that its not just me, and for testing it with other devices.

But the Android app should be written to be defensive against glitches in communications over a radio link. Even in perfect conditions, radios still do their own thing.

tolson

  • Global Moderator
  • *****
  • Posts: 854
  • Karma: +20/-0
    • View Profile
    • Thomas Olson Consulting
Re: Problem with multiple Simblee devices, one phone
« Reply #8 on: November 04, 2016, 09:18:16 AM »
Quote
Just now I clearly hit a different timing window, with the phone app "stopped" but the board left in a connected state as my LED is still lit. I don't see any affordance to cure that other than my reset button or power switch.

I've seen that too, where the Simblee is stuck on, yet phone has no way to reconnect or even know the Simblee exists since advertising is gone. And for some reason the Simblee doesn't detect that it has lost connection to phone. So Simblee needs to be (in my case power down) reset.



« Last Edit: November 04, 2016, 09:26:12 AM by tolson »

RBerteig

  • RFduino Newbie
  • *
  • Posts: 12
  • Karma: +0/-0
  • Engineer and Magician
    • View Profile
Re: Problem with multiple Simblee devices, one phone
« Reply #9 on: November 04, 2016, 12:33:39 PM »
RFD Support emailed this morning with the suggestion to make the cache domain be unique for each device. A quick test here seems to indicate that does prevent the failures I was seeing. It also seems to defeat at least part of the purpose of that cache, but for my immediate needs that isn't a problem.

Since I prefer to compute uniqueness at run time so that I can flash the same HEX file into every node, I made a function to build a unique domain name from the DEVICEID:

Code: [Select]
char *getDomain(const char *s) {
  static char dname[32];
  uint32_t sn = NRF_FICR->DEVICEID[0] ^ NRF_FICR->DEVICEID[1];
  sn = 0xffff & (sn ^ (sn >> 16));
  snprintf(dname, sizeof dname, "%04X.%s", sn, s);
  return dname;
}

And then modified setup() to set the domain somewhere before it calls SimbleForMobile.begin():

Code: [Select]
void setup() {
  // ...
  SimbleeForMobile.domain = getDomain("myproject.example.com");
  // ...
}

If I were more paranoid, I'd use the entire DEVICEID as the domain, as that would be unique. The 16-bit hash is unique over my sample collection of boards so I'm using that for now.

tolson

  • Global Moderator
  • *****
  • Posts: 854
  • Karma: +20/-0
    • View Profile
    • Thomas Olson Consulting
Re: Problem with multiple Simblee devices, one phone
« Reply #10 on: November 04, 2016, 01:54:11 PM »
Curious why they didn't respond here! I think I might move[d] this thread to bugs, because you are right that hack should not be required.
« Last Edit: November 06, 2016, 11:48:48 AM by tolson »

tolson

  • Global Moderator
  • *****
  • Posts: 854
  • Karma: +20/-0
    • View Profile
    • Thomas Olson Consulting
Re: Problem with multiple Simblee devices, one phone
« Reply #11 on: November 06, 2016, 12:38:41 PM »
Hi RBerteig,

Changing the domain for each identical device does defeat the purpose of the feature, as the objects being cached would increase by the number of identical devices. So might as well, not use it then, except then it may take longer to upload images everytime. The domain name is theoretically your projectName.yourDomain, so the smart device isn't caching duplicates images.

So playing around again with the temperature example, I kept the  the domain name the same, but changed the baseline from Oct 23 2013 to Oct 23 2016. So far I don't see the errors we were seeing before. (except the toggling of chooser to red and back for no apparent reason).

What were you using for baseline dates in your APP? I am curious if the issue is with using really old baseline dates (at least for the temperature example).

OK, so to see if I am just being fooled, I set the baselines back to the Oct 23 2013...
So now still working. Hmm! So killed the app and restarted. Seems to be working. So now I don't know if going to a recent date cleared whatever was the issue. I wish we knew exactly how this domain and baseline feature is implemented in detail. Can't really troubleshoot by second guessing what is being done.

In summary, I have both devices set to use the same domainName and same baseline and now working. I guess the next test will be to upload a totally different program and/or perhaps power down the phones and see what happens.

OK, tried the power down and restart of the Android 6.0.1. Seems to still work, albeit, very sluggish response times compared to immediate results using Android 5.1.1 and iOS.

RBerteig

  • RFduino Newbie
  • *
  • Posts: 12
  • Karma: +0/-0
  • Engineer and Magician
    • View Profile
Re: Problem with multiple Simblee devices, one phone
« Reply #12 on: November 08, 2016, 11:39:59 AM »
Quote
Changing the domain for each identical device does defeat the purpose of the feature, as the objects being cached would increase by the number of identical devices. So might as well, not use it then, except then it may take longer to upload images everytime. The domain name is theoretically your projectName.yourDomain, so the smart device isn't caching duplicates images.

Yup. That was my conclusion as well. Luckily my immediate need is to make a few nodes work for a demonstration. More than one total, but only one at a time is intended to be used in the formal demo.

Quote
So playing around again with the temperature example, I kept the  the domain name the same, but changed the baseline from Oct 23 2013 to Oct 23 2016. So far I don't see the errors we were seeing before. (except the toggling of chooser to red and back for no apparent reason).

What were you using for baseline dates in your APP? I am curious if the issue is with using really old baseline dates (at least for the temperature example).

At one point while my code was failing, I was setting the baseline with SimbleeForMobile.baseline = __DATE__ " " __TIME__; which would have made it different for every compile, but would also be a very recent date.

Which brought up a pet peeve of mine with Arduino: the sketch uploader in the IDE essentially always recompiles, which meant that every device had a different baseline because __TIME__ would always be different by the amount of time I took moving the serial cable around. That is safest for a hobbyist with a single Arduino board, but is not really ideal for replicating code in several nodes of a sensor mesh.

Quote
OK, so to see if I am just being fooled, I set the baselines back to the Oct 23 2013...
So now still working. Hmm! So killed the app and restarted. Seems to be working. So now I don't know if going to a recent date cleared whatever was the issue. I wish we knew exactly how this domain and baseline feature is implemented in detail. Can't really troubleshoot by second guessing what is being done.

Problems could also be in the BLE stacks in the phones, in the phone's own API somewhere, or...

There really is too little visibility into what is really going on. I do wonder if a BLE protocol sniffer might tell me anything, but I don't have a budget to buy any more tools right now.

Quote
In summary, I have both devices set to use the same domainName and same baseline and now working. I guess the next test will be to upload a totally different program and/or perhaps power down the phones and see what happens.

OK, tried the power down and restart of the Android 6.0.1. Seems to still work, albeit, very sluggish response times compared to immediate results using Android 5.1.1 and iOS.

Bottom line is that this is some kind of a ghosty problem, likely at the core an open timing window based on my past experience with network protocol implementation.

I'm also about to ship away all but one of the Simblee modules I have here, so I may not be able to test anything more.


tolson

  • Global Moderator
  • *****
  • Posts: 854
  • Karma: +20/-0
    • View Profile
    • Thomas Olson Consulting
Re: Problem with multiple Simblee devices, one phone
« Reply #13 on: November 08, 2016, 12:24:08 PM »
Quote
At one point while my code was failing, I was setting the baseline with SimbleeForMobile.baseline = __DATE__ " " __TIME__; which would have made it different for every compile, but would also be a very recent date.

Which brought up a pet peeve of mine with Arduino: the sketch uploader in the IDE essentially always recompiles, which meant that every device had a different baseline because __TIME__ would always be different by the amount of time I took moving the serial cable around. That is safest for a hobbyist with a single Arduino board, but is not really ideal for replicating code in several nodes of a sensor mesh.

Once you have code you want to load into multiple devices, don't use Arduino IDE to program the various units.
Find where Arduino stores the working files during compilation and copy the .hex file to somewhere safe.
Then use RFDLoader to program each of the units with that .hex file.


RBerteig

  • RFduino Newbie
  • *
  • Posts: 12
  • Karma: +0/-0
  • Engineer and Magician
    • View Profile
Re: Problem with multiple Simblee devices, one phone
« Reply #14 on: November 08, 2016, 03:58:56 PM »
Quote
Once you have code you want to load into multiple devices, don't use Arduino IDE to program the various units.
Find where Arduino stores the working files during compilation and copy the .hex file to somewhere safe.
Then use RFDLoader to program each of the units with that .hex file.

This is really an Arduino IDE complaint, but that whole process could be a single click in the Tools menu. So could some way to actually *find* the compiled code which they go out of their way to hide. All of that hiding results from the heritage of Wiring being related to Processing, and originally intended to let artists write programs without needing to learn where to find the plumbing. It's what makes the Arduino so slick to use for a first project.

But needing to look in C:\Users\Ross\AppData\Local\Temp\arduino_build_* for the folder that is most recent to extract and archive a HEX file is annoying. Even more because that spot is not easy to discover from the IDE.  A "Tools|Save HEX file..." could compile and save it, and even tell you the command line of the configured loader that the sketch would have used to flash it.