IMU data logger brain storm

[pmd]

Hello,
 
This is my first post here
 
I would like to have a little brain storm with you about a new product that I'm currently designing.
 
This is an IMU data logger that has to record IMU data to flash memory - 9 axis (16 bit x 10) at 100Hz rate. 
The device has to record for 3 hours minimum, it has to be battery powered, very small and data download has to be very easy.
 
My first brain storm - 

• What MCU do i choose, STM, Atmel, NXP, Cypress? The parameters are - cost, performance, development environment, size, battery life
• 8 bit or 32 bit MCU?

Part 2:
I have to download data from multiple (24) loggers, so I'm going to design some kind of docking station for 24 units that will charge the units and download the data (32MB each) to PC
 
Second brain storm  -
Should I add USB for each device and design the docking station as USB hub, this way each device will show up on the PC as USB drive
or
Should I use UART/SPI/I2C interface between unit and docking station and the docking station will connect to the PC as COM port?
 
Any input will be appreciated
 
Thanks
 
Michael
 

[krho]

stm32l0 or stm32l4, qspi for datastorage and USB for communication/charging.

[thm_w]

Should I add USB for each device and design the docking station as USB hub, this way each device will show up on the PC as USB drive

I would do this. If its not a problem for user to open 24 drives and cut and paste the data. Or you could automate this.

Data rate about 2kB/s right? Thats easily done with microSD, 1-bit data.
32MB is on the edge of serial flash (largest size), but IMO microSD is nice because you can swap it out easily and manually download if needed. If you are certain you would not need more than 32MB, a serial flash chip would be the smallest solution. You can see some data in my report under "4.7 External storage", it might be relevant (https://hackaday.io/project/21912-portable-air-quality-monitor#menu-details file is portable_air_quality.pdf).

I used STML476, but that would be too expensive. For sure you can get away with a lower cost chip. I didn't implement mounting FatFS over USB, but should be doable.

[Kalvin]

Do you care about violating patents? If not, then use a microSD card and let the user to handle data downloading. You will be violating SD patents and FAT file system patent, but considering there are so many devices using these technologies without paying patent fee, I think you can be safe to do so.

It might be worth taking a look at those patents as some of the patents regrading FAT has already been expired.

[pmd]

All, thank you for your replays

Do you care about violating patents?

Can you explain more?

I don't want to use SD card because it will be more expansive to add SD card holder and buy SD cards - I'm going to mass production. Also, the product is sealed and there wont be no access to remove SD

I see that every body recommend STM32L (I also prefer STM), generally speaking why not Atmel or NXP?

[thm_w]

I don't want to use SD card because it will be more expansive to add SD card holder and buy SD cards - I'm going to mass production. Also, the product is sealed and there wont be no access to remove SD

Then use the flash I mentioned, if there is space put a footprint for a second chip in case 32MB is not enough.

[krho]

QSPI flash in 8pin package goes up to 1Gbit => 128MiB