Beta Test: Multitone Loopback Analyzer software

[Guy.Cohen]

Thank you anyway

 

[pkane]

Thank you anyway

If you want, upload one of the history files for me to look at. There's only one setting that controls if calibration file is used or not.

 

[pkane]

A new preview/test update, MTA v1.1.12: https://app.box.com/s/ue7ll9xmvwogst817x2l1xg09opvgy47

New feature added: Interval Sweep. Like all other sweeps, this one allows multiple measurements to be placed on a chart. Measurements are done on a specified time interval, and repeated a specified number of times. As with other sweeps, the plot provides for a comparison of up to three different measured values which can be selected during or after the sweep completes. This provides for a way to measure changes in the DUT due to warm-up or other time-related effects.

Please test and provide feedback on anything that isn't working or can be improved.

 

[Rantapossu]

A new preview/test update, MTA v1.1.12: https://app.box.com/s/ue7ll9xmvwogst817x2l1xg09opvgy47

New feature added: Interval Sweep. Like all other sweeps, this one allows multiple measurements to be placed on a chart. Measurements are done on a specified time interval, and repeated a specified number of times. As with other sweeps, the plot provides for a comparison of up to three different measured values which can be selected during or after the sweep completes. This provides for a way to measure changes in the DUT due to warm-up or other time-related effects.

Please test and provide feedback on anything that isn't working or can be improved.

View attachment 367288

View attachment 367287

Thanks!

A couple of findings...

The round counter goes one step late. Like this with 10 intervals:

Step: Counter:
#1 ... 0/10
#2 ... 1/10
#3 ... 2/10
#4 ... 3/10
#5 ... 4/10
#6 ... 5/10
#7 ... 6/10
#8 ... 7/10
#9 ... 8/10
#10 ... 9/10

 

[Rantapossu]

There is no waiting time with every other interval period:

#1
Wait
#2
No waiting
#3
Wait
#4
No waiting
#5
Wait
#6
No waiting
#7
Wait
#8
No waiting
#9
Wait
#10
Stops

It makes the time-axis to look jumpy and the 10 minute measurement time drops to under 7 minutes:

 

[Sokel]

There is no waiting time with every other interval period:

#1
Wait
#2
No waiting
#3
Wait
#4
No waiting
#5
Wait
#6
No waiting
#7
Wait
#8
No waiting
#9
Wait
#10
Stops

It makes the time-axis to look jumpy and the 10 minute measurement time drops to under 7 minutes:

View attachment 367298

Confirm the late counter.
The time thing as I tested it seems ok but I only tested with very small time,I'll repeat with longer times.

 

[Sokel]

There is no waiting time with every other interval period:

#1
Wait
#2
No waiting
#3
Wait
#4
No waiting
#5
Wait
#6
No waiting
#7
Wait
#8
No waiting
#9
Wait
#10
Stops

It makes the time-axis to look jumpy and the 10 minute measurement time drops to under 7 minutes:

View attachment 367298

That's what it looks like with 30 sec,10 intervals.

 

[pkane]

Updated v1.1.12 with fixes for the reported two issues: https://app.box.com/s/ue7ll9xmvwogst817x2l1xg09opvgy47

• Fixed: counter starts at 0 not 1
• Fixed: interval can vary by a lot between successive captures

@Rantapossu , @Sokel - please check.

 

[Rantapossu]

Updated v1.1.12 with fixes for the reported two issues: https://app.box.com/s/ue7ll9xmvwogst817x2l1xg09opvgy47

• Fixed: counter starts at 0 not 1
• Fixed: interval can vary by a lot between successive captures

@Rantapossu , @Sokel - please check.

Thanks again!

Both issues fixed:

 

[Sokel]

Updated v1.1.12 with fixes for the reported two issues: https://app.box.com/s/ue7ll9xmvwogst817x2l1xg09opvgy47

• Fixed: counter starts at 0 not 1
• Fixed: interval can vary by a lot between successive captures

@Rantapossu , @Sokel - please check.

Thanks again!

Both issues fixed:

View attachment 367336

Here too,perfect!

 

[Rantapossu]

Hi @pkane !

I don't know if this is intentional, but I noticed that with the 1k, 2k, 4k and 8k FFT sizes my primary computer completely syncs the refresh rate of the waveform graph and the incoming signal. The end result is just like a traditional oscilloscope, the graph remains perfectly stationary with respect to the x-axis and the y-axis changes according to the measured signal. With 16k FFT and above the x-axis isn't synced any more and the graph jumps left and right with every refresh.

