Author Topic: Using a AWG and a Scope -> using stairs to get to 1 mV accuracy  (Read 8973 times)

0 Members and 1 Guest are viewing this topic.

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 617
  • Country: nl
    • KiCad-BOM-reporter
For the added overcurrent protection in this little project:
https://www.eevblog.com/forum/projects/battery-voltage-to-5v-regulation/msg2280605/?all#lastPost

I want to find out what the temperature sensitivity is when the zenerdiode would be replaced by a normal one.

First I simplified the schematic, so it is more easy to see what is measured in the experiment. The experiment uses the term input and output. The op amp feeds the subcircuit (input) which has an output on the non inverted input.

The subcircuits curve and the amplification determines when the positive feedback collapses.

In the experiment I've done 3 measurements:
* At room temperature: Non automated set of points by turning up the AWG in DC mode and measuring the output with a MM. This method is very precise and is the baseline to compare the next one to.
* At room temperature: A 50% triangle ramp with the AWG from 0 to 800 mV at 5 hz. Measuring the in and output many times with a DSO using the 64x average mode.
* At 50 deg (using a heatgun): The same as above.

The data of the DSO was fetched using SCPI. I manually removed data that wasn't in the ramp up. So it was known that all voltages should be rising (discarding noise). With this knowledge I took only the first voltage/time point of a certain voltage. Values in between are interpolated later on. In this way one can use the very high horizontal resolution to get very high vertical one. (Precision is another matter).

Also I used a 450 ohm resistor instead of a 500 ohm (R9) one, because of the 50,74 ohm output of the AWG. The voltage drop over the 450 ohm resistor is used to determine the drop over the extra 50,74 ohms.

Using the two datasets (Ramp and output) a new dataset for the use in Excel can be created. There the MM and DSO measurements can also be compared.

I think the DSO results are very usable! I did not even took out abnormal values, which would not be very difficult to spot.

I'm still not sure whether the fetched dataset is an averaged one or whether averaging is only used for the DSO screen.

The next step is to check for each temperature what amplification is needed to let the positive feedback collapse. If the difference is high, then a normal diode is not suited to be used in this circuit. (It may also that a Zener diode's curve at low currents also differs too much.) I will write a simulation script which will use the datasets I got to find the answers. There's even a slight possibility it won't collapse using the current component values.

BTW: The curves already tells me that temperature dependency is a bit too high to my likings. But these experiments are a good learning experience. So we shall continue!
« Last Edit: June 10, 2019, 11:22:12 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Online tautech

  • Super Contributor
  • ***
  • Posts: 16012
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
I'm still not sure whether the fetched dataset is an averaged one or whether averaging is only used for the DSO screen.
FYI the displayed sampling rate and mem depth are clues to what happens when Averaging or E-Res modes are selected.  ;)
Avid Rabid Hobbyist
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 617
  • Country: nl
    • KiCad-BOM-reporter
I'm still not sure whether the fetched dataset is an averaged one or whether averaging is only used for the DSO screen.
FYI the displayed sampling rate and mem depth are clues to what happens when Averaging or E-Res modes are selected.  ;)
The mem-depth I already manually turned down, so that's no clue to me ;). The sample rate does then also not need to be high anymore so I'm missing that clue also :-//

Personally I would like to have the averaging in the dataset, but I don't think deep memory (?) can be used for that. I think there is some screen buffer where the averaging is happening, no? So it doesn't end up in the dataset.

Or is it "segmented" and are the segments averaged when retrieving the dataset (or outputting to the screen)? But then there're not enough segments.

There's prop. a 4 byte/Mpt deep memory buffer allocated where the summing is done.

Now I really like to know!

“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Online tautech

  • Super Contributor
  • ***
  • Posts: 16012
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Try a full mem depth before selecting Average and then see the mem depth drop so the scope can process the averages quickly.
Both sampling rate and mem depth are timebase setting dependent so you can see what's going on.
Avid Rabid Hobbyist
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 617
  • Country: nl
    • KiCad-BOM-reporter
Try a full mem depth before selecting Average and then see the mem depth drop so the scope can process the averages quickly.
Both sampling rate and mem depth are timebase setting dependent so you can see what's going on.
But is also needs memory to store the summing in, that alone could be a reason for not having the full memory to be available.

