[Serial] Problem with start

Projects General Guidance
1

Hi!
Im using an Arduino Uno R3 with 14.7456Mhz resonator. I've uploaded new bootloader etc. and it works just fine ( except for delay(), micros() etc. functions ). The thing is that i've swapped resonator to reach higher baudrates without errors. Im operating at 460800 baud right now. And Im recieving only partially correct data. It just randomly "adds" an 1 at MSB. Im reading the output on Tera Term on my PC. And it looks like :

What i send ->> What i recieve

[a] 0110 0001 ->> [ß] 1110 0001
[6] 0011 0110 ->> [v] 0111 0110
[7] 0011 0111 ->> [w] 0111 0111

When i send a char's with 1 at MSB, it just sends it correctly.

2

That baudrate is half a MegaHertz. Perhaps the signal is not very good, and the first bit gets a little from the start bit.
Does the Uno have a good 5V ?
Could you measure the signal from the TX pin, after the resistor of 1k, with an analyzer/scope ?
Perhaps you can remove the 1k resistor in the RX and TX line. The are there to be able to override the RX and TX signals, but you probably don't need to override them.

Is that an official Arduino Uno R3 ?
If not, can you tell what is used for the usb-serial chip. If you have a clone, you could add a few decoupling 100nF capacitors. If you have a bad clone, there might be a problem with the ground plane, and it will never work well.

To make delay() and millis() work, you could make a new board definition in boards.txt to set the right frequency.
Test if you have done it right with : Serial.println(F_CPU) ;

The Arduino Leonardo does not use a usb-serial chip, but uses the USB part of the ATmega32U4. The baudrate is not really used, it is kind of free running over the usb cable. The software for that USB part can slow it down, so I don't know what the maximum throughput is. If you want high baudrates, you could try the Leonardo.

3

Serial.println(F_CPU) returns 14745600 value ( correct ). Too bad, I dont have any measuring aparature except multimeter. In future, I wont be using USB connection - Im using it only for test of new resonator. I will be using HC-05 modules ( this is why I had to switch quartz, HC-05 forced me to use such baud, instead of 250000/500000 baud ). Using baud 921600 shows the same problem.

I, just like you, thought that it could be a remaining of start bit... but when sending [6] char, it affects not the MSB in sent byte, but the MSB in sent value.

I will show it on this example :

[6] 0011 0110 ->> [v] 0111 0110

As we can see, the six'th ( starting counting from 0 ) bit is affected by this error. In my opinion, if it was the start bit affection it would look like :

[6] 0011 0110 ->> [Â] 1011 0110

Since Im certain about micros(), delay() malfuncions, could it be possible cause of such errors ? Im not familiar with Arduino core libraries. Maybe Hardware Serial relies on one of those ? I've seen an implementation of Software Serial libraries, and it used delays :slight_smile:

[Edit]
Im using clone, since it was a polygon for my soldering skills :slight_smile: The chip used it Atmega16u2. It uses two SMD capacitors ( of unknown for me capacitance ). But as I've said USB communication isnt my target. I will be communicating over HC-05 :slight_smile: I also have two 18pF capacitors next to the 14.7456Mhz quartz :slight_smile:

[Edit 2]
I've tested another sets of chars. Everything works with this weird pattern.

0010 0001 -> 0110 0001
0000 1111 -> 0001 1111

In some cases, the values are partially correct, partially corrupted ( by this +1 ) pattern. But in most cases it's flawless stream of data, just affected by this weird phenomen. It always looks for the MSB in char we are sending, and then adds an "1" at one bit higher.

0000 0000 -> 0000 0001
0000 0010 -> 0000 0110
0000 0011 -> 0000 0111
0010 1101 -> 0110 1101

etc...

I have no idea what's going on :slight_smile:

4

Is there a relation between the faulty bits and the crystal ? I have never heard of a crystal that has the hiccups.
Could it be a very bad crystal ? Can you make a photo of it ?
Did you solder it directly to the Uno board ? or are there extra wires ?

