I can not use 1.1 V like reference in Sdfat.h, although I select "(1 << REFS1) | (1 << REFS0)" I measure that the reference used is 5V.

SdFat has nothing to do with the ADC.

How are you setting the reference voltage?  

Did you call analogReference(INTERNAL) ?  You can't use "(1 <<REFS1) | (1 << REFS0)" in this call.

Are you using ChibiOS20130208.zip http://code.google.com/p/rtoslibs/downloads/list.

The 20130208 version of ChibiOS should work with 1.04/1.52.  There are two versions of malloc in 1.04/1.52 and older versions of ChibiOS cause an attempt to link both.

Soon 1.05/1.53 will be released with another version of malloc and ChibiOS will fail again.  I will post a fix as soon as I can test it with the 1.05/1.53 release.

I don't think SD.h is the problem.  Single byte reads are slow but you should be able to read several KB/sec.

I suspect the single byte write to the network is the main problem.

Using the SD.h function

Code:

int read(void *buf, uint16_t nbyte);

helps read speed a lot.  You should be able to read 50-100 KB/sec with a 10 byte buffer and well over 100 KB/sec with a larger buffer.

Try a multi-byte read/write something like this:

Code:

  uint8_t buf[BUF_DIM];
  while(myFile.available())  {
    int n = read(buf, BUF_DIM);
    //  could check for read error with "if (n == 0)"
    client.write(buf, n);
  }

The end the write is "brute force"

No you can't just pull the card.  You must call "sd.card()->writeStop()" and close the file with file.close().

The SdFormatter.ino program can format any SD no matter how corrupt. SdFormatter.ino erases the SD so all blocks contain zeros and then formats the SD.

Post the output from SdFormatter.ino.  It should look like this:

This sketch can erase and/or format SD/SDHC cards.

Erase uses the card's fast flash erase command.
Flash erase sets all data to 0X00 for most cards
and 0XFF for a few vendor's cards.

Cards larger than 2 GB will be formatted FAT32 and
smaller cards will be formatted FAT16.

Warning, all data on the card will be erased.
Enter 'Y' to continue: Y

Options are:
E - erase the card and skip formatting.
F - erase and then format the card. (recommended)
Q - quick format the card without erase.

Enter option: F
Card Size: 7580 MB, (MB = 1,048,576 bytes)

Erasing
................................
............................
All data set to 0x00
Erase done

Formatting
Blocks/Cluster: 64
FAT32
................
Format done

If SdFormatter.ino fails, try the SD Association's formatter which also can format any SD no matter how corrupt.

https://www.sdcard.org/downloads/formatter_4/

If the SD Association's formatter fails, you have a bad SD card.  SD cards are 3.3 V devices and you can ruin them by applying voltages greater than 3.6 volts to power or signal lines.

If the SD Association's formatter works but the SdFat formatter fails, you have a problem with the SD module or the way it is wired to the Arduino.

This uses I2C as I think I remember reading in the documentation. 

No, I2C is not used. The logger reads from the Arduino's internal ADC and write to the SD using the SPI bus.

I remember reading that 2G was about the max storage capability that these datalogger hardware devices were meant to support.

SdFat supports any SD card formatted FAT16 or FAT32.  SDHC cards can be as large as 32 GB.  The maximum size of a file on a FAT32 volume is four GB so you must create multiple log files.

SdFat can write to SDXC cards that have been formatted FAT32.  many vendors sell 128 GB SDXC cards. FAT32 is not the standard format for SDXC cards but the SdFat formatting sketch, SdFormatter.ino, will format SDXC cards as FAT32 volumes and Windows, Macs, and Linux accept this format.

You must post all of your code.  It's not clear how many blocks you write or how you end the write.  You must be writing over the MBR.

Don't format SD cards with Linux utilities they can't format some corrupt cards and don't produce a format that complies with the SD standard.  The same is true for Mac and Windows utilities.

Use the SD Association's Formatter https://www.sdcard.org/downloads/formatter_3/.

You can also use the SdFat example sketch SdFormatter.ino located int the SdFat/examples/SdFormatter folder.

Read is not a problem.  

Write always has severe restrictions for small memory since you can't create or extend files without a 512 byte buffer.

You can rewrite selected portions of an existing file assuming each write starts on a 512 byte boundary and the write record will be filled to the next 512 byte boundary, usually with zeros.

Petit Fat is extremely limited for file write.

The write function has some restrictions listed below:

    Cannot create file. Only existing file can be written.
    Cannot expand file size.
    Write operation must start/stop on the sector boundary.

