Can't find the Accelerometer or Heart Rate Sensor Code? about infinitime

[JF002]

Thanks for your work, it looks promising.
If the watch reset every 10s, it might come from the watchdog, which is configured to reset the cpu if has not been refreshed for more than ~7s.
The wdt is refreshed by the SystemTask. You should check if there is nothing that blocks or slows down the loop in SystemTask.

[JF002]

Accelerometer and heart rate sensor have been integrated in version 1.0 :)

[JF002]

You couldn't find the accelerometer and heart rate sensor code because... there it doesn't exist (yet)...

I did some work related to these sensor, and even managed to make a small demo of both of them working in InfiniTime.
I haven't pushed these changes because of license issues : I want InfiniTime to be really open source (that's why I chose the GPLv3 license) and the code I wrote for these sensors was based on non free/proprietary code, blobs and libraries :

• The heart rate sensor needs a library to drive the sensor and compute heart rate values from raw values
• The motion sensor needs a binary BLOB (configuration file) to be uploaded to the chip for advanced functionalities (step counting, for example).

There's very few documentation, datasheet and example code about these 2 devices, and the implementation will certainly need a bit of reverse engineering. I know that ATCWatch and Wasp-OS worked on the support of these chips, but I don't know which license is applied on their code. It might be worth to have a look.

If you (or anyone else) want to write a driver for these devices, I will happily share the rest of the code (UI, message passing between tasks,...).

[jones139]

Ah, that accounts for it then.
I will look at the accelerometer first and aim to make something that will use interrupt driven monitoring of the accelerometer without using anyone else's code. I did this for a different accelerometer chip a while ago so as long as the chip datasheet has the information on which registers you need to set etc. it should be possible - I seem to remember reading the datasheet for it a while ago before I got distracted by another aspect of my project.

If you could share what you have done, that would save me a lot of effort understanding the software 'infrastructure' - I have only ever used FreeRTOS as a C implementation using old fashioned makefiles so find this one a bit daunting to start on!

I'll go and read a datasheet......

Thanks!
Graham ([email protected])

[JF002]

