sigrok-devel — sigrok development mailing list.

Re: [sigrok-devel] QuantAsylum QA100 - adding support

[Bert V. <be...@bi...>]

On 10/31/25 18:51, John wrote:
> Thank you. That at least clarifies the position on any starting code.
> 
> The chips on the PCB have their numbers filed off, although I suspected
> one of them might be an FPGA. Not knowing the part numbers is not at all
> helpful. I was going to see whether it can be probed via JTAG or an
> on-board UART or something but haven't got around to that yet. It a
> shame there is no Linux software for it. I got rather mis-lead by their
> Github repository thinking that there was O/S software available only to
> later find just an empty tar.gz file.
> 
> This instrument initially comes up on USB as :
> 
>       Bus 002 Device 089: ID 16c0:4e21 Van Ooijen Technische Informatica
> 
> But subsequently on Windows that changes to:
> 
>       QuantAsylum QA100 Oscilloscope
> 
> According to what I have been able to find online, the VID is shared for
> "hobbyist or custom projects" and the device ID would be defined by the
> creator of the device. There is apparently no generic driver. I have
> already discovered that getting information from the developer is
> impossible. There is a suggestion that it might be possible to access
> the device with libusb, but I have not looked into that yet.

That just means that the fx2 initially loaded some firmware from an 
on-board flash chip. This is certainly the case, as without firmware the 
FX2 announces itself with VID/PID 04b4:8613. The VID/PID you saw is also 
documented here: https://sigrok.org/wiki/QuantAsylum_QA100/Info

Did that VID/PID change on windows? If so, that means something on your 
windows computer (a QuantAsylum driver) uploaded firmware to it.

If you capture that upload, you have the FX2's firmware. If you capture 
the QuantAsylum software on Windows talking to that firmware, you have 
the protocol.

> But even if possible, it would be difficult to go further without
> any information about the protocol. Not a good start and the odds of 
> getting anywhere seem a bit steep.
Oh no, that's not at all a problem. Many (most?) sigrok drivers were 
written only after reverse engineering the protocol. It's the most fun 
part of writing a driver, and not that hard.


-- 
Bert Vermeulen
be...@bi...

Re: [sigrok-devel] PR Review crunch

[Ladislav L. <kra...@kr...>]

Hi!

> thanks a lot for doing that. Although we should be asking the
> submitters in the future, it might even serve a "still interested?"
> check.

True, and this is definitely the way to go moving forward. In this case,
I took it on myself, since the project kind of owes a small favor to all
the developers that posted many months or event years ago. Some of them
may not even be around. The cases were also so small it wasn't worth the
back and forth.


> 
> > https://github.com/sigrokproject/libsigrok/compare/master...Krakonos:libsigrok:master
> 
> I will try take a closer look during the weekend. One improvement could
> be adding "Closes: https://github.com/sigrokproject/libsigrok/pull/
> <XYZ>" lines into the commit messages, so there is a cross reference to
> the original submission that can contain useful technical discussion,
> etc. But again, thanks for you work so far, Ladislav :-)

I considered this, ended up not doing it since some PRs are in multiple
commits, so there is not a single place to put it (since the project
does prefer rebased fast-forward merges instead of merge commits). I
could put it into the last one, or all of them. We can give it some
thought and decide later on how to proceed there.

> 
> 		Dan
>  
> > @Soeren, 
> > 
> > I think you can pull as is into mainline and close all of the
> > abovementioned PRs. A few caveats that I don't know how to solve with
> > this workflow:
> > 
> > * Commit hashes have changed, just because of the rebase.
> > * I have edited some commit messages to adhere to the commit message
> >   style (I hope I did a passable job there).
> > * In the vc96 case, I've also squashed the commits as there was a lot of
> >   incremental work.
> > * In all cases I've kept the author & date information in
> >   the commits.
> > 
> > ... However, I feel for those small PRs it's more efficient way to do
> > it, as the alternative would mean asking for tiny changes & rebases from
> > each author independently.
> > 
> > Let me know how this works for you and how we should continue moving
> > forward. I'm happy to hear feedback on improving the process for
> > everybody, so don't hesitate to speak up!
> > 
> > Next, I'll be moving into the I2S decoders by @endolith and will likely
> > do the same there unless there are objections.
> > 
> > Best regards,
> > Ladislav
> > 
> > 
> > -- 
> > S pozdravem Ladislav "Krakonoš" Láska                http://www.krakonos.org/
> > 
> > 
> > _______________________________________________
> > sigrok-devel mailing list
> > sig...@li...
> > https://lists.sourceforge.net/lists/listinfo/sigrok-devel
> 
> 
> _______________________________________________
> sigrok-devel mailing list
> sig...@li...
> https://lists.sourceforge.net/lists/listinfo/sigrok-devel

-- 
S pozdravem Ladislav "Krakonoš" Láska                http://www.krakonos.org/

Re: [sigrok-devel] QuantAsylum QA100 - adding support

[Philipp K. K. <pk...@sp...>]

Am 31.10.25 um 15:15 schrieb John via sigrok-devel:
> I see that each device has a .ihx, .lk, .map, .mem as well as other 
> various text and source files. What tools were used to create or extract 
> these?
The .ihx would be compiled firmware in Intel Hex format. The .lk, .map 
and .mem are some extra information from the compiler/linker that might 
be helpful while debugging (in particular when running out of memory on 
the device).
All those would be generated by the Small Device C Compiler (SDCC), the 
only free compiler targeting the MCS-51 architecture of the µC in the FX2).

Philipp
(sigrok user, SDCC maintainer)

Re: [sigrok-devel] QuantAsylum QA100 - adding support

[Bert V. <be...@bi...>]

On 10/31/25 15:15, John via sigrok-devel wrote:
> I acquired this a while back and noticed that it was listed under the
> "Work in progress" category.
> 
> It seems to be based on an fx2lafw device. The software directory for
> the oscilloscope/LA contains what looks like a firmware file. I notice
> that sigrok-firmware-fx2lafw contains drivers for a number of devices
> for that are based on this hadrware. Is there are documented procedure
> or notes anywhere for adding new devices to the sigrok fx2lafw firmware?
> 
> I see that each device has a .ihx, .lk, .map, .mem as well as other
> various text and source files. What tools were used to create or extract
> these?
> 
> Is there any prior work already existing anywhere for this bit of kit?

That's my unit in the pictures on the wiki. Unfortunately I never did 
get around to working on it, so no, there's no code to get you started.

As for sigrok-firmware-fx2lafw, that's firmware for the FX2 clone boards 
i.e. that use the FX2 to sample and stream directly to the host over 
USB. It builds versions for different boards, but they're all minor 
variations on the same thing.

The QuantAsylum QA100 is very different in architecture: it has an FPGA 
and RAM on board, meaning it likely uses the FPGA+RAM to store samples 
before forwarding them to the host via USB (I assume via the FX2).

So while fx2lafw can serve as a springboard to write custom firmware for 
this scenario, you'll likely end up rewriting most of it. The board may 
also need FPGA firmware uploaded, unless it's already on board.

So writing a driver for this is a big job. The good news is this is not 
a unique architecture: there's other gear very similar, even using an 
FX2 I believe.


-- 
Bert Vermeulen
be...@bi...

[sigrok-devel] QuantAsylum QA100 - adding support

[John <si...@gm...>]

I acquired this a while back and noticed that it was listed under the 
"Work in progress" category.

It seems to be based on an fx2lafw device. The software directory for 
the oscilloscope/LA contains what looks like a firmware file. I notice 
that sigrok-firmware-fx2lafw contains drivers for a number of devices 
for that are based on this hadrware. Is there are documented procedure 
or notes anywhere for adding new devices to the sigrok fx2lafw firmware?

I see that each device has a .ihx, .lk, .map, .mem as well as other 
various text and source files. What tools were used to create or extract 
these?

Is there any prior work already existing anywhere for this bit of kit?

I would appreciate any information please.

Re: [sigrok-devel] PR Review crunch

[Dan H. <da...@da...>]

On Fri, 31 Oct 2025 14:34:10 +0100
Ladislav Laska <kra...@kr...> wrote:

> Hello All,
> 
> I've processed a few PRs on github:
> 
> * raspberrypi-pico: Add link to firmware repo #268
> * support SWIG 4.2 and later #253
> * Fix Deprecations in libzip and libcheck APIs #265
> * hardware/beaglelogic: Don't include incorrect header <sys/errno.h> #267
> * README.devices: Fix typo #264
> * configure: Fix bashism in _SR_DRIVER #263
> * Update vc96.c #234
> 
> To adhere to the commit style and make it as easy as possible to pull
> into mainline, I've prepared "integration branch":

thanks a lot for doing that. Although we should be asking the
submitters in the future, it might even serve a "still interested?"
check.

> https://github.com/sigrokproject/libsigrok/compare/master...Krakonos:libsigrok:master

I will try take a closer look during the weekend. One improvement could
be adding "Closes: https://github.com/sigrokproject/libsigrok/pull/
<XYZ>" lines into the commit messages, so there is a cross reference to
the original submission that can contain useful technical discussion,
etc. But again, thanks for you work so far, Ladislav :-)


		Dan
 
> @Soeren, 
> 
> I think you can pull as is into mainline and close all of the
> abovementioned PRs. A few caveats that I don't know how to solve with
> this workflow:
> 
> * Commit hashes have changed, just because of the rebase.
> * I have edited some commit messages to adhere to the commit message
>   style (I hope I did a passable job there).
> * In the vc96 case, I've also squashed the commits as there was a lot of
>   incremental work.
> * In all cases I've kept the author & date information in
>   the commits.
> 
> ... However, I feel for those small PRs it's more efficient way to do
> it, as the alternative would mean asking for tiny changes & rebases from
> each author independently.
> 
> Let me know how this works for you and how we should continue moving
> forward. I'm happy to hear feedback on improving the process for
> everybody, so don't hesitate to speak up!
> 
> Next, I'll be moving into the I2S decoders by @endolith and will likely
> do the same there unless there are objections.
> 
> Best regards,
> Ladislav
> 
> 
> -- 
> S pozdravem Ladislav "Krakonoš" Láska                http://www.krakonos.org/
> 
> 
> _______________________________________________
> sigrok-devel mailing list
> sig...@li...
> https://lists.sourceforge.net/lists/listinfo/sigrok-devel

Re: [sigrok-devel] PR Review crunch

[Ladislav L. <kra...@kr...>]

Hello All,

I've processed a few PRs on github:

* raspberrypi-pico: Add link to firmware repo #268
* support SWIG 4.2 and later #253
* Fix Deprecations in libzip and libcheck APIs #265
* hardware/beaglelogic: Don't include incorrect header <sys/errno.h> #267
* README.devices: Fix typo #264
* configure: Fix bashism in _SR_DRIVER #263
* Update vc96.c #234

To adhere to the commit style and make it as easy as possible to pull
into mainline, I've prepared "integration branch":

https://github.com/sigrokproject/libsigrok/compare/master...Krakonos:libsigrok:master

@Soeren, 

I think you can pull as is into mainline and close all of the
abovementioned PRs. A few caveats that I don't know how to solve with
this workflow:

* Commit hashes have changed, just because of the rebase.
* I have edited some commit messages to adhere to the commit message
  style (I hope I did a passable job there).
* In the vc96 case, I've also squashed the commits as there was a lot of
  incremental work.
* In all cases I've kept the author & date information in
  the commits.

... However, I feel for those small PRs it's more efficient way to do
it, as the alternative would mean asking for tiny changes & rebases from
each author independently.

Let me know how this works for you and how we should continue moving
forward. I'm happy to hear feedback on improving the process for
everybody, so don't hesitate to speak up!

Next, I'll be moving into the I2S decoders by @endolith and will likely
do the same there unless there are objections.

Best regards,
Ladislav


-- 
S pozdravem Ladislav "Krakonoš" Láska                http://www.krakonos.org/

Re: [sigrok-devel] PR Review crunch

[Ladislav L. <kra...@kr...>]

Hi!

thanks, I'm looking at the PR now. I have some reservations to this PR
-- specifically it changes some whitespaces around, but mainly the order
of if...else if statements regarding the units, making somewhat unclear
what actually changed there.

The worst part is -- the PR removes the call to parse_value and since
the function is static, I believe it is unreachable.

I think the PR needs a bit of testing. If the parse_value is somehow not
necessary, it needs to be removed. If it was a mistake, it should be
added. I would also suggest to add examples of the parsed string, and if
possibly the addition of some tests to the parsed values to make sure
the code works (there likely is not a good framework to do it though..).

Best regards,
Ladislav

On Fri, Oct 24, 2025 at 03:06:06PM +0200, ttnp--- via sigrok-devel wrote:
> Hi, 
> 
> harper23 wrote to me about PR #234 at 08.02.2024
> 
> ---------------------------------------------------------------
> Hello sigrok,
> 
> I propose to add the changes to the sigrok repository.
> I don't see any reason why this pull request should be rejected.
> 
> Best regards,
> Helge
> 
> On Fri, 2025-10-24 at 11:20 +0200, Ladislav Laska wrote:
> > Hi All,
> > 
> > Based on the conversation here, it seems everybody wants to keep the
> > project running, so let's make it happen.
> > 
> > I'd like to start a review crunch of the PRs on github, with the idea
> > the project could release a decent version, ideally by the end of this
> > year (we can think of it as a christmas gift to the community). Anybody
> > willing to help?
> > 
> > Please post here if:
> > 
> > 1. There is a PR you've already reviewed and believe it's ready for
> > merge.
> > 
> > 2. There is a PR you want to review & test to help out the project.
> > (this is to so we divide the work properly)
> > 
> > 3. Have special interest in some PR (fixes an issue you're facing, adds
> > support for hardware you have). I'll try to look into those if they are
> > within my skill set (or somebody else can pick them up).
> > 
> > ... or if you want to help in any other way.
> > 
> > 
> > In the first pass, I plan to look at each PR, process what I can test
> > without hardware (there are some general library and compatibility
> > fixes). I'll then check if some of the PRs match hardware I have and can
> > be easily tested. My main interest is to get my LA DSLogic U3Pro16 up
> > and running in mainline sigrok, but I also have some Siglent and Rigol
> > gear at home, work and friends.
> > 
> > Best regards,
> > Ladislav
> > 
> > 
> > _______________________________________________
> > sigrok-devel mailing list
> > sig...@li...
> > https://lists.sourceforge.net/lists/listinfo/sigrok-devel
> 
> 
> 
> _______________________________________________
> sigrok-devel mailing list
> sig...@li...
> https://lists.sourceforge.net/lists/listinfo/sigrok-devel

Re: [sigrok-devel] PR Review crunch

[Ladislav L. <kra...@kr...>]

Hi!

This is definitely true, but overall I'm actually surprised by the
quality of some of the PRs, but also on the community review posted.

In many cases, the PRs are small enough or self-contained enough so it
would be OK to squash the commits before merge. Especially when adding a
completely new driver, I frequently find it's easier to just check out
the code and go through it all, unless the original developer did a
_really_ good job splitting the history for easy merging. This is
relatively common in the linux kernel community and is really nice to
see.

Regardless, I think it's fair to ask the contributor to rework the code
according to the standards - and if he doesn't, somebody else could
build on top of those changes (crediting the original author).

In simple cases, the project owner can usually modify the PR as well as
the author, and can perform some simple changes. I've done this multiple
times if it's a small thing like poor formatting -- in that case it's
easier to just fix it than to explain the issue.


In any case, it _should_ be written down and not ignored.

Best regards,
Ladislav

On Fri, Oct 24, 2025 at 06:19:07PM +0200, Dan Horák wrote:
> On Fri, 24 Oct 2025 11:20:35 +0200
> Ladislav Laska <kra...@kr...> wrote:
> 
> > Hi All,
> > 
> > Based on the conversation here, it seems everybody wants to keep the
> > project running, so let's make it happen.
> > 
> > I'd like to start a review crunch of the PRs on github, with the idea
> > the project could release a decent version, ideally by the end of this
> > year (we can think of it as a christmas gift to the community). Anybody
> > willing to help?
> > 
> > Please post here if:
> > 
> > 1. There is a PR you've already reviewed and believe it's ready for
> > merge.
> > 
> > 2. There is a PR you want to review & test to help out the project.
> > (this is to so we divide the work properly)
> > 
> > 3. Have special interest in some PR (fixes an issue you're facing, adds
> > support for hardware you have). I'll try to look into those if they are
> > within my skill set (or somebody else can pick them up).
> > 
> > ... or if you want to help in any other way.
> 
> one issue I see with many projects is that PRs are not following the
> project's standards (doesn't have to be written down, just follow the
> example) for writing commit messages and splitting the changes into
> individual commits. Which makes it difficult to follow the development
> in the mid/long term, especially when multiple developers and
> maintainers should be involved. It also affects the willingness to
> review other people's PRs/code.
> 
> 
> 		Dan
> 
> 
> _______________________________________________
> sigrok-devel mailing list
> sig...@li...
> https://lists.sourceforge.net/lists/listinfo/sigrok-devel

Re: [sigrok-devel] PR Review crunch

[Dan H. <da...@da...>]

On Fri, 24 Oct 2025 11:20:35 +0200
Ladislav Laska <kra...@kr...> wrote:

> Hi All,
> 
> Based on the conversation here, it seems everybody wants to keep the
> project running, so let's make it happen.
> 
> I'd like to start a review crunch of the PRs on github, with the idea
> the project could release a decent version, ideally by the end of this
> year (we can think of it as a christmas gift to the community). Anybody
> willing to help?
> 
> Please post here if:
> 
> 1. There is a PR you've already reviewed and believe it's ready for
> merge.
> 
> 2. There is a PR you want to review & test to help out the project.
> (this is to so we divide the work properly)
> 
> 3. Have special interest in some PR (fixes an issue you're facing, adds
> support for hardware you have). I'll try to look into those if they are
> within my skill set (or somebody else can pick them up).
> 
> ... or if you want to help in any other way.

one issue I see with many projects is that PRs are not following the
project's standards (doesn't have to be written down, just follow the
example) for writing commit messages and splitting the changes into
individual commits. Which makes it difficult to follow the development
in the mid/long term, especially when multiple developers and
maintainers should be involved. It also affects the willingness to
review other people's PRs/code.


		Dan

Re: [sigrok-devel] List configuration breaks SPF and DKIM

[Paul F. <fer...@gm...>]

Hi,

On Fri, Oct 24, 2025 at 12:39:39PM +0300, Vesa-Pekka Palmu wrote:
> This list follows the old best-practices of mailing lists, where the list
> server will resend all the messages to subscribers with the original
> author in the From: -field and setting reply-to address to the list.
> 
> Previously this has worked fine, but since SPF, DKIM and DMARC rules were
> implemented this practice now triggers email-forgery protections. Altering
> the message contents at all breaks DKIM signatures and using addresses in
> the from -field that the list-server hasn't been allowed to will break
> SPF.
> 
> The best work-around is to configure the list to put the original authors
> name in the from -field along with the lists own address instead of
> forging the sender information

FWIW, for OpenOCD the issue was resolved by creating a support ticket
with SF.net with the following contents:

"Hello,

For the OpenOCD project mailing list I'm trying to follow best
practicies as recommended by
[2]https://seanthegeek.net/459/demystifying-dmarc/ . I want all
messages to be sent as is, without any additions or munging, and that
way they won't be failing DKIM test and so DMARC shouldn't be a
concern.  However, the server config doesn't allow me to set
dmarc_moderation_action to Accept with "Error: dmarc_moderation_action
must be >= the configured default value".

Please consider allowing list admins to do the right thing. Thank you.
"

their (eventual) response was

"
Hello,

Our team set all your project's lists to "Accept" like you wanted.
The only thing to keep in mind is not to update the mailman settings
on that
page.
Bacause it it will change back to it's previous configuration.

Sincerely,
SourceForge Support
"

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...

Re: [sigrok-devel] PR Review crunch

[<tt...@ma...>]

Hi, 

harper23 wrote to me about PR #234 at 08.02.2024

---------------------------------------------------------------
Hello sigrok,

I propose to add the changes to the sigrok repository.
I don't see any reason why this pull request should be rejected.

Best regards,
Helge

On Fri, 2025-10-24 at 11:20 +0200, Ladislav Laska wrote:
> Hi All,
> 
> Based on the conversation here, it seems everybody wants to keep the
> project running, so let's make it happen.
> 
> I'd like to start a review crunch of the PRs on github, with the idea
> the project could release a decent version, ideally by the end of this
> year (we can think of it as a christmas gift to the community). Anybody
> willing to help?
> 
> Please post here if:
> 
> 1. There is a PR you've already reviewed and believe it's ready for
> merge.
> 
> 2. There is a PR you want to review & test to help out the project.
> (this is to so we divide the work properly)
> 
> 3. Have special interest in some PR (fixes an issue you're facing, adds
> support for hardware you have). I'll try to look into those if they are
> within my skill set (or somebody else can pick them up).
> 
> ... or if you want to help in any other way.
> 
> 
> In the first pass, I plan to look at each PR, process what I can test
> without hardware (there are some general library and compatibility
> fixes). I'll then check if some of the PRs match hardware I have and can
> be easily tested. My main interest is to get my LA DSLogic U3Pro16 up
> and running in mainline sigrok, but I also have some Siglent and Rigol
> gear at home, work and friends.
> 
> Best regards,
> Ladislav
> 
> 
> _______________________________________________
> sigrok-devel mailing list
> sig...@li...
> https://lists.sourceforge.net/lists/listinfo/sigrok-devel

Re: [sigrok-devel] PR Review crunch

[<tt...@ma...>]

Hi,

harper23 wrote to me about PR #234 at 08.02.2024

---------------------------------------------------------------
Hello sigrok,

I propose to add the changes to the sigrok repository.
I don't see any reason why this pull request should be rejected.

Best regards,
Helge

On Fri, 2025-10-24 at 11:20 +0200, Ladislav Laska wrote:
> Hi All,
>
> Based on the conversation here, it seems everybody wants to keep the
> project running, so let's make it happen.
>
> I'd like to start a review crunch of the PRs on github, with the idea
> the project could release a decent version, ideally by the end of this
> year (we can think of it as a christmas gift to the community). Anybody
> willing to help?
>
> Please post here if:
>
> 1. There is a PR you've already reviewed and believe it's ready for
> merge.

Re: [sigrok-devel] USB3 logic analyzer with FT601

[Ladislav L. <kra...@kr...>]

Hi!

This is very interesting information.

On Sun, Oct 19, 2025 at 02:15:30PM +0200, Embedded Systems Engineering wrote:
> Hi Everyone,
> 
> thank you for all your feedback. I did some more research, datasheet reading
> and calculations to answer everything properly. While doing this I
> oscillated back and forth between possible and not possible, now I'm
> convinced that it will work :)
> 
> ## Concept/Idea
> The idea would be to use a FT601 with some glue/clock-logic supporting only
> USB3 for data capturing.
> 
> Important is to use USB3 in bulk transfer and that the FT601 is the only
> USB3 device on the bus.

For me, this is a significant limiting factor, especially since the
topology is not necessarily clear on what is the bus. I'm not 100% sure
about USB3 architecture, but in USB2 terms this should rather be "the
only USB3 device on the root hub", which is possibly difficult to
achieve due to internal architecture of PCs/laptops.

> The datasheet of the FT601 claims 100 MB continues data stream and 400 MB in
> burst with USB3 mode, so these settings would be an possible:
> - 8ch @ 100 MHz: 1 Byte x 100 MHz = 95.36 MB/s or
> - 16ch @ 50 MHz: 2 Byte x 50 MHz = 95.36 MB/s or
> - 32ch @ 25 MHz: 4 Byte x 25 MHz = 95.36 MB/s
> 
> The FT601 has a 16kB (16384 bytes) FIFO.
> Sampling 8 channel with 100 MHz would mean 1 byte per 10ns.
> 16384 bytes x 10 ns = 163.84µs
> So the FIFO could hold data for 163.84µs.

Meaning any jitter past this time would be a problem.
> 
> ## USB Timing
> USB1 and USB2 are electrically based on one bidirectional differential pair,
> meaning the Host or the Device can send data, not both together. In practice
> the host polls the device every (micro)frame and that's the fines time grid,
> the device can send data back to the host.
> 
> USB1 frame: 1ms
> USB2 micro-frame: 125µs
> 
> It might already work with USB2 since the buffer can data for 164µs and the
> USB2 timing grid is 125µs. But its highly unlikely that data can be send on
> every micro-frame with USB bulk or interrupt transfer.
> 
> USB3 uses a differential lane, meaning one unidirectional differential pair
> for Transmit and one for Receive. Host and device can send data
> simultaneously. It also uses 125 µs micro frames for communications, but
> uses a credit based system, meaning that the device is allowed to transmit a
> certain amount of data without further permission.
> 
> 1 credit = 1 packet (1024 byte)
> 
> Up to 256 credits per endpoint are possible; meaning 256kB without further
> permission. Every transmission decreases the credit count, while every micro
> frame the Host will update the credits. In practice 8-16 credits are
> typical.
> 
> USB3 Bulk transfer can occupy the entire micro frame bandwidth as long as
> the host grants enough credits.
> 
> USB3 max data rate: 5Gb/s x 8/10 => 500 MB/s
> USB3 max. data per micro frame: 600 MB/s * 125µs = 62.5 kB
> FIFO data per micro frame:12.5 kB
> 16 USB3 credits would already work.
> 
> With this mechanism the device can send data to the host continuously,
> resulting in a stream-like h.
> 
> Please let me know if you find any mistakes in my calculations.
> 
> ## open questions
> Can anyone answer or help with those questions:
> 
> 1. How many credits does the FT601 get from the USB Host and can those be
> change within the driver?

The driver uses libusb and I was unable to find a way to change the
credit allocation. TBH, I did not know about the exact mechanism until
I read your email. USB2 has been plenty enough for the stuff I usually
do.

> 2. Could someone check the USB descriptors of the FT601 with "lsusb -v" on a
> linux machine and share the output?
> 3. Is it possible to change the settings/mode of the FT601 with Lambda
> Concept driver?

I don't think so, but I might be wrong. I tried to dig into this and I
can't find credits mentioned in the lambda driver, or in the linux
kernel -- with the exception of USB3 tunneling over TB/USB4. This leads
me to believe this is managed in the USB3 silicon. Or it can just be
named something I'm not expected, not an expert here.

However, this forced me to look into the lambda concept driver and I
realized it's not a libusb driver (as I expected it would be), but
rather a linux kernel driver. This means it would not be possible to use
it on windows/osx, and would be quite difficult to ship it with sigrok.
(while it likely also means it would perform well)

> 4. Which FT601 board are you guys using? Anyone using the evaluation board
> UMFT60x?
> 


Best regards,
Ladislav

Re: [sigrok-devel] USB3 logic analyzer with FT601

[Ladislav L. <kra...@kr...>]

Hi!

I love it. And I want one. Or two. And the HydraUSB3. Excuse me, I think
I need to go and order some PCBs :-)

ECP5 is the route I was thinking to suggest to to take due to the
opensource support. I don't know much more about FPGAs, it's been a long
time since in dabbled in them.

Cheers,
Ladislav

On Sun, Oct 19, 2025 at 08:14:04PM +0000, Yann Sionneau wrote:
> Hi sigrok folks, 
> 
> Since we're talking about USB 3 Logic Analyzers, I take this opportunity to say a few words about SucréLA (name is a (bad) pun based on French pronunciation of Saleae ^^) :)
> Those on the #sigrok IRC channel surely already know about it since there have been many conversations about it already.
> I am working since a few months (actually a few years!) on a USB 3.0 logic analyzer.
> 
> It's interesting (I hope!) because of a few points:
> * USB 3.0 (5 Gbps)
> * open source software (mcu fw, libsigrok driver)
> * open source gateware (FPGA design)
> * Reproducible with open source tools (gcc for the software, Yosys+NextPNR for the FPGA gateware since I am using Lattice ECP5 which is one of the best supported FPGA by the open source toolchain)
> * open source hardware (all kicad files: schematics + board layout + BOM, you can modify it and produce it yourself)
> * "interesting" speeds (not just a basic toy project): 100 Msps on 16 probes, 200 Msps on 8 probes, 400 Msps on 4 probes, and 700 Msps on 1 or 2 probes.
> * FPGA design is not "from scratch/custom", I am using LiteX and litescope as bases, which now are standards in the open FPGA world, it makes it open source friendly because it's easy to understand and modify (modular).
> * one of the most important feature I like when using an LA: "infinite" streaming capture, not just filling an onboard "buffer".
> 
> 
> 1st prototype has been made which is not fully functional (it was just a PoC with dupont wire to connect together a HydraUSB3 and an OrangeCrab FPGA board).
> 2nd prototype where a board was made which hosts an FPGA and is a "hat" board to plug on top of a HydraUSB3 board.
> 
> Bringup of the 2nd prototype is done and I am working on the next board prototype which will be a single board with both the FPGA and the USB 3 mcu (CH569, risc-v).
> 
> Everything is on gitlab over there: https://gitlab.com/yannsionneau/SucreLA/
> 
> Don't hesitate to come on the #sigrok IRC channel to have a chat about it :)
> I'm still not sure about how to do some things like having dynamic input voltage selection for instance.
> 
> Cheers!
> 
> Yann Sionneau
> 
> October 15, 2025 at 12:52 PM, "Daniel Tzschentke" <hi...@es... mailto:hi...@es...?to=%22Daniel%20Tzschentke%22%20%3Chi%40ese-labs.de%3E > wrote:
> 
> 
> > 
> > Hi Everyone,
> > 
> > Thanks a lot for Sigrok!
> > 
> > Recently I came across this USB3 (super speed) chip: FT601 from FTDI https://ftdichip.com/products/ft601q-b/
> > It's a 32 bit sync FIFO to USB3 bridge and intended for parallel camera interfaces.
> > 
> > My first thought was, that it should be pretty straight forward to build a 32 channel 100 MHz logic analyzer with it.
> > 
> > I was thinking of an open source/community logic analyzer made for Sigrok - schematic and pcb I know how to do, but I have no idea how to support the chip in Sigrok - would anyone be up for taking care of the Sigrok support?
> > 
> > I could send out some PCBs to developer from the first test batch but would also upload all the kicad files (sch, pcb, bom, gbr, ...) to a public github repo, so anyone could order PCBs.
> > 
> > What do you guys think?
> > 
> > Best,
> > Dan
> > 
> > _______________________________________________
> > sigrok-devel mailing list
> > sig...@li... mailto:sig...@li... 
> > https://lists.sourceforge.net/lists/listinfo/sigrok-devel
> >
> 
> 
> _______________________________________________
> sigrok-devel mailing list
> sig...@li...
> https://lists.sourceforge.net/lists/listinfo/sigrok-devel

-- 
S pozdravem Ladislav "Krakonoš" Láska                http://www.krakonos.org/

[sigrok-devel] List configuration breaks SPF and DKIM

[Vesa-Pekka P. <vp...@de...>]

This list follows the old best-practices of mailing lists, where the list
server will resend all the messages to subscribers with the original
author in the From: -field and setting reply-to address to the list.

Previously this has worked fine, but since SPF, DKIM and DMARC rules were
implemented this practice now triggers email-forgery protections. Altering
the message contents at all breaks DKIM signatures and using addresses in
the from -field that the list-server hasn't been allowed to will break
SPF.

The best work-around is to configure the list to put the original authors
name in the from -field along with the lists own address instead of
forging the sender information


-- 
This message may contain traces of Truth.

[sigrok-devel] PR Review crunch

[Ladislav L. <kra...@kr...>]

Hi All,

Based on the conversation here, it seems everybody wants to keep the
project running, so let's make it happen.

I'd like to start a review crunch of the PRs on github, with the idea
the project could release a decent version, ideally by the end of this
year (we can think of it as a christmas gift to the community). Anybody
willing to help?

Please post here if:

1. There is a PR you've already reviewed and believe it's ready for
merge.

2. There is a PR you want to review & test to help out the project.
(this is to so we divide the work properly)

3. Have special interest in some PR (fixes an issue you're facing, adds
support for hardware you have). I'll try to look into those if they are
within my skill set (or somebody else can pick them up).

... or if you want to help in any other way.


In the first pass, I plan to look at each PR, process what I can test
without hardware (there are some general library and compatibility
fixes). I'll then check if some of the PRs match hardware I have and can
be easily tested. My main interest is to get my LA DSLogic U3Pro16 up
and running in mainline sigrok, but I also have some Siglent and Rigol
gear at home, work and friends.

Best regards,
Ladislav

Re: [sigrok-devel] Sigrok future - community maintenance?

[Ladislav L. <kra...@kr...>]

Hi Soeren,

first of all, let me apologise for missing this email. While I've
seen parts of it quoted and was quite puzzled, I did not look into my
spam folder and did not see it in sourceforge (I have 0 idea how anybody
can find anything there these days). My mistake.

(The reason is got classified as spam is a failed SPF check on
your domain, I think you should look into that.)

Now, to the topic.

On Mon, Oct 13, 2025 at 11:03:36AM +0200, Soeren Apel wrote:
> Hi Ladislav,
> 
> I completely agree with your reasoning and conclusions. Historically, the
> sigrok project had a division of labor that mostly worked but I'm genuinely
> struggling to find a way that works for everyone (including me).

Nothing to be ashamed of, this happens, people change, interest changes,
life happens. I'm also struggling to find time for some of my projects that I
used to be very involved in.

> The two core issues for me are that libsigrok's architecture is
> fundamentally outdated and that it is *impossible* for me to review and
> merge changes to libsigrok device drivers. Why? Because I lack both the
> time to perform in-depth reviews and I lack the hardware to test changes
> against regressions.

That is understandable. Not having the devices is problematic,
especially if some of the code needs to be changed. However, I think
this boils down to having a community of people that have the hardware
and are willing to at least test.

Hardware that nobody has... might eventually stop working and be
deprecated from the project. As much as it hurts me to remove support
for anything, sometimes it's just the smart move.

> On the architecture side, it would make way more sense to spend time on
> rebuilding libsigrok so people can write device drivers in languages other
> than C - python or rust, for example. While logic analyzers likely need the
> performance, a lot of other drivers do not.

I actually think libsigrok does not need to be rebuilt. As I already
noted in the thread about the interface, it seems pretty thin, so it is
possibly a question of metadata and a loader and we can have rust folks
produce a binary that provides the entrypoint, is dlopen()-ed and
called. Virtually zero performance hit after the initial load. Similar
thing could be done for python (I can build a wrapper that runs python
in the init and tunnels all the function calls). Also virtually zero
overhead (well, except it'll be slow due to the analyzer running in
python).

TBH I don't see the need or the momentum to such a huge project like
this...

> That's why libsigrokflow was born to have a gstreamer-like data pipeline
> that is as flexible and powerful as can be. Unfortunately, we never got
> very far because it requires forking the gstreamer core library and
> modifying it to suit our needs - while Covid-19 hit soon after.

... And the libsigrokflow is an example of not having the momentum. I
didn't look into the details and can't say with a clean concience
whether the idea is good or not (there doesn't seem to be much code and
I did not find a design doc or similar in the flow repo). However, from
my professional experince it seems like a bad idea to fork gstreamer and
try to modify it. Maybe it's a simple library and it's OK, but my
experience with gstreamer is from the media world and it always was a
huge headache.

Overall, I think having a pluggable architecture would alleviate the
issue and would possibly allow to decouple the device drivers. The main
benefit there is the testing & development will primarily be done by
community maintainers that have the actual hardware. This would possibly
speed up the process and make it easier on the core libsigrok
maintainers. I'm not sure how much is left there in libsigrok though :-)

> So what's needed from my point of view?
> 
> - People who can perform PR reviews on drivers and give me a thumbs up or
> down on whether to merge or not.

Thanks. I'll work on some PR reviews in my spare time. I don't have a
huge amount, but I have some interests.

> - People who can help me prepare releases by summarizing the commit changes
> since the last release. I started making such a list for libsigrok but it
> just takes too much time I can't justify spending at the moment.

Does this happen on a wiki or separately? Let's work on it. I usually
take the whole `git log --oneline prev..this` and start editing it to
something legible by a non-developer.

> - People who look at the open PRs and let me know which PRs should be
> included in the upcoming releases and which can be omitted for now.

Let's do it. I'll start looking into the PRs. Additionally, some of the
PRs were reviewed by Bert (according to his email on 21st), I think we
should start there and merge those if possible, or try to remedy any
issues there.

> - Someone who is willing to spend some time with me to conceptualize a way
> forward in terms of gradual changes to the project architecture and
> document it on the wiki.

I'm in, though I don't know many details about the currenct
architecture, I have design enough systems to have a general idea what
to expect. Additionally, I really believe this needs to be a general
consensus of developers/contributors and should not be forced.

I'd also like to hear Bert's opinion on this, since he's spent
significantly more time thinking about these issues that I have.

Based on the emails I understand there seems to be a rift between
yourselves, however I'd suggest we put our differences aside and focus
on what's best for the project both short and long term.

I've made a mistake by pushing an idea I really wanted to see, just to
watch it die slowly due reasons I didn't anticipate (and that included
lack of anthusiasm from other developers).

> Individually, all these things can be done by myself, sure, but the amount
> of work is just too much when taking it all together since I need to focus
> on project infrastructure first.

True and I agree 100% here.

> In short: yes, I want sigrok to continue and be successful but it's way too
> much work for me to do it on my own. After the server crash earlier this
> year I kind of burned out and need to get back into things. Thanks for
> giving me a push by writing your message.

I love to hear it. No problem. Also, if you'd like, I can offer a help
with server hosting etc., possibly with by providing some space for
backups or contributing to the hosting fees.


Cheers,
Ladislav

[sigrok-devel] BISS examples for sigrok-dumps

[Marshal H. <ka...@gm...>]

Hi,

I have some BISS protocol examples over at
https://github.com/kamocat/sigrok-dumps
in the biss branch.

I’ve never sent a patch over email. Is that still the right way to do this?

Marshal Horn

Re: [sigrok-devel] Sigrok future - community maintenance?

[Bert V. <be...@bi...>]

(I am not subscribed to this list, sorry for messing up the threading)

Hi,

I'm the original founder and implementer of the sigrok project, back in 
2009. I have not been involved in a long time, though I still like to 
keep an eye on things, like this list.

It's been painful to see the sigrok project die over such a long time. 
When I felt I could no longer be maintainer, I did the honorable (and 
normal) thing: I passed the buck to my then co-maintainer, Uwe. When he 
could no longer be maintainer, he did the same, and chose Soeren as the 
new maintainer.

Soeren lost interest a long, long time ago, but did _not_ do the right 
thing and find a new maintainer. I've been hoping somebody would step in 
and either take over, or fork the project. As Ladislav said, it's an 
important piece of tooling for many people.

I feel I must correct a few things.

Soeren Apel wrote:
 > he two core issues for me are that libsigrok's architecture is
 > fundamentally outdated and that it is *impossible* for me to review
 > and merge changes to libsigrok device drivers.

You are wrong on both counts. The libsigrok architecture is great, as 
shown by the fact that it effortlessly supports hundreds of devices 
across tons of device types. The problem is rather that you don't 
understand it, by your own admission, and thus don't feel able to review 
code for it.

Not being able to review the code is no excuse: I've offered my help, 
and reviewed nearly every libsigrok PR on github, and held your hand 
through pushing many of them through. This was last year. I eventually 
stopped trying when you stopped responding to mails. One set of drivers 
I asked you *three* times to push, and you ignored it all.

 > On the architecture side, it would make way more sense to spend time
 > on rebuilding libsigrok so people can write device drivers in
 > languages other than C - python or rust, for example.

We've talked about this, and it simply isn't true. Writing a device 
driver is easy, and there's lots of examples and tooling to help. It's 
no coincidence that so many people have written drivers.

If you want to see more device drivers, all you have to do is *merge* 
the ones people have been submitting for years, not rewrite the 
foundation they're based on. The problem is you, not libsigrok.

 > That's why libsigrokflow was born to have a gstreamer-like data
 > pipeline that is as flexible and powerful as can be. Unfortunately,
 > we never got very far because

This was always a terrible, terrible idea, and I said so at the time. 
Not only is it not necessary, it's such an obvious case of second-system 
syndrome -- very much a utopian ideal of smashing together all notions 
of drivers, in/out modules etc into a language agnostic thing that would 
solve all of your problems. Predictably, it came to nothing. I can't 
*believe* you're still mentioning this failed idea SIX years after even 
the repo has been touched. Don't you think it's time to face facts?

 > - People who can perform PR reviews on drivers and give me a thumbs up
 > or down on whether to merge or not.

I did *exactly* that, and you stopped responding and merging.

- Someone who is willing to spend some time with me to conceptualize a
 > way forward in terms of gradual changes to the project architecture
 > and document it on the wiki.

I made several suggestions just last year, and you ignored them completely.

Soeren, you need to finally, after much too long, step down and give 
somebody else a chance to maintain the sigrok project. Your inaction 
over so many years is incredibly corrosive to community enthusiasm for 
the project, and has done a *lot* of damage. Please do the right thing now.

I hope somebody else will step up and offer to maintain, or co-maintain 
(ideally) the project, and that Soeren will honorably hand over the reins.

As for me, while I am unable to go back to being a maintainer, I remain 
willing to help where I can. I reviewed dozens of libsigrok PRs, and can 
do so again. If people step in, I'll be there to help with architecture, 
coding, reviewing, the wiki, and everything else that needs doing. I 
just don't wanna be the guy on top, is all.


-- 
Bert Vermeulen
be...@bi...

Re: [sigrok-devel] USB3 logic analyzer with FT601

[Yann S. <ya...@si...>]

Hi sigrok folks, 

Since we're talking about USB 3 Logic Analyzers, I take this opportunity to say a few words about SucréLA (name is a (bad) pun based on French pronunciation of Saleae ^^) :)
Those on the #sigrok IRC channel surely already know about it since there have been many conversations about it already.
I am working since a few months (actually a few years!) on a USB 3.0 logic analyzer.

It's interesting (I hope!) because of a few points:
* USB 3.0 (5 Gbps)
* open source software (mcu fw, libsigrok driver)
* open source gateware (FPGA design)
* Reproducible with open source tools (gcc for the software, Yosys+NextPNR for the FPGA gateware since I am using Lattice ECP5 which is one of the best supported FPGA by the open source toolchain)
* open source hardware (all kicad files: schematics + board layout + BOM, you can modify it and produce it yourself)
* "interesting" speeds (not just a basic toy project): 100 Msps on 16 probes, 200 Msps on 8 probes, 400 Msps on 4 probes, and 700 Msps on 1 or 2 probes.
* FPGA design is not "from scratch/custom", I am using LiteX and litescope as bases, which now are standards in the open FPGA world, it makes it open source friendly because it's easy to understand and modify (modular).
* one of the most important feature I like when using an LA: "infinite" streaming capture, not just filling an onboard "buffer".


1st prototype has been made which is not fully functional (it was just a PoC with dupont wire to connect together a HydraUSB3 and an OrangeCrab FPGA board).
2nd prototype where a board was made which hosts an FPGA and is a "hat" board to plug on top of a HydraUSB3 board.

Bringup of the 2nd prototype is done and I am working on the next board prototype which will be a single board with both the FPGA and the USB 3 mcu (CH569, risc-v).

Everything is on gitlab over there: https://gitlab.com/yannsionneau/SucreLA/

Don't hesitate to come on the #sigrok IRC channel to have a chat about it :)
I'm still not sure about how to do some things like having dynamic input voltage selection for instance.

Cheers!

Yann Sionneau

October 15, 2025 at 12:52 PM, "Daniel Tzschentke" <hi...@es... mailto:hi...@es...?to=%22Daniel%20Tzschentke%22%20%3Chi%40ese-labs.de%3E > wrote:


> 
> Hi Everyone,
> 
> Thanks a lot for Sigrok!
> 
> Recently I came across this USB3 (super speed) chip: FT601 from FTDI https://ftdichip.com/products/ft601q-b/
> It's a 32 bit sync FIFO to USB3 bridge and intended for parallel camera interfaces.
> 
> My first thought was, that it should be pretty straight forward to build a 32 channel 100 MHz logic analyzer with it.
> 
> I was thinking of an open source/community logic analyzer made for Sigrok - schematic and pcb I know how to do, but I have no idea how to support the chip in Sigrok - would anyone be up for taking care of the Sigrok support?
> 
> I could send out some PCBs to developer from the first test batch but would also upload all the kicad files (sch, pcb, bom, gbr, ...) to a public github repo, so anyone could order PCBs.
> 
> What do you guys think?
> 
> Best,
> Dan
> 
> _______________________________________________
> sigrok-devel mailing list
> sig...@li... mailto:sig...@li... 
> https://lists.sourceforge.net/lists/listinfo/sigrok-devel
>

Re: [sigrok-devel] USB3 logic analyzer with FT601

[Embedded S. E. <hi...@es...>]

Hi Everyone,

thank you for all your feedback. I did some more research, datasheet 
reading and calculations to answer everything properly. While doing this 
I oscillated back and forth between possible and not possible, now I'm 
convinced that it will work :)

## Concept/Idea
The idea would be to use a FT601 with some glue/clock-logic supporting 
only USB3 for data capturing.

Important is to use USB3 in bulk transfer and that the FT601 is the only 
USB3 device on the bus.