File write operation must be done in following sequence.

    pf_lseek(ofs); read/write pointer must be moved to sector boundary prior to initiate write operation or it will be rounded-down to the sector boundary.

    pf_write(buff, btw, &bw); Initiate write operation. Write first data to the file.

    pf_write(buff, btw, &bw); Write next data. Any other file function cannot be used while a write operation is in progress.

    pf_write(0, 0, &bw); Finalize the write operation. If read/write pointer is not on the sector boundary, left bytes in the sector will be filled with zero.

The read/write pointer in the file system object increases in number of bytes written. After the function succeeded, *BytesWritten should be checked to detect end of file. In case of *BytesWritten < ByteToWrite, it means the read/write pointer reached end of file during the write operation. Once a write operation is initiated, it must be finalized or the written data can be lost.

2840? Did you intend 1284 there?

Yes.  I will never get this post right.

I have no idea how to connect an Arduino Due

Sorry, I meant an Uno and have edited the original post.  It should work on your board.

It works on AVR Arduinos, 328, Mega, Leonardo, and 1284 boards.

Check for insufficient SRAM by adding this function to your program.

Code:

uint16_t freeMem() {
  char top;
  extern char *__brkval;
  extern char __bss_end;
  Serial.println( __brkval ? &top - __brkval : &top - &__bss_end);
}

Call it in setup() like this:

Code:

void setup() {
  Serial.begin(9600);
  freeMem();
}

If it prints less than 700, you can not add SD.h.  SD.h has a 512 byte buffer for SD blocks and you will need about 200 for stack.

I have posted a sketch for logging data from a TekPower TP4000ZC or Digitek DT4000ZC multimeter as TP4000ZC20130427.zip code.google.com/p/beta-lib/downloads/list.

Instructions for interfacing the meter to an Arduino are included.  The interface consists of a standard audio cable with 3.5 mm plugs, a 3.5 mm socket, and a 10k resistor.

Here is the readme file:

The sketch TP4000ZC.ino is a data logger for TekPower TP4000ZC and
Digitek DT4000ZC multimeters.

This sketch requires the SdFat library located here:

http://code.google.com/p/sdfatlib/downloads/list

An Arduino interface for the meter is described in interface.txt.

logger.jpg shows my debug setup.

The meter protocol is defined in TP4000ZC_serial_protocol.pdf.

Links to other meter info are in meter_info_url.txt.

The sketch was debugged with an Adafruit Data Logging Shield but
any SD module/shield should work.

Data is logged to a file named DMMLOGnn.CSV where nn is a number 00-99.

The csv log file has three or four columns depending on the value of
MULTIPLIER_FORMAT.

For MULTIPLIER_FORMAT = 1 the format is:
<time in seconds from boot>,<value with multiplier>,<units and other info>

For MULTIPLIER_FORMAT = 2 the format is:
<time in seconds from boot>,<value>,<multiplier number>,<units and other info>

For MULTIPLIER_FORMAT = 3 the format is:
<time in seconds from boot>,<value>,<multiplier character>,<units and other info>
possible multiplier characters are

'n' - nano
'u' - micro
'm' - milli
' ' - multiplier of one
'k' - kilo
'M' - Mega

The following are configuration parameters:

const uint8_t DMM_RX_PIN = A0;   // DMM connected to analog pin 0.
const uint8_t DMM_TX_PIN = A1;   // Analog pin 1, not used.
const uint8_t SD_CS_PIN = SS;    // SD chip select pin.

// Options for multiplier format are 1, 2, 3
#define MULTIPLIER_FORMAT 3

// If ECHO_TO_SERIAL is nonzero, print record to Serial.
#define ECHO_TO_SERIAL 1

ATtiny84 also has only 512 bytes of SRAM, too little to write an SD with a file system.

The UT61C sends 14 byte packets and several websites have the protocol.  The protocol is in the file UT61BCD.LOG on this site.

http://www-user.tu-chemnitz.de/~heha/hs_freeware/UNI-T/

Here is the meter chip datasheet http://www.ic-fortune.com/upload/Download/FS9922-DMM4-DS-11_EN.pdf.

Making an interface cable is a bit tricky.  These meters have opto-isolators and use tricks to generate RS232 with power from control lines driven by the PC serial interface.

I was able to use 5V and a resistor to generate TTL serial from the output of the opto-isolator.

I don't know how the UT61C does it's serial.

The ATtiny85 has too little SRAM to write an SD with a file system. 

An SD block is 512 bytes and the entire block must be written.  File systems require a block to be read, updated, and rewritten.