Memory can be volatile, as the data will be retrieved after the logs are=20
done, and the memory does not need to be retained after that.  I will=20
probably have to put in a battery backup or similar, but that's=20
relatively easy.

"rugged" means it will get shaken quite a bit, so the=20
connector/connection to the microSD card is what I'm worried about. I do=20
have some push-pull microSD connector samples on the way, but will have=20
to test.

This will be for for a portable/mobile device.  WiFi is not an option,=20
as well as directly sending the data to some other device. It's going to=20
have to be quite compact.  FWIW though, I recently investigated various=20
wireless options for another project and WiFi modules (especially the=20
lower-cost ones like the ESP8266) are really power-hungry.  For on-going=20
data transmission, you should look into the nRF24L01 which can be had=20
for less than a buck nowadays.  I understand it's good on power=20
consumption, but have to investigate that still.

Up to this point, I've been assuming that if I use SD/microSD it would=20
be removable for retrieval of the data, but perhaps I should consider=20
just soldering and attaching permanently to the PCB.  I've seen some=20
hobbyist 3DP control boards do this and thought it looked hokey/amateur,=20
but I can probably do that and 3D-print a cover to hide it.

Re: wear leveling, reliability is important.  Shouldn't I be=20
uncomfortable logging data for a couple hours over 4GB or 8GB w/o any=20
wear leveling?  FWIW, my pallpark logs will be just under 1K bytes per=20
second.

Cheers,
-Neil.



On 6/17/2016 3:35 PM, Denny Esterline wrote:
> Your question is a bit confusing. Are you looking for volatile or
> non-volatile memory?
> PC RAM is of course volatile and dynamic - you would need to refresh the
> data quite often, I don't think that's a practical option in the PIC worl=
d,
> but you didn't mention what you're using.
> You mention "low-volume" and "rugged", both of which are vague enough to
> make any advice possibly meaningless.
>
> Various versions of SD cards can be quite rugged - probably not "artiller=
y
> shell" rugged, but certainly "automotive" rugged. (GoPro cameras?) And
> depends more on the connector used. For more robust mechanics in low volu=
me
> I would start with a gob of hot-melt glue on and around the card after
> install (micro SD better here because of low mass). Other option is no
> connector at all, solder wires directly to the card fingers then bond the
> card to your product with a suitable adhesive. May complicate retrieving
> the data, but in "low volume" it may be an option
>
> Either of these options require you to manage the file system which may o=
r
> may not be an issue.
> There are also several commercially available "dataloggers" that basicall=
y
> have some flash memory (SD card slot usually) and a processor preprogramm=
ed
> to allow you to send it the data via serial. It may be helpful in a low
> volume situation. I've seen some of those used in model rocketry, so
> there's one measure of "rugged". Here's a couple links from a cursory
> search:
> https://www.adafruit.com/product/1141
> https://www.sparkfun.com/products/12772
>
> There's also the FTDI Vinculum parts that do something very similar but u=
se
> a USB flash drive:
> http://www.mouser.com/new/ftdi/ftdivinculum2/
> Options from bare chips to breadboardable modules to panel mountable full=
y
> enclosed units.
>
> One of the other emails mentions "wear leveling" - absolutely critical in
> long life products. Completely meaningless for some short lived
> applications. I've done datalogging during development projects that's on=
ly
> ever had to be written a couple times - didn't bother with any of the
> "normal" file system niceties, just spew data into the chip and parse it
> back out later with PC side tools.
>
> The other option worth mentioning - can you upload the data realtime with
> some type of telemetry? I've recently been digging into WiFi modules and
> it's been an eye opening experience. If you're in an environment where
> wireless of some type is an option, it wouldn't be "too much work" to
> uplink the data to a more capable system. WiFi is almost trivial to
> implement nowadays, but dozens of other wireless options exist with vario=
us
> benefits and drawbacks.
>
>
> Hope this helps - if it doesn't, we may be able to do better if we better
> understand your application.
>
> -Denny

--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.