Unrealistic Scope Trace Arduino serial console. - Page 1
Forum section: electronics / projects

author: frank2644
author_rank: Contributor
timestamp: March 16, 2024, 07:46:19 pm
content: 45 years ago I wrote an assembly language UART program so I was pretty knowledgeable, but today I have forgotten many details.My problem: The Arduino baud rate is set @ 115200 and that calculates to an 8.6us bit rate. The attached scope trace seems to say the bit rate is roughly 71ns. The Arduino IDE is set at 115,200 and it reads that serial signal just fine, but that is impossible if the scope trace is true.Attached is the scope trace. Yellow trace is the Arduino serial signal, green trace is 1mhz from a signal generator. The green trace is unrelated to the Arduino circuit, it’s just there to verify that the scope sweep setting is accurate (500ns).My scope is a Siglent sds1104x-e and I was initially trying to do a serial decode. However, that didn’t work so I changed to a standard (no-decode) trace and discovered the above apparent problem.Can anybody explain why the scope trace is apparently not correct?

author: MarkT
author_rank: Frequent Contributor
timestamp: March 16, 2024, 08:00:40 pm
content: Quote from: frank2644 on March 16, 2024, 07:46:19 pmWell its seems to be around 10Mbaud, not 115.2kbaud, so something's up. Can you post the code for the sending device?

author: frank2644
author_rank: Contributor
timestamp: March 16, 2024, 08:44:43 pm
content: MarkT,Thanks for the quick reply. To save everyone a lot of pain reading my convoluted sketch, I modified the blink sketch to write "hello world".Same result, here's the sketch and a new trace.

author: Benta
author_rank: Super Contributor
timestamp: March 16, 2024, 08:52:45 pm
content: Can't help with Arduino, but are you sure that it's a UART signal?Looks more like Manchester coding to me.

author: frank2644
author_rank: Contributor
timestamp: March 16, 2024, 09:30:21 pm
content: Thanks, Benta,I'm 99% sure it's a UART signal. I tried to manually decode the trace using UART conventions, assuming the trace represents an "h" or a "w" (hello world), but I could not. I need to brush up on the UART convention. I have forgotten things like LSB or MSB transmitted first, is negative a 1 or 0, probably other stuff. Maybe somebody here is fluent and can decode the trace.

author: ebastler
author_rank: Super Contributor
timestamp: March 16, 2024, 09:41:07 pm
content: You have not told us much about the hardware you are using. You mention an Arduino, but apparently it is not the classical one, since the sketch mentions the ESP8266. So, could you please provide details? Thanks!- What's the exact board type?- What is the boards's crystal frequency?- Which board type (coming from which boards package) have you chosen in the Arduino IDE?- Is there a real UART connection to the computer? I assume it's via USB CDC?- On which pin exactly are you measuring the UART (?) signal?

author: pcprogrammer
author_rank: Super Contributor
timestamp: March 17, 2024, 07:45:30 am
content: An UART sends data based on a start bit, which is a transition from high to low and lasts for 1 bit time. Then the data follows with least significant bit first. After that a parity could be send finished of with stop bit(s) which have a high value. For 8 bits data the default probably is 10 bit times, assuming single stop bit and no parity.But your scope image in the second post almost only show that the delay between two repeats is longer. On the first one there is a repeat after about 1.5us. The first bit of the data looks the same and only later on there is a difference in it. Based on the duration it looks like only 4 bytes of data, which is far from "Hello World".It might well be USB that you are probing instead of actual UART.

author: Ian.M
author_rank: Super Contributor
timestamp: March 17, 2024, 08:29:07 am
content: Which Arduino (exact model please, including Vcc voltage if there are different options for it)?Which pin are you probing?Show us your code!Edit: I missed the attached sketchIts claims to be for an ESP8266 ESP-01, not an Arduino.Frank, please confirm you are using an ESP-01 and probing GPIO1

author: tooki
author_rank: Super Contributor
timestamp: March 17, 2024, 10:46:15 am
content: Quote from: frank2644 on March 16, 2024, 07:46:19 pmAssuming the sample code you provided in a reply is correct, you're using an ESP-01 ESP8266 board. And if so, did you actually read the comments in the Blink sketch?QuoteIn your code, you do this:Code:void setup() {Serial.begin(115200);pinMode(LED_BUILTIN, OUTPUT); // Initialize the LED_BUILTIN pin as an output}If you were to dig down to what theSerial.begin()function does, it ultimately includes this function:Code:if (tx_pin == 2){uart->tx_pin = 2;pinMode(uart->tx_pin, FUNCTION_4);}else{uart->tx_pin = 1;pinMode(uart->tx_pin, FUNCTION_0);}That means that the pin mode of the UART TX pin is not supposed to beOUTPUT, but something else.Then in the next line of your code, you take thesame pinand and dopinMode(LED_BUILTIN, OUTPUT)to it, thus overriding itsFUNCTION_nmode and setting it back to ordinaryOUTPUT.I'm not intimately familiar with the ESP8266, so I don't know what happens when you subsequently perform a UART write to a TX pin that's set to the wrong mode. But it wouldn't surprise me if it ended up coming out wrong.So if in fact you're running an ESP-01 module whose LED is on the TX pin, then this might be the issue. A simple fix would be to run atrue"Hello World" that does NOTHING except the serial output.If you must keep using the same pin for both LED output and UART, perhaps try addingSerial.begin(115200);immediately before theSerial.println()call, to ensure the TX pin is in the correct mode to work as UART, and then following it withpinMode(LED_BUILTIN, OUTPUT);to set it back so the LED can blink.

