I'm capturing data from an analog-to-digital converter, spi clock is about 2MHz and word length is 24 bits. I use the "export entire row" function to obtain a text file containing sample timing and spi data values, which I then import to a spreadsheet for analysis of various details of performance of the ADC.I've found a line in the spreadsheet that does not match the PulseView spi decoder's on-screen display: Decoder shows data on-screen that matches the logic analyzer acquisition display clock and data: a 24-bit spi transfer containing the value 1E7 hex. Data transferred to the "export entire row" text file contains a hex value 10000000. This requires at least 29 bits to represent as binary, which is more than the 24-bit setup that I used for configuration of the spi decoder. I see the same results using either Excel or Libre Calc to open the text file, and here's the relevant line from the text file: 437377406 437377820 SPI: MISO data: 1.00E+07 To recap the problem: PulseView shows this sample value as 1E7, which is a valid result. The process that exported the spi data file seems to be converting 1E7 (hex) into 1.00E+07, which is wrong. In my present file, any 3-digit hex value beginning with a numeral, then "E", then another numeral, has this error of representation.
Thanks for your report. Can you please attach an .sr file that we can use to reproduce the issue?
ping
Created attachment 545 [details] text file, data exported from PulseView SPI decoder The SPI decoder's display of hex data within PulseView is correct. The exported text file produces incorrect representation of the hex data, for example: 1E1 hex is represented as 1.00E+01 It looks like some feature of the export process is turning the hex values into incorrect decimal values using scientific notation. This seems to occur with any data that originates as nEm hex, in which n and m are numeric. The cases that I'm seeing originate mostly as 3-digit hex values, so I'm not sure what would happen if the original value were 32E19h, for example. Maybe it would be exported as 32.00E+19.
Thanks for the comment but this is not an .sr file.
Hi Soren No, this is not an sr file, it's the text file that is exported using the export function that is provided within PulseView. I found that the mishandled representation occurs in the case in which export is used in the original PulseView session that captured and decoded SPI data, AND it also happens in the case in which I've loaded a previously saved sr file to PulseView, then exported the text file from the selected row of SPI hex data. In other words, what's relevant to my bug report is that the process for creation of the text export file it mishandling hex data which has the form that I described. In my present task, I'm using the logic analyzer and PulseView to intercept data from an analog-to-digital converter. I export that data from PulseView as a text file, then import that text file to Excel or Libre Calc for further analysis. The text file that's delivered by PulseView contains the erroneous data representation that I've noted. Mike
Well, if I can't reproduce the issue, I can't really fix it, and you're the first and only person to have encountered it. I've tried to reproduce it and failed and another member from the community also failed in reproducing it, so there has to be something special about either your data or the environment that PV runs in. I'm not trying to be an ass here, I'm just saying that without being able to reproduce the issue, the chances of fixing this bug are rather slim...
Created attachment 546 [details] .sr file for bug 1417
Comment on attachment 546 [details] .sr file for bug 1417 SPI decoder setup for .sr file for bug 1417 CLK D6 MISO D4 CS D2 chip select active low Clock pol 1 Clock ph 1 MSB first Word size 24
As Soeren mentioned, the problem does not reproduce everywhere universally. We tried with UART data in the past (when your capture was not available yet, notice that the maintainer and other persons spent their time trying to reproduce the issue), and I just tried again with your SPI data. The issue that you report here does not reproduce for me. The above communication suggests neither does it for the Pulseview maintainer. So if it's not the data and not "the software" (in the general sense), it must be something local or the platform which triggers the unexpected behaviour. ... 359682029-359682453 SPI: MOSI data: 1DE 360482597-360483011 SPI: MOSI data: 1D5 361283042-361283456 SPI: MOSI data: 1CF 362083552-362083966 SPI: MOSI data: 1E2 362883999-362884413 SPI: MOSI data: 1DA 363684483-363684908 SPI: MOSI data: 1E3 364484970-364485394 SPI: MOSI data: 1EE 365285439-365285863 SPI: MOSI data: 22B 366085907-366086321 SPI: MOSI data: 1E5 366886418-366886832 SPI: MOSI data: 1EC 367686844-367687258 SPI: MOSI data: 1D0 368487321-368487735 SPI: MOSI data: 1F0 369287801-369288225 SPI: MOSI data: 1EC 370088314-370088728 SPI: MOSI data: 1EB 370888760-370889174 SPI: MOSI data: 1F4 371689293-371689707 SPI: MOSI data: 1F1 372489756-372490170 SPI: MOSI data: 1ED 373290254-373290668 SPI: MOSI data: 1F1 374090697-374091111 SPI: MOSI data: 206 374891209-374891623 SPI: MOSI data: 1FE ... Does the 9bit UART example data of the sigrok-dumps repo work for you? This file also contains patterns \d+E\d, and work as expected here.
Closing the report due to user inactivity and the inability to reproduce at several sites in several attempts. Feel free to re-open when input data or instructions become available which allow to reproduce the issue.