New Shimmer hardware revision 3R

[lumagi]

Please find above a general overview of the changes for the IMUs. The things to note:-

• the raw sensor format (e.g. gyro in this case) can change between HW (e.g. Shimmer 3 vs Shimmer3r) versions
• we would like to add two additional sensors, the high g accel (200G) and the wide range mag, and in future may add other sensors (e.g. microphone etc)
• the high g accel format is custom
• just so you are aware we’ve had multiple revisions of Shimmer3 with different (imu) chips being used, but this we can help address (if issues are raised)
• it would be better for the front facing elements of the API to use user friendly names

I think the most important is just to build a general understanding of how the API wants to manage different hardware versions. Once we reach an agreement we can pick up from wherever you left off. Appreciate the help. Thanks.

Originally posted by @ShimmerEngineering in #22 (comment)

[lumagi]

@ShimmerEngineering
I have done a bit of reviewing regarding the planned changes you mentioned in the PR. I have a couple of questions, I would kindly ask you to comment on:

• Am I understanding correctly that you're extending the config Bytes from 4 to 7? Does this also affect the binary format of the files?
• In the Python API, I use several enums to identify the sensors and channels, see ESensorGroup and EChannelType. Am I understanding correctly that the new accelerometer / gyroscope / magnetometer chips will use the same channel and sensor indices in the binary files and the Inquiry response?

[ShimmerEngineering]

yes correct we are extending it to hold more configurations. for the binary file header this is the format for the 3R. so the new size for the header is 384 bytes for the 3R

however please note, we have not finalized the designed for the sdlog(binary file) header. We are thinking of adding the Channel ID sequence (similar to the inquiry response) to the sdlog(binary) file header. So the parsing order of the bytes in the binary file will be determined through said Channel ID sequence. I will notify as soon as its been finalized.

the same channel ID values will be used for both shimmer 3 and the 3R. e.g. channel ID = 0 will be the LN Accel X Axis for Shimmer3 and Shimmer3R. I hope that covers your questions, do not hesitate if you have other or follow up questions.

[lumagi]

I have been thinking on it for a little while. I think the best way to move forward is to continue with your suggestion of renaming the channel types to a user-friendly version that is sensor agnostic. I will need to refactor all the channel and data type mappings in the dev package to encapsulate it in a dedicated class. This class is aware of the shimmer hardware type and can map from logical channel types to the underlying data types and lengths. The Reader and Bluetooth classes will need to instantiate it once they know what HW and SW version is being used. Then they can query all HW/SW specific information from the class instance.

[ShimmerEngineering]

hi @lumagi I think that makes sense. thanks. let us know if we can help.

[lumagi]

@ShimmerEngineering I just formatted the code base with black to have a consistent code style. Since this affects all forks and future pull requests, I would advise you to pull the current main branch again.

[lumagi]

@ShimmerEngineering I have tried renaming the EChannelType instances to something less chip-reliant. But there seem to be more acceleration / mag / gyro channels than in your screenshot. Would you be willing to shed some light on the different channels and their use cases? The contents of EChannelType are mostly based on:
https://github.com/ShimmerResearch/shimmer3/blob/8fa04982b70877d88a40aaa12c342774c862bd34/LogAndStream/shimmer_btsd.h#L186-L226
Which new channels will you be adding with the new hardware revision?