Trouble is, to go national, it will be handled by an office at "head quarters" that doesn't handle projects of less than a million bucks, and they have plenty of people in their roladex who will be happy to propose a study at a price more than the entire project should cost. Plus, their typical timeframe is measured in years, so I hope I still give a shit by the time they decide.
SCPI, Linux, Home LAN, and the Rigol 1054Z
3 weeks 5 days ago #17995
In the programmers manual for my Rigol, there are SCPI commands for reading the raw data from sample memory on a AS-PER channel basis. I wanted to include that here. I know that peeps have had trouble with this, but that might be related to communications via telnet and windows. Even when using Putty. I have my scope connected to my home LAN and will be doing the bulk of my data acquisition via my Debian Linux home server. I do have a large quantity of scribbles on a note pad however concerning a bench server consisting of 4 RPI Zero's in a stack. This would be a great interface task for them and would free up my home server for the tasks I already heavily burdened it with.
Anyway, a whole block of sample data cannot be pulled all at once, and there is specific data about how much can be pulled per block. There is also specific commands to target the start and stop points of the memory. It should be a rather easy job of stopping the Rigol, querying the scope as to what is available, and then systematically pulling the data into individual files. I will have to do this for all 4 formats of data to see what is the most viable. I am more concerned with the logic states than I am about slew rates, so I am not sure if a full analog sample is needed. Timing is important though, so I need to query the sample rate and amount of samples per channel so I can properly map the data and clock streams. Once I do that, it should be a fairly simple task of assembling data from the sampled streams and displaying it with timing information. Even a streams comparison feature to see what bits changed based on new samples. This will be a HUGE diagnostic/learning tool for me to visually see how protocol data streams react to different protocol parameters and changed payload data.
I would rather have algorithms look at the signals than my aging eyes anyway. More when I know it...
Description Read the waveform data.
Explanation Reading procedures of the screen waveform data:
S1. :WAV:SOUR CHAN1 Set the channel source to CH1
S2. :WAV:MODE NORM Set the waveform reading mode to NORMal
S3. :WAV:FORM BYTE Set the return format of the waveform data
S4. :WAV:DATA? Read the screen waveform data