Categories

[ZeROSEro7] BLE fully operationnal

I made the last improvements to the BLE control and enabled fast two-way connection to a characteristic with a simple programming interface. I am using Write requests with no response on the GATT client side and notifications on the server side along with the highest MTU available for the nRF52 (200+ bytes). This will be usefull for the USB sniffer where we will download a great amount of data.

I ran a test program on our SpyTalk custom PCB and the BLE and LoRa chip worked. Yet, because of difficulties when welding, one of the Quartzs doesn’t seem to work but it is not critical. It will only raise consumption during off time.

I prepared a test program on the nRF SPI for the USB Sniffer that sends packets to the STM32 and expects a response. This program is proven to work because it did with the LoRa chip so now Erwan and I can implement the SPI driver on the STM side and imagine a simple protocol to exchange our data. This part will be even easier on the Stealth Drop because only a wakeup is sent. It could be done with a simple GPIO.

My next priorities are to finish the USB Sniffer, including the final user interface, and to design and implement a simple protocol over LoRa for the SpyTalk. This protocol will include at least addressing, retransmission, and basic AES encryption. I abandonned using LoRaMAC because this protocol, despite being very efficient for what we want to achieve, requires gateway stations which are usually public and it is not what we planned as our network architecture. It would also require different hardware. Given the time left, I may also add synchronization for lower RX time, better security with changing keys and any other ideas that may come to my mind. I’d also like to add bonding and security on the BLE connections.

Erwan and Vincent made great progress on their side and I think we are very close to having every of our 3 gadgets fully working!

[ZeROSEro7] Android CI, GATT dynamic connection and custom service

Great progress was made since my last post!

First of all, the CI was greatly improved. We now use smaller docker images for the different jobs and the code formatting is asserted using the checkstyle pluggin for gradle.

I’m intensely working on the BLE part as it is essential for all 3 sub-projects. We tested it on our USB Sniffer PCB and the BLE part is working with a 20dBm compared to the Nordic dev kit which enables a roughly 15m range for connection. This is completely satisfying for all gadgets but a bit short for the stealth drop. We don’t need a connection, but one advertisement has to be sent. We will measure the range for this packet reception once the stealth drop is welded.

I implemented GATT connection to a custom service on both sides (nrf52 and android app). It uses write and notification callbacks for faster transmission. Reading is much slower as it requires more transmissions. Just for the reminder, during our connection protocol, the device first waits for a specific advertisement from the phone (just the name field is examined for now, more complex mechanisms could be implemented if we have time). It then advertises itself as a smart shoe (nobody will try to find it ;)) and the phone initiates the GAP connection to this advertising. The connection is already dynamic, that is to say timeouts, disconnections and restarting is handled from both sides smoothly. The device also returns to observe mode a few seconds after the advertisement.

I read some documentation on bluetooth security and found many ways to have a secure process and connection. Nothing is enabled right now, but if I have time before the deadline, which is in 10 days, I could do the following:

  • Enable privacy by randomly masking the address of the device. An IRK (identification resolution key) will have to be shared with the phone.
  • Enable GAP connection encryption with AES and MITM protection
  • Enable GATT layer similar protections
  • Whitelist the phone’s scan requests instead of observing to get it’s advertisments. This has the downside that for demos with other phones, they either need to be in root userspace, or their BLE address must be entered in th device through some other way.

In the near future, I will provide the SPI interface to communicate between the phone and the STM through the BLE and the corresponding UI. Once the BLE is completly finished, I will switch to the LoRa communication to have the final Spy Talk prototype.

I am very confident that us 3 will have fully working demos for all 3 projects :). Yet, I have doubts concerning the range and data rate for the Stealth Drop.

[ZeROSEro7] SX1276 DIO, ANT and now low power

Last week I improved my LoRa driver by using the IRQ through the DIO pins and greatly improved range. I increased the dBm output to 14 and made sure the RX sensitivity was correctly set. I then played with the CRC and spreading factor parameters to have best range performance. I still have to do an exterior range test with the antenna we will use, but with the dev kit, we were able to receive the signal on the other end of Telecom with all it’s walls.