The datasheet of the FT601 claims 100 MB continues data stream and 400 
MB in burst with USB3 mode, so these settings would be an possible:
- 8ch @ 100 MHz: 1 Byte x 100 MHz = 95.36 MB/s or
- 16ch @ 50 MHz: 2 Byte x 50 MHz = 95.36 MB/s or
- 32ch @ 25 MHz: 4 Byte x 25 MHz = 95.36 MB/s

The FT601 has a 16kB (16384 bytes) FIFO.
Sampling 8 channel with 100 MHz would mean 1 byte per 10ns.
16384 bytes x 10 ns = 163.84µs
So the FIFO could hold data for 163.84µs.

## USB Timing
USB1 and USB2 are electrically based on one bidirectional differential 
pair, meaning the Host or the Device can send data, not both together. 
In practice the host polls the device every (micro)frame and that's the 
fines time grid, the device can send data back to the host.

USB1 frame: 1ms
USB2 micro-frame: 125µs

It might already work with USB2 since the buffer can data for 164µs and 
the USB2 timing grid is 125µs. But its highly unlikely that data can be 
send on every micro-frame with USB bulk or interrupt transfer.

USB3 uses a differential lane, meaning one unidirectional differential 
pair for Transmit and one for Receive. Host and device can send data 
simultaneously. It also uses 125 µs micro frames for communications, but 
uses a credit based system, meaning that the device is allowed to 
transmit a certain amount of data without further permission.

1 credit = 1 packet (1024 byte)

Up to 256 credits per endpoint are possible; meaning 256kB without 
further permission. Every transmission decreases the credit count, while 
every micro frame the Host will update the credits. In practice 8-16 
credits are typical.

USB3 Bulk transfer can occupy the entire micro frame bandwidth as long 
as the host grants enough credits.

USB3 max data rate: 5Gb/s x 8/10 => 500 MB/s
USB3 max. data per micro frame: 600 MB/s * 125µs = 62.5 kB
FIFO data per micro frame:12.5 kB
16 USB3 credits would already work.

With this mechanism the device can send data to the host continuously, 
resulting in a stream-like h.

Please let me know if you find any mistakes in my calculations.

## open questions
Can anyone answer or help with those questions:

1. How many credits does the FT601 get from the USB Host and can those 
be change within the driver?
2. Could someone check the USB descriptors of the FT601 with "lsusb -v" 
on a linux machine and share the output?
3. Is it possible to change the settings/mode of the FT601 with Lambda 
Concept driver?
4. Which FT601 board are you guys using? Anyone using the evaluation 
board UMFT60x?

Best,
Dan



On 10/16/25 23:41, Ivan Wick wrote:
> Hi Dan,
> I see on the Sigrok wiki that there has been some prior hardware 
> designed with the FT601: https://sigrok.org/wiki/CoLA
> This uses the FT601 for a host interface, and logic signals are read 
> by an FPGA which can also do multiplexing etc.
> But if I understood your idea correctly, it is to read logic signals 
> directly into the FT601 FIFOs without another chip, which is a 
> simpler, less expensive design.
>
> Anyway, there is a barrier to using the FT601 chip: "The CoLA does not 
> have integration into Sigrok and Pulseview. This is because the used 
> FT601 driver is from FTDI and is closed source. This is the reason 
> that prevents the software from being released under Sigrok compatible 
> licence."
>
> The closed source driver mentioned is D3xx: 
> https://ftdichip.com/drivers/d3xx-drivers/
> So we could probably get an FT601 device working "out-of-tree" using 
> the proprietary driver, but I couldn't find a free software library 
> (analogous to libftdi) to drive the FT601.
>
>
> On Wed, Oct 15, 2025 at 4:36 AM Daniel Tzschentke <hi...@es...> wrote:
>
>     Hi Everyone,
>
>     Thanks a lot for Sigrok!
>
>     Recently I came across this USB3 (super speed) chip: FT601 from FTDI
>     https://ftdichip.com/products/ft601q-b/
>     It's a 32 bit sync FIFO to USB3 bridge and intended for parallel
>     camera
>     interfaces.
>
>     My first thought was, that it should be pretty straight forward to
>     build
>     a 32 channel 100 MHz logic analyzer with it.
>
>     I was thinking of an open source/community logic analyzer made for
>     Sigrok - schematic and pcb I know how to do, but I have no idea
>     how to
>     support the chip in Sigrok - would anyone be up for taking care of
>     the
>     Sigrok support?
>
>     I could send out some PCBs to developer from the first test batch but
>     would also upload all the kicad files (sch, pcb, bom, gbr, ...) to a
>     public github repo, so anyone could order PCBs.
>
>     What do you guys think?
>
>     Best,
>     Dan
>
>
>
>     _______________________________________________
>     sigrok-devel mailing list
>     sig...@li...
>     https://lists.sourceforge.net/lists/listinfo/sigrok-devel
>

Re: [sigrok-devel] USB3 logic analyzer with FT601

[Lucien Anti-S. <luc...@ya...>]

 Hi,
1. Lambda Concept already did a FT60X open source Linux driver!  These guys rock! 
https://github.com/lambdaconcept/ft60x_driver
2. Yep
3. On top of that there is a handshake for the fifo that could be done in discreet logic but would probably be easier / cheaper in a pld or FPGA then you could include bigger buffer, timing data, etc etc.  if you're making a board with this chip then might as well add the cheap FPGA - I can highly recommend PCBWay, i have no affiliation but they're easy for quick proto and will populate boards at a cost too.
Timing diagram in the docs if you wanna check.  
DS_FT600Q-FT601Q-IC-Datasheet.pdf https://share.google/tLX2Dg7Rw1vNUnk0J
Good luck on your journey

    On Sunday, October 19, 2025 at 03:09:27 AM GMT+7, Ladislav Laska <kra...@kr...> wrote:  
 
 Hi All,

interesting, but I don't think it's a good idea:

1. I found no documentation on the USB protocol. This would have to be
reverse-engineered from the closed source D3XX driver.

2. There is a very limited buffer on the chip itself (a couple of kB).

3. The chip is meant to implement clocked protocols. It possibly
generates the clock itself, I did not find a way to configure a trigger
input to sample data. In addition, the data packet likely does not have
a timestamp. This means the data read would not have reliable timing
operation, making it useless for data analysis (a lot of jitter,
possibly clock drift or even missed data if the jitter is significantly
more than the period of a sampled signal).

Now, I'm not 100% sure as I didn't spend a whole lot of time on this,
but I strongly suggest somebody proves me wrong before much time/money is
spent on the hardware.

