Example apps do not line up with the documentation.

[SteveHx]

The developer kit is impressive, and I was able to get a test app running quickly using the UART thru the USB connection. However, the example BLE apps feel a great deal like I'm trying to hack my way thru some downloaded garage-shop freeware. I am able to get the demo to run and advertise, and it's remarkably easy with the firmware automatically downloaded upon compile. But they just don't line up with the documentation, with just enough connection to suggest that I do indeed have the correct docs for the code. I am running the CGMS demo, and going step-by-step thru the provided instructions, referenced by number below.

1) Compile and it's advertising. So far so good.

2) nRF Connect, seems to work. Once I figured out that the little anonymous starburst thingy is the "settings button", I got past that. The rest of this step sometimes appears to work, sometimes not ("Pairing" remains red). However, the serial port reports bonding to a previously connected device, when Pairing stays red. OK.

3) What "Play" button? I see nothing that says Play, nor anything the looks like a play button, and none of the buttons offer any hover text. My best guess at this point is that the little arrows on the left that expand each of the 6 displayed areas under the device might also serve to "Play". If I open the Battery Service section, for instance, and now find what looks to be a Play button on the Battery Level subarea, and I see notifications every 10 seconds, or every 3 seconds by modifying the code in the demo.

4) I think I "started a play session" by opening the Continuous Glucose Monitoring section, and finding and then clicking what appears to be a Play button on the CGM Measurement subtopic. Writing 1A to the Specific Operations subtopic yields the documented 1C 1A 01 response perhaps one time in 20. The Write and Indicate buttons never seem to do anything that would be suggested by their names. It appears that the only way to have the 1A accepted is to press Enter immediately after typing a value; none of the buttons seem to work.

5) After I figured out it wants Enter, I get the expected 1C 1A 01 response.

6) "Observe that measurement notifications are received on the Measurement characteristic (UUID 0x2AA7)." This is the whole point of the exercise - and no matter what I do, there is no Measurement characteristic displayed.

If I could get the above sorted out I can probably hack my way thru the rest, but it surely doesn't feel very professional. I keep looking for some kind of configuration utility or even a configuration file whereby I can declare the BLE variables, linkages, update intervals, etc. Hints?

Here are the instructions from the Nordic documentation for reference:

Testing

Test the Continuous Glucose Monitoring Application with the nRF Toolbox app, which is available on both iOS (App Store) and Android (Google Play).

You can also test the application with nRF Connect by performing the following steps:

1. Compile and program the application. Observe that the BSP_INDICATE_ADVERTISING state is indicated.
2. Connect to the device from nRF Connect (the device is advertising as 'Nordic_CGMS'), then bond to the device. To bond, click the settings button for the device in nRF Connect, select "Pair", check "Perform Bonding", and click "Pair". Wait until the bond is established before you continue. Observe that the BSP_INDICATE_CONNECTED state is indicated.
3. Observe that the services are shown in the connected device and that you can start receiving values by clicking the 'Play' button. Battery Level notifications are received every ten seconds.
4. Start a CGM session by clicking the 'Play' button and then write '1A' to the Specific Operations Control Point (UUID 0x2AAC).
5. Observe that the notification '1C 1A 01' (Response code 1C - Session start 1A - Success 01) is received on the Specific Operations Control Point (UUID 0x2AAC)
6. Observe that measurement notifications are received on the Measurement characteristic (UUID 0x2AA7). An example measurement is '06 00 05 00 01 00' (length 06, flags 00, Glucose Concentration 0005, offset 0001).
7. Do a Read all records operation:
   • Write '01 01' (OpCode : REPORT_STORED_RECORDS, Operator : ALL_STORED_RECORDS) to Record Access Control Point Characteristic (UUID 0x2A52).
   • Observe that you receive notifications of the glucose measurements(UUID 0x2AA7) and one indication of the RACP indicating success (06000101).
8. Read the number of stored records:
   • Write '04 01' (OpCode: REPORT_NUM_STORED_RECORDS, Operator: ALL_STORED_RECORDS) to Record Access Control Point (UUID 0x2A52).
   • Observe that you get an indication of the RACP giving you the number of records. For example, 05000400 is 4 records (Number of records response opcode 05, Operator 00, least significant byte of record number 04, most significant byte of record number 00).
9. Test the Bond Management Service by deleting the bond that the application has with nRF Connect:
   • Disconnect the device and reconnect in nRF Connect. Observe that the devices are still bonded. (Link encryption is ON.)
   • Observe that the Feature characteristic (0x2AA5) of the Bond Management Service (0x181E) displays '20 08 00'. This means that the deletion of the bonds for the current connection is supported.
   • Write '03 41 42 43 44' (Command to delete current bond 03, authorization code ABCD) to the Bond Management Service Control Point characteristic (0x2AA4).
   • Disconnect the device. This will trigger the bond deletion procedures.
   • Connect to the device again and observe that the pairing request fails, ending in a link loss. (BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION)

[Joakim Jakobsen]

Hi again.

SteveHx said:

I'm not sure either. I can't find any documentation as to what this "Bond" feature is, what it is good for, how to turn it on or off, etc.

Pairing: Devices that are initially connected can exchange encryption keys and encrypt the link. When they have,
the link is secure and they are paired.

Bonding: Paired devices can be bonded. This means that they store the keys that have already been exchanged when
they paired and use those again the next time they connect.

This means that when you delete the bond information on just one of the devices,
the other device will try to reconnect using the old bonding information. This will not match the deleted device,
so the connection drops.

SteveHx said:

1) How to configure a particular application as to BLE parameters, choice of variables to expose on the BLE interface, options as to those variables (read-only, write-only, etc.)?

We do have nRF Connect,  where you can change the connection interval and so on. This is not possible on most
phones, because the OS handles that.
I don't know what it is you want to change, but in general you have to make changes to the code to acheive this. If you tell me more specific what parameters you want to change, I can help you track down the part of the code you will need to change.

SteveHx said:

choice of variables to expose on the BLE interface

What do you mean by this?
Are you talking about Services and Characteristics?
Or what information that is advertised by your device?

We have a tutorial section here on devzone that you might want to take a look at.
We have an advertising/service/characteristic tutorial. They were made with reference to SDK 11. But apart from some API changes etc, there is a lot of useful information.
One of my colleagues also have a Custom Service Tutorial on his GitHub, which is compatible with SDK 14.2.0.

SteveHx said:

2) How to correct the examples so they will connect reliably with either nRF Connect or with an actual user device?

The examples works just as expected when I try it myself. There is no step in the instructions that doesn't work when I try this.
The connection is consistent, it advertises as expected, connects, bonds and runs just as explained.

Maybe you could tell me which part of the code you made changes to, if you made any changes?

SteveHx said:

Step 1 works. When I connect, I can't even get to the bonding at step 2, because even my fast fingers can't get there before it decides to reject me. When I first tried this, it would at least let me make the selections and click the final "Pair" button before tossing me out on my ear, with the same errors.

This suggests that you have deleted the bond information in nRF Connect, but not in your application.

SteveHx said:

<info> app: Connected to a previously bonded device.

Your device tries to connect to nRF Connect using the keys stored when you bonded the device. This information is deleted in nRF Connect, so the connection is dropped.
Try erasing your board, download the application again, delete any bond information in nRF Connect and try again.

I would also like to note that you are testing an experimental example in our SDK.

Best regards.

[SteveHx]

It sounds like you've hit the nail very precisely on the head, and I have some reading to do. That's exactly what I was asking for, some pointers to cut thru the mass of documentation. One remaining unclear item: You mention a need to erase my target board as a separate step from writing the firmware to it. I would expect, based on many dozens of device programmers that I've used in the past 4 decades, that the J-link would by default erase before programming, and would require special steps to avoid that erase step. I'm running it from within Visual Studio, which hides most of such details. How would I perform the "erase" step that you describe?

[Joakim Jakobsen]

I'm glad you found that helpful.

Well, for the most part the it will erase the application before programming, without you having to perform the "erase step" manually.
But if you for any reason would like to erase your device, we do have a windows application called nRFgo Studio.
"nRFgo Studio supports auto detection of Nordic nRFgo motherboard and radio modules. It also support the nRF51 and nRF52 evaluation kits and programming nRF5x devices through SEGGER J-Link". You can use that to erase your device or flash hex-files to it.
You can also use nrfjprog to acheive the same.

The infocenter is worth mentioning, as it contains alot of information about devices, softdevices, SDK's, examples etc.

Be sure to let us know if you have any more questions.

Cheers,
Joakim.

[SteveHx]

Perhaps I should start a fresh thread, as now I'm down to just the Bonding issue (although the documentation still does not line up with what I see on the screen - I've learned to work around that).

I am using the CGMS example, knowing that it's "experimental", and knowing that such markings usually mean it's more reliable that the supposed "released" versions. When it connects, it works great, and streams data all the way from my very low-level analog sensor thru the SAADC thru the BLE stack to an iPhone. But by far the majority of the time, it either refuses to connect, or connects and instantly disconnects, with various complaints about authentication, bonding, etc. I have not been able to see any pattern to when it connects and when it doesn't. I have tried everything suggested above, deleting the bond information from the phone, reloading the firmware and hence erasing anything that may have been stored on the device, doing both at the same time, etc.. I have chased the error messages down dozens of rabbit holes that get lost in the layers of system calls.

I just need to be able to load firmware and have the phone be able to connect and stream data. It should not be this hard. What am I missing?

[Joakim Jakobsen]

Hi!

"knowing that it's "experimental", and knowing that such markings usually mean it's more reliable that the supposed "released" versions"
I think you meant to write less reliable than non-experimental examples?

As you are down to just this issue, which is not that related to the original question, you could start a new thread that is only focusing on this.

But it is very hard to tell what is causing these connection issues. Especially since I'm not able to reproduce them myself. 

Maybe you could provide some more information?
If you can provide a sniffer log, that could shed some light on what is happening.
Also, if you made any changes to the code, posting the changes could prove useful.
Your setup, with what device, which phone, software versions, which errors you might be getting and so on.

You could try to test another example, preferably one that is out of the experimental stage. The HRS example should be a very reliable example you could test.

Best regards,

Joakim.