I am now working on the power consumption, that is to say on sleep modes and wakeup times. Since I am focusing on the spy talk, I preferred the ON base current standby consumption for the nRF to save roughly 100ms on wakeup for only double the sleep consumption. I think this tradeoff is justified because even if the spy talk has low throughput, it should be able to send alarm messages really quickly. I must now try to disable as many peripherals, including the SX12 when I want to save energy. Depending on the algorithm, deep sleep may also be needed later.

I had a good look at the MAC layer from Semtech, but I’m not sure we will be using it. As mentionned above, we will aim towards very low latency and I’m not sure it will achieve that. Moreover, there is a lot of overhead and Everything isn’t completely customizeable. I still need to investigate this more, but for now I think I will design my own TCP-like protocol.

My next step will be to run a GATT server on BLE and I should have all my basic blocks to start the Spy talk software.

[ZeROSEro7] First LoRa transmission

Last week I worked further on controlling the SX1276 from the nRF52. Once I could use the high level functions from Semtech, I tested it and checked if the registers were set as expected. To complete the implementation, I had to write the code to control the antenna switch, which is trvial on our schematic. I also had to link the handlers for the optional IRQ DIOs. Unfortunately, the SDK doesn’t support them being disconnected so I had to rewrite a small part of the SDK with a similar behavior but without the IRQs. It is possible to switch back to the previous code by defining a symbol for the preprocessor. This will reduce CPU execution time but is completly optionnal otherwise.

I had very few debuging options to finally transmit over LoRa. I knew my timing and SPI transfers were right, but the transmission wasn’t working. After further analysis of the SX12 datasheet and checking the state registers, I was able to make a first transmission !

Among other things, there was a very misleading naming for modes :

There was the continuous mode vs packet mode, which states wether the rx data goes in the fifo or to the DIO. I chose packet.

And the continuous mode as opposed to single-shot mode. In single-shot, the antenna only goes to rx mode for a few symbols of time so I couldn’t receive anything. So I had to choose this continuous mode.

Before I resolved this ambiguity, I ran into troubles because the receiver didn’t have the expected behavior and spent all his time in standby mode.

Aside from this, I helped reviewing the schematics and PCBs that Erwan and Vincent made.

 

For this week, I’ll try to finish the parrots on both LoRa and BLE to close those PSSCs in time. I’ll use the remaining time (if any) to help Erwan with the USB. Indeed, driving 2 USB bus in parallel will probably be a tough challenge and will require to dive into the drivers if we want to respect the timing constraints. I also hope that we will finish all our PCBs before next week.

[ZeROSEro7] SX1276 on nRF52 dev kit

Since we will be using the SX1276 connected via SPI to the nRF52, I started to implement basic LoRa communication by plugging the SX1276 on the Nordic dev board. Now that I made my first BLE transmission, I am quite comfortable with the Nordic dev kit and I’m also a bit used to piloting the SX12 with iCube. Unfortunatelly, the LoRa Middleware is only available for STM32s. I could pilot it by manually coding all SPIs transmission, or I could bridge the LoRa Middleware and make it work on Nordic’s dev kit instead of iCUBE.

What I got from iCube isn’t just Semtech’s LoRaMac driver, STM enhanced it a bit for cortex 4, which is also included in the nRF so I’ll rather start with the iCube version of this SX12 driver. I had already dived into the code of both SDK and found the proper layer of abstraction where I can replace the header files in iCUBE with my custom ones. I found out that the middleware was already designed to be portable by implementing 3 custom headers : hw_spi hw_rtc and hw_gpio. It even provided templates for it. But with the additions of iCube, there’s a bit more to it : I also need a hw_conf to define some compiler specific symbols. I reduced to the minimum the templates, especially the gpio one which is only used to reset the SX12 by toggling a single pin with a few ms delays.

 

After a lot of understanding the SDKs, I was able to create a Makefile combining both SDKs interesting parts and using my own headers. That was a really interesting and challenging puzzle. I really enjoyed it and gained much experience. From there, I started implementing the source files for those headers.

The compiler specific one was the first and i had minor troubles because Nordic also used it’s version of CMSIS, like iCube so some symbols were redefined, causing a comilation error when I tried linking both. I could have tweaked nRF’s Makefile but I found a simpler solution in enclosing my definitions in an #ifned.

That done, I implemented the RTC bridge. I hesitated for some time when choosing which one of the 3 (!!!) timing drivers from Nordic which are poorly named. I opted for app_timer, which works on the RTC peripheral from the MCU after checking if the timing precision was sufficient. Then, by carefully reading through iCube’s implementation of the RTC part, I designed my own relying on Nordic’s functionnalities. Some functions were very misleading. The worst was a getTime for which the documentation said “get Time in ticks. Returns time in microseconds.”. I was speechless. Also this is not at all an isolated case. Hopefully they corrected it in newer versions of the middleware. Anyway, each time I made a function, I tested it through my RTT and the LEDs and checked if the timing was alright. Even though Nordic as quite a good documentation, I was stuck for a few hours because the RTC wasn’t starting but no error was raised in the code. The doc doesn’t mention it, but I found on a forum that to enable the RTC module, the app_timer_init() function isn’t enough ! You also have to ask for some other driver that uses the low frequency clock to start it as a side effect ! Once I found out, I simply started my BLE module because softdevice is one of those drivers having this side effect. I really think all SDKs with which I have worked in embedded systems should spend more efforts on documenting.

Thereafter, I started working on the SPI bridge. I tested the SPI demos from Nordic with a logical analyser and coded my version of hw_spi.c.

Here is where I’m at. I still haven’t tested using the SX12 in any way but I implemented almost all necessary files to that the LoRa driver is compatible with the Nordic SDK. Only the gpio is missing and I will start connecting the SX12 and make it happen.

 

Hopefully I will run the ping pong demo on the nRF dev kit by next week. In the meantime, I will also work on the PCBs.