This likely is a reason why CoLA mentioned here pairs it with an FPGA --
the FPGA will provide stable sampling clock, buffer, compression - then
stream this data to the PC via the FT601 chip. This is completely fine,
since the timing is as good as the FPGA can provide (pretty good even if
it's a slow one) and even if in the worst case the buffer overflows, the
FPGA can at least recognize this and throw an error - better than hide
something.

Cheers,
Ladislav

On Thu, Oct 16, 2025 at 02:41:11PM -0700, Ivan Wick wrote:
> Hi Dan,
> I see on the Sigrok wiki that there has been some prior hardware designed
> with the FT601: https://sigrok.org/wiki/CoLA
> This uses the FT601 for a host interface, and logic signals are read by an
> FPGA which can also do multiplexing etc.
> But if I understood your idea correctly, it is to read logic signals
> directly into the FT601 FIFOs without another chip, which is a simpler,
> less expensive design.
> 
> Anyway, there is a barrier to using the FT601 chip: "The CoLA does not have
> integration into Sigrok and Pulseview. This is because the used FT601
> driver is from FTDI and is closed source. This is the reason that prevents
> the software from being released under Sigrok compatible licence."
> 
> The closed source driver mentioned is D3xx:
> https://ftdichip.com/drivers/d3xx-drivers/
> So we could probably get an FT601 device working "out-of-tree" using the
> proprietary driver, but I couldn't find a free software library (analogous
> to libftdi) to drive the FT601.
> 
> 
> On Wed, Oct 15, 2025 at 4:36 AM Daniel Tzschentke <hi...@es...> wrote:
> 
> > Hi Everyone,
> >
> > Thanks a lot for Sigrok!
> >
> > Recently I came across this USB3 (super speed) chip: FT601 from FTDI
> > https://ftdichip.com/products/ft601q-b/
> > It's a 32 bit sync FIFO to USB3 bridge and intended for parallel camera
> > interfaces.
> >
> > My first thought was, that it should be pretty straight forward to build
> > a 32 channel 100 MHz logic analyzer with it.
> >
> > I was thinking of an open source/community logic analyzer made for
> > Sigrok - schematic and pcb I know how to do, but I have no idea how to
> > support the chip in Sigrok - would anyone be up for taking care of the
> > Sigrok support?
> >
> > I could send out some PCBs to developer from the first test batch but
> > would also upload all the kicad files (sch, pcb, bom, gbr, ...) to a
> > public github repo, so anyone could order PCBs.
> >
> > What do you guys think?
> >
> > Best,
> > Dan
> >
> >
> >
> > _______________________________________________
> > sigrok-devel mailing list
> > sig...@li...
> > https://lists.sourceforge.net/lists/listinfo/sigrok-devel
> >


> _______________________________________________
> sigrok-devel mailing list
> sig...@li...
> https://lists.sourceforge.net/lists/listinfo/sigrok-devel


-- 
S pozdravem Ladislav "Krakonoš" Láska                http://www.krakonos.org/


_______________________________________________
sigrok-devel mailing list
sig...@li...
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
  

Re: [sigrok-devel] USB3 logic analyzer with FT601

[Ladislav L. <kra...@kr...>]

Hi All,

interesting, but I don't think it's a good idea:

1. I found no documentation on the USB protocol. This would have to be
reverse-engineered from the closed source D3XX driver.

2. There is a very limited buffer on the chip itself (a couple of kB).

3. The chip is meant to implement clocked protocols. It possibly
generates the clock itself, I did not find a way to configure a trigger
input to sample data. In addition, the data packet likely does not have
a timestamp. This means the data read would not have reliable timing
operation, making it useless for data analysis (a lot of jitter,
possibly clock drift or even missed data if the jitter is significantly
more than the period of a sampled signal).

Now, I'm not 100% sure as I didn't spend a whole lot of time on this,
but I strongly suggest somebody proves me wrong before much time/money is
spent on the hardware.

This likely is a reason why CoLA mentioned here pairs it with an FPGA --
the FPGA will provide stable sampling clock, buffer, compression - then
stream this data to the PC via the FT601 chip. This is completely fine,
since the timing is as good as the FPGA can provide (pretty good even if
it's a slow one) and even if in the worst case the buffer overflows, the
FPGA can at least recognize this and throw an error - better than hide
something.

Cheers,
Ladislav

On Thu, Oct 16, 2025 at 02:41:11PM -0700, Ivan Wick wrote:
> Hi Dan,
> I see on the Sigrok wiki that there has been some prior hardware designed
> with the FT601: https://sigrok.org/wiki/CoLA
> This uses the FT601 for a host interface, and logic signals are read by an
> FPGA which can also do multiplexing etc.
> But if I understood your idea correctly, it is to read logic signals
> directly into the FT601 FIFOs without another chip, which is a simpler,
> less expensive design.
> 
> Anyway, there is a barrier to using the FT601 chip: "The CoLA does not have
> integration into Sigrok and Pulseview. This is because the used FT601
> driver is from FTDI and is closed source. This is the reason that prevents
> the software from being released under Sigrok compatible licence."
> 
> The closed source driver mentioned is D3xx:
> https://ftdichip.com/drivers/d3xx-drivers/
> So we could probably get an FT601 device working "out-of-tree" using the
> proprietary driver, but I couldn't find a free software library (analogous
> to libftdi) to drive the FT601.
> 
> 
> On Wed, Oct 15, 2025 at 4:36 AM Daniel Tzschentke <hi...@es...> wrote:
> 
> > Hi Everyone,
> >
> > Thanks a lot for Sigrok!
> >
> > Recently I came across this USB3 (super speed) chip: FT601 from FTDI
> > https://ftdichip.com/products/ft601q-b/
> > It's a 32 bit sync FIFO to USB3 bridge and intended for parallel camera
> > interfaces.
> >
> > My first thought was, that it should be pretty straight forward to build
> > a 32 channel 100 MHz logic analyzer with it.
> >
> > I was thinking of an open source/community logic analyzer made for
> > Sigrok - schematic and pcb I know how to do, but I have no idea how to
> > support the chip in Sigrok - would anyone be up for taking care of the
> > Sigrok support?
> >
> > I could send out some PCBs to developer from the first test batch but
> > would also upload all the kicad files (sch, pcb, bom, gbr, ...) to a
> > public github repo, so anyone could order PCBs.
> >
> > What do you guys think?
> >
> > Best,
> > Dan
> >
> >
> >
> > _______________________________________________
> > sigrok-devel mailing list
> > sig...@li...
> > https://lists.sourceforge.net/lists/listinfo/sigrok-devel
> >


> _______________________________________________
> sigrok-devel mailing list
> sig...@li...
> https://lists.sourceforge.net/lists/listinfo/sigrok-devel


-- 
S pozdravem Ladislav "Krakonoš" Láska                http://www.krakonos.org/

Re: [sigrok-devel] USB3 logic analyzer with FT601

[Ivan W. <iva...@gm...>]

Hi Dan,
I see on the Sigrok wiki that there has been some prior hardware designed
with the FT601: https://sigrok.org/wiki/CoLA
This uses the FT601 for a host interface, and logic signals are read by an
FPGA which can also do multiplexing etc.
But if I understood your idea correctly, it is to read logic signals
directly into the FT601 FIFOs without another chip, which is a simpler,
less expensive design.

Anyway, there is a barrier to using the FT601 chip: "The CoLA does not have
integration into Sigrok and Pulseview. This is because the used FT601
driver is from FTDI and is closed source. This is the reason that prevents
the software from being released under Sigrok compatible licence."

The closed source driver mentioned is D3xx:
https://ftdichip.com/drivers/d3xx-drivers/
So we could probably get an FT601 device working "out-of-tree" using the
proprietary driver, but I couldn't find a free software library (analogous
to libftdi) to drive the FT601.


On Wed, Oct 15, 2025 at 4:36 AM Daniel Tzschentke <hi...@es...> wrote:

> Hi Everyone,
>
> Thanks a lot for Sigrok!
>
> Recently I came across this USB3 (super speed) chip: FT601 from FTDI
> https://ftdichip.com/products/ft601q-b/
> It's a 32 bit sync FIFO to USB3 bridge and intended for parallel camera
> interfaces.
>
> My first thought was, that it should be pretty straight forward to build
> a 32 channel 100 MHz logic analyzer with it.
>
> I was thinking of an open source/community logic analyzer made for
> Sigrok - schematic and pcb I know how to do, but I have no idea how to
> support the chip in Sigrok - would anyone be up for taking care of the
> Sigrok support?
>
> I could send out some PCBs to developer from the first test batch but
> would also upload all the kicad files (sch, pcb, bom, gbr, ...) to a
> public github repo, so anyone could order PCBs.
>
> What do you guys think?
>
> Best,
> Dan
>
>
>
> _______________________________________________
> sigrok-devel mailing list
> sig...@li...
> https://lists.sourceforge.net/lists/listinfo/sigrok-devel
>