I've finally gotten hold of a Saleae analyzer and can now describe my problem in more detail thanks to it.
I've only had a half-an-hour's worth of experience with the analyzer, so if I'm doing something wrong, then please point it out.
A summary of the experiment:
Edison TX -> Nextion RX
Edison TX -> Saleae channel 0
Nextion TX -> Saleae channel 1
All grounds are combined
I send a Nextion command from Edison to Nextion by UART.
I analyze the TX of Nextion parallel to this transmission.
Saleae file is enclosed.
okay seems I was late and already dissected
The wires are 20cm long.
The protocol configuration is:
con_nect is the name of a normal variable to which I assign the value 1.
If I understood you correctly, then this noise which comes from Nextion and which Edison interprets as 0xFF bytes is a normal thing and I can't possibly avoid it? So is there only one solution: clear the Edison receive buffer from 0xFF bytes?
the noise comes from the Edison itself, not from the Nextion ...
Gerry, Edison is connected to Nextion only with the EdisonTX->(Salaea_Channel0+NextionRX) connection
There is NO connection between NextionTX and EdisonRX
NextionTX is connected only to Saleae channel 1.
It is transmitting loads of 0xFF bytes onto Saleae which Koepel calls "noise".
So the noise is emitted directly from Nextion and has nothing to do with Edison.
If I do connect NextionTX to EdisonRX, I will get a buffer full of 0xFF bytes which is what I'm trying to prevent.
I repeat that this "noise" is interpreted when Nextion is connected to Edison as 0xFF bytes.
On the other hand, if I connect Nextion to my laptop using a UART-to-USB connecter, it will not react and the RX buffer will be clean.
Noise as Koepel points to was only 2ns spike low
- this is too short for any bit, can only be interpreted as noise
- 2ns wide is 500MHz - is also clock of Edison but is correlation only
Source of noise or cause noise hasn't yet been determined.
Serial TTL communication starts with the falling edge (of a start bit)
- as Koepel points to, fall is already enough to trigger an interrupt
- as the next 1,042µs are high (it should only be interpreted as noise)
even though is incorrectly being interpreted as an 0xFF
- for it to even be possibly considered as a byte being sent
the spike would have to hold low for 104.2µs - one full bit width at 9600
- this 104.2µs at 9600 baud is the width of the start bit which is always low
Therefore, It is indeed not a byte being sent at all
1 TTL Serial byte = 10 bits from falling edge
1 start bit - always low for (1/baudrate) seconds
8 data bits - varied but width is each (1/baudrate) seconds
1 stop bit - always high for (1/baudrate) seconds
Therefore an 0xFF at 9600 baud would look like
a drop low for ~104.2µs from falling edge
returning and remaining high for 937.5µs from rising edge.
Since the line never went low for a full 104.2µs
and Edison can not produce 500 Mbps communications
and Nextion's highest clock of 108MHz is already less than capable
noise on the line remains the only possibility.
When connected to laptop, Windows buffer is clean -- no pile of 0xFFs
When connected to Edison, Edison buffer has abundance 0xFFs
This is code Edison side misinterpreting noise as a byte
- since at all positons of the data bits are high (capture) = 0xFF
But since start bit was never held even close to 1 bit width
- this is indeed a misinterpretation on the Edison side.
Where the source of the Edison misinterpretation in code is ... arrgg!!
What is the cause line noise can be caused from
- plenty of sources directly and indirectly can related to
But Edison should not respond with byte into the receive buffer.
- this is too presumptuous that line never will have noise
and in real world cases - such is rarely ever the case.
- as you see even 2ns fluxuation was enough to cause error
way too low - tolerance is being ignored and bypassed especially at 9600.
Where in all of Edison's code,
which version of drivers, kernel, libraries etc?
- this indeed takes some digging into.
Which to replace with better code
- again more digging into
Patrick, your explanation was spot on and I agree with everything you say.
Koepel, I will try a similar experiment with a second Edison in order to exclude the possibility of a hardware malfunction.
If everything turns out the same, then there is no faulty hardware and it's some special quirk of Edison for Arduino. In that case I'll switch to Intel's forums and let them look into it because I'm sure Patrick is on the right track.
ITEAD can take care of their noise, maybe they'll manage to get rid of it completely.
Once again, a huge thanks to everyone for your cooperation and help!
Too quick to say what is causing the noise and for Itead to take care of:
Noise can be produced from any EM field
- both Wifi and Bluetooth Radios ON on Edison can cause
- interference from a EM or radio signal depending on wire placements
wires passing through a radio zone can cause EM or radio to be
captured by the wire ... in such case, wire becomes an antenna.
- if radio interference, ferrite beads can already reduce some noise
Many many possible causes of noise
- there is always some noise whenever electrons flow.
- placement of items can play into such.
Way too many noise sources - always environment dependant
But it is your Edison that seems overly sensitive of this
Most hardware UARTS would have oversampling to correct and ignore noise
- Intel claims 16550 and 16570 UART compliance
on such, oversampling would already ignore any noise < 50% of sampling
to me this lends more to port configuration (if no fractured wires)
but reading shows TTL (high on idle) so it isn't 9600,N,8,1 or inversion issues.
- it could lean towards a software serial implementation
where code assumes line so clean (never in real world) and no bother to
implement line oversampling but assumes byte on falling edge.
But also look into Koepel's suggestions with keenness to rule any of those out.
- a broken/fractured wire can indeed cause as it heats up with use
- where? as Koepel suggests get as close to Nextion as possible
TX pin Nextion side of socket before cables go out (with Eddy connected)
Be interested to see what readings say when Nextion RX/TX connected to Edison TX/RX
connected and in use. Make sure all grounds from everything (on all sources) are common
Is the power supply for the Nextion stable, no spikes or voltage drops?
Maze Mieter: The power supply is just fine. I used many adaptors during this time and received the same results every time.
Koepel: It seems we're at a misunderstanding. Edison's RX is not connected to Nextion's TX. Nextion's TX is connected to the analyzer (see the two connection diagrams enclosed). Moreover, if I do connect Nextion's TX to Edison's RX, I will receive the necessary data, but it will be preceded by a bunch of 0xFFs, which appear only if there was a TRANSMISSION prior to the READ.
Patrick: I changed the wires again and again, used different Edison for Arduino boards. The environment which can give off interference are my power supply adapters, LCD screen and Wi-Fi router.
I've run a second test, as you recommended, when Edison RX/TX is connected to Nextion TX/RX.
I've enclosed connection diagrams and resulting Saleae graphs for both tests into this post.
Patrick, I've posted a question in Intel's forums with illustrations, memory dumps, test program source code and the works. Here's the link: