Uno vs Nano USB communication

I'm using the ADC of the ATmega328 for data acquisition, storing 1000 8-bit values in the buffer and then sending them through USB to the PC where they're read and interpreted by LabVIEW.

On the UNO everything works fine, but on the Nano the data starts lagging behind by a few seconds (~20 buffer transmissions). Sometimes it gets so behind LabVIEW is giving an error "an over run error occured during transfer. A character was not read from the hardware before the next character arrived".

Could the FTDI chip on the Nano be slower than the ATmega16U2?

An over-run error suggests the data is arriving too quickly.

Post your code.


It's hundreds on lines of code... And I can't post the LabVIEW code, unless I upload the VI.

But as I said, it works fine on the UNO... :frowning:

Here's some of the code:

void loop()
	if ( stopDAQ )
		//send buffer to serial in correct order
		//Serial.write sends binary data, while Serial.print sends ASCII
		Serial.write( (uint8_t*) ADCBuffer + ADCCounter, ADCBUFFERSIZE - ADCCounter);
		Serial.write( (uint8_t*) ADCBuffer, ADCCounter );
		Serial.print( DATAEND );
		//turn off LED errorPin, digital 13
		cbi( PORTB, PORTB5 );
		//clear buffer
		memset ( (uint8_t*) ADCBuffer, 0, sizeof(ADCBuffer) );
		//resetting variables
		stopDAQ = false;
		bufferIndex = -1;
			singleDAQ = false;
			//restart the analog to digital converter
			//let the ADC buffer fill
			//restart the comparator

And the interrupt handling:

#include "header.h"

//		ADC Conversion Interrupt
//	Triggers when bit ADIF in register ADCSRA (status register A) is set to 1
//	ADIF is set to 1 each time a conversion completes, in Free Running Mode

	// When ADCL is read, the ADC Data Register is not updated until ADCH
	// is read. Consequently, if the result is left adjusted and no more
	// than 8-bit precision is required, it is sufficient to read ADCH.
	// Otherwise, ADCL must be read first, then ADCH.

        ADCBuffer[ADCCounter++] = ADCH;
	if ( ADCCounter >= ADCBUFFERSIZE ) ADCCounter = 0;
	if ( bufferIndex == ADCCounter )
		//stop DAQ and allow sending data to serial
		//disable ADC
		cbi(ADCSRA, ADEN);
		stopDAQ = true;


//	Triggers when bit ACI in register ACSR is set to 1

	// disable Analog Comparator interrupt
	cbi(ACSR, ACIE);
	// turn on LED errorPin
	sbi( PORTB, PORTB5);
	bufferIndex = ( ADCCounter + after_Trigger_Samples ) % ADCBUFFERSIZE;

If you use REPLY and not Quick Reply, you will find at the bottom of the screen an ATTACHMENT facility.
Attach your arduino sketch there.

Tom..... :slight_smile:

It's hundreds on lines of code...

Perhaps you could write a short Arduino program that illustrates the problem?


I guess it is the FTDI chip. Borrowed a cheap chinese version with the CH340G chip and it works great.

Long live the clones! (?)

I would not expect a problem with a genuine FTDI chip. Have you time to investigate further ?


I would not expect a problem with a genuine FTDI chip. Have you time to investigate further ?


How would I check if it's genuine?

How would I check if it's genuine?

I was assuming it is genuine if it has FTDI printed on it and it is attached to a board from a reputable maker.

I meant that you might find time to investigate the cause of the problem - not whether the chip is genuine.


Ok. Well, I assume it is a genuine FTDI chip since it is properly marked. The whole board has good quality. Anyway.

How would I go about debugging this?

What clock does the nano has? 8 or 16 mhz? Nd the chinese clone? I assume you are using same baudrate on both..

Both are 16 MHz, I think. I programmed them as 16MHz and they work, and they both have 5V regulators, so yeah.

The original is V3.0, and the clone is a DCCduino.

How would I go about debugging this?

I would write a simple program that sends data and try it at different baud rates. That obviously needs an appropriate program on the PC to receive the data.