Never achieving sync with initial ascii response

[strud]

I have a binary data packet being transmitted with the default 0xAA sync byte and another 17bytes following.

The packet rate is set rather low at 1000Hz and baud set to 926100.

I am triggering the stream using the serial out function in Telemetry Viewer and my device responds with some ASCII text before the binary stream begins.

TelemetryViewer does not manage to gain sync at all, so Iam wondering if the initial ascii response to the serial command is throwing it off?

Image below showing star of stream when captured. 0xAA still being used for sync

[strud]

So I removed any ascii responses from my device and the sync is still never achieved.

Captured start of stream now:

[farrellf]

The ASCII text should not cause a problem but TelemetryViewer would report a corrupt packet/loss of sync when that text is received.

Are you sure the COM port / baud rate / data structure are defined correctly in TelemetryViewer? A 1kHz packet rate should be fine. I'm currently testing a USB UART project that outputs packets at 600kHz and uses ~250Mbps of bandwidth.

[strud]

Ok thanks for the feedback, that is good to know.

Will check the definition. I assume that if the packet length is wrong this would be a show stopper.

[strud]

So a bit more information.

If I have my device stream at 1kHz for 1 minute, TV reports loss of sync until the very end where it seems to capture 10s of data and then shows it on the chart.

[strud]

Not sure if it is relevant or not, but the code example section is blank with my config.....

[strud]

Can I get confirmation if the sync 'word' is actually a byte or a word as in two bytes?

[strud]

One more data point, if I turn off 'Show Failure Notifications' obviously the lost sync messages are no more, but also the data chart seems to be showing captured data....

[farrellf]

The blank code example section is normal for now. I have not written a code generator for binary UART mode, but I plan to do that eventually.

Yes, the sync word is 1 byte long.

It sounds like you are getting a flood of failure notifications, which is slowing things down. A loss of sync means there were bytes found between the end of one packet and the start of the next packet. Based on your screenshots, it looks like you defined a packet that is 18 bytes long, and it also looks like you are sending packets that are 18 bytes long. So I'm not sure what is causing this problem.

Can you run the program from the command line, and share all of the text that gets printed to the console?

[farrellf]

Hmm... in your first post you mentioned a baud rate of "926100" but it looks like you are using 921600 (which is a common baud rate.) I assume you have the baud rate in TelemetryViewer set to the correct value (921600)?

[strud]

That baud rate was a typo, yes I am running at 921600.

Baud rate in TV set to this value also.

I wonder if there is some sort of error being caused by the OpenGL problem you mentioned at some point?

When I run for a 10s to 60s burst, TV shows a very large number of messages in the command line: [FAILURE] Lost sync with the telemetry packet stream.

Here is a snippet:

2023-02-04 15:50:35.296 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.297 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.299 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.301 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.303 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.305 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.307 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.317 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.319 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.321 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.322 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.323 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.325 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.327 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.328 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.330 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.340 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.342 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.344 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.346 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.348 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.350 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.352 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.362 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.363 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.364 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.365 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.365 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.367 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.369 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.371 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.373 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.383 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.385 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.387 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.389 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.390 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.391 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.392 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.393 [FAILURE ] Lost sync with the telemetry packet stream.
2023-02-04 15:50:35.394 [FAILURE ] Lost sync with the telemetry packet stream.

It is not every packet but many and sometime many in a row.

The display charts do not update during this time, however at the end if I minimise and maximise the window they are updated and seems to show no missing data which is curious.

This chart is showing from 10s to 20s ie the second 10s burst I ran in this session and it looks like the data is all there (just a sine wave).

There are other graphical issues with the TV application ie I cannot edit the charts that have been created and the time control is not present down the bottom centre of the screen.

I am running your release 0.8 with the recommended command line arguments, ie

java --add-exports=java.base/java.lang=ALL-UNNAMED --add-exports=java.desktop/sun.awt=ALL-UNNAMED --add-exports=java.desktop/sun.java2d=ALL-UNNAMED -jar TelemetryViewer.jar

Anything else you need to help nut it out please advise, I really want to get your awesome app going.

Something to mention is that my stream source is coming from a queue that is essentially asynchronous in that an ISR is triggered by the ADC and the bytes are added to the queue. Then a seperate thread has a loop looking at this queue and when it falls behing it simply spits out the bytes to catch up/keep up. This could mean that they are not coming out in neat packets vs time, but should mean (and the captured packets agree) that there are no extra bytes being put in there.

However, the data I'm capturing with my IO Ninja application is showing them arriving as contiguous 18byte packets

[farrellf]

I'm guessing the ~1000 errors per second are causing problems with the rendering. I have reworked the notifications logic to be more efficient, so the next release will probably not have that problem. But I don't think that is the root cause of your problems.

I have been using UARTs in binary mode for years with reliable operation, and I think you are the only user so far to have these kinds of problems. So I'm tempted to think it's a firmware issue. Are you capturing the UART data with IO Ninja the entire time, including when the errors are occurring? Do all of the packets look right?

Having the telemetry packets arrive without neat spacing between them is perfectly fine.

You might want to try generating a dummy telemetry stream with some test firmware. Have a timer at 1kHz, and in the timer ISR just transmit a dummy telemetry packet via DMA. See if you get any loss of sync errors in TelemetryViewer.

Some common firmware bugs I have made or seen in the past include:

• Configuring a DMA stream before the previous DMA transfer finished.
• Starting a DMA transfer before the peripheral's FIFO has emptied.
• DMA'ing from a buffer that is allocated on the stack, instead of the heap.
• Different ISRs using the same DMA stream for different tanks, and not ensuring the stream is available in a "thread-safe" way.

[strud]

Thanks for the suggestions.

If you look at the debug stream on from the command line, it is not a constant stream of errors ie not every packet is losing sync and there are some patches of 10ms without issue :-)

I will try much lower rates and also capture the data with IO Ninja during the run.

Thanks for the assistance, much appreciated.

[strud]

I captured a 10s stream using the IO Ninja serial tap ie it captured this while TV was connected and running.
1000Hzstream_capture_tapped.txt

There does not seem to be any out of sync bytes in that stream, but there is irregular timing of the data as labelled by the Serial Tap log.

[farrellf]

Have you tried the latest version of Telemetry Viewer? Downloads are available here:
http://www.farrellf.com/TelemetryViewer/

I have not had any reports of similar problems, and I'm not able to duplicate this issue.