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?

[JongChern]

Shimmer3	Channel ID	User Friendly Name
X_A_ACCEL	0x00	Low Noice Accelerometer
Y_A_ACCEL	0x01	Low Noice Accelerometer
Z_A_ACCEL	0x02	Low Noice Accelerometer
VBATT	0x03	VSenseBatt
X_LSM303DLHC_ACCEL	0x04	Wide Range Accelerometer
Y_LSM303DLHC_ACCEL	0x05	Wide Range Accelerometer
Z_LSM303DLHC_ACCEL	0x06	Wide Range Accelerometer
X_LSM303DLHC_MAG	0x07	Magnetometer
Y_LSM303DLHC_MAG	0x08	Magnetometer
Z_LSM303DLHC_MAG	0x09	Magnetometer
X_MPU9150_GYRO	0x0A	Gyroscope
Y_MPU9150_GYRO	0x0B	Gyroscope
Z_MPU9150_GYRO	0x0C	Gyroscope
EXTERNAL_ADC_7	0x0D	External ADC A0
EXTERNAL_ADC_6	0x0E	External ADC A1
EXTERNAL_ADC_15	0x0F	External ADC A2
INTERNAL_ADC_1	0x10	Internal ADC A3
INTERNAL_ADC_12	0x11	Internal ADC A0
INTERNAL_ADC_13	0x12	Internal ADC A1
INTERNAL_ADC_14	0x13	Internal ADC A2
X_MPU9150_ACCEL	0x14	High G Accelerometer
Y_MPU9150_ACCEL	0x15	High G Accelerometer
Z_MPU9150_ACCEL	0x16	High G Accelerometer
X_MPU9150_MAG	0x17	Wide Range Magnetometer
Y_MPU9150_MAG	0x18	Wide Range Magnetometer
Z_MPU9150_MAG	0x19	Wide Range Magnetometer
BMPX80_TEMP	0x1A	Temperature
BMPX80_PRESSURE	0x1B	Pressure
GSR_RAW	0x1C	GSR
EXG_ADS1292R_1_STATUS	0x1D	EXG1 Status
EXG_ADS1292R_1_CH1_24BIT	0x1E	EXG1 CH1
EXG_ADS1292R_1_CH2_24BIT	0x1F	EXG1 CH2
EXG_ADS1292R_2_STATUS	0x20	EXG2 Status
EXG_ADS1292R_2_CH1_24BIT	0x21	EXG2 CH1
EXG_ADS1292R_2_CH2_24BIT	0x22	EXG2 CH2
EXG_ADS1292R_1_CH1_16BIT	0x23	EXG1 CH1 16 Bit
EXG_ADS1292R_1_CH2_16BIT	0x24	EXG1 CH2 16 Bit
EXG_ADS1292R_2_CH1_16BIT	0x25	EXG2 CH1 16 Bit
EXG_ADS1292R_2_CH2_16BIT	0x26	EXG2 CH2 16 Bit
STRAIN_HIGH	0x27	Bridge Amp High
STRAIN_LOW	0x28	Bridge Amp Low

**For the 3R we plan to support all the channels above. If it helps I am attaching a link to our c# api where we parse the inquiry response (channel IDs) , it might help serve as a reference for the number of bits/endianess etc if required.

I hope the above helps, apologies for the delay in reply.

[JongChern]

Hi @lumagi how are things getting along, just dropping in to see if we can help in any other way.

[lumagi]

Thank you for offering. I haven't forgotten about this, I hope I will get to it over the next two weeks.