Also how does is implement FIFO? Has it got 2 or more summing buffers?

I did some testing, and averaging is in the dataset! (my scope was stored to leave from the livingroom to the e-lab, so I saved that investigation for later. Now that later has become soon)

I had an averaged sine wave of 6V ampl. and set it to 0V ampl. and then quickly retrieved a dataset. And indeed the ampl. hadn't dropped much. Nice to know!
« Last Edit: April 12, 2019, 10:13:08 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Online tautech

  • Super Contributor
  • ***
  • Posts: 16012
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Also how does is implement FIFO? Has it got 2 or more summing buffers?
Dunno, past my level of knowledge.
Others might know and help.
Avid Rabid Hobbyist
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 617
  • Country: nl
    • KiCad-BOM-reporter
Also how does is implement FIFO? Has it got 2 or more summing buffers?
Dunno, past my level of knowledge.
Others might know and help.
Did some googling, and found no answer yet, so that's not easy obtained knowledge. A more practical question would be: can one retrieve the summed values, because they've got a higher resolution  :-+
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Online tautech

  • Super Contributor
  • ***
  • Posts: 16012
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Also how does is implement FIFO? Has it got 2 or more summing buffers?
Dunno, past my level of knowledge.
Others might know and help.
Did some googling, and found no answer yet, so that's not easy obtained knowledge. A more practical question would be: can one retrieve the summed values, because they've got a higher resolution  :-+
Yes I think that's correct.
4ch X-E right ?
Enter the webrowser and download the .bin to .csv file converter.
Use it to convert the default .bin data file to .csv then Copy/Paste the data into your program. (Excel etc)
Avid Rabid Hobbyist
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 617
  • Country: nl
    • KiCad-BOM-reporter
Also how does is implement FIFO? Has it got 2 or more summing buffers?
Dunno, past my level of knowledge.
Others might know and help.
Did some googling, and found no answer yet, so that's not easy obtained knowledge. A more practical question would be: can one retrieve the summed values, because they've got a higher resolution  :-+
Yes I think that's correct.
4ch X-E right ?
Enter the webrowser and download the .bin to .csv file converter.
Use it to convert the default .bin data file to .csv then Copy/Paste the data into your program. (Excel etc)
Yes, I went fancy with my post and on each glowing abrev. more details are shown. But here on the iPad it doesn’t work, so not worth the effort.

The way I get the samples is via SCPI in a byte per sample, so the extra bits are chopped off in that way. If the webbrowser does it otherwise it would pleasantly surprise me.  But I think that not many consumer level scope’s will support the extra bits feature.
« Last Edit: April 17, 2019, 11:15:02 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Online tautech

  • Super Contributor
  • ***
  • Posts: 16012
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Also how does is implement FIFO? Has it got 2 or more summing buffers?
Dunno, past my level of knowledge.
Others might know and help.
Did some googling, and found no answer yet, so that's not easy obtained knowledge. A more practical question would be: can one retrieve the summed values, because they've got a higher resolution  :-+
Yes I think that's correct.
4ch X-E right ?
Enter the webrowser and download the .bin to .csv file converter.
Use it to convert the default .bin data file to .csv then Copy/Paste the data into your program. (Excel etc)
Yes, I went fancy with my post and on each glowing abrev. more details are shown. But here on the iPad it doesn’t work, so not worth the effort.

The way I get the samples is via SPCI in a byte per sample, so the extra bits are chopped off in that way. If the webbrowser does it otherwise it would pleasantly surprise me.  But I think that not many consumer level scope’s will support the extra bits feature.
The .bin/csv files can be pretty large but with use of a careful setup restricting mem depth, trigger level and Single shot you can keep the data sample size quite small and manageable.
Just try with some simple waveform to get some system that works for you sorted then migrate the settings into your test setup.
Avid Rabid Hobbyist
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 617
  • Country: nl
    • KiCad-BOM-reporter
I did some testing with the AVG acquisition mode to find out how it functions and what the algorithm behind it might be.


