Due to some legacy code from the first MIMU3333 test boards, the internal sampling frequency of the board was previously set to around 400Hz while the internal sampling frequency of the IMUs was a 1000Hz. The main reasons for the low sampling frequency was that the IMUs (of the MIMU333 test board) were originally connected to two different ports on the uC and that the uC was running on a single internal PLL, which limited the internal clock frequency since the USB needed 48MHz. These hurdles have now been cleared and the sampling frequency of the board is now set to 1000Hz, just like the internal IMU sampling frequency.
Unfortunately, the 1000Hz sampling frequency is not without problems. For the MIMU22BT boards everything works fine. However, for the MIMU4444 array boards, the sampling frequency works fine internally but the USB cannot keep up in case you want all raw data from all 32 IMUs. If you try to output all raw data from all IMUs at every sampling instant, the sampling frequency will drop to around 500Hz since the uC will be waiting for the data to be sent. I’m not sure whether this is a limitation of the USB profile, the USB stack, or our code.
The mechanization and the filtering of the aided inertial navigation can be run at 1000Hz. This means that the clock frequency, i.e. power consumption, can be traded for sampling frequency. Currently, the uC makes up around 2/3 of the power (current) consumption of around 100mA. Its power consumption will scale rather linearly with the clock frequency. Consequently, the power consumption could, in principle, for example, be reduced by 1/3 by halving the clock frequency at the cost of halving the sampling frequency.