Created attachment 785 [details] The above cycle is being shown as 1 cycle instead of 1.5 cycle I was producing a 500Hz frequency using a raspberry pi pico and analyzing it on pulseview using FT232H module. I noticed that 1.5 cycle is being counted as 1 cycle. I've attached one image. The above cycle is equivalent to the signal which I'm producing that is 500Hz with 50% duty cycle. The lower image is being counted as 750Hz which doesn't make sense. Now due to this, It actually helped to me to figure out why the UART signal which I was trying to decode gave me garbage values. This bug is confirmed to reproduce on Windows and Arch linux-lts 5.15.89-1
Your bug report is not clear to me - what feature of sigrok or Pulseview is showing that as "1 cycle"? Is it some protocol decoder? How have you determined that this is related to the specific hardware interface?
We can use cursors to determine the frequency of a duty cycle in pulseview, right? So, I was testing my FT232H in pulseview. I was generating a signal source of 500Hz with 50% duty cycle using raspberry pi pico and analyzing with FT232H module using ftdi-la drivers. Apparently, in pulseview, using cursors to check the frequency of one cycle was being shown as 750Hz. So, I think that something is wrong with ftdi-la drivers. Maybe this has something todo with timers. Dues to this, UART signal are also giving garbage values.
Thanks for the extra information. Can you add also: * What samplerate are you using? * Upload the .sr file of the data with the problem.
Created attachment 786 [details] 500hz square wave captured using FT232H
I have uploaded the .sr file in which the FT232H has captured the 500Hz square wave signal generated by raspsberry pi pico at the samplerate of 10Khz. Anything lower than 10Khz (i.e 3.6Khz and 5Khz) produced more inaccurate results. Going higher is same as the 10khz.
Yeah, it seems like the capture samplerate is wrong for some reason. There is a not-yet-merged pull request here that has large updates to the ftdi-la driver: https://github.com/sigrokproject/libsigrok/pull/145 It might be worth a try if you can get it built.