Voters 8
-
-
-
P
-
R
-
K
-
M
-
- + 2 voters
-
A
8
Terminal messages to be timeline synced
- Open
- Subscribe
 |
YS |
Today terminal view groups the input messages by signal.
When debugging a protocol it is often very important to have the messages shown in the order of appearance (for example BT module communication over UART should show the messages of RX and TX interlaced, etc. )
Activity Newest / Oldest
Tim
(#87384)
Note: Issue Report below is due to the following Terminal behavior.
- in the case when analyzers are added to previously recorded data, or when opening a previously saved capture, our terminal view will group the output results by analyzer (not in timeline order).
- however, while a capture is ongoing, and data is printed to the terminal, the data is organized differently compared to when the analyzers are added to previously recorded data
"I use 2 async serial analyzers for RS232 RX and TX signals and print the data to the terminal. TX is blue, RX is green. If I use it in the live view, everything works as expected.
If I save the capture and reopen it, RX and TX are both green. No chance to distinguish it."
Tim
Merged with: Synchronise multiple UART analyzers
Chris
When using multiple Async Serial (eg Rx & Tx) the data analyzer outputs are out of sequence compared with the logic analyzer traces
Tim
This is unfortunately a known issue that we are tracking in another bug report post below.
ideas.saleae.com/b/feature-requests/terminal-messages-to-be-timeline-synced/
I'll close this request and will merge it with the post above.
Chris
Thanks Tim, FYI I'm using Logic-2.4.13 appimage on Ubuntu 20.04 if that helps
Peter
The text in text bubbles for individual async serial analyzers is not well aligned with the actual character timing at low zoom, but this doesn't change with multiple analyzers as far as I've seen. Can you show an example?
Text alignment with the relevant signal is a drum I beat on often so I am interested to understand what you are seeing.
Chris
Hi Peter, I don't want to attach a log as it has keys & URLs so I've attached screenshots. This is a capture of Tx & Rx at 115200 and the red text is Tx. If you look at the analyser output the last line is AT%AWSIOTCMD="SUBSCRIBE","test" (tx) but the local echo on Rx is displayed 3 lines earlier in green. In the raw capture these can be seen in the correct sequence.
Tim
(#80588)
"When i am trancing UART data in data console, i find that data console print in wrong order."
Tim
(#79297)
"Hi, There appears to be a bug with multiple Async Serial decoders when opening a saved capture.
When capturing data in a live session the serial decoder outputs are interleaved with one another in the terminal view. This means for example if you were capturing both Tx and Rx for an AT Command interface the terminal view shows a series of commands and then responses.
When opening a saved capture the entire output of serial decoder 1 is dumped to the terminal followed by serial decoder 2, the output is no longer interleaved. If you view the data in the table view it is correctly interleaved."
Tim
This seems to be an unintentded consiquence of this bug. I've attached some photos to show the terminal contents before a capture is saved, and after that saved capture file is re-opened.
Andreas
We would be happy if this feature would finally work, do you have any news about it?
Tim
(#79022)
"I've observed that orders of the decoded frames displayed in terminal is not correct check time...Can you please check if it's known issue or maybe I'm doing something wrong... I'm printing to the terminal in the same moment when creation of the object AnalyzerFrame (first print then create object)
-----
hopefully I can import data to the excel and sort data via time...
consider adding autosort of data when capture of data is stopped as simple solution"
Rob
Yes please! Would be immensely helpful.
Tim
(#78068)
"When terminal/console window show my RX and TX data the order can be wrong..
eg. i send a cmd and expect a response - some times the response is shown before the command this is a bug - In table window everything is shown correct."
Tim
(#76630)
"Maybe in the future there will be time to adress these issues. In my opinon the terminal view of a saved capture has to be generated again from the times which are stored in the table view.
In the end it is quite important to preserve the times from different UART messages. Because all that I can do at the moment is CTRL+A und C to copy the text from the terminal window. But than I loose the colors and with them the relationship between the different UART messages. If I have three UART TX pins to observe simultaniously than it is impossible to tell from which pin a message was send without the colors preserved or the whole capture and terminal view generated again."
Tim
(#75250)
"I'm seeing a very odd result in Logic 2 monitoring an async serial port.
---
I had to compress the time scale but the trace and table show the start character of an xmodem transfer occurring before the transfer starts, but the console view shows the start character ('C') occurring after the packet is received.
---
This behavior is not consistent. Sometimes the start character appears where expected. However, I'm not sure which is the reality, because of odd behavior on the receiver when the character shows as coming after the packet."
Tim
(#74593)
"Hi. When using multiple async serial decoders the data in the terminal view doesn't always come in the correct order. Even if my data always comes as one (json)request followed by one (json)reply it sometimes showes two requests followed by two replies. This is at 921600 baud. There is 100ms between the different requests but the reply comes quite fast, approx 2-3 ms after the full request is recieved"
Paul
Going to add a bump and another vote for this. Trying to debug a particularly tricky modem interaction that only happens when I trace circuit connected. Trying to get the UART trace to the modem manufacturer is quite challenging as I have to hand order all of the terminal output to match the trace window. Can we please get the terminal in time sequence to match the trace? Or a post processor that can do the same? Saving and loading is worse because it stacks each channel in order.
Tim
Sorry about this... we're aware of the issue right now, and if we could solve this quickly, we certainly would have by now. We talk about this particular quirk a lot internally. Long story short, there are some technical limitations behind the scenese that prevent us from implementing the fix easily. We're a small team of 3 developers, and our focus right now is to add automation support to the 2.x software.
Tim
(#66627)
"In the terminal, 2 Async lines to not interlace properly in the way they are really received. You can see in the capture they are talking back and forth in a alternating fashion, but the text in the terminal puts all of the "D0" data first and then puts the "D1" data."
Tim
(#63673)
"When using the terminal with multiple decoders the output order should follow the order of the reception (start of the frames) and they should not overlap on the display. Also when reloading a saved capture, the frames should be in order. Right now, it simply loads the entries for each decoder one by one (all frames from decoder A then all from decoder B). That would make this feature much more readable and usable."
Tim
(#63104)
"Terminal output is not displayed in chronological order, if capture was saved and is leaded again."
Tim
(#61680)
"In the attached, I'm monitoring the comms between a MCU and a modem, sending AT commands. But as You can see the terminal output is not in order. It is for each channel. But sometimes it prints the response before the command, any idea why this is?"
Tim
(#60160)
“Hi, Just want to add my vote to this. In our development team people often argue a terminal window is superior as it is easier to read while I prefer a logic analyser as it allows me to see deeper into what is going on. With this feature we have the best of both worlds however it if is not displaying in the correct order it negates a lot of the benefit of it..... It would be great if this was fixed as soon as possible.”
Tim
(#60160)
"Hi,
I really like the new version of software and what a huge improvement on the old software. One of the features i find great is the UART decoding to a terminal window however it often times does not display text in the correct order leading me to think I have bugs in my code which I do not...."
Tim
(#58784)
"3 serial Interface are traced and safed in a session file. open the file again and in the terminal one Channel after the other is displayed, but not in historical order as during capturing."
Tim
(#58318)
"The terminal lines are not shown in the correct sequence when decoding two channels/signals. You can see it on the screenshots. If the data blocks overlapped, I can see it can be hard to decide which one to show first. In this case it should be possible to sort the lines correctly. I'm sure this is caused by the way the analyzers/decoders are called. With timestamps on each line (behind the scenes), the lines could be sorted correctly."
Tim
discuss.saleae.com/t/serial-monitor-window-formating/865
"I’m using the Async Serial (2) for monitoring to and from a hybrid board/modem at 9600baud, so pretty low rate.
Its fantastic that each Async can be color coded - so thank you for the new feature.
However the Serial Terminal ‘i’ says that Results are not in time order if more than one “Async Serial” analyzer is used.
Its incredibly useful to be able to see the cmds in and the response from the Xbee in the serial analyzer and typically half duplex.
Just wondering if there is any work going on to be able to make it so two analyzers can output the information together with some usability “visualization” terminal display configuration
eg keep ESC characters like r as visible
The Table view does show the raw data, maybe there could a “processing rules” column.
Many thanks for some great new features in 2.3 (I’m on latest) 2.3.16"
Kazimierz
The Terminal data is not in the right order. The ATrrnOKrn on Channel 2 has been captured between ATrn and AT&F0rn on Channel 1, but in Terminal it appears way below the Channel 1's data.
resources.usersnap.com/company/5854fe9e-2cfa-4c1f-8b90-4de6eed77493/datapoint_screenshot/b94626e8-872d-40d3-8204-10000201d954-annotated_7b6d53b3-fdc7-428a-9f76-4ff9e0735480.png?etag=b7cd373e79e07e2c089a14588db02c51
Tim
Merged with: Sort the Terminal data from multiple analyzers by time
Tim
Agreed - we definitely need to get this solved at some point. The software right now provides an "info" bubble popup mentioning this behavior. There are some backend challenges that prevent us from putting the results in time-order, but it's certainly doable.