Best setup for an offline busy data logger running on batteries

Other Hardware Storage
1

I want to make a PIR sensor data logger that will run offline on batteries. As the logging will take place at least every second I run into troubles concerning space and power consumption.

  1. Board - I don't need the USB unit, the regulator and any onboard led but I don't want to mess with the hardware. So what is my best option?
  2. Storage - I prefer to write to a file on a SD card but I saw that those are problematic power consumption wise. Do I have a better alternative?

Thanks for any guide on this!

2

Garfielder:
I don't need the USB unit, the regulator and any onboard led but I don't want to mess with the hardware. So what is my best option?

A Li-ion or Li-Po battery with at least 5000 mAh (for really long runs), because the on-board LEDs do take up some juice (between 5-10 mA) each one.

To bypass any regulator, don't feed the power from the barrel jack, VIN or RAW pin; but from the 5V pin. Yeah I know it says 5V, but by experimenting I discovered that the microcontroller can perfectly live with the voltage range of a Li-ion or Li-Po cell; just don't let it fall below 3 volts or the brown-out detector may kick-in and cause erratic resets (that is, unless when it's asleep with that turned off).

Now, there's also the issue of whatever storage medium you wanna use; it also has to tolerate the voltage range of a Li-ion or Li-Po cell. Remember, you are avoiding regulators to minimize power losses.

Garfielder:
I prefer to write to a file on a SD card but I saw that those are problematic power consumption wise. Do I have a better alternative?

In this topic we were talking about an interesting type of memory that claims to have a very low power consumption suitable for battery-powered devices; the only downside is that the largest capacity you can find is 2 Mbits (256 KB). Maybe by logging everything as raw binary, but still 256 KB can get filled up for not so long (specially at a pace of one second). Assuming 16-byte records (4 float variables) being saved every second, 256 KB fills up in 16384 seconds (273 minutes or roughly 4 and half hours).

So for mass storage options there aren't many; in fact I dare to say an SD card is your only feasible choice in this regard; even USB pendrives draw the same or more power. That is, unless I missed an actual low-power NAND flash chip with built-in SPI interface and massive capacity (other than an SD card of course).

Some forums suggest to turn on/off the card via MOSFET to save power; but I'm dubious about how much in the end. Powering it off is the same as removing it from the slot; so every time you wanna do something with it, you'll have to repeat all the initialization process (SD.begin() and open the file). I don't know you, but this sounds counterproductive to me, at least for an update rate of once per second.

Some also mention that power consumption varies from manufacturer (both idling and busy), so there's no better way of knowing it by looking at a datasheet (if it has a brand printed on it), or measuring its current draw with a precise enough ammeter (in the milliampere range).
This is important to make your own conclusions about whether or not a complete power-off of the card actually worths the hassle involved, for the sake of saving precious juice on the battery.

3

I would not power an Arduino with a voltage below the spec of the microcontroller. Yes, e.g. a 328P micro clocked at 16 MHz will still work at around 4V (estimated based on the frequency vs voltage graph in the datasheet) but below that it might or might not work.

The right board for OP is probably a SparkFun Pro Micro clocked at 8MHz and running on 3.3V; it only has a power led that can be removed (I know you don't want to mess with the hardware but removing an LED is not really messing with hardware ;)). Polulu might also have some 3.3V boards.

@OP
How much data do you want to store? A reading every second with a timestamp and a one byte value will result in 300 bytes per minute and 18 kByte per hour. You can obviously use a more clever approach because you know the time between the readings; e.g. store the time in the beginning of the file and next combine 8 readings (true/false, 0/1) in a byte.

4

I recently did a remote control project, and used a 3.3V 8MHz Pro Mini. I removed the voltage regulator and the power LED, and powered it directly from an 18560. That's no problem for the processor because it has a wide operating range up to 5.5V or so, but won't necessarily operate reliably at 16 MHz as the battery voltage drops. So operating at 8 MHz gives you lots of flexibility, and a regulator isn't needed. In power-down sleep mode, the processor draws about 0.4µA.

But that means the SPI pins for your SD card also operate at battery voltage, which is 4.2V for a fully-charged Li-ion battery. And that's a problem for the SD card because it is a 3.3V device. MicroSD card adapters usually have a level-shifting chip that converts the processor's 5V to 3.3V for the SD. But they also have an AMS1117 3.3V regulator to provide power to the SD card, and that's a problem because it has a 1V dropout rating, which means 4.2V is already too low. So this can get complicated. You might need to use a truly low-drop-out regulator that would still work down to around 3.5V input.

It may be possible to run the SD card at 4.2V, but even if it works in the beginning, you just don't whether it will be damaged over time. But that option would let you use a plain microSD brakeout module with no regulator or level shifter chip - the kind made for use in 3.3V systems.

Writing to the card uses a lot of power, so it would be best to save up as many readings as you can, and write them to the card all at once, one or more full sectors at a time if possible. Even so, I think you're looking at a minimum of 20-30 mA even if the card is idle. So switching the power with a mosfet might be worth looking at.

Something like an m25pe16 serial flash memory might use less power than an SD even when writing, and it has a power-down mode so you wouldn't need a mosfet. But anything like that would require you to offload the data via wifi or usb from the processor. You can't just switch out an SD card.

It seems to me that you could either run everything at 4.2V and take your chances, or run the battery output through a really good 3.3V, or maybe even 3.0V, LDO regulator that supplies both the processor and the SD or serial flash.

5

Thanks for the comments!

  1. The FRAM is a nice option - I'll have to get economical. Can I write to file just like with a SD card? And can I dump the data to a PC?

  2. Is there a led-free suitable board? Maybe the Attiny85 will do? Is there another option which is maybe stronger and easier to work with?

  3. As for the battery what about using 3*1.5V AA ? The FRAM is declared to have a wide range of in-voltage so I don't see any problem.

6

If you want to deal in files, then you will need a file system - something like FAT16 or FAT32. It may be easier to think of the FRAM as one file that you fill up. Dumping the data to a PC also requires code to do that in your sketch. I think to have any chance of making this work, you would have to find the right libraries that already support what you want to do (Google "Arduino FRAM library"). But first you need to figure out the amount of data you will be dealing with. It appears that the 5V FRAMs currently available are pretty small. There's a lot to be said for using an SD card that you can just swap out when you want to harvest the data.

I don't know of a board without a regulator and power LED, but it's a pretty simple process to remove both of those with a soldering iron.

Three AAs or AAAs should work fine, but everything depends on how much current you will need. If the batteries won't last long, then rechargeables would probably be best.

7

Garfielder:
Maybe the Attiny85 will do?

Yes and no.

If your program just logs every so often, then it should fit in its flash memory. However, that MCU has insufficient RAM to handle SD cards (512 bytes + space for the heap and stack are required); it even lacks an SPI master controller (its slave-only and only for the ICSP), although it can be bit-banged (emulated by software) but at a pretty limited clock frequency.