Categories

BreathUp: LoRa, integration and strange behavior

Hi,

During this end of the week, the project have seen great improvement, as we have put together all the different part of the project that was developed separately.

I first worked on LoRa, and we are now able to send messages to TTN network from a PCB. This wasn’t as easy as expected. Indeed, I encounter two major difficulties. First, an incompatibility between the SPI driver and the SD driver because of DMA shared channels witch forced us to make an hard version of the SPI driver.  Then we (I was coding with Samuel) found out that there might be an issue in the stm32 because when we set the SPI configuration to send 8 bits, it’s sending 16, so we find a way to send our 8 bits by asking the stm to send only 4bit, but that’s quite dirty…

Then I worked on the complete integration of the communication from the PCB and to the PCB, containing the creation of a report, ciphering it, trying to send it via Bluetooth, deciphering it while on the server and all the way backward with a new configuration of the device coming from the server.

Then I worked with Benjamin on the integration of the SD drivers, the filters and the qualification algorithms. After some unexplained problems, we finally find a way to make it work. Then I worked on the test on the filters and the qualification, they are now tested with the code and configuration that will be put on the PCB, and not another file. We can therefore change easily some parameters and be sure that everything will be ok on the PCB.

Eventually, during the IMU driver development and during the implementation of LoRa and the qualification algorithms on the PCB, I have found an still unexplained issue, changing value when they are passed to a function as parameter. The dirty fix I found is to allocate them as static values. then they are stored in the bss and the issue doesn’t happen. It looks as a stack overflow, but we didn’t find any other proof of this…

This week will be the last week before the project evaluation, and therefore I will work again on the global integration. I might also try to use the Objenious network for LoRa instead of the TTN one.

Xavier Chapron

BreathUp: IMU, low-power and making a box

Hi,

During the start of the week I implemented an IMU driver that give us the gravity vector and a way to evaluate if the patient is moving or not.

I also created a first version of the box that will host the PCB and the battery. That was my first 3D printing and it is not gorgeous, but I’m still happy with it.

Finally, I started looking at the RTC driver and the low-power modes of our STM, but there is still a lot of thing to do on this subject.

Eventually, during the end of the week, I will work on the global integration of all the drivers we have produced and I will continue my work on the low-power modes.

Xavier Chapron

BreathUp, Android – Bluetooth – Time

Good Evening,

Since Wednesday, I have continued to work on the application and after some tests I found an error about the way I used to handle the thread of the service. So, after to speak with Sam, I decided to change how I made it and used a conditionVariable. I also split the application to put on a new app the part about the Bluetooth Server, I used that to make tests. I also modified a little bit the design of the application.

Friday, with my team-mates, we made some checks about our progress and we decided to do some changes. Indeed, now, it is the application which will send the time to the device,thanks to the Bluetooth connection, instead of the Lora chip. So, the application could receive different kind of requests sent by the device. The device could send a report, ask the parameters’ setup, and ask the time. To do that I modified a little bit the structure of the application. I need to make tests to valid that. At the same time, I changed the error codes which are sent to the device in order to have a response which have always the same length.

Eventually, the next week, I will finish with the treatment of the time requests and the other kind of requests. It is implemented but not tested. I need to implement a remote device which send different requests. I will use the work of Alexandre to do that on the Olimex E407 or on own PCB if the Bluetooth module works on. After, I will work to handle the time in order to have signals which match with a time to file them.

Have a nice week!

Benoît

BreathUp: I2C, IMU, LoRa, Qualification, Cipher

Hi,

During the end of the week I worked mainly on the IMU. It uses I2C, and I had never worked on it. Therefore I first needed to make myself familiar to this protocol. And this is done.

Then I had to send correct requests from the MCU, and this is also done and checked with a logic analyzer.

But the final part, is to receive correct responses from the IMU. And this is still not the case and I still don’t know why and will therefore investigate on it during the beginning of the week.

I also implemented on our PCB the LoRa driver (not tested since we don’t have a LoRa chip for the moment), the qualification and the cipher part that had been prepared.

Eventually during the next week I will work on the IMU and on the LoRa.

