Bode plotting slowing the system massively down - Maybe the dips representing a shortly interruption from the bode "programm" to do something else.
Bode plotting slowing the system massively down - Maybe the dips representing a shortly interruption from the bode "programm" to do something else.
Not the case if the dip repeats at the same frequency in multiple runs
That does not make sense if it happens with internal awg where it can take all day to take a measurement and still get a proper plot since it's in control of the awg.
That does not make sense if it happens with internal awg where it can take all day to take a measurement and still get a proper plot since it's in control of the awg.
It works only with Siglent AWG's it can control...
Does it happen in "Vout/Vin" mode and also in "Vout" mode?
That does not make sense if it happens with internal awg where it can take all day to take a measurement and still get a proper plot since it's in control of the awg.
It works only with Siglent AWG's it can control...
That's my point. It controls the input and should be reading input and output. Getting spikes like that wouldn't be about the program being busy with some other task it would simply slow down the operation not cause errors.
That does not make sense if it happens with internal awg where it can take all day to take a measurement and still get a proper plot since it's in control of the awg.
It works only with Siglent AWG's it can control...
That's my point. It controls the input and should be reading input and output. Getting spikes like that wouldn't be about the program being busy with some other task it would simply slow down the operation not cause errors.
Why do you think that? Algorithm is usually not adaptive. It probably simply changes frequency, waits for signal to settle, takes measurements (for averaging), moves on..
On each frequency point it will need dwell time, and that will be variable with frequency. Maybe it simply doesn't wait enough for siggen to settle, or measuring too quick ...
It would be useful to take a look with another scope...
That's what I suspect, it's not monitoring input and assuming gen is ready when that's not the case. If you're reading the input and output it'd be a software bug or hardware failure. If the program got busy it'd just slow things down. Not sure how it could possibly cause errors in the plot.
Simple and stupid is what i think...
a race condition; which several of you are alluding too
Now where? Hard to say other than its reading an incorrect value at somewhere in its logic path
I think I found a bug.
After rebooting the box, the vertical position of the channels is where I left them, but the channel markers and info are wrong.
In the specific example the vertical offset was set to -3V for C1 and -1V for C2.
The restored values displayed are -300mV and -100mV.
However the waveform is offset correctly.
I think they don't take into consideration that the probes are 10X
Simple and stupid is what i think...
a race condition; which several of you are alluding too
Now where? Hard to say other than its reading an incorrect value at somewhere in its logic path
A race condition is not going to lead to repeatable errors like this. The invalid point is constant over many sweeps, as I understand. There seems to be no randomness, other than the bug appearing sometimes and not another time, but when it's there, it's there over many sweeps.
Simple and stupid is what i think...
a race condition; which several of you are alluding too
Now where? Hard to say other than its reading an incorrect value at somewhere in its logic path
A race condition is not going to lead to repeatable errors like this. The invalid point is constant over many sweeps, as I understand. There seems to be no randomness, other than the bug appearing sometimes and not another time, but when it's there, it's there over many sweeps.
Hello,
I don't know for others, but for me the error point is not always the same.
You can see on previous posts the different results.
Sometime one points, sometimes two...
The error point is always at low frequency (<1kHz).
Frex
Simple and stupid is what i think...
a race condition; which several of you are alluding too
Now where? Hard to say other than its reading an incorrect value at somewhere in its logic path
A race condition is not going to lead to repeatable errors like this. The invalid point is constant over many sweeps, as I understand. There seems to be no randomness, other than the bug appearing sometimes and not another time, but when it's there, it's there over many sweeps.
Mine is random and not in the same place
Should also note the only consistent part i've seen so far is that its always sub 100Hz, just going to let it run all day and let it churn at 10Hz to 120Mhz
Got another one, twice just over 100Hz
I just happened to be looking at it when it did one just now
Maybe not a delay.. i think they just got something wrong somewhere, my scope made a clicking noise like it was changing a relay or something
So... what is triggering it to want to do this relay flip?
Yep it did it again... it clicks THEN the error in the graph shows up
It might be something simple like autoranging during sampling.... Does it have autoranging and adaptive level?
Maybe something like this from another FRA :
"Outstanding bugs
The method of changing frequencies results in discontinuities in the function generator output. When in AC coupling mode, the DC offsets introduced by these discontinuities take some time to settle out. The program tries to adapt to this, but is not perfect. The main issue is at very low frequencies where there can be a DC offset decay that appears in the captured data. This is largely compensated by the DFT, but may affect noise measurement.
"
I would say that description fits like a glove.
It might be something simple like autoranging during sampling.... Does it have autoranging and adaptive level?
Maybe something like this from another FRA :
"Outstanding bugs
The method of changing frequencies results in discontinuities in the function generator output. When in AC coupling mode, the DC offsets introduced by these discontinuities take some time to settle out. The program tries to adapt to this, but is not perfect. The main issue is at very low frequencies where there can be a DC offset decay that appears in the captured data. This is largely compensated by the DFT, but may affect noise measurement.
"
Yes, it does autoranging if you let it. But IIRC, @Frex mentioned that the error happens also without autoranging.
It might be something simple like autoranging during sampling.... Does it have autoranging and adaptive level?
Maybe something like this from another FRA :
"Outstanding bugs
The method of changing frequencies results in discontinuities in the function generator output. When in AC coupling mode, the DC offsets introduced by these discontinuities take some time to settle out. The program tries to adapt to this, but is not perfect. The main issue is at very low frequencies where there can be a DC offset decay that appears in the captured data. This is largely compensated by the DFT, but may affect noise measurement.
"
Yes, it does autoranging if you let it. But IIRC, @Frex mentioned that the error happens also without autoranging.
I mentioned autoranging for completeness, thank you for letting me know, didn't catch that what Frex said. I personally think it's probably something similar to that settling bug mentioned...symptoms look exactly like that..
Sorry to divert the conversation from Bode Plotting, but is anyone else annoyed by the "Sequence" a.k.a segmented memory mode?
If one configures it to capture X amount of frames, and then receive X+1 frames, it just wipes out the previous memory and starts from scratch.
I would expect it to either stop at X frames and go into History mode, or just use a circular buffer. Not wipe out ALL the old frames.
Sorry to divert the conversation from Bode Plotting, but is anyone else annoyed by the "Sequence" a.k.a segmented memory mode?
If one configures it to capture X amount of frames, and then receive X+1 frames, it just wipes out the previous memory and starts from scratch.
I would expect it to either stop at X frames and go into History mode, or just use a circular buffer. Not wipe out ALL the old frames.
It should stop after acquiring X frames.
Sorry to divert the conversation from Bode Plotting, but is anyone else annoyed by the "Sequence" a.k.a segmented memory mode?
If one configures it to capture X amount of frames, and then receive X+1 frames, it just wipes out the previous memory and starts from scratch.
I would expect it to either stop at X frames and go into History mode, or just use a circular buffer. Not wipe out ALL the old frames.
It should stop after acquiring X frames.
That's what I was expecting too, but it doesn't:
They've never done a good job at frames/segments...
I just make it work and dump the data before hitting it again
They've never done a good job at frames/segments...
I just make it work and dump the data before hitting it again
Yeah, doesn't look like this is specific to a model. I see same behavior on the SDS1000X-E too.
Sorry to divert the conversation from Bode Plotting, but is anyone else annoyed by the "Sequence" a.k.a segmented memory mode?
If one configures it to capture X amount of frames, and then receive X+1 frames, it just wipes out the previous memory and starts from scratch.
I would expect it to either stop at X frames and go into History mode, or just use a circular buffer. Not wipe out ALL the old frames.
It should stop after acquiring X frames.
That's what I was expecting too, but it doesn't:
What happens if you press single instead of run?