author: ebastler
author_rank: Super Contributor
timestamp: March 17, 2024, 10:56:44 am
content: I am not sure whether the OP is even using an ESP8266 module, or just grabbed the wrong sample code from the internet. And, like pcprogrammer, I was wondering whether the OP is actually probing the USB connection instead of a UART; about 10 MHz bit rate could be in the ballpark.Hence my earlier questions about the specific "Arduino" board used, and where the data were measured. But I won't speculate any further until the OP comes back with those details.

author: frank2644
author_rank: Contributor
timestamp: March 17, 2024, 02:21:05 pm
content: BINGO... ebastler hit the nail on the head, and others gave me big clues to the problem that I missed. I was stupidly probing the USB pin, not the actual serial data. I guess at age 82 I am slipping a bit, maybe a lot.Thanks for all the great suggestions and comments. And because people took the time to reply I'll take some time and try and answer some of the other comments.I am using an Ardurino IDE with a Wemos D! Mini, which basically provides a convenient development platform for an esp8266. It has a built-in CH340 serial-to-USB chip an I/O programable LED, and a 5v to 3.3v power conversion. I also have tried a Nodemcu which is a similar development platform for an ESP8266.I didn't previously read the comments on the blink sketch, but now I see the comment about Tx and the LED sharing the same I/O pin. I checked the schematic and that is not true for Wemos platform. But I'll start reading those headline comments from now on.Now I know why my Siglent oscilloscope UART decode function did not work...BTW, the esp8266 is amazing. It's typically used for it's WIFI capability, but I also use it for other applications especially if speed is important. I'm amazed how fast some of my time sensitive code works. Maybe other chips are faster, but it's 80mhz basic clock speed, supposedly configurable to 160mhz, seems faster than many other Arduino IDE compatible platforms. Ok, I know clock speed is only one factor, but again my code runs fast (checked w/scope).

author: ebastler
author_rank: Super Contributor
timestamp: March 17, 2024, 04:24:41 pm
content: Glad you got to the bottom of it! You can still use your scope's UART decoding capability by probing the signals between the CPU and the CH340, of course. They should also be available at the RX and TX pins of the D1 mini board, I believe.As it happens, I just used two of the same Wemos board to build little remote water-level sensors for our rainwater cistern and drainage shaft. I also like the balance they struck with that CPU and package: You get a few I/Os to control or read some external gadgets (although several of them have dual functions, watch out for the traps...), and get easy-to-use WiFi thrown in. Have fun playing with the board!

author: zapta
author_rank: Super Contributor
timestamp: March 17, 2024, 07:49:32 pm
content: > I am using an Ardurino IDE with a Wemos D! Mini, which basically provides a convenient development platform for an esp8266.You may look at the esp32 boards. More or less they replace the esp8266, for about the same price, and they are also supported by the arduino ide.

author: tooki
author_rank: Super Contributor
timestamp: March 17, 2024, 11:04:22 pm
content: Quote from: frank2644 on March 17, 2024, 02:21:05 pmI actually have never used the ESP8266, but I’ve used the successor series, the ESP32 series, for numerous projects and they’re great! The most common variants are dual-core, default 160MHz (but can be set up to 240MHz), with WiFi and Bluetooth and 4 or 8MB Flash memory!ESP32, Raspberry Pi Pico (RP2040), and the faster STM32 models are probably the fastest Arduino-compatible MCUs. Each family has its pros and cons, of course, but they’re all good.

author: zapta
author_rank: Super Contributor
timestamp: March 17, 2024, 11:13:32 pm
content: Quote from: tooki on March 17, 2024, 11:04:22 pmThe teensy 4 is also plenty fast, at 600Mhz.https://www.pjrc.com/store/teensy40.html

author: tooki
author_rank: Super Contributor
timestamp: April 07, 2024, 02:58:55 pm
content: Quote from: zapta on March 17, 2024, 11:13:32 pmOh yes, of course! It slipped my mind that those are also supported under Arduino! Those are seriously beefy devices!