Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - RBerteig

Pages: [1]
Support / Re: Simblee, OTA and flash
« on: December 02, 2016, 12:41:09 PM »

I thought I read somewhere that each Simblee is uniquely serialized. (Can't find info at the moment.) If this were the case, and if DFU Implementation could read the value, then the iOS app could allow DFU only for the Simblee that was connected prior to the user initiating OTA update.

I don't know what other serialization might exist in the modules, but the Nordic nRF51822 chip at its core has a 64-bit serial number that is provided by the factory. This is documented in the nRF51 Series Reference Manual in Chapter 7 Factory Information Configuration Registers (FICR). Unfortunately, they say very little about it:

64 bit unique device identifier
DEVICEID[0] contains the least significant bits of the device
identifier. DEVICEID[1] contains the most significant bits of the
device identifier.

There is also a 48-bit DEVICEADDR with a similarly vague description.

In your sketch, the necessary definitions appear to be "magically" included, so you can read any of the FICR registers from the global NRF_FICR. E.g., the ID is found in NRF_FICR->DEVICEID[0] and NRF_FICR->DEVICEID[1].

Nordic's documentation is available at their site:

Simblee For Mobile / Re: Button text clipped on iOS
« on: December 02, 2016, 12:16:42 PM »
It could address the cropping of the color wheel on the iOS screen, if you place it at "screenHeight-100" or something like that, so it definitely won't go out of the screen.

That would work if its size were documented. It isn't. And on Android, I observed that the color wheel was scaled to avoid cropping, so that it was not possible to place it freely on screen without it filling unexpected space. I discovered that while trying to measure its size by moving it closer to the edges. From the screenshot I posted, you can see that on iOS it is cropped at the bottom, so it is not being scaled there.

Closer to your problem of non-centered text in the buttons, I agree that there should be a feature for the Buttons to select the size automatically depending on the size of the text, and then to center the text accordingly.
Maybe a function override on the side of the SimbleeForMobile Library would permit this?

The existing three overrides of drawButton() allow freedom to specify color and button type. The "button height is automatically calculated" as is typical, but the "width can be specified, to aid in alignment". Setting width isn't very useful if the dimensions of the font aren't known. And screen layout is made much more difficult by the automatic calculation of height, since there's apparently no way to discover what height was calculated.

Lets see wether developers at RFDigital chime in on this, or give us feedback, and otherwise we might want to write them asking directly for this feature.

(To an admin, maybe move this thread to the SFM category?)

The original bug report is the cropped button text, which is clearly wrong in iOS and right in Android.

The issues with sizes of font and UI elements are universal, and probably should get their own thread.

Simblee For Mobile / Re: Button text clipped on iOS
« on: December 01, 2016, 02:20:11 PM »
You can even calculate the proper button width. It will automatically adjust to any phone.

Look at the screen shots. The buttons have generous width on Android, and the single letters are centered. On iOS, the letter starts at the center of the button, and is cropped off almost immediately.

I could have calculated that button width as screenWidth/10, and that would not have made a difference to the crappy rendering on iOS.

I can't find a documented API to learn the actual display width of a string, or how wide to make a button. And for this sort of dashboard application I should not have to.

For that matter, nothing documents the size of the built-in color wheel graphic, so using it as I did seems to be a bit of a crap shoot. Moreover, on Android it seems to scale to fit the space left on the screen, while on iOS it is cropped at the screen bottom.

No one would ship the For Mobile app as their interface to a commercial product. I don't see that as being its market. It is, however, a decent idea for how to get a quick, cheap, and usable dashboard interface to a one-off piece of hardware whether that is a demonstration as part of design of a real product or a hobbyist's toy.

As such, it seems reasonable to demand that it do a better job of trying to just get along with what the firmware asked for. Doing a better job of fitting text into a button is a good example.

Providing some simpler screen layout idioms would also be lovely.

So would automatically avoiding the bands at the top (iOS) and bottom (Android) which are customarily used by the OS itself. Not being an iOS user, I was shocked to find controls that I placed at the top of the screen were located on top of system status displays and buttons on iOS. The app simply should not do that by default.

It's mission is not to be an immersive experience app. It is a dashboard browser for controls.

Simblee For Mobile / Button text clipped on iOS
« on: November 11, 2016, 04:21:42 PM »
I developed a demo with an Android (Nexus 5, specifically) but its user has an iPhone (6S I believe). After some troubles with using PNG images reliably, I switched to buttons marked A, B, C, D, and Z. Good enough for a demo. All looked and worked great on my Android. The intended user just sent be a screen shot from his iPhone where the button labels are placed off-center and cropped to the point that you'd have to know what the button said.

The attached PNG shows screen shots from both phones scaled down to match and placed side by side.

The buttons are drawn like this:

Code: [Select]
void ui()
  // ...
  uint16_t y0 = 0;
  if (SimbleeForMobile.remoteDeviceType == REMOTE_DEVICE_OS_IOS) {
    // leave room at top for iOS status and controls
    y0 = 60;
  // ...
  btn1 = SimbleeForMobile.drawButton( 25, y0+155, 35, "A", WHITE);
  btn2 = SimbleeForMobile.drawButton( 65, y0+155, 35, "B", WHITE);
  btn3 = SimbleeForMobile.drawButton(105, y0+155, 35, "C", WHITE);
  btn4 = SimbleeForMobile.drawButton(145, y0+155, 35, "D", WHITE);
  btn5 = SimbleeForMobile.drawButton( 260, y0+155, 35, "Z", WHITE);
  // ...

I suspect I could undo the clipping by changing the button width to something wider than 35 pixels. But how was I supposed to know that when it displays just fine in Android without having an iOS for testing?

I thought a big selling point of the SimbleeForMobile was to provide a reasonably simple platform agnostic experience.

It runs. But making it look good in both places is still more work than it ought to be.

Bugs / Re: Problem with multiple Simblee devices, one phone
« on: November 08, 2016, 03:58:56 PM »
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.

Bugs / Re: Problem with multiple Simblee devices, one phone
« on: November 08, 2016, 11:39:59 AM »
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.

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.

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.

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.

Bugs / Re: Problem with multiple Simblee devices, one phone
« 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("");
  // ...

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.

Bugs / Re: Problem with multiple Simblee devices, one phone
« on: November 03, 2016, 11:03:04 PM »
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.

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.

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.

Bugs / Re: Problem with multiple Simblee devices, one phone
« 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...

Bugs / Re: Problem with multiple Simblee devices, one phone
« 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.


Bugs / Re: Problem with multiple Simblee devices, one phone
« 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.

Bugs / 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.

Pages: [1]