You wrote the word "Software Serial" :o
Let's no go there. That is a complete different world, full of pitfalls.

Is it a resonator or a crystal ?
I assume that you have quartz crystal of 14.7456Mhz and two 18pF capacitors. That is okay.
Do you know this website : WormFood's AVR Baud Rate Calculator Ver. 2.1.1

If you have your own board definition and F_CPU is 14745600, then the millis() and delay() should work perfect. Both the micros() and millis() can be a little wrong with very low values (say 5 or less).

The hardware Serial library uses the hardware USART and interrupts. No delays.

Could you show a (small test) sketch ?
Could you try another crystal, and another Arduino board. Not the same components from the same series.
Did you try adding extra decoupling capacitors and removing the 1k resistors ?

5

I dont think those are very bad crystals. Plural because I own two of them, each for one of my two Arduino Uno's R3. They are meant to "talk" to each other at +460800 baud rate over Hc-05. For now, I am testing communication at those speeds via my TeraTerm on PC.

Sorry for the confusion with a "resonator" and "crystal" :slight_smile: Im using Crystal oscillator, same as there :

It's very same thing, with "WTL 94 14.7456" wrote on its metal case. It's two terminal element. I havent soldered it directly to the Uno board, I've made alittle walkaround - I put out my Atmega328P out of socket, and then bend out two pins ( Xtal legs ) so there is no connection with socket at those two, and then soldered a two cables to them ( leaving SMD quartz on Uno board ). Wires are indeed long - they could be more than 20cm long each. And I see your point. I've neglected the fact it could interfere the signal. In addition, the quartz is mounted on the breadboard just next to the HC-05 module. I will switch it's location asap.

I know this website, and it helped me chose a crystal for my uno's. Unfortunately I cant try another crystal and another Arduino board, besides two I already have.

The doubts I was having about delay() and micros() functions are caused by the code in "wiring.c" I've found.

In the micros() we can find :

return ((m << 8) + t) * (64 / clockCyclesPerMicrosecond());

In 16Mhz case, its fine, because 64/16=4. But with 14.7456Mhz we have float value projected to integer. Im not sure, but it could change something. Next, if we come to delay() :

uint16_t start = (uint16_t)micros();

It uses our micros() function which is ( is it ? ) corrupted. I dont know if interrupts use this function.

Coming to those decoupling capacitors and removing 1k resistors - im not that good at soldering, and SMD parts scares me away easily :slight_smile: I would like to eliminate rest of possible causes before I try to solder my Uno :wink:

About my sketch : there were hundreds of them already :smiley: I dont think, that it could be the cause of errors, since most of my test sketches, was like :

void setup() {
  Serial.begin(460800);
}

void loop() {
      Serial.write(97);
}

[Edit]
I soldered quartz straight to the pins of the Atmega. Still the same problem.
Another question : I cant find information how quickly can HC-05 and Serial communication switch from transmitting to recieving, because it cant do both simultaneously for sure. What I am trying to achieve is two-side bluetooth voice communication. I have external ADC and DAC which works fine, but im having a bad time with communication :slight_smile:

6

[Update]
I think, that the errors occured in my case are fault of USB communication, or PC Terminal. I dont know why, havent I done it before, but I've connected my two Uno's cross TX->RX, and RX->TX. Everything worked as expected. The voice was sent and recieved at the same time with expected quality.

Crucial part of the code, which covers "talking" to each other. Bit shifts, are done since i can transmit only single byte at once, and my ADC and DAC are 12bit quality.

void loop() {
      readvalue = readADC(0);
      Serial.write((readvalue >> 4) & 0xff);
      while(!(Serial.available())){}
      readvalue = Serial.read();
      setDAC((readvalue << 4) & 0xff0, 0);
}

