[ZeROSEro7] First transmission from smartphone to nRF52

As Erwan said, we swapped the LoRa and BLE dev kits and explained to each other what we understood. Since the SW1276 dev kit has changed, he will have some modifications to make but I hope we’ll eventually get the LoRa Ping Pong demo code run on this one very soon !

Additionnaly, I made great progress on the nRF52 dev kit. Erwan did a great job and could run the Fibonacci program and even toggle some LEDs, but I couldn’t run any code including BLE from the SDK. I eventually found out that the driver responsible for BLE, “softdevice” had been obfuscated. It’s actually a binairy file that I had to place at the start of the flash. It contained an SVC interruption handler at the specific address which then tried calling different “observers” by finding them in the binairy through function IDs. It’s the only part of the SDK which doesn’t provide it’s source code and works so weird. Anyway, this adventure helped me understand how most of the BLE functions bizarre prototypes. Indeed, they look like this :

SVCALL(SD_BLE_GAP_ADV_START, uint32_t, sd_ble_gap_adv_start(ble_gap_adv_params_t const *p_adv_params));

This discovery was made possible because I had implemented a logging tool via RTT. Not only can I printf things with it, but I also mixed it with a few debug tools in the dev kit. For instance, I was able to override a weak error_handler that is called every time a SoftDevice function returns an error code and print it. I also found a translator that, for a given error code, returns a printable string describing it. It is then easy to find the Doxygen I generated for the SDK and have additionnal information.

After that adventure, I was finally able to make a successfull ble_init ! The next step was to communicate with something else through BLE. Since our gadgets have to be discreet, I didn’t wanted the dev kit to advertise itself but rather wait for a particular signal before starting a connection so in the first steps of the use case, the gadget will actually act as a “central” BLE device rather than a “peripheral”. Unfortunatelly, this will mean more power consumption since BLE is an assymetrical protocol so that the peripheral can reduce power.

After reading the examples, I incrementally built a software to detect BLE advertisements, and then a nice function to parse them and print each field separately through RTT. It worked and I discovered 2 BLE peripherals advertising in my area but unfortunately among their 31 bytes of data was only a “manufacturer specific” field and private addresses so I couldn’t know what was their use. I then tried to see if I could receive the name of my phone through BLE by activating it. But it didn’t work.

Indeed, phones advertise themselves in normal BL and not BLE ! So I had to write an app to do the job, which I did. I learned all I had to learn in Android and made a “service” to advertise just the name of the device in BLE. And it was a success ! Here’s what I printed via RTT on the other end :

=> Advertisement detected

 Address : Type = 0x00 , GAP = 0x38B020490

 Advertisement Type : 03 

Parsing advdata : 

Data field :Type = 0x09 Data :ZeROSEro7 phone

Once this was done, I added the gitlab CI rules to produce the apk as an artifact and run all JUnit tests if any.

Next week : Wifi, PCB schematics

We have a huge assignment aside from ROSE to make a PCB that is due on Thursday so I won’t have much time for the projects. My next goals are to help Vincent with the wifi module and also to advance on our PCB schematics. I also really enjoyed working with the Nordic SDK because it has a nice documentation and Android is cool too so maybe I’ll try to create a GATT connection on BLE.

See you next week,

Enguerrand