baudrate 921600 without errors?

Have you succeeded in transfering megabytes of data without errors from Arduino Uno to Windows Xp through the usual USB cable and serial COM-port at the nominal baudrate of 921600?

I have have tried with my Arduino Uno and Serial.print() with testdata length of 128 chars/call. The receiving program in XP is not the Arduino monitor window, but other programs( e.g. AVR Studio 5 terminal window, where one can specify a baudrate of 921600; realterm worked also). (Arduino monitor window has the highest speed 115200 bps).

There are random errors , mainly missing characters or short sequences of missing characters every now and then, but there are also correct sequences of kilobytes in length.

My application could tolerate some errors in the transfer, but if there is a good way to eliminate them, the better.

Any ideas how to continue?

I have succesfully used 230.400, 345.600, 500.000 baud withoout errors using putty as receiving app.

You can better try 1.000.000 baud as 921.600 to decrease errors if the app supports it. Note 1 million is a divider from the 16Mhz clock...

Thanks Rob, that confirms my observations, too. The problem might be mainly on the pc-side. My pc might be limited to fixed set of baudrates in the com-ports, although AVR-Studio 5 in the options formally accepts any number, e.g. exactly 1 megabit/s speed instead of 921600 b/s. In a repeated transfer test Arduino probably sent at exactly 1 megabit/s, and in practice could reach that sending speed if programmed with uart registers (but with Serial.print only 1/5 of that speed was attained in practice). The error rate was variable again, kilobytes of data could go without errors, then some missing character(s), and errorfree kilobytes again etc.

With the Arduino clock of 16 MHz one could with optimized programming theoretically send at least 8 megabits/s a short while (?) so this USB-solution soundsa bit awkward when trying high speeds. Perhaps Arduino Ethernet card would allow higher speeds?

Sending with SPI to an SD-card using sdfatlib SPI_FULL_SPEED gave the highest speed about 570 kilobits/s only, although I expected much higher. Arduino Ethernet card uses SPI also, so that probably is the bottleneck in spite of Ethernet's 10 /100 megabit/s speed.

Perhaps I'll try my Ethernet card next.

If I recall correctly SPI can do 4 Mbit/sec. High speeds are interesting as more time is left to do measurements and processing.

The accuracy of the 16Mhz Crystal is quite crucial at high speeds. If your board has a resonator (disclaimer not an hardware expert ;) then the cpu ticks can fluctuate quite a bit which might be an important source for your errorbytes. Furthermore if you want error detection and correction at those high speeds you must send a CRC + SEQ byte every N packets and return an (N)ACK. Mind you if the timing is lost it will be lost for a long time at those very high speeds.

SD cards can be best written in blocks of 512 bytes as that is the sectorsize of SD cards. See the storage section of the board (search for the work of fat16lib)

My experience with the (wiz5100) ethernetcard is that it is slow - but never tried to optimize its throughput. For my purpose it was fast enough. Don't know for that other famous ethernet chip (enc....something)

The clockrate in the SPI of a 16MHz Arduino can be up to 8 MHz, but the actual payload might be less than half of that (?). SPI in the SdFat-library could read from an SD-card at the average useful rate of 1.9 megabits/s during a several megabyte operation (writing was only 570 kilobits/s). The transfer was with single 512byte block read or write operations based on the physical block number, without any regard to the file structures on the SD card.

An ethernet test was a big disappointment: With the modified 'official' example of the Ethernet library Web client I read from my localhost a 100 kilobyte http-page. The speed was hardly 4 kilobytes/s (28 seconds to transfer the whole page). How to improve substantially?

When raw USB-speeds in a PC can be 1.5/12/480/5000 Mbit/s (depending on the USB version), I am puzzled about the difficulty to utilize that easily with Arduino Uno.

How to improve substantially?

pumnp your raw measurements to pachube and let them handle the load ...

robtillaart:

How to improve substantially?

pumnp your raw measurements to pachube and let them handle the load ...

Good to learn to know pachube, thanks. But the problem might be that Arduino gets into its RAM data faster than it can send it out anywhere (PC, Pachube, SD-card, ...).

Anyhow, after these experiments it is useful to know the practical speed limits of Arduino Uno; if essentially higher rates are needed, some other hardware is necessary. Signal processor chips e.g.

But the problem might be that Arduino gets into its RAM data faster than it can send it out anywhere

Think that is true for most processors ;)

Sd-card programs by fat16lib can transfer data at very satisfying speeds, when using multiple block transfers instead of one block at a time!

When erasing and writing 64 blocks of 512bytes (from a constant buffer of 512 bytes), the writing speed was 584 kilobytes /s = 4.66 megabits/s on an average during tens of megabytes of writing.

SPI clock rate was 8 MHz, 16MHz/2.

This seems to solve my problem well. Instead of trying to send the bursts of data directly to PC, they are written to the SD-card (in this case, 2 gigabyte FAT16 formatted Transcend microsd card). SD card is treated as one file of 512 byte blocks.

The data loss is very likely between the 328 and 8u2 chips. Once the data is into the 8u2 chip, there is end-to-end flow control provided by the USB protocol.

If you reprogrammed the 8u2 chip to provide a flow control signal back to the 328 chip, and changed the HardwareSerial class in Arduino to use it, you could probably make this work very reliable. This probably isn't feasible on the 8u2, due to lack of code space, but on the new Uno R3 boards with a 16u2 chip, it could probably be done.

On Teensy, where Serial is USB virtual serial, it's possible to transfer to the PC at speeds approaching 1 Mbyte/sec, if the data is written in blocks with Serial.write(buf, size). It works extremely well, with zero data loss, due to USB's end-to-end flow control. Yes, that's 1 million BYTES per second, not 1 million BITS per second. The max speed depends greatly on the software running on the PC side, and also to some degree what other USB devices are active.

Of course, there's pretty much no source of meaningful 1 MByte/sec data on a 16 MHz chip. But that raw speed is indeed possible in testing if you send the contents of a buffer in RAM repetitively. Often when "real" data sources are involved, maximum speeds achievable are in the 120 to 200 kbytes/sec range. However, when Teensy implements a USB disk using an SD card, speeds are approx 500 kbytes/sec (about half the raw 1 Mbyte/sec used on the SPI port).