First: it seems to work with a summing buff, which does not throw values out (no FIFO). The summing is weighted, new values are added with a greater weight. This means over time older values are loosing more and more their share. But that can take more time than one might think especially if the differences are great.
With this algorithm one summing buffer is enough. (When I was thinking about this stuff, I also thought of a way which discards values over time, and works more like you would expect. But that needs extra buffers. But to my understanding of the moment that wouldn't be a problem. )


How did I test this?


I ran a 140 hz square wave (fits the screen nice) which starts at 95% duty cycle.
Then its triggered.
Then imediately it goes to 90%.

Then it waits 10 seconds.
Then 5% less duty cycle.

The above is repeated until 5% duty cycle.

Then it waits 10 seconds.

Then it is stopped and a screendump is made.

So looking at the dumps, one can see how a high value decays over time. Left: “young low values”, right: older ones.

To use the AVG mode correctly this information might be of use. In this regard I find the "Averages 1024x" indication some what misleading. I mean after 18 x 140 samples/sec x 10 sec = 25200 samples later a value has still a lot of influence. And isn't "thrown out".

That is not a bad thing, but one should know that. (And maybe restart the triggering more often)
« Last Edit: April 14, 2019, 07:33:20 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 617
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... scope averaging mode tested
« Reply #11 on: April 14, 2019, 09:27:52 am »
When the positieve feedback collapses can be shown by a graph, however it is depended on the slope of the Vi/Vout graph. I've put that slope against a second y-axis and come to the conclusion the data is not smooth enough to do anything meaningful with it.

The path I'll take then is to have a function fit of the points and take a differential of that (slope).

However it would also be nice to find a way to get smoother data, hence the exploration of averaging the samples. For me using the averaging acquisition mode has some drawbacks. One step better would be to have the separate sample sets and do the averaging myself. In this way every sample set is of equal influence and we would end up with a higher resolution as well.

Does someone now how to use SCPI to get the data from individual segments/frames when sequence mode enabled?
« Last Edit: April 17, 2019, 11:16:18 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 5723
  • Country: us
Re: Using a AWG and a Scope -> sidetrack... SPCI individual segements?
« Reply #12 on: April 14, 2019, 12:42:07 pm »
Looking at the duty cycle average test.   Assuming I follow, which I am not sure I am,  at 140Hz or every 7.15ms the scope will see a trigger.   You wait 10 seconds except for the very first, to allow up to 1400 cycles to be captured.  Even with 32 averages, it should should be flushed but it's showing some residual.  The scope may not be collecting all the data.   

Send out a burst of 1400 cycles at the 140Hz and see how many trigger events the scope reports.   Maybe they provide you the retrace time.   Slow down the time between pulses (send a 356us pulse, wait for the scope retrace, then send the next pulse.)   You could even wait a second between.  Just use the lowest averages so you don't waste a lot of time.   

Basically, just curious if you made sure your test was valid before running it.
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 617
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... SPCI individual segements?
« Reply #13 on: April 14, 2019, 02:17:11 pm »
Looking at the duty cycle average test.   Assuming I follow, which I am not sure I am,  at 140Hz or every 7.15ms the scope will see a trigger.   You wait 10 seconds except for the very first, to allow up to 1400 cycles to be captured.  Even with 32 averages, it should should be flushed but it's showing some residual.  The scope may not be collecting all the data.   

Send out a burst of 1400 cycles at the 140Hz and see how many trigger events the scope reports.   Maybe they provide you the retrace time.   Slow down the time between pulses (send a 356us pulse, wait for the scope retrace, then send the next pulse.)   You could even wait a second between.  Just use the lowest averages so you don't waste a lot of time.   

Basically, just curious if you made sure your test was valid before running it.
I haven't seen a trigger counter anywhere, so I'm also not sure how many times it triggered.

But is should retrigger after 100ns. 140hz isn't even close to missing the next one. The period is also larger than what's in screen so it should have one trigger per period. But even if it had 2, the explanation still matches.

Also the after the first 95%->90% drop the script doesn't wait. So that average has very few high's in it.

The screenshots are static, but I off course saw an animated decay. Fast at first, than slowing down, so I know for sure it didn't trigger infrequent. (But I also would like to see how many)

Also I'm not surprised that it works like this, otherwise one needs more buffers. Which have to be shared by several frames. One buffer per frame x 1024 takes to much space: 4 buffers of 256 frames should however be possible. After 1024 frames one can than drop one buffer, and continue with 768 (3 full buffers) + 1 frame. Essentially doing a FIFO with buffers.

How I came to 4 buffers:
Going from 14M -> 1.4M gives 9 x 1.4M buffer space. A summing buffer needs 2 bytes/sample to handle overflows.

This however would have some artefacts like a few sudden drops in the average.

I cannot think of another way to really get rid of old values. Maybe someone else has a genius idea?
« Last Edit: April 14, 2019, 03:22:57 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 5723
  • Country: us
Re: Using a AWG and a Scope -> sidetrack... SPCI individual segements?
« Reply #14 on: April 14, 2019, 04:08:03 pm »
Basically, just curious if you made sure your test was valid before running it.
I haven't seen a trigger counter anywhere, so I'm also not sure how many times it triggered.

But is should retrigger after 100ns. 140hz isn't even close to missing the next one. The period is also larger than what's in screen so it should have one trigger per period. But even if it had 2, the explanation still matches.

Also the after the first 95%->90% drop the script doesn't wait. So that average has very few high's in it.

The screenshots are static, but I off course saw an animated decay. Fast at first, than slowing down, so I know for sure it didn't trigger infrequent. (But I also would like to see how many)

Also I'm not surprised that it works like this, otherwise one needs more buffers. Which have to be shared by several frames. One buffer per frame x 1024 takes to much space: 4 buffers of 256 frames should however be possible. After 1024 frames one can than drop one buffer, and continue with 768 (3 full buffers) + 1 frame. Essentially doing a FIFO with buffers.

How I came to 4 buffers:
Going from 14M -> 1.4M gives 9 x 1.4M buffer space. A summing buffer needs 2 bytes/sample to handle overflows.

This however would have some artefacts like a few sudden drops in the average.

I cannot think of another way to really get rid of old values. Maybe someone else has a genius idea?
Obviously I don't know anything about the scope you are using.   Normally I will use Labview to collect and crunch the data.  Still, if you wrote you own software you would need to see how fast you could collect it first. 
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 617
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... SPCI individual segements?
« Reply #15 on: April 14, 2019, 05:14:56 pm »
Basically, just curious if you made sure your test was valid before running it.
I haven't seen a trigger counter anywhere, so I'm also not sure how many times it triggered.

But is should retrigger after 100ns. 140hz isn't even close to missing the next one. The period is also larger than what's in screen so it should have one trigger per period. But even if it had 2, the explanation still matches.

Also the after the first 95%->90% drop the script doesn't wait. So that average has very few high's in it.

The screenshots are static, but I off course saw an animated decay. Fast at first, than slowing down, so I know for sure it didn't trigger infrequent. (But I also would like to see how many)

Also I'm not surprised that it works like this, otherwise one needs more buffers. Which have to be shared by several frames. One buffer per frame x 1024 takes to much space: 4 buffers of 256 frames should however be possible. After 1024 frames one can than drop one buffer, and continue with 768 (3 full buffers) + 1 frame. Essentially doing a FIFO with buffers.

How I came to 4 buffers:
Going from 14M -> 1.4M gives 9 x 1.4M buffer space. A summing buffer needs 2 bytes/sample to handle overflows.

This however would have some artefacts like a few sudden drops in the average.

I cannot think of another way to really get rid of old values. Maybe someone else has a genius idea?
Obviously I don't know anything about the scope you are using.   Normally I will use Labview to collect and crunch the data.  Still, if you wrote you own software you would need to see how fast you could collect it first.

So I ran the script now using Sequence mode, and it clears up how fast it triggers. It can capture 1891 frames (buffers) of 14K in total The time it took was 27 sec. That makes 70 frames per sec. So 2 periods/cycles per frame.

In that mode we could get the 1891 buffers and calculate the average our selves. That does not need to be done realtime, because if we use the Single trigger mode it stops after 1891 frames/buffers.

The problem is, I haven't figured out how to get the data frame by frame via SCPI yet.

I've also searched for a Trigger counter but I don't think the scope has one.
« Last Edit: April 20, 2019, 11:39:44 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 5723
  • Country: us
Re: Using a AWG and a Scope -> sidetrack... SPCI individual segements?
« Reply #16 on: April 14, 2019, 05:40:49 pm »
Odd they don't offer example code.   At these speeds, you may be able to grab it frame by frame.   There are some advantages to working this way, if you can pull it off.   All my vintage scopes allow creating your own scripts to control them.  I've never gone this route as the desktop PC's processing power can easily out pace the scopes I have.   You can take advantage of the GPU for example.     

Even if you can't collect individual frames without missing, the raw accumulated data sounds like it will work for you, assuming that is really what they send you.   I am envisioning a very sparse manual for your particular scope.   
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 617
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... SPCI individual segements?
« Reply #17 on: April 14, 2019, 06:10:21 pm »
Odd they don't offer example code.   At these speeds, you may be able to grab it frame by frame.   There are some advantages to working this way, if you can pull it off.   All my vintage scopes allow creating your own scripts to control them.  I've never gone this route as the desktop PC's processing power can easily out pace the scopes I have.   You can take advantage of the GPU for example.     

Even if you can't collect individual frames without missing, the raw accumulated data sounds like it will work for you, assuming that is really what they send you.   I am envisioning a very sparse manual for your particular scope.   
What you suppose is also doable for me to, frames don't need to adjacent to each other. :-+ (My mind was stuck on duplicating an averaging algorithm)
But it is also good to have a small timeframe at which all data is acquired. The fetching of data goes fast (for such small data blocks), like 5 MiB/s, so 14K frames could be downloaded at the speed of 35 frames/sec.

-Edit I have to correct the speed I usually get:
6 MB/sfor large blocks, but only 0,24 MB for 14K blocks.
« Last Edit: April 16, 2019, 10:22:08 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 617
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... SPCI individual frames?
« Reply #18 on: April 14, 2019, 06:16:40 pm »
With the command FRAME_SET the current frame can be set, that will probably the wavedata which is downloaded. That is something I will checkout later!
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 5723
  • Country: us
Re: Using a AWG and a Scope -> sidetrack... SPCI individual segements?
« Reply #19 on: April 14, 2019, 07:37:03 pm »
Odd they don't offer example code.   At these speeds, you may be able to grab it frame by frame.   There are some advantages to working this way, if you can pull it off.   All my vintage scopes allow creating your own scripts to control them.  I've never gone this route as the desktop PC's processing power can easily out pace the scopes I have.   You can take advantage of the GPU for example.     

Even if you can't collect individual frames without missing, the raw accumulated data sounds like it will work for you, assuming that is really what they send you.   I am envisioning a very sparse manual for your particular scope.   
What you suppose is also doable for me to, frames don't need to adjacent to each other. :-+ (My mind was stuck on duplicating an averaging algorithm)
But it is also good to have a small timeframe at which all data is acquired. The fetching of data goes fast (for such small data blocks), like 5 MiB/s, so 14K frames could be downloaded at the speed of 35 frames/sec.

It seems like if you are capturing 5ms at 2Msamples/sec with no accumulation, and 8-bits/sample you need to send 10KBytes for each frame.  If your frame rate is 140Hz,  you need to send 1.4MBytes/sec or a 11.2Mbit.   This seems very doable if my basic math is correct.   

About 4 years ago,  I added a 1G Ethernet card to one of my old scopes.  Guessing all scopes will have their tricks depending what you are trying to do with them.  On this particular scope, I can move the frame into an internal memory buffer and then transfer that memory across the Ethernet to the PC while the scope grabs the next frame.   This allows me to achieve sustained data rates of well over 300Mbits.   I would imagine a modern scope would far out pace what my old scopes can do but again, I really have no idea about your particular setup.

If the data is unpacked on your scope (say they really send two bytes anytime you enable accumulation) the actual data rate you need would be much lower once you get past a one accumulation.     
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 5723
  • Country: us
Re: Using a AWG and a Scope -> sidetrack... SPCI individual frames?
« Reply #20 on: April 14, 2019, 07:40:49 pm »
I doubt it will help you with the experiment you are trying to run but it should give you some idea how fast I can transfer data with my vintage scope. 

https://youtu.be/DlsBnumQaCA?list=PLZSS2ajxhiQA9yWh-hvVtv2ib-3ObOHGV&t=15
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 617
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... SPCI individual frames?
« Reply #21 on: April 14, 2019, 08:06:25 pm »
I doubt it will help you with the experiment you are trying to run but it should give you some idea how fast I can transfer data with my vintage scope. 

https://youtu.be/DlsBnumQaCA?list=PLZSS2ajxhiQA9yWh-hvVtv2ib-3ObOHGV&t=15
Nice to see and very fast  speeds! But think that also depends a lot on how fast chipset and cpu of the scope are. As far as I can see your data goes also through a VISA driver layer.
Which my software also directly communicates with. Also more pro scopes will prop. have better tuned software running on them.
I still find it amazing what my Siglent SDS1104X-E is capable of feature wise. Maybe if I ran jumbo packets on the network the speed goes up as well, I don’t know. To many network interrupts can slow things down. I don’t even know wether it is a Gib network interface.
For my experiment tons of data would also be overkill. With 14K frames I think a good dataset can be created. It is slowly rising so I can tune on that property and do heavy averaging.
« Last Edit: April 14, 2019, 08:41:07 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 5723
  • Country: us
Re: Using a AWG and a Scope -> sidetrack... SPCI individual frames?
« Reply #22 on: April 14, 2019, 09:13:26 pm »
Many companies rolled their own VISA layer back then and I am using the custom one for this scope.   This DSO uses a P4 and was Windows 2000.   

I doubt jumbo will gain you much if anything.  The PC side should present no problem at these speeds, even with Labview.  As long as you have a large enough buffer setup, Windows should keep up with ease.   Someone here was asking about how fast the data could be transferred with the PC running an FFT on it.   It looks like I removed the video but the limiting factor is really updating the screen. 

I  looked up your scope on their site.  They show it has a LAN connection but details are sparse.  I couldn't locate a manual for it.  If you can post a link to the manual, I will have a look.     

Here you can see the time stamp of the data with Wireshark.  Keep in mind, the PC that I am using for these demos is fairly old.  My new PC will run circles around it.   
https://youtu.be/GhVQGPra9DQ?t=149
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Online tautech

  • Super Contributor
  • ***
  • Posts: 16012
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Re: Using a AWG and a Scope -> sidetrack... SPCI individual frames?
« Reply #23 on: April 14, 2019, 10:43:36 pm »
I  looked up your scope on their site.  They show it has a LAN connection but details are sparse.  I couldn't locate a manual for it.  If you can post a link to the manual, I will have a look.     
The manuals of interest are:
SDS1000X-E Series User Manual
Programming Guide For Digital Oscilloscopes Series

They're down the list a bit here:
https://www.siglentamerica.com/resources/documents/digital-oscilloscopes/#sds1000x-e-series

Some further data on LAN connection speeds is here:
https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/msg1394796/#msg1394796

Also there's some guidance about data collection in the Operation tips:
https://www.siglentamerica.com/operating-tips/sds1000x-e-series/
And videos:
https://www.siglentamerica.com/videos/sds1000x-e-series/
Avid Rabid Hobbyist
 
The following users thanked this post: joeqsmith

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 617
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... SPCI individual frames?
« Reply #24 on: April 14, 2019, 10:59:04 pm »
I  looked up your scope on their site.  They show it has a LAN connection but details are sparse.  I couldn't locate a manual for it.  If you can post a link to the manual, I will have a look.     
The manuals of interest are:
SDS1000X-E Series User Manual
Programming Guide For Digital Oscilloscopes Series

They're down the list a bit here:
https://www.siglentamerica.com/resources/documents/digital-oscilloscopes/#sds1000x-e-series

Some further data on LAN connection speeds is here:
https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/msg1394796/#msg1394796

Also there's some guidance about data collection in the Operation tips:
https://www.siglentamerica.com/operating-tips/sds1000x-e-series/
And videos:
https://www.siglentamerica.com/videos/sds1000x-e-series/

Thanks!

I checked the color of the led of the switch at the scopes connection: it is of amber color meaning a 100mbit connection.

I did a large 14M test, and it was fetched at 6MB/s
It's not 30MB/s but enough for a lot of applications.

Then I tried to use USB, but the VISA com interface crashed in that case so I cannot report any speeds on that.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf