I've set bkcmd=0 but I still receive various errors such as 1A FF FF FF.
Doesn't bkcmd=0 completely stop any error replies from Nextion or is there a catch?
There is a little more information needed
Which version of Nextion Editor?
- where did you set bkcmd=0?
and where else did you set bkcmd
- is this still Intel Studio and Edison with noise issue or other
Default power on default is 2 - returns failures 0x02 through 0x24
Things like Iteadlib NexHardware::nexInit()
- sends bkcmd in the nexInit() procedure
So on Nextion, set bkcmd in preinitialize of page
can be undone in Arduino setup() nexInit() call.
But bkcmd once set to 0 ignores such important things
like the fact the last command was calling non existent
variables/components and/or their attributes and will
not send a 0x1A failure status until rebooted and the
power on default is once again 2.
Checking the value of with a get bkcmdÿÿÿ sends
0x71 0xAA 0x00 0x00 0x00 0xFF 0xFF 0xFF
where 0xAA is the current setting of bkcmd.
it is possible if noise is still present, that intended
bkcmd=0ÿÿÿ sent is not received at Nextion intact.
There is nothing which you could call 'noise' on the Edison TX when my SHT sensor is working.
There is actually genuine data on the TX, normal width signals. It's like the same data is simultaneously sent to the sensor and UART.
To avoid any consequences for Nextion, during a request to the sensor I do the following:
before calling the sensor function, I send these commands to Nextion:
Then I call the sensor function which begins to transmit uncalled for data onto the Edison TX.
After I receive data from the sensor, I send these commands to Nextion:
0 0xFF 0xFF 0xFF (to close the received bogus data in the Nextion buffer)
I imply that I shall not receive any possible error messages from Nextion in this case and will therefore exclude any effect of the illegal UART transmission on Nextion.
Is my strategy correct or am I missing something?
I don't even think I need to set bkcmd=0 in this case...
Okay - let me reiterate this back
- no noise on Edison TX, line looks clean
- occasional noise on Edson RX line
- side effect Edison receives bogus 0xFFs 0xFCs
and real data somewhere in the mix.
So I think that you are not understanding the "noise"
iterate 100 text and number assignment commands to Nextion
t0.txt="<long phrase>"ÿÿÿ or n0.val=<large number>
where <long phase> and <large number> are above average length
and where you can verify what Edison has sent has arrived intact.
If your 100 iterations are clean without error (I presume they are)
then this issue isn't about having Nextion stop processing its RX
Nextion's RX is Edison's TX - there isn't an issue here.
And if there was a 2ns spike on the wire - it is Nextion receiving
... in which the noise is more than likely discarded in handling.
(Nextion uses an STM32 / GD32 USART module)
com_stop = stockpile incoming bytes from Edison
code_c = disregard all unprocessed serial commands NOW
com_star = resume normal processing.
So in essence, you tell Nextion to ignore Edison
- bkcmd=0 seems to have been discarded in the code clearing.
You still have to deal with your receiving and yes, it has noise.
Nextion TX to Edison RX ... has some 2 ns noise.
This equates to a "big_fat_so_what". Deal with it and be done.
Now again, like as above the TX side (Nextion) is not effected
by noise on this line. But the RX side (Edison) really is
As stated before
your phantom byte is occurring from falling edge
not because there is really a byte coming in
but because the handling procedure is not expecting a spike
and has no precautions taken in case line was ever noisy.
ONCE this procedure starts, it finishes even though at more
than one spot it should have discarded the byte
BUT NO ... it puts the fake byte into the buffer anyway
So as the 2 spikes appear to only be 2 ns wide
then placing the filter on what is coming into the Edison
RX line would be able to trim those away (Intel's suggestion)
(assuming the noise is actually on the physical wire)
If the noise is originating elsewhere then filtering will have
no effect as the noise isn't on the physical wire between
Nextion's TX and Edison's RX.
This is really dependent on accurately interpreting the
observations made by your Logic Analyzer and nailing
down where the real source of the noise comes from.
However, on the software side this can also be solved.
Oversampling is the polling of the value of serial 16x per bit.
pseudo on the other thread
At 2 ns wide noise, the odds of reading exactly when noise
spike occurs is indeed lessed. The averaging of the other
15 samples rule the noise out.
- Just need an interrupt and logic (pseudo in other thread).
Now shutting off bkcmd I think is in the wrong manner.
People should really be cranking it up to bkcmd=3
and by doing so solve many timing issues.
Don't send new until result of last as been received
In this manner, there is little to zero chance of buffer issues
Patrick, if you're interested, take a look at another guy who's been receiving garbage on his Edison:
Now, you didn't correctly understand what's going on. I'll try to elaborate using your own scheme:
-There is a SHT10 sensor and Nextion display connected to Edison.
-There is nothing on Edison TX and RX.
- I send a legal command to Nextion and then I receive the "2ns multiple 0xFF" reply onto Edison's RX.
- Among them, there is a legal Nextion reply, if a reply was necessary.
(Nextion's reply is intact and there are no 0xFFs in between, only before and after.)
- Silence on Edison TX and RX.
- I call update_sht1x
- During and after this update, Nextion receives normal, genuine data, which I didn't send (see enclosed file). After 0.2 seconds this illegal transmission ends. Then the Edison RX gets the 2ns 0xFF noise data again.
- Silence on Edison's TX and RX
Simply put, after every legal and illegal transmission to Nextion, I get the noise effect on Edison's RX.
During sensor updates, I get illegal, real data transmissions on Edison's TX.
I assure you I am getting the issue here
A step by step procedure to solve it ... remains the missing part.
When comparing apples to apples
- ALL factors remain the same
- someone else attempts to recreate your experiment exactly
(or as close as is humanly possible)
- FerryT confirmed SHT can produce false bytes on TX.
- Others have analyzed your Logic capture
this noise does indeed exist - so you're not crazy.
- Others CAN have the phenomena - again, not crazy.
What happens when this 2 ns spike occurs is
the 2 ns noise is triggers a routine
the routine is continuing without validation of data
the routine at the end of time (bps x10) dumps reading
- byte on RX or byte on TX
the 2 ns noise is NOT a byte of data
verified by Logic capture.
Edison side is responsible for this, code or hardware.
Commonality is libmraa, actual or merely correlation.
Now when you CHANGE the conditions of the experiment
- you end up with more observations
- but this CHANGE creates a new condition, NEW experiment
- more experiments that others need to attempt to recreate
- new observations provide data that helps narrow down cause
But your NEW experiment without notice to others and replication
does not create a lack of understanding by the others
What do we know
cause of such a short (2 ns) flux CAN be caused by Edison
it can also be caused by ANY number of other sources
Wire connected to Edison CAN become an antenna
EM signal captured by wire CAN create
But in reality, CAN be coming from almost anywhere.
But we also know a 2 ns duration is a 500 MHz frequency
We know that Nextion valid baudrates range is 2400 to 115200.
- so 500MHz is well beyond the upper end of 115200.
therefore it is worth while to explore putting low pass filters on
- such that the max frequency becomes less than 500MHz
If low pass becomes such that highest allowed through is 1MHz
then such 500MHz becomes ignored - with 2ns having no effect.
So Intel's suggested low pass may be solve for your issue.
or not, filter should be between source and Edison,
so if Edison SoC is source .... then software to solve.
But we also know that
- that issue does not exist on all kernels
- and that some do not get issue when using gpio over libmraa.
So some have solved this issue by moving away from libmraa and kernel
- as such digging into why libmraa seems to be contributing factor ...
a) you can see logic in that someone who no longer has libmraa can not test
b) you can see logic in that someone who no longer has issue can not nail down source.
- so because of these two factors, the issue persists without public solution
What avenues are available?
- the entire source code of kernel and libraries are available
- the tools to create new kernels exist
- source code of most libraries (open source) exist
As Edison is an Intel Atom dual core with Pentium MCU
- this is an Intel chip, using the Intel instruction set
Therefore a 32 bit x86 Linux on VM (Centos 5, Redhat 8.0, etc)
can be used to produce a binary that can be copied to Edison
and such binary will indeed run
The paths to seek a solution are near endless
- most solutions may not include using libmraa
- some solutions may not include using the default kernel
- most users picked a path and were on their way
for these folks libmraa is a distant memory.
What I don't have is a step by step procedure for you
that includes using libmraa in Studio
But I certainly understand how the noise is erroneously translated into a byte
- routine triggered from falling edge without any validity checks.
Most UART implementations would have ignored this 2 ns noise
and tossed it out when the width didn't hold to start bit definition
and noise would have been averaged out with oversampling.
On Intel's forum I'd ask you to find out what your actual IO pin configurations
are set at before, during and after erroneous noise bytes
This can not be answered with how you asked libmraa to do for you
it requires digging deeper (/sys/class/gpio and read out the subfolders and files)
Indeed if misconfigured, could be a cause of jitter - worth investigating.
Here on the Nextion forum, other Nextion users have little experience with Edison
you will not have much chance for Nextion users to find your answers
On the Edison forum, there is little time remaining, and I am sure fewer wanting
to dig in for a "horray! we finally solved it" after it's closed.
- what was the result of using the low pass filter.
- you stated illegal transmissions from Edison TX (can not be on, its outgoing)
test - setup a Nextion waveform and issue addt command
I am less convinced any data points will be added as USART will probably
eliminate as invalid.
- are you certain Logic is not contributing to noise factor?