The good news is - Hardware Serial library is fast enough to cover my needs, and it works good at my new quartz. The bad news is - HC-05 modules doesnt work as they should. Both 460800 and 921600 baud isnt their "max". Im using 3.3v-5.0v level converter, but I dont think it is slowing whole thing down. I have literally no idea what is slowing down the process. Audio effects after sending audio over HC-05 is similiar to the audio I've recieved after adding 2ms delays between readADC and setDAC. The difference is huge, by simple crosswire I've recieved a sound, and by HC-05 I've recieved an geiger counter sound :slight_smile:

7

It's been so many years, I had to go look at a reference book. Asynchronous ASCII is sent LSB first.

Paul

8

Sending LSB first eliminates the "start bit" influence :slight_smile: But I'm not sure what does it mean...

9

It may mean your Tera Term program is discovering a parity error and changing one bit to make parity correct. Are you able to monitor the status of the UART such errors?

Paul

10

TeraTerm's parity control is set "none" just like in Serial.begin() at Arduino code. But as I've said, somehow it was only recieving via USB problem :slight_smile: Straight communication between UNO revealed no malfunctions.

11

Thanks Paul_KD7HB, the databits are indeed lsb :-[

Gosucherry, so you have a crystal then ?
I don't like the term "crystal oscillator". I prefer "crystal" for a bare crystal and "oscillator" for a component that contains an oscillator and outputs a frequency.
That wikipedia page is about an oscillator.

The crystal should be very close to the ATmega328P. The wires may be 1cm, but no more. The 18pF are also very critical. They must be very close to the crystal and very close to the GND of the ATmega328P.

I think you are right about the micros().
This is the wiring.c you already found with delay() and micros():
https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/cores/arduino/wiring.c
The "Arduino.h" has: #define clockCyclesPerMicrosecond() ( F_CPU / 1000000L )
https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/cores/arduino/Arduino.h
And that is where the accuracy is blown out the window. It is accurate per MHz.

Which level shifter do you have, and how is it connected ?

I don't know what HC-05 modules can do. I suppose there are a number of different HC-05 modules, perhaps even fake modules that work a little.

12

The level shifter is same as on this picture. How is it connected - its two directional bus, so TX and RX are connected straightly, two grounds, to grounds, and Arduino Vcc to 5V, and 3.3V ( from my resistor divider ) to 3v3 :slight_smile:

Converter link

Yes, Im having a crystal.

Im not sure if the problem isnt occuring only at reading Serial over USB, since straight connection between two UNO's showed no malfunctions. This make it half-solved :slight_smile:

13

When two Uno's are connected, that is without the level shifter ?

I think your level shifter is for a open-collector bus. It has mosfets with a weak pullup of 10k to 5V (or 3.3V).
I'm not happy with using that for high data rates. It is not a logic chip for digital signals.

Are there more wires we have to know about ?

What is the value of the resistors for the voltage divider for 3.3V ?

14

Yes, two UNO's are connected without the level shifter. I've tried plugging HC-05 for a few moments without it, and the result was the same. Plugging UNO's 3.3V output into level shifter also didnt change anything :slight_smile:

15

Can you make a photo of your project ?
Perhaps one of the boards is too cheap, or does not have enough decoupling capacitors.
I wonder if good things (for example from Adafruit.com) would work right away without problem.
You many need very expensive equipment to test where the cheap boards go wrong :frowning:

16

Project works fine. I've tested it now making two simple programs. One constantly does "Serial.write(97)", second one check Serial.available() and reads, if there is anything to read. Then, he check if that was "a" letter. If true, it turns on LED, if false, it turns off LED and wait 300ms. The data transmission was flawless :slight_smile: But i've noticed that HC-05 modules works... slower ? I dont know how to call it, but it seems like HC-05 takes data into buffer and wait some time before he sends it, and it takes lot of time, no matter what baudrate. But it's topic for another discussion, which I started HERE. We can say, that this "error" thing is solved, and the malfunctions of data, was caused by PC-USB or Arduino USB com side :slight_smile:

17

Well, okay, okay. That is not a very satisfying answer, but you tried to find the limits. It might have been a combination of things, and one thing was the Arduino ATmega328P via the usb-serial to the USB.