Open Stefan-Olt opened 6 months ago
I did a quick search and I think this ringbuffer implementation could be used: https://github.com/DNedic/lfbb
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?
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)
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
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:
misrc_capture
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?
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:
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)