The secondary computer never syncs perfectly, but I can tweak it better by changing the FFT-sizes manually, tweaking FFT size for example from 8192 to 8184 makes it almost synced, only jumping like 10-20 pixels left or right when the graph refreshes.

If I'm just lucky and it was never intented to sync the waveform perfectly, would it be hard to implement some kind of zero-crossing trigger to the waveform view, so the waveform view would be synced regardless the computing power and FFT sizes when using a simple and repeating signal like sine?

That would be cool!

 

[pkane]

Hi @pkane !

I don't know if this is intentional, but I noticed that with the 1k, 2k, 4k and 8k FFT sizes my primary computer completely syncs the refresh rate of the waveform graph and the incoming signal. The end result is just like a traditional oscilloscope, the graph remains perfectly stationary with respect to the x-axis and the y-axis changes according to the measured signal. With 16k FFT and above the x-axis isn't synced any more and the graph jumps left and right with every refresh.

The secondary computer never syncs perfectly, but I can tweak it better by changing the FFT-sizes manually, tweaking FFT size for example from 8192 to 8184 makes it almost synced, only jumping like 10-20 pixels left or right when the graph refreshes.

If I'm just lucky and it was never intented to sync the waveform perfectly, would it be hard to implement some kind of zero-crossing trigger to the waveform view, so the waveform view would be synced regardless the computing power and FFT sizes when using a simple and repeating signal like sine?

That would be cool!

Somewhat by design The oscilloscope view is lower priority than waveform capture and processing, so if you have a slower computer (a laptop, for example), you may see some jumps because the oscilloscope isn't keeping up with the data coming in. Also, if you are using two different devices/clocks for DA and AD, or different sample rates for in/out, the clock drift will result in slow (or fast) motion of the sine wave across the screen, depending on the magnitude of the drift.

 

[Rantapossu]

Somewhat by design The oscilloscope view is lower priority than waveform capture and processing, so if you have a slower computer (a laptop, for example), you may see some jumps because the oscilloscope isn't keeping up with the data coming in. Also, if you are using two different devices/clocks for DA and AD, or different sample rates for in/out, the clock drift will result in slow (or fast) motion of the sine wave across the screen, depending on the magnitude of the drift.

I'm using a shared clock and same sample rates for both in and out, so I'm just lacking the oomph, I guess.

 

[pkane]

I'm using a shared clock and same sample rates for both in and out, so I'm just lacking the oomph, I guess.

That would be my expectation. Oscilloscope isn't tied to the spectrum view FFT rate. When you increase FFT size, you likely increase the load on the CPU leaving fewer cycles for the oscilloscope to process its data. I'll see if I can optimize this a little more by giving higher priority to the view that's currently on the screen.

 

[pkane]

I'm using a shared clock and same sample rates for both in and out, so I'm just lacking the oomph, I guess.

Out of curiosity, can you please try this version? I added the prioritization for what's on the screen, so hopefully the waveform/oscilloscope view will be less jerky:

https://app.box.com/s/ue7ll9xmvwogst817x2l1xg09opvgy47

 

[Rantapossu]

Out of curiosity, can you please try this version? I added the prioritization for what's on the screen, so hopefully the waveform/oscilloscope view will be less jerky:

https://app.box.com/s/ue7ll9xmvwogst817x2l1xg09opvgy47

Thanks, but it doesn't seem to help.

8k FFT is still the largest that syncs...

 

[Rantapossu]

With 8k FFT the processor load is about 13-14%, with 64k FFT it's something like 22-23%.

 

[pkane]

With 8k FFT the processor load is about 13-14%, with 64k FFT it's something like 22-23%.

Hmm. Are you sure you updated to the latest version? There shouldn't be any FFTs of the size you set on the Spectrum tab being performed while you're watching the oscilloscope plot.

 

[Rantapossu]

Hmm. Are you sure you updated to the latest version? There shouldn't be any FFTs of the size you set on the Spectrum tab being performed while you're watching the oscilloscope plot.

I downloaded it again and reinstalled. Maybe my PC was doing something in the background that made the CPU load rise last time?

Now it 13-14% load with 8k and 64k FFT. 512k FFT it's about 24% when watching the oscilloscope, so it might not be the CPU load.

But don't use too much your time with this, I can always switch to 8k FFT when watching the oscilloscope view for example to ballpark the clipping point and then switch back to bigger FFTs when doing the actual measurement with the right levels.

 

[Rantapossu]

Overall the new prioritizated version is much better than the old one, you can now cut the CPU load easily to half or even lower, if you use other view than the spectrum view during the measurement.

Please keep these changes, If they do not cause any drawbacks.