[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

[ZeROSEro7] Running demo and fibonacci on the LoRa Discovery kit

LoRa Discovery kit and CI advancement

This week we all coded each on a dev kit. I retrieved the 2 LoRa boards and started analyzing the demo Ping Pong program from icube LRWAN. The demo software was only available for some IDEs and I wanted a Makefile so I explored the configuration files for these IDEs and recreated a similar compiling command that worked. icube is segmented in several drivers which are dependent on each others. There is the HAL driver, the BSP, CMSIS and the LoRa Middleware.

The dev board uses the sx1276 which we will be using for our Spy Talk. It is connected via SPI to a STM32L0X with a Cortex M0+. I first downloaded the documentation for the chip, sx12 and the HAL driver and built the other ones with doxygen since the source files included doxygen comments. The highest level API is the LoRaMAC layer which then uses the LoRa PHY and other LoRa layers. These layers must be linked to the correct BSP driver for the sx1276 which defines the different registers and pilots them to do basic init, rx, tx, sleep mode and so forth… The BSP itself requires a HAL driver to define the GPIO ports and driver and a SPI driver.

I am still deciphering the doc and code of all these drivers and the demo but then it will be much easier to pilot the LoRa module. If we want to use those, it will be necessary to port them to our custom chip though. I successfully modified the example a bit by toggling a LED and launched it on the board. Unfortunately, the debug server tool I am using (texlane/stlink) often has bugs. I tried using opencv but to no avail. Next step before coding anything is fixing the debug toolchain.

This week I also further completed the CI tests including a linter stage to check if the code we push respects the coding style with clang-format. I also added some artifacts in the build stage and a test stage that checked the results from Erwan’s Fibonacci.

Indeed, one of our coming pssc is to compute some Fibonacci numbers on all boards just to be sure we can run and debug some custom code.

Additionally, I made a few test with Android studio and a Moto G4 plus as we’ll have to code BLE and wifi communication apps soon.

Next week : Athens week

Since next week is dedicated to other courses, we won’t make too much progress. Our next goals are to share with each other all knowledge acquired on the dev boards and then try communicating via BLE/LoRa/wifi. We also have to start to implement a transparent USB relay on a STM32F4 as part of the USB Sniffer project.

 

[ZeROSEro7] Dev kits incomming

This week we ordered the dev kits that we will be using to develop our softwares on and we will receive them on Monday. That way we should have partly finished the softwares untill we receive the prototypes’ PCBs. We will be using the B-L072Z-LRWAN1 KIT DISCOVERY as well as CC3220SF-LAUNCHXL, the Nordic nRF52 dev kit and an OLIMEX STMF4X board for our STMF2.

 

I started setting up different Gitlab tools like CI, Templates for Issues and Merge Request and also translated our PSSCs as issues as was asked. I also thought about the automated tests we will be implementing for each pssc when it relevant.

 

Next week we will finish setting up the environments for all the dev kits (SDK, makefiles, .gdbinit…) and we hope to have a fibonacci program running on all of them. As everyone in the group must understand every device, I don’t think I will mainly focus on either one. We will probably just try to make all dev kits work and review what the others did instead of focusing on one in particular. We will also start the lessons on PCB view, the software with which we will design our PCBs but I don’t think we will be advanced enough to start the schematics by next week.

[ZeROSEro7] PSSCs

Hi all,

This week’s post is a group post as well. It sums up what we have done and what’s planned for next week.

I wish you happy Reading !

Enguerrand for the ZeROSEro7 team

 

PSSC

This week, we made the first version of our PSSCs – Project Specific Success Criteria – which are reachable on the Wiki page of our project (Only available for other students). Each of our 3 devices has it’s own PSSCs although many deadlines are shared across them. Our general idea would be to have all of the PCBs ordered early December and meanwhile we would develop the softwares on development boards. This means that we should choose the µControllers, OS and Wireless modules soon so that we have ordered the dev boards and modules for testing around mid November.

 

We also made our first presentation in class where we explained our PSSCs and features of each device. Here is what we have came up with for now :

USB Sniffer

  • USB Female
  • USB Male
  • BLE
  • (Optional battery)

Spy Talk

  • USB (debug and recharge)
  • BLE
  • LoRa
  • Battery

Stealth Drop

  • USB (debug and recharge)
  • BLE
  • Wifi
  • Battery

 

We are still investigating solutions for these questions :

  • Will the USB Sniffer be able to take control of the keyboard and write stuff. Example : typing a password would open a shell on a notepad.
    • Will the USB Sniffer be able to remotely control the computer through Windows shortcuts. Example : ctrl+R, cmd, DOS commands ….
  • Will the USB Sniffer have a battery for instance to still emit over a weekend where the computer is shut down ?
  • The SpyTalk is a BLE to LoRa relay and thus, most of the software part can be done in the smartphone app (messages routing, encryption …). Is there any difficult computing left for the device?

Next Week : Constraints and Components (beginning)

Next week, we will put numbers on all the constraints we want for the project in order to choose the components. This includes range, bandwidth, memory available, battery life …

Since we have 3 devices and not just one, and that they share some modules in common, we want to reuse as much as possible the same components between them.
Ideally, all 3 would have the same µController, BLE and USB ports; We would also find a single dev board that can take the role of any of our gadgets. The flash sizes vary a lot between them so it probably won’t be the same (small for SpyTalk, 1Gb for USB and several Gb for StealthDrop).

 

Our methodology to achieve the component selection at the moment is to scan the recommended vendors for the BLE modules for instance. Then compare them. It gives us a good idea of what’s achievable (range, size, consumption…) and which components would best suit each of our devices. We also keep in mind that the USB sniffer should be as small as possible (Ideally the size of both USB connectors and no more) as well as the SpyTalk which is to be carried by the agent at all times. One of our concealments designs would be to hide it in a zippo for instance.