Start a new topic

Multiple 0xFF transmission issue (continued)

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:

Connections:

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.


Hi, I took a look at that file.
How long are the wires ?
I think the protocol is okay, idle high, non-inverted, lsb first, 8N1, 9600 baud.
The 9600 baud results in a bit width of 1041 or 1042 µs, that matches your capture.

The TX Edison sends the command: con_nect.val=1, 0xFF, 0xFF, 0xFF
I don't know that command.
A short command is "sendme" (with three 0xFF), the display returns the current page.
Another command is "connect" (with three 0xFF), the display returns a lot of info.

The TX Nextion shows only noise. It's only noise, nothing else. There are pulses of about 2ns.
When you zoom in into the first level change of TX Edision, then there is a noise pulse as well.

You are not receiving 0xFF from the display. You are receiving noise. The Edison RX detects the noise pulses and sees them as start pulses for a byte, but there is no byte. There is only the noise pulse.

 

okay seems I was late and already dissected

Thanks Koepel

Hi Koepel!

The wires are 20cm long.

The protocol configuration is:

i= mraa_uart_set_baudrate(m_uart,9600);

i= mraa_uart_set_mode(m_uart,8,MRAA_UART_PARITY_NONE,1);

i= mraa_uart_set_flowcontrol(m_uart,false,false);

i= mraa_uart_set_non_blocking(m_uart,false);


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


I hope you understand that you don't receive 0xFF transmitted by the Nextion display. We don't know what the Nextion display is transmitting, because you see the 0xFF due to noise spikes. It is not really 0xFF, it is a small start pulse and nothing else.

It seems that the Edison RX is connected to a loose wire. Perhaps the Edison RX is using a different pin. Perhaps a wire is broken. Perhaps your ground is not okay. Perhaps you have connected RX to RX and TX to TX.
Perhaps the Nextion TX pin is not soldered to the pin of the connector. Could you check that with a magnifier ? Could you capture the Nextion TX pin at the connector of the display ? The Nextion TX is the blue wire.

Start with the most simple command: "sendme".

 

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?

I noticed that the Edison RX signal has more spikes when the Edision TX is transmitting. Therefor I'm pretty sure that the Edison RX is an open loose wire and not connected to the Nextion TX.

Perhaps you should test without the Edison board, for example with a usb-serial module. Or with an Arduino. With an Arduino you can use my command pass-through using an Arduino: Arduino sketch to type commands for the display in the Arduino serial monitor.

 

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:

https://communities.intel.com/thread/115927

Login or Signup to post a comment