More non-volatile memory

[hagster]

I'm just getting started, but it looks like i'm going to run up against a memory limit if I try to do any form of logging.

One solution is to use I2C comms to external memory devices.

But, a dev board(+reference design) with built in SD card support and some hard coded file system support would be awesome.

[kbanks]

We know such a thing is doable from SNAPpy, because we've done it on multiple Custom Solutions hardware designs.

What sort of $ add-on do you think this feature is worth? (If a SN171 Protoboard is $x, and there was a "SN171SDMEM" (I just made that part number up, don't bother trying to order it) that supported removable SD cards, how much more would you be willing to pay for it?

We often kick around ideas for fancier demo boards, but have a hard time making a business case for them...

[hagster]

We know such a thing is doable from SNAPpy, because we've done it on multiple Custom Solutions hardware designs.

What sort of $ add-on do you think this feature is worth? (If a SN171 Protoboard is $x, and there was a "SN171SDMEM" (I just made that part number up, don't bother trying to order it) that supported removable SD cards, how much more would you be willing to pay for it?

We often kick around ideas for fancier demo boards, but have a hard time making a business case for them...

We would definitely pay more for the that protoboard, provided the software support was there to make it easy to develop for. Couldn't say how much but i'm sure an extra 10 to 30% premium wouldn't be prohibitive. I'm still getting into SNAP at the moment and need to prove that it can do what we want on a less ambitious task first.

Would this be useful for anyone else on the forum? I'm thinking of applications such as a GPS loggers, but i'm sure there are other uses.

UPDATED:- Actually just thinking it might be better if an SD card board could sit underneath the SNAP engine in a stack arrangement. This way we could use it on any Protoboard and even use the same the board for end products saving us customers development time and effort. It would probably scale better that way for synapse too maybe?

[John Payson]

The RF300 documentation seems to suggest that only 64K out of 128K of external memory is ever used for any purpose by the SNAP firmware. Would there be any practical way of accessing the rest of it from within a SNAPpy script?

[jcwoltz]

I'm just getting started, but it looks like i'm going to run up against a memory limit if I try to do any form of logging.

One solution is to use I2C comms to external memory devices.

But, a dev board(+reference design) with built in SD card support and some hard coded file system support would be awesome.

Depending on how much data you want to log offline, an I2C EEPROM may work. If that is not enough storage, then you could use an SD Card, but I would not want to write the SNAPpy code to handle a a FAT filesystem.

This is just an example, I made a board that had an atmega32u4 on it to receive serial data from the RF Engine and logged it to files on a microSD card. That way you could take the microSD card out and read it on you computer if you wanted to.

Image of first proto-type:
https://www.jcwoltz.com/wp-content/uploads/2011/03/IMG-20110323-00162-e1300902737612.jpg
Design Image of latest board:
https://www.jcwoltz.com/wp-content/uploads/2011/04/AtMEGA32u4-uSD-AddON-v01a-brd-e1304272520325.png
Board is design to fit on this board:
https://www.jcwoltz.com/wp-content/uploads/2011/03/IMG-20110315-00147-e1300740913949.jpg

Another option is to use something like an openlog:
http://www.sparkfun.com/products/9530
Or use something like the SDLogger:
http://www.seeedstudio.com/depot/sdlogger-open-hardware-data-logger-p-723.html?cPath=132_136

just some suggestion to think about.