Connecting the Electron 3G over TCP to Your own Server with third party SIM to send SD card data

Getting Started
21

Hi @mbyamukama
Do use ever have issues with your SD card failing to initialize or communicate via SPI?
@jaza_tom and I have been having some SD issues and wonder what strategies you employ to keep your read/writes working smoothly over long periods of time. We’ve tried different SD cards, re-formatting, etc. Usually a reset fixes things.
Thanks.

22

@SCM

  1. What else is connected to your particle device?
  2. What SD card module are you using?
  3. What SD card brand are you using?

In my application, the only issues we have identified with SD cards are:

  1. Low VCC on the card- the standard says 2.7-3.6V but we often got a few issues before reaching 2.7V especially for large writes
  2. Fake SD cards- Some cards from china claim to be “San Disk” and yet they weren’t. Often, they do work in your PC but not with the microcontroller.
  3. Grounding - Damage to PCB tracks or loose jumper wires can cause poor grounding. We have at times found a small voltage between the SD GND and the system GND because of this.
  4. Load on any of the SPI pins - Do you have another slave connected to the SPI? Some loads may have a low impedance and drain some current (like the 2nd master I was talking about in this thread), leaving insufficient current for the SD R/W operation.
  5. We have also at times corrupted the data just by trying to remove the SD card when it is powered!

My advice:
We chose the module in question because of our interest in low power operation. If your application can use 5mA extra, I’d advise you to change the module to this one like this below:
Untitled

We bought some from here
The AMS117 ensures 3.3V always. You can power the module from a 5V supply. You can get 5V from a tiny boost converter module like this one hooked up directly to your battery. This module features a SN74LVC125A bus buffer gate for level shifting (In case you are using some other microcontroller). We never had any issues with those, except the extra power.

23

Thanks @mbyamukama
Answering your questions:

  1. Lots of things, but to the SPI pins that our SD card holder (integrate into a custom PCB), the only other thing is a LCD display.
  2. Answered above.
  3. SanDisk (purchased on Amazon, seemingly authentic).

Re: the issues you mentioned:

  1. We rely on the Electron’s 3.3V supply (powered by an isolated 5V supply)
  2. I’ve also read about this. Was in Shenzhen recently and very tempted to buy a suitcase full of cheap SD cards, but resisted. Still buying off Amazon primarily.
  3. Haven’t come across any grounding issues yet
  4. I suspect this is a likely candidate.
  5. We are pretty careful about this - only removing the SD card when powered down or in DFU mode (to ensure no R/W cycles happening)

@jaza_tom Any other thoughts?

24

I suspect it is most likely a result of voltage supply issues during read/write operations.

Since we are powering the SD card off the same 3.3V supply that is used by the modem, there may be unacceptably low voltage dips on that supply during modem transmission events which may coincide with read/write operations on the SD card.

The voltage dips may also be caused by differential “ground” voltages between Electron and SD card (basically same as power supply dip issue, except could be caused by other ground currents flowing in the ground plane between Electron and SD card).

Finally, I guess it may be possible the the logic “high” level of the Electron is not quite as high as it should be during modem transmission, which could result in corrupted command sequences being sent to the SD controller.

I think powering the SD card / SPI pullup resistors with a dedicated 3.3V DC/DC converter is probably the best solution because it will eliminate the potential voltage supply issues discussed above, and will also allow our software to power cycle the SD card (assuming we pick a DC/DC converter that has an enable pin that can be controlled by the Electron).

We could also look at using a tristate buffer or multiplexer to share SPI between LCD and SD, or re-map pinout to use two dedicated separate SPI peripherals concurrently.

25

How often are you writing to the SD card? How much data would you miss out on if you halted the write process until after the upload? Can you buffer during that period? In my application, there's about 25 seconds to connect to the cellular network and another 10 to upload ~33KB of data. We forego the data in those ~35 seconds (which may be anything between 0 and 10 reports) but in environment monitoring that is very little data.

26

I like the idea of creating a timing buffer between known transmissions and sd writes. I’m going to look into this I think.

Normally we publish right after SD card writes to avoid the possibility of transmission-induced voltage dips, but there are occasional writes to SD during/shortly after a transmission. It would be useful if there was a way to know if a transmission was taking place before writing (i.e. the non-app transmission events that occur behind the scenes as part of the Particle ecosystem - keepAlives, handshakes, etc).

I think the most challenging part of implementing some sort of write block during transmission events is the startup sequence… there are several spots where SD writes during the startup sequence are desirable. Probably easiest way to test if transmission voltage dips are our culprit would be to delay connecting to the cloud until after all SD writing operations that are part of the startup sequence have been completed.