Have a nice week,

Xavier Chapron

BreathUp, New requests!

Hi !

Like I wrote in my last post, I worked on the integration of the new requests in the app. Indeed, thanks to the Bluetooth connection, the remote could send bytes instead of chars. To do that I created a class PostRequest with OkHttp package. The main difficulty was to understand how make the request because I would like sending only bytes in the body and I did not know which content-type was the good. Moreover, there was a mistake on the server because it wanted 19 bytes instead of 18. So, I did not understand why my request was bad with the error 400 and I spoke with Xavier to be agree with him on the post request. Now, that is ok. I also modified a little the structure of the app to be able to handle bytes.

Now, the application seems to be ok, I just need to clean up and I could work on the IMU.

Bye,

Benoît

BreathUp: Clocks, USB, UID and battery level

Hi,

I started the week by finding out why our quartz wasn’t oscillating. Indeed, we had configured it as an oscillator and not as a quartz in the MCU registers…

Then I worked on the USB and was quite blocked by an hard fault until Samuel found out that this was due to a too old version of my toolchain. I still can’t believe that it was possible to compile without any warning  even though the generated binary was wrong…

With the USB working, I was able to implement a shell and a function to get a unique id from the STM. It will help us to have different device id while flashing the same code! And I also implement a basic function to get the battery level with one of the STM ADC. It still needs to be test and calibrated.

Eventually, I worked on the start of the drivers for the ADS and the IMU and this should be one of my main job for the end of the week.

Xavier Chapron

BreathUp, Bluetooth interfacing and Post Request

Good Evening!

During this end of the week, I spent my time to interface the Bluetooth Application with the code which made by Alexandre in order to connect the smartphone to the Bluetooth unit and do long exchanges. After some problems and tests, the two devices are interfacing.

Since yesterday, Xavier has changed the encryption’s algorithm and the server request. I have began to switch the two Get requests to Put requests, but I will finish that next week.

Before the interfacing of the Bluetooth, I spent few times on the IMU driver to understand how the I2C communication works .

Have a nice week,

Benoît

BreathUp: AES, PCB, and debug

Hi!

During this end of the week, I worked on the AES and implement C and Python functions that encrypt and decrypt messages using AES128 CTR mode and they work pretty well.

I also worked on our PCB, and implemented some code to drive the LEDs with PWM.

We also discovered another problem: the quartzs are not oscillating, and as we need the 25MHz one for the USB, we still can’t use printf() to debug our drivers, witch makes thing a bit trickier. Therefore, while we are looking for a way to use the quartz, I worked on Segger Real Time Transfer (RTT) that should allow us to debug the code on the STM, but this is not working for the moment.

Eventually, during the beginning of the week I will work on RTT and on the quartzs.

Have a nice week,

Xavier Chapron

BreathUp, bad news

Hi!

Since Monday, I have added a detection to know if the user switches off the Bluetooth of his smartphone when exchanges with the Bluetooth module were launched. I also fixed errors.

Today, BreathUp received the PCB. However, there were some problems. Indeed, when we have connected the battery on the PCB. There were components which became warm. After investigations, we found errors with the imprints of the LoRa component and the regulator of tension. For the second error, it seem to be not very difficult to correct it with a patch. But about the first, it will be more difficult 🙁 .

Now, I will begin to work on the IMU driver.

Benoît

BreathUp, Works during holidays

Happy New Year!

I hope you spent good times for Christmas and the New Year’s celebrations!

During holidays, I carried on the application. Indeed,

  • I put the Bluetooth connection in a service to do that in background.
  • I modified the Bluetooth Server to be able to simulate a remote device.
  • I handle it to start and stop the service’s thread.
  • like the server’s API has been modified, I had to changed how I made requests.
  • I made tests to find bug and correct them.
  • I changed a little bit the UI.
  • I reviewed and cleaned the code.

Now, about the application, I will work with Alexandre to make tests and modified some parameters which will be modified with the new encrypt program. Indeed, encrypted messages will not have the same length. And to split the key and the message, I need to know their length.

Benoît for BreathUp