The binary data consists of d chunks of 3Nch bytes each, where Nch is the number of channels requested via the bitmask. Each chunk containsNch three-byte entries, each representing a single CDF value F(V ;Δt) for each requested channel.
For the manual, you may want to remove the "Single-Point Upsets".
It wasn't clear to me how this data was formatted. I convert the entire chunk array (which includes data for all selected channels) to form a voltage/CDF array. I then decimate the data V1_Ch1,CDF1_Ch1; V1_Ch2,CDF1_Ch2; ... V1_Chn,CDF1_Chn; V2_Ch1,CDF2_Ch1; V2_Ch2,CDF2_Ch2; ... V2_Chn,CDF2_Chn; ...
where Ch is the channel number, Vt and CDFt are the voltage and CDF for a specific sample. I thought it may have sent all of the data for the first channel, then the second rather than interlace them.
When no trigger is present, the scope will trigger off its internal clock (>100 Mtrig/s) until a valid
trigger source returns.
With nothing attached to the scope's trigger your software will continue to sweep. Connecting a DC signal to the scope's inputs, you are certainly reading the correct data. When I try this with my software, the scope never appears to send data unless there is a valid trigger. Is there another command you are using to force the scope to send the data?
It never returns to what ever state it was in that allowed it to collect without triggers.
Also, while experimenting with my own software and yours, I got the scope into some mode where when I attempt to run your software, I get the attached error. Your software would come up to the main menu but that dialog would remain. I could exit your software and restart and would get this same error. Eventually, I pulled the USB connection to the scope (power cycling it) which cleared the problem. I am not a fan of having to power cycle any device to clear an error. I don't want to be driving down the highway and have to pull over to yank the battery cable to reset the engine's computer.
There is a command that selects the internal clock source as the trigger (X1 sets internal source, X0 sets to normal trigger mode). For each acquisition, the software first tries in normal mode, and if no trigger is detected, issues the X1 command and retakes the CDF.
See attached image - we'll document this command in the next manual revision.
The software should automatically return to the internal trigger ("wait") mode if no triggers are detected (e.g. the signal source is removed). What happens when you try this - does the software freeze?
Please take the time to document ALL of the commands. Even if you have commands you feel are not something customers would/should use, they may still prove helpful.
*** Sending X1 or X2, it responds with OK Xn. Sending X1 followed with R, I do not get any data. There must be more to it.
The software displayed Wait but it stopped sweeping. I could apply a trigger signal and it remained in Wait. I can't tell you for sure that it froze. I have yet to perform a three finger solute to shake your software loose. I exited the software and restarted and it worked as normal. I can tell you that I am having a difficult time replicating it.
1) zoomed out showing 46 sweeps, 5ps resolution for 1ns. I make no attempt to align the channels and we can see that one channel is a bit off compared with the others like I had mentioned.
2) Looking at the minimum values of the peak area. Note how channel 1 is smooth where the others have some sort of pattern to them.
3) Looking at the maximum, we can see they are all smooth.
If I reset the collection and watch it, I can see when it will create a single mini-glitch. They are much smaller in amplitude than the original glitches. This appears very reproducible. Nothing special with the cables, splitter or RF gen. Have you seen these smaller spikes?
*** Sending X1 or X2, it responds with OK Xn. Sending X1 followed with R, I do not get any data. There must be more to it.We were able to get CDF data with the following procedure:
1. Plug in the scope.
2. Issue command X1.
3. Issue command R1 10000 10000 10000 10000 50000 50000 50000 50000.
Does this sequence fail to return data on your unit?
So no difference. I assume X1 is sent with no other payload and terminated normally. The fact it returns an OK it seems correct. If X1 is selected and I supply a trigger, it does trigger normally. It behaves the same for X0 and X1. I'm sure I am missing something simple as your software appears to work correctly.
As it continues to run, it's interesting that channel 1 never exhibits these downward spikes where the other three do. It never happens in the valley, only the peak. I would not have noticed it as I was only ever looking at channel 1 with my software until today. I'll take your word for it that it is the expected behavior from your design perspective. As a user, I would be concerned it was my signal generator causing this, then spending time hunting down a problem that isn't there.
So no difference. I assume X1 is sent with no other payload and terminated normally. The fact it returns an OK it seems correct. If X1 is selected and I supply a trigger, it does trigger normally. It behaves the same for X0 and X1. I'm sure I am missing something simple as your software appears to work correctly.That's odd. Are you sending any commands in between? Sending a D command will reset to normal trigger mode (X0) - see our reply #154.
Our software issues exactly this sequence (X1 then R).
We are running a test unit in the same configuration as you (~240mVpp @ 1 GHz on all channels), and so far (300 sweeps) our min-max spread on all channels does not exceed 1.1 mV. This is using the interpolation method - doing an error function fit pushes the noise even lower.
Can you send the raw CDF data from some of the worst samples (~15 mV off)?
If I use your software to stream all the data to disk and let it run for a half hour, could you track it down from that?
Installed and running. I have it recording all four channels. If you have a way to sift through all of that data, I can send you the worse case ones, or I can compress the whole directory and send it. I'll let it run a half hour.
I'm using 30 samples, linear fit.
you can recover the signal voltage V0 by interpolating between the two neighboring voltages where F(V ;Δt) first transitions from below 1/2 to above 1/2.
...
2. If two or more voltages in the CDF are equal, sort the corresponding CDF values (for that voltage value) from lowest to highest. If the interpolation is done in an incorrect order, a large apparent spike may result (example 2, attached).
These considerations do not apply if you directly fit an error function to the CDF data.
We just discovered effect (2) recently, so we may send you an updated firmware file tomorrow that implements this sorting for you.
...Do you always use a Gaussian fit to get the centroid?A bit complicated, but details if you're interested: to a first approximation, you can use the interpolation procedure we described in the last post. This usually gets you close, but the noise performance is poor since you're only using two samples.
Fitting a Gaussian error function is theoretically the best thing to do (in the sense of Fisher information), but in practice is overly sensitive to outliers on the wings. What we've found works well in practice is to fit a line to the inverse Gaussian CDF applied to the data, but truncated within a certain region (say 10-90%) of the CDF, with the truncation also seeded by the interpolation method. (This is also faster on the CPU.) You need to weight samples with some care to maintain equal sensitivity to all values (which minimizes the total propagated noise, and improves outlier robustness).
This gives a significantly lower noise floor than the interpolation method alone, but is still robust to spurious errors.
First, do I always need to sort the CDF values? Is there a problem that I am seeing what appears to be out of order data?
Plot comparing the linear and gaussian fit with sorted CDF and 10/90% window, 0 weight for anything outside. Again, linear interpolation used to locate mid point.
I have not tried these in my software to see which is more robust. Rather I would like to replicate what your software does.
Could you do me a favor and write a simple program that maybe reads one of the streamed CSV files from your software, performs the calculations (identical to how your software works) and shows the result? I wouldn't care if you released the source or not although it may be helpful to have it. Basically, I want to prove that we obtain the same results.
Another option you may want to consider is where you provide interface libraries for the different OSs you support. This would give you total control over the algorithms and takes that burden away from customers. Personally, I see it as a wash, as long as you provide enough detail to implement your exact algorithms.
Also, personally I like having the PC make all of these calculations rather than the embedded system. Why not leverage the latest PC technology. I have to believe it also makes your job much easier by minimizing the complexity of the firmware. I think about that NanoVNA and just how unstable that firmware was.