I remember I pushed the branch hrs3300 a while ago for consultation only (I won't merge it as is).
The low level drivers are in https://github.com/JF002/Pinetime/tree/hrs3300/src/drivers.
Then there are 2 'controllers' (motion and heart rate) in https://github.com/JF002/Pinetime/tree/hrs3300/src/Components/Motion and https://github.com/JF002/Pinetime/tree/hrs3300/src/Components/HeartRate. These controllers provides easy API to the UI, so that the UI does not depend on the drivers directly.
There is also the heart rate task (https://github.com/JF002/Pinetime/tree/hrs3300/src/HeartRateTask) that runs when heart rate measurement is required by the application.

Do not hesitate to ask any questions, I would be happy to answer them !

[jones139]

Thanks!
I hope I will be able to use those commits to see how you added a component etc, then I can start writing things to the screen and will feel like I am getting somewhere - first task is to read the ID from the chip, which will prove we can talk to it.....
I will let you know how I get on.
Graham.

[jones139]

I am trying to merge your 'main' branch into my fork of the hrs3300 branch to get the code bases consistent before I start.
I think the cMake parts are working, but I am getting a compile error I don't understand (I don't use c++ much!) - it is complaining about the "new Screens::ScreenList" here https://github.com/OpenSeizureDetector/Pinetime/blob/hrs3300/src/DisplayApp/DisplayApp.cpp#L205

Error is:
DisplayApp.cpp:205:26: error: expected type-specifier
205 | currentScreen.reset(new Screens::ScreenList(this,

It is getting a bit late now so I will look tomorrow, but if this error is obvious to you, I would appreciate your thoughts on what is causing it!
Thanks

[JF002]

Mhm this branch generates a lot of warnings, but no error on my side...

Which version of the toolchain do you use ? I'm using this one : https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads/9-2020-q2-update.

Could you also try to delete the build directory and start again from scratch (cmake & make)?

And if it does not work, could you provide the whole error message?

[jones139]

Thanks - I'll have a better look at it, or might start a new branch based on master if it gives too much trouble. I just thought I'd check if it was obvious to you what was wrong.

…

On Mon, 28 Sep 2020, 21:20 JF002, ***@***.***> wrote: Mhm this branch generates a lot of warnings, but no error on my side... Which version of the toolchain do you use ? I'm using this one : https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads/9-2020-q2-update . Could you also try to delete the build directory and start again from scratch (cmake & make)? And if it does not work, could you provide the whole error message? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#67 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACLSY7YEXROFKFWQE4OOILSIDV2JANCNFSM4R3W5CLQ> .

[jones139]

I didn't find the problem, even after updating the toolchain. I think it must be something to do with how the header files were updated - but I don't understand how it compiled for you.
I decided that I will learn more about how your code works if I implement the 'Motion' app myself using your code as examples, so am working through that. I think I have got that bit working now, so will actually try and talk to the accelerometer chip tomorrow....

[jones139]

I have made some progress - mostly with learning the structure of the code so I can add a screen to display data, and am just starting to look at TWI_master to start to talk to the accelerometer chip.
I looked at the code from Bosch (BMA4.c etc.), and I wondered what the issue is with using it? It looks like it is nicely written code, and has a permissive licence - do you think it is incompatible with a GPL3 project? It says it can be distributed with or without modification provided we keep their attribution, which sounds ok to me.
I have never looked much at compatibility of different open source licences though so I may have missed something? It is just that what I write will be very similar to the Bosch version, but not likely to have all of the features and error checking that their code has in it....

I also wondered about TWI_master - I can't see a way of checking if a read/write is successful or not. Have I missed something, or should I expose the structure that reports error codes etc., either by making it public, or adding getter functions - do you have a preference?

Thanks
Graham.

[JF002]

Sorry for the delayed answer !

I'm not sure there are any license issue. These files come from unknown sources and I don't know if we can use it in a FOSS software. If I recall correctly, an SDK for the BMA423 is available on Github, but not for the BMA421. It also needs a BLOB (configuration file) to enable advanced features like step counting, and we don't have the sources of this blob.

Maybe we just need to take the time to check that it is OK (and compatible with GPLv3) to use them in the project?

Regarding the error management in TwiMaster (and other drivers), you're right, there's not much. The first reason is that I haven't taken the time to think about it. Second reason is that if a transfert fails, there's not much we can do at the application level in case of error, except maybe retry (or reset). So, any help on this subject is welcome :)

What structure would you want to expose?
In "normal" project, I would use exception, but I don't think that's a good idea for embedded, so error codes (enum class ?) returned by method might be a good candidate.

[jones139]

No problem - you have lots of issues and pull requests to look at lately! I hadn't spotted the 'configuration file' I thought it was just a dump of the registers on the chip, but maybe there is more to it. I'll have a look at the two licences and see if they are compatible - because it would be a shame to reinvent the wheel when what has been published looks so close to what I would write (...and if I write it I am likely to lose interest once I have interrupt driven FIFO transfers of the accelerometer data working (which is what I want out of the chip), but I'll do steps if it is easy.... For my application I am interested in errors because I want to report fault conditions. I think the structure that is populated in TWI master has some fields to do with error codes, so if we expose those in the driver, the code that accesses it can look at the current error state straight after a request - then it is up to the calling code whether to look for errors or not. Do you know if it is possible to get a 'serial' console on the device over BLE or SWD? That would be much easier than writing to the display to check what it is doing. I can see some of the code calls a 'logging' function, but I do not know where that logging information will appear (and I haven't read up enough on the NRf52 sdk to check - I am being lazy, sorry!). Will let you know what the licences look like tomorrow. Thanks Graham.

…

On Sun, 4 Oct 2020 at 10:07, JF002 ***@***.***> wrote: Sorry for the delayed answer ! I'm not sure there are any license issue. These files come from unknown sources and I don't know if we can use it in a FOSS software. If I recall correctly, an SDK for the BMA423 is available on Github, but not for the BMA421. It also needs a BLOB (configuration file) to enable advanced features like step counting, and we don't have the sources of this blob. Maybe we just need to take the time to check that it is OK (and compatible with GPLv3) to use them in the project? Regarding the error management in TwiMaster (and other drivers), you're right, there's not much. The first reason is that I haven't taken the time to think about it. Second reason is that if a transfert fails, there's not much we can do at the application level in case of error, except maybe retry (or reset). So, any help on this subject is welcome :) What structure would you want to expose? In "normal" project, I would use exception, but I don't think that's a good idea for embedded, so error codes (enum class ?) returned by method might be a good candidate. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#67 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACLSY2Y7OJT43JY6IFV4D3SJA3NPANCNFSM4R3W5CLQ> .

-- Graham Jones <http://google.com/+GrahamJones> Hartlepool, UK.

[Avamander]

Do you know if it is possible to get a 'serial' console on the device over BLE or SWD?

Yes, either ARM Semihosting or Segger's RTT are both possible.

[Avamander]

@jones139 This is the accelerometer blob that we don't know the license of: https://github.com/daniel-thompson/bma42x-upy/raw/master/BMA421-Sensor-API/bma421_config.h

[jones139]

Ah, thanks - I will read up on what that does - it looked like you should be able to get the main accelerometer functions by just reading and writing registers (based on the BMA423 datasheet), but I will see.
Just having trouble with my SWD interface which seems to have stopped working reliably - hopefully I have got a loose connection in the pinetime - otherwise I've wrecked the pinetime and will have to start on one of my P8's instead.... Will get back to the accelerometer once I can talk to a watch!

[jones139]

I have just tried incorporating the open source BMA423 library from Bosch (https://github.com/BoschSensortec/BMA423-Sensor-API) and using that with minimal modification (just changed the expected chip_id.
It looks promising - I can read at least one value of acceleration and temperature from the chip. The config_file write fails with an invalid file error, so I don't think the on-chip step counting etc. will work - but we could implement that on the watch cpu if we have to.
There is still something wrong in my code (https://github.com/OpenSeizureDetector/Pinetime) because the watch resets every 10 seconds or so, and the accelerometer values are not updating on the screen. I will have to cure that first, then try and get the FIFO and interrupt working, which is likely to be important to keep the watch power consumption down.

[donpdonp]

I'd really like to see a heartrate sensor on infinitime. I searched around the wasp-os code for the relevant bits and the license is LGPL-3.

the hardware driver
https://github.com/daniel-thompson/wasp-os/blob/master/wasp/drivers/hrs3300.py

the "Photoplethysmogram (PPG) Signal Processing"
https://github.com/daniel-thompson/wasp-os/blob/master/wasp/ppg.py

[jones139]

Thanks for this - I was thinking I'd need to look up how to convert the two signals (one visible and one infrared) into the saturation figure - hopefully the signal processing one does that - I'll have a look.

…

On Fri, 6 Nov 2020 at 23:58, Don Park ***@***.***> wrote: I'd really like to see a heartrate sensor on infinitime. I searched around the wasp-os code for the relevant bits and the license is LGPL-3. the hardware driver https://github.com/daniel-thompson/wasp-os/blob/master/wasp/drivers/hrs3300.py the "Photoplethysmogram (PPG) Signal Processing" https://github.com/daniel-thompson/wasp-os/blob/master/wasp/ppg.py — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#67 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACLSY3FIHWBQ5WHIDXGZHTSOSERZANCNFSM4R3W5CLQ> .

-- Graham Jones <http://google.com/+GrahamJones> Hartlepool, UK.