Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better capture tool than sigrok-cli #8

Open
Stefan-Olt opened this issue Feb 10, 2024 · 6 comments
Open

Better capture tool than sigrok-cli #8

Stefan-Olt opened this issue Feb 10, 2024 · 6 comments
Assignees
Labels
Capture Software enhancement New feature or request help wanted Extra attention is needed

Comments

@Stefan-Olt
Copy link
Owner

sigrok-cli has a major issue: It is a single-threaded application. That means if only once the disk is not finished writing a data packet before the next one comes in the capture is ruined. The sigrok-cli manual says one should use a ramdisk, but this is currently not an option for the vast majority of users, as usual capture sizes are significantly larger than the RAM.
I think the easiest way is to write a minimalist replacement for sigrok-cli (we do not need all the stuff that is in it, like the decoders, signal display, special output formats), that will open the device using libsigrok in one thread and write the data in another thread having a fifo or a ringbuffer in between. We could even include the extraction routine from misrc_extract (if the PC is fast enough).

I would image something like this:

misrc_capture --buffer-size 4G -d cypress-fx3 -s 40m -r rawfile.bin -a channel_one.s16 -b channel_two.s16

With samplerate and device having the shown values as default options. The entire buffer should be allocated before the capture starts, with the size being adjustable by the user (4 GB seems reasonable I think, as the average user will have at least 16GB of RAM)

@Stefan-Olt
Copy link
Owner Author

I did a quick search and I think this ringbuffer implementation could be used: https://github.com/DNedic/lfbb

@harrypm
Copy link
Collaborator

harrypm commented Feb 10, 2024

I'm just wondering from a documentation perspective should there be a direct suggestion towards using NVME for pure safety of writing, SSDs are de facto go to either way but I'm just wondering is there a better safe margin of error due to pure speed?

@Stefan-Olt
Copy link
Owner Author

I tried writing to NVMe SSD, same issue (I do not have a dedicated NVMe for capture, it was the one with my OS), so far capturing to my NAS is the best option (connected at 10G)

@Stefan-Olt
Copy link
Owner Author

Correction to first idea: It seems libsigrok handles way too much for us, including the writing of the file, but we want direct access to the buffer. Better option is probably to only copy the device driver code (which is not part of sigrok anyway due to licensing issue) and use that. That also had the benefit that we had a single standalone application for capturing

@Stefan-Olt Stefan-Olt added enhancement New feature or request Capture Software labels Feb 11, 2024
@Stefan-Olt
Copy link
Owner Author

After inspecting the driver code I think the best option is to rewrite it more or less: Make new functions and copy only small sections of code, as the driver uses a lot of sigrok-specific data structures etc.
First steps would be:

  1. Create a new tool misrc_capture
  2. Create two threads, one for capturing and one for processing/storing
  3. Include libusb and open usb bus in the capture thread
  4. Function to scan usb bus for fx3 device
  5. Function to upload firmware to fx3

@Stefan-Olt Stefan-Olt added the help wanted Extra attention is needed label Feb 12, 2024
@jara1
Copy link

jara1 commented Mar 14, 2024

Hi, I'm pretty sure you are aware of https://github.com/cnlohr/fx3fun. Isn't there something (API?) what could be reused to simplify creation of the capture tool?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Capture Software enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

4 participants