by

|   December  7, 2009 at 11:29 AM

couple of questions, Is 8mA a constant current or Can it be turned off completely ?

Is there a website or project page to find more info or send patches?


Thank you,

Juan

by

|   December  8, 2009 at 2:07 PM

8mA is what is takes to have the device on and waiting for a command. To power down the device, you would need an external control such as a MOSFET or transistor.

We don't have a good repository spot yet. Maybe google code. Looks like there are a few people out there doing similar work:
http://code.google.com/p/sdfatlib/

For now, email patches to spark at sparkfun.com. Thanks! We appreciate any help.

by

|   February  7, 2010 at 4:12 PM

If you modify the code to shut off the unused parts of the chip, you can get down to close to 2mA when nothing is being received.

It may be possible to go lower by setting the port pins to the SCI to consume less current when idle.

Beyond that, it becomes very tricky since the UART needs its clock to see a character and wake up. Otherwise there could be a deeper sleep.

by

|   December  7, 2009 at 3:10 PM

There are some subtle changes between SD and SDHC. This page has a bit of information about it:

http://elm-chan.org/docs/mmc/mmc_e.html

Might be worth having a poke at the page here:

http://elm-chan.org/fsw/ff/00index_e.html

The sample projects may be of particular interest.

by

|   December 18, 2009 at 1:26 PM

At the link, it talks about MMC v.s. SD, but I didn't see anything at all about SD v.s. SDHC.

by

|   December 20, 2009 at 10:55 AM

See the section titled "How to support SDC Ver2 and high capacity cards" - on the other hand, the firmware above also has support for SDHC...

by

|   December 14, 2009 at 7:01 PM

This is very nice, less than half the price of the logomatic, much tinier, and with the more familiar AVR.

It would be nice to see this grow and gain the same triggering-on-specified-character abilities as well, I see a lot of promise in this!

by

|   December 17, 2009 at 3:57 PM

Just got it working! Very nice.

Couple of hints for others.

--Default baud is 9600 8n1.

--Make sure your card is formated as fat16.

--If you hook it directly up to FTDI Basic don't forget to cross the rx and tx lines.

by

|   December 18, 2009 at 5:57 AM

Got a couple of these, work exactly as advertised!

If anyone else is looking to modify the firmware and is unfamiliar with the workflow to get the serial bootloader working (like i was) then i can highly recommend Nate's walkthrough of his process here:

http://www.sparkfun.com/commerce/tutorial_info.php?tutorials_id=142

(this took me heaps longer to find than it should have, and so i found lots of ways to *not* make it work in the meantime. Hopefully putting the link here saves someone else that pleasure...)

by

|   December 24, 2009 at 5:13 PM

So, how do you actually upload a new version of code to the device?

The guide doesn't talk about this particular model.

I can't get ISP via usbtiny (sparkfun) or anything with stk500 to work with avrdude.

by

|   December 18, 2009 at 1:20 PM

The schematic shows an AVR328, 3.3v and a 16Mhz crystal.

One of the three values is wrong or Atmel has a new version of the chip. A 3.3v 16Mhz arduino would be welcome...

by

|   December 18, 2009 at 2:27 PM

Good catch, maybe the idea is that the system works down to 3.3V but you need to update the firmware and fuse bits yourself?

by

|   December 18, 2009 at 2:32 PM

oh it looks like the system runs on 3.3V always... which throws my theory out the window

well if it fails mysteriously, you know why

by

|   December 23, 2009 at 10:07 AM

Hi TZ - Check the ATmega328 docs again. The ATmega328 can run within spec at 16MHz at 3.3V. Currently on page 318 of the datasheet inside Electrical Characteristics.

by

|   December 24, 2009 at 2:16 PM

Do you have a link to whatever datasheet contains the 16Mhz/3.3v? I can't find it - and I assume there is some specific suffix or something indicating the speed grade?

(And when are we going to see 3.3v/16Mhz Arduinos?)

by

|   December 31, 2009 at 9:18 AM

Do a search for 'atmega328'. It should bring up Atmel first. I'm looking at the 10/09 version D datasheet. Under the "Electrical Characteristics" chapter it shows figure 28-1, a linear line from 1.8 to about 4.5V. Assuming 1MHz/.27V, we can run 3.3V at 12.22MHz. So running at 16MHz @ 3.3V, we are not inside the safe gray area. This doesn't keep me up at night. We test every board in production and haven't had one fail yet. Once we prove FAT16/32 works at 8MHz, we may downgrade the resonator.

by

|   January  8, 2010 at 11:58 AM

It probably works when you test it, but I'd worry about having one recording (or trying to) around Yuma, AZ next summer.

The firmware works on an Arduino Pro Mini at 3.3v/8Mhz to a microSD breakout (after fixing the frequency defs in the makefile and config). I didn't check the second LED though :).

It would be slower at reading and writing - the maximum SPI SCK rate is used, which is based on CPU speed.

by

|   December 18, 2009 at 1:30 PM

Could someone try putting an SDHC formatted with just a FAT16 partition (I have several cards but they don't have any more stock as I write this).

At least that would confirm the hardware would work without change.

by

|   December 24, 2009 at 2:10 PM

I just did (a 16Gb card) and it won't get past the "1". It is a FAT16 2g partition, the only one, as the first.

by

|   December 24, 2009 at 4:09 PM

... and SD_RAW_SDHC was set to zero in the config, so the current firmware won't support SDHC.

I suppose there is no arduino bootloader, so I'll need a programming adapter?

The Makefile for the firmware link here is set to a 168, not a 328, though there seems to be some problem with the defines.

And of course nothing says what the fuses need to be set to much less "make fuse"...

I'm going to be busy on christmas day.

by

|   December 30, 2009 at 6:16 PM

Hi TZ - please check again. The file called 'Makefile' in the zip listed above has ATmega328 listed at the top. And I'm not sure what you're trying to do with a 'make fuse' command. You should never need to set the ATmega328 fuses.

by

|   December 19, 2009 at 1:26 PM

I too am working on FAT32 - I won't have one of these but I may try to do it on one of my arduinos.

Read works - I already have it scanning every partion (including an extended partition) for FAT32, then getting the boot sector and geometry, reading the root directory and able to read an entire file by following the FAT chain. In about 200 lines of code, 1 512 byte sector buffer, several limitations (512 byte sectors, no fs errors, short filenames only, etc.), but every FAT32 format I've seen does this.

I hope to get write working this weekend.

by

|   December 20, 2009 at 9:05 AM

Another bit of strangeness - you have the reset circuit the same as the one on the arduino.

So connecting it to the arduino will result in the DTR line being functionally open - capacitor to capacitor.

Another (for me) annoyance is the inability to do binary. I suppose you could use a break condition to signal going back to command mode.

by

|   December 23, 2009 at 10:10 AM

I agree, a binary interface is a good thing to have. There are many options that we intentionally left out to keep it simple. If there are options you'd like to add, help us out!

by

|   December 24, 2009 at 5:51 PM

I have a 3.3v ftdi breakout (which works on all my arduinos).

I have it hooked up as in the datasheet on git, but avrdude can't find it. Do I need 5v to do serial bootloading?

Nor can it find it if I connect it via ISP.

I can communicate fine in a terminal program and even work at different baud rates.

Does anyone have an avrdude command line that will recognize it?

by

|   December 31, 2009 at 9:09 AM

Hi TZ - I use a 3.3V FTDI Basic (with a TX/RX swap in between) to do all my development. 3.3V is fine even though the regulator on OpenLog is probably dropping this to 3.2V.

by

|   December 28, 2009 at 10:53 AM

To repeat for clarity -

It would help greatly if someone could give me an avrdude command line that will verify the above firmware's hex file (I'm assuming that is what is in the unit), and one that will reflash it.

Also if there is anything tricky about using an ISP - the 4 data pins out of the six are on the other side. I'm using the sparkfun usbtiny but can try something else.

by

|   December 29, 2009 at 2:30 PM

To use the firmware from the link on this page on a 3.3v arduino (e.g. pro mini) to the uSD breakout, you can flash directly using something like:

avrdude -c stk500v1 -b 57600 -P /dev/ttyUSB0 -p m328p -Uflash:w:main.hex

however the baud rates for the application will be off since the crystal is 8Mhz instead of 16. To fix that (so you can try enabling debug and SDHC) you need to add a line around line 76 of uart.c after it selects the baud rate by reading the eeprom.:
new_ubrr >>= 1;

You will also need to adjust F_CPU to 8000000 in the makefile.

The breakout use CD. VCC and GND go to the 3.3 regulated out and grounds from the arduino.

The bottom four pins near the LED are the SPI.
From the bottom going up (10 going to 13):
pin func uSD
10 - SS - CS
11 - MOSI - DI
12 - MISO - DO
13 - SCK - SCK

SDHC cards are recognized if you set the option in sd_raw_config.h, and they can read FAT16, but doing ls, md, or trying to write will cause a reset (at least if debug is on).

2>disk
manuf: 0x03
oem: SD
prod: SU16G
rev: 80
serial: 0x7045eef6
date: 8/8
size: 15193MB
copy: 1
wr.pr.: 0/0
format: 0
free: 1029341184/1029816320
>

by

|   December 29, 2009 at 5:06 PM

Connecting A2 (pc2, a/d2) on the arduino to the card detect enables that function - it works too.

by

|   December 29, 2009 at 9:47 PM

Now flashing the openLog - there seems to be a problem between avrdude - linux ftdi - 3.3v ftdi breakout - reset on the arduinos. Note I have 3 FTDI breakouts all 3.3v and it happens on all three.

I have a similar problem on my 3.3v arduinos (but they have a button and I'm used to pressing it). Fortunately the square framed hold is "reset" and shorting it to the uSD holder will ground it causing a reset - and releasing it will allow avrdude to flash.

by

|   December 29, 2009 at 11:21 PM

Hi all, if any of you are trying to flash the firmware, i have written a short guide which is aimed at getting the OpenLog working with the UAV Dev Board, but includes information on getting new firmware onto the board. Unfortunately windows based, using winAVR, but the avrdude commands should be the same anywhere i guess. The guide is here:

http://code.google.com/p/gentlenav/wiki/OpenLogConnection

I have found the code to be very unstable in my environment for some reason. The code as supplied works fine, and simple changes (such as changing some baud rate stuff to enable 19200) work fine. But anything more complex seems to cause the code to fail in wierd ways. It still compiles and loads onto the OpenLog board fine, but code unrelated to the changes i have made will stop working. ie the 'ls' command will print out half the disk information table, then the device will crash and reboot. Seems like some sort of memory corruption, although i would have thought the stack and heap should be ok, as code use is only about 50% of capacity. Any thoughts?

by

|   December 30, 2009 at 1:24 AM

Just noticed the github link, have moved my code issue over there...

by

|   December 31, 2009 at 11:24 AM

1) Which one is STAT1 LED and STAT2 LED? I just wonder it be better if different color coding is used or label on PCB.

2) I just send out serial character "Hello" from Atmel to OpenLog. What should I expect as output? Will I see a text file if I read SD card from PC?

Thanks!

by

|   January  1, 2010 at 8:53 PM

Finally, up and running. My unit is in command mode at power up ( I guess ver 1.1 will be different). It took me quite a few hours to guess. I think the best is to connect the unit to Hyperterminal or Tera Term or any terminal emulator. This will help you in debugging. Also, please don't forget to send line feed character after every command.

good luck,

by

|   January  6, 2010 at 0:45 AM

I successfully fed data into the logger and it works as expected.
Is it a "must" to read out the logger with a separate FTDI breakout or is there a way of using the Arduino for that? I can't find a hint or even a tutorial.

by

|   January 10, 2010 at 8:37 AM

http://harleyhacking.blogspot.com/2010/01/fat32lib-01-zap-your-card-edition.html

Alpha quality, but for really early adopters...

Flashable firmware, source with build-able library and sdhc driver. FAT32 only with 8.3 names only, but 11k for the lib and sd/sdhc driver.

Direct link: http://www.zdez.org/fat32lib-0.1.zip

by

|   January 10, 2010 at 2:08 PM

As usual, I missed a few things. Update code and link:

http://www.zdez.org/fat32lib-0.1a.zip

by

|   January 19, 2010 at 8:15 AM

The addition of a real-time clock would make this perfect for some apps I have in mind. Even if the clock's only function is to put a timestamp on the log files.

by

|   January 19, 2010 at 4:12 PM

I was wondering if anyone ran into the issue of a microSD card not support SPI mode?

I was reading that this is optional for microSD cards is this true?

by

|   January 19, 2010 at 11:07 PM

I have a dozen (different!) from 512Mb to 16Gb - all support SPI. I don't think it is optional (even for SDIO).

I don't know about the earlier MMC, or how compliant the SD models are.

by

|   January 20, 2010 at 7:43 AM

http://www.interfacebus.com/MicroSD_Card_Pinout.html
The SPI mode is optional in the microSD format.
http://en.wikipedia.org/wiki/SD_Card
All cards must support all three modes, except for microSD where SPI is optional.

by

|   January 22, 2010 at 10:57 PM

The link doesn't go to the spec. I've seen discussion on MMC cards but don't have a full spec. On MMC, SPI is optional, but that doesn't tell me precisely how to talk to one (where it is different from the SD cards).

But there are no micro MMCs.

by

|   January 21, 2010 at 10:40 PM

Hi

How do I connect this to Arduino Duemilanove?
for mini:
GRN: Reset pin and connects to the GRN pin on the Arduino Pro Mini. Pulling this line low will reset the ATmega328. Because there is a capacitor on this line, holding this line low will not keep OpenLog in reset.
RXI: Serial input into OpenLog.
TXO: Serial output from OpenLog.
VCC: 3.3V to 12V input.
GND: Ground
BLK: This pin is connected to GND. Connect this pin to BLK on the Arduino Pro Mini.

Thanks

by

|   January 22, 2010 at 10:36 PM

For the adventurous:

http://github.com/tz1/hyperlog

Works at 57600 default. Other baud rates by adding a 1-line (with line ending) HYPERLOG.CFG file containing the baud rate, e.g. "115200".

Boots and starts logging. Break flushes, plus flush timer.

by

|   February  4, 2010 at 3:24 AM

Hi tz,
Link broken

by

|   February  7, 2010 at 4:05 PM

I can't edit it here.
http://github.com/tz1/sparkfun in the hyperlog directory (source).

by

|   January 25, 2010 at 2:46 PM

SPARKFUN
“Description: OpenLog is an open source data logger. Simple to use, simple to change. We wanted to create a serial logger that just worked. Power this device up and it will start logging any received serial data at 9600bps”

Datasheet (GITHUB)
“OpenLog is a simple serial logger based on the ATmega328 running at 16MHz. The ATmega328 should be able to talk to high capacity (larger than 2GB) SD cards. The whole purpose of this logger was to create a logger that just powered up and worked. OpenLog ships with a standard serial bootloader so you can load new firmware with a simple serial connection.”
________________________________________________________________________
I can’t get the darn thing to operate. I’m rather incompetent at some of this stuff . However, not just because of my incompetence, but also judging by the previous comments about the device, OpenLog is not as simple to get operating as stated.

PO’T

by

|   February  4, 2010 at 3:34 AM

I've been testing these modules prior to installing in some equipment, ready to log long term on a beta product.
Apart from teething trouble at the start (the instructions for flashing are now out of date), I have managed to recompile and flash the firmware correctly. I have changed the code to 115200 in all cases.

I am using a 2gig SD card (not SDHC). Amongst other testing, I tested the open log by filling the card with 1.6gig of data (a 1.6gig file), then inserted the card into the openlog device. It fails to log with an "error writing to file" always. If I reformat and do not put 1.6gb data into the card, it always works correctly, it can log data.

My query is, has the openlog been tested to capacity of a 2gig SD card. Has anyone actually managed to fill a 2 gig card without errors?
I'm wondering at what point the logger starts to fail?
Any ideas?

by

|   February  4, 2010 at 4:18 AM

ok. A bit more testing later. The logger fails when just over 1gig. Is this known about?