S |
SHocker |
In automating captures, I need to access the data directly in the RAM. You have not provided any pointer to that data. I.e., plug in the socket and say "data = s._s.get_data()" in a python script for example. Please provide access pointer to the raw data that is in the RAM so it can be reduced with a script and then saved to hard-drive in reduced form and then cleaned from the RAM and ready for next capture. All with minimal processing time required. Moving the data from the RAM to the hard-drive then back to the RAM is a very time consuming and inefficient. Honestly, I don't want your software in the way or popping up, just want the hardware to stream the raw data so I can use it to my application's purpose.
Activity Newest / Oldest
Tim
(#89684)
"The trigger would occur every 20 ms approximately and each time it happens, Saleae should make a capture and write channel states to a single row in a csv file. So far I haven't been able to do so, because all the methods I can see are provided just write an entirely new CSV file for every capture, and they do not append new lines to one existing file."
Tim
(#89425)
"The trigger action can be different for every situation (sometimes
even real-time CAN decoding and trigger on some packet anomaly's). For us it would be the best solution if we can use the Saleae Logic Pro 16 to use it as a fast up to 16 channel ADC from a C/C++ program."
Tim
(#87039)
"I would like to purchase a logic analyzer for capturing and analyzing data. I will need to use this hardware with my own logic analyzer user interface for display, control, and analysis software. Do you have a C, C++ API to allow me to control and retrieve captured data from your logic analyzer hardware?"
Tim
(#86148)
"it might take a bit of thinking effort to start swapping the beginning of a capture to disk when the buffer is somewhere near full. But I simply don't see it as a problem; in case of a very slow drive, the worst case is that a little less of the data in the buffer i overwritten. In most real case scenarios today, it will simply capture the stuff; most new PCIe SSDs will easily keep up with your typical USB-3 connection"
Tim
(#86442)
"Hello! I need access to analog channels data in low-level analyzer for real time processing. Is it possible? I need real time analog data to process them in my software. Unfortunatly you stopped support for Device SDK and I had to use Analyzer SDK which does not provide access to analog channel directly. Using "save to file" is not an option It is too slow"
Tim
(#83824)
"From your documentation it appears you do not support this, however, we believe it would reasonable simple to implement a double buffer to the capture code. Is this something that either we or yourselves could implement either using the logic source code (I imagine yourselves) or through the automation api?
I am looking to save the filled buffer to disk whilst immediately starting to fill a new buffer so I can continuously save the input stream to disk."
Tim
discuss.saleae.com/t/may-i-can-let-the-looping-mode-allows-for-a-continuous-recording-into-my-disk/2411/2
"We want to keep continuous recording about 24h, but old data is deleted while new data arrives,is there any way to solve it?May i can let the looping mode allows for a continuous recording into my disk?
Thank you for your support and look forward to your reply."
Tim
(#80675)
"I would also like to just capture the result entry and interrogate it directly within my code instead of writing to file but I don't see a way to get the list of results from the datatable in a uint32 type during run time. Is this possible?"
Tim
(#75349)
"Allow sampling to file while running for low sample rates, to ensure that the sample is not lost afterwards, e.g. due to user failure.
---
By "user failure" I consider the case where the user by accident closes the app, but there could also be cases where the capture PC shuts down for other reasons.
Regarding streaming to file, then then Saleae Pro with USB 3.0 has a bandwidth limit of 4.8 Gb/s, where my SSD at PCIe 3.0 x4 can write about 20 Gb/s, so for raw bandwidth, so modern SSD drives are hardly the bottleneck."
Michael Leonard
Hi all, you might find my "Socket Transport" HLA in the Marketplace useful for this. It opens a socket and streams the data out, not quite as 'real-time' as providing direct memory access but it is better than saving output to a file and performing post-analysis.
github.com/LeonardMH/SaleaeSocketTransportHLA
Tim
Wow this is fantastic! Thanks for uploading it to our marketplace! We'll certainly have to play with your HLA sometime.
Tim
Request from Twitter to access data directly:
twitter.com/azonenberg/status/1484694349053001728
The idea would be to stream directly to a 3rd party open source app, such as GLSCOPECLIENT.
Tim
(#60623)
"I’m part of the embedded test automation team, so that’s why I am interested in the API specifically. When talking about „live data access“ I mean the ability to stream the captured input signals to a different software for processing and evaluation during the capture.
This would be interesting for both the analog and digital signals as well as the output produced by the analyzers. It would allow me to test more complex behavior by being able to react to stimuli while still capturing.
Right now I have to capture the signals, export to disk, then read the file and evaluate, which is rather slow and also means I have to stop capturing briefly. Alternatively I can stream the data to a test system from a custom analyzer, but then I have to add this functionality to every analyzer individually and still don’t have access to the analog channels.
Being able to react to events while still recording for the whole duration of the test would be neat. I hope this explains what I’m trying to do."
Lior
We also need such a feature. We log transaction for days and must store to disk.
I think the fast and easy solution would be to release a low level DLL API of the HW (C/C++ is recommended) w/o the need to use the nice GUI. The API capture raw data into PC RAM. The PC RAM is use as FIFO in this case.
User write it's own application on top of the that API and retrieve the capture data from the RAM FIFO. On-the-fly, the application may parse the data, save to disk or whatever the application need.
In case stream data into the FIFO is faster then data retrieve, a FIFO FULL will hit and capture pause as long as it is FULL. The application will get this status and decide on the next action (e.g., stop, clear the FIFO and restart the capture or ignore and continue) .
In general, a good API is that the LOGIC2 GUI can be written on top of this API.