search

Stefan-Olt / MISRC

MISRC Is a multi channel RF capture device for FM RF, S-Video, CVBS RAW capture and anything else, but intended and supported for the decode family of projects vhs-decode, ld-decode, hifi-decode.
46 stars 4 forks source link

Better capture tool than sigrok-cli #8

Open Stefan-Olt opened 6 months ago

Stefan-Olt commented 6 months ago

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 commented 6 months ago

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

harrypm commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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
jara1 commented 5 months ago

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?