Feature request: on-board uSD-slot

[idea--list]

Hi there,

As the Apollo is an ULP MCU and the Thing Plus has a tiny form factor, many of us will tend to build battery powered solutions that will run several days or maybe even weeks. 99% of long running projects do log sensor data. Radio transmission is not a good idea for battery powered projects, so an on-board uSD-slot would make perfect sense for the thing plus and also for the nano board (right now i can solder an SD breakout but that takes away 6 pins).

As an alternative you could also build a break-out board with some GB non-volatile memory chip on it that we could read out via USB cable such chips are not expensive anymore and they consume even less power than writing an SD card

Also a way to implement battery metering without additional soldering would be really welcome.

I know these boards were released just few months ago, but if you plan newer revisions please take these into account

[oclyke]

I think this is an excellent idea! I always love a good uSD slot and the battery monitoring/metering is certainly a big deal for embedded data loggers...

I'm not promising anything but keep an eye out on our products page in the near future for something that might fit the bill!

[idea--list]

Thanks for the response. I know changing such things are not easy-peasy and also take a while usually. I found a push-push uSD socket in your store, that costs under $4. I would not mind paying even $35 for an artemis thing plus with that on board out of the box. :wink:

Let me focus your attention on some further useful considerations: I have this board right now, as the vendor does not update the SW-stack it got almost unusable as mbed-os evolves...

Notice the empty golden patch in top center. Advanced makers can solder a QSPI flash chip there to expand the memory significantly. The patch itself costs only some cents to implement.

Imagine someone would like to log weather data continuously for several weeks/months (or record some analog signal) from a battery out in the field far away from any computer or laptop. For that case even the SD is suboptimal (as there is an MCU built into the SD card that consumes ~100mA when writing so the project would not work long on batteries). Offering a QSPI patch and support for 256MB or above QSPI chips would open up whole new dimensions for the Apollo MCU! :rocket:

Also note how the SD-slot is placed. If you ever release any boards with an on-board SD socket, please do not place it like in my picture. I mean that might be okay until you sit in your lab next to your computer, but again if you have a real battery powered project, then the device is not installed in your lab and the next computer might be miles away. Chances are about 100% the project would have some enclosure in such a case. Any casing is at least 2-3mm thick... now if you would place the socket as you can see in the picture, than you just will not be able to remove/change the card as it does not extend beyond the casing. The push-pull socket makes that even more problematic. So the user would end up with tons of logged data they just can not access despite a slot for the card has been planned&printed on the casing... and you just do not want your makers feel :tired_face:

If you happen to have a computer and an USB cable at your hands, you could try to access those data via USB (exactly that functionality is not supported anymore for my board causing me looking for alternatives). In that case however by placing the socket more centrally, the user would not need to bother about implementing a hole on the casing...:wink:

So to sum it up: place a push-push SD socket as close to the edge of the board as possible. That way the maker has the choice: if they want removable SD-cards, they could really remove that even if the project has a protective enclosure. Would they prefer a dust-proof design, they just would plan a bit longer casing to cover the SD card completely, as a compromise they could access the data via USB only and not by changing the card. For more advanced users who really want the longest battery life possible, you should also deliver the board with a QSPI memory of great capacity or if you want cut down manufacturing costs, then implement only an empty QSPI patch for that purpose.

Hope this somewhat long comment inspires your mind and helps you avoid pitfalls an other vendor could not do.

[oclyke]

Thanks @idea--list! These are certainly great things to keep in mind. We love hearing feedback from customers - especially when you share details about your use cases.

I will leave this issue open for more people to find when designing new boards.