Magnova oscilloscope

[john74]

Hi John,
thanks for reporting this. We are already looking into it and will provide an appropriate solution as soon as possible.

I just realized, the bug with the cursor in the math channel only appears, when trigger is STOPPED.
(in case you can't reproduce it)

[Performa01]

Yes, my example shows cursors exclusively in the zoom view. That's because we use zoom to inspect signal details within a longer record. But then the main window is just an overview and navigation aid. One might still apply automatic measurements to the main window, but not many would want to use fiddly cursor measurements there. And the fact, that we're using Zoom hints on quite some fiddling with cursors in the main window. While it's nice to have that little rectangle indicating the zoomed portion of the record in the main window, I cannot see any advantage in having a cramped copy of the zoom cursors there - we just don't need that information. The zoom rectangle together with the cursor position in the zoom window tells us enough about the position of the cursor measurement in relation to the complete record.

I would counter argue against that and would miss the cursors in the main window. Because I often need to measure the time delay between two events
(maybe also between two different signals)

And here I need a very precise way to set both X-Cursors (with the help of the zoom window) to the start and the end of the events
and these two events won't fit together in the zoom window at the same time....so either Cursor-A or Cursor-B should be visible on the main window as reference all the time.

Agreed, for this very use case, cursors in the main window can be handy. But until now, we were talking about tracking cursors. You usually don’t need tracking cursors to measure non-local (hence long) time differences.

Furthermore, I believe that in many cases, the start, end or other relevant positions within an event will have some sort of edge – as long as the event is not mostly noise (where you could not position a cursor precisely anyway). Of course it could also be a peak, but since there cannot be a peak without associated edges, we might just need to accept a little time offset.

In cases where the above stated is true, automatic measurements of a modern DSO can make cursor measurements completely obsolete.

To demonstrate the principle, I’ve set up a simple example, where the events are just 50 ns wide pulses, with a repetition rate of 1 MHz. This example measures the time between the falling edge of the 20th pulse to the rising edge of the 70th pulse, using a selectable threshold for both edges. The result is ~50.95 µs, and we can even activate measurement cursors to let the DSO show us what has been measured; look at the first screenshot.

This measurement works also with two different channels.

The following two screenshots demonstrate just the classic cursor measurement. On the device shown, the numbers are still associated with the zoom window and the cursors in the main window are just for quick positioning and reference purposes.

[john74]

Today I testet the new CAN decoder view.
Limit of my hardware is 4Mbps can clock...
so I tested: 500kbps, 1Mbps, 2Mbps, 4Mbps with CAN frames up to 64 databytes
(see screenshot)

The decoder is working with all these settings and the table view make sense now.

One last thing is missing though...The trigger type "decoder" is not working for CAN messages
or at least you can't setup any filter like CAN-START, CAN-ID or message data content,
so the trigger will never hit.

[john74]

And a question for a different topic:

Is there any technical reason why the history buffer gets cleared when there is a switch between
"single trigger events" and "normal/auto trigger events" ?

At the moment you can store multiple "normal" or "auto" trigger events and the buffer get's filled (or overwritten, when the buffer is full).
The same goes with "single" trigger events, you can store multiple events and the buffer get's also filled (or overwritten).

But when there are already elements in the buffer from "single trigger" events and you create a "normal/auto" trigger event, the buffer gets cleared.
Also when there are elements in the buffer from "normal/auto trigger" events, the buffer gets cleared by the next "single" trigger event.

[FloBX]

[...]
I just realized, the bug with the cursor in the math channel only appears, when trigger is STOPPED.
(in case you can't reproduce it)

Hi John,
thanks for the additional information. A fix has already been implemented and will be included in an upcoming firmware update.

Today I testet the new CAN decoder view.
Limit of my hardware is 4Mbps can clock...
so I tested: 500kbps, 1Mbps, 2Mbps, 4Mbps with CAN frames up to 64 databytes
(see screenshot)

The decoder is working with all these settings and the table view make sense now.

One last thing is missing though...The trigger type "decoder" is not working for CAN messages or at least you can't setup any filter like CAN-START, CAN-ID or message data content, so the trigger will never hit.

Thank you for testing the CAN decoder and for sharing your feedback. CAN trigger functionality has not yet been implemented, even though the trigger type "Decoder" allows the corresponding decoder group to be selected. Starting with the next firmware version, a corresponding warning will be displayed to make this clearer.

And a question for a different topic:

Is there any technical reason why the history buffer gets cleared when there is a switch between "single trigger events" and "normal/auto trigger events" ?

At the moment you can store multiple "normal" or "auto" trigger events and the buffer get's filled (or overwritten, when the buffer is full).
The same goes with "single" trigger events, you can store multiple events and the buffer get's also filled (or overwritten).

But when there are already elements in the buffer from "single trigger" events and you create a "normal/auto" trigger event, the buffer gets cleared.
Also when there are elements in the buffer from "normal/auto trigger" events, the buffer gets cleared by the next "single" trigger event.

Our software team has already looked into this behavior. At the moment, switching between Single and Run mode resets the history because the two modes are handled slightly differently internally. We will further evaluate whether switching between them can be made possible without clearing the history.

Best regards
Florian
Batronix

[john74]

@Florian and Andre,

i really appreciate the quick response of you and all of the Batronix team to our feedback...that's not a given in this industry I must say.

but here I have the first response to a "new feature" that I not like (maybe I am alone with this 

With the new "auto trigger timeout" there is now way to trigger on "slow" or "rare" events when "auto trigger mode" is enabled

When I set up a trigger event (let's say "falling edge on CH-1")....
I am interested exactly in this event and want the osci to capture this event when it happens
and I don't care about the update rate at this moment...1 wfms/s would be enough to set the trigger point or move the channels into the right spot.

In the "old" version 1.8.2 you could do that. In "auto" mode the update rate was (e.g. 4 wfms/s @ 200us/div and every trigger event was captured and stored into history buffer, regardless how slow)
In the "new" version 1.9.3 you can't capture rare events in "auto" mode anymore. The update rate is much higher now 140 wfms/s but what's the point in that, when the trigger is ignored?

Maybe other users are good with this new behavior and they can tell me why I am wrong.

[jusaca]

I would argue that seems like a job for the "normal" trigger mode, not auto.

[john74]

another finding:
in roll-mode the "extended capture" setting is only working when the "single trigger" button is used.

during "roll-mode" after pressing "stop" the data on the left hand side is allways cut to the visible screen width.
(for slow signals it could be handy to see more of the previous data, especially when you have to stop the measurement manually and you are not quick enough 

[john74]

and me again....
another "not so intuitive behaviour" is the quicksave of a screenshot
when you are using the menu to input a filename.

You can choose a file name for your file let's say "T1" ... this file is then saved as "T1_screen.png".
If you are saving a second file with name "T2" this is saved as "T2_screen.png"
(I am sure adding the "_screen" tag serves some purpose...but that's not my issue)

My problem is that you can't overwrite an already existing file in the "standard" workflow:
1. Press "save"
2. Select the file to overwrite (e.g. "T2_screen.png")
3. Press "ok"

with this approach you create a third file with the name: "T2_screen_screen.png"
(see screenshots)

If you want to overwrite a file, you have to manually delete the "_screen" tag from the file name before saving,
or type in the name "T2" again.
(and maybe there should be also a warning before overwriting an existing file)

[Andre77]

another finding:
in roll-mode the "extended capture" setting is only working when the "single trigger" button is used.

during "roll-mode" after pressing "stop" the data on the left hand side is allways cut to the visible screen width.
(for slow signals it could be handy to see more of the previous data, especially when you have to stop the measurement manually and you are not quick enough 

Thanks for the detailed feedback!

As you already noticed, Extended Capture is not active during the live Roll Mode display. If it were, the roll display would effectively have to start several divisions beyond the right edge of the screen, and the incoming signal would only become visible after roughly 6 × the selected time scale.

By pressing Single, you bypass the live Roll Mode display and perform a normal acquisition instead. That acquisition supports Extended Capture, which is why you can access the additional data in this case.

and me again....
another "not so intuitive behaviour" is the quicksave of a screenshot
when you are using the menu to input a filename.

You can choose a file name for your file let's say "T1" ... this file is then saved as "T1_screen.png".
If you are saving a second file with name "T2" this is saved as "T2_screen.png"
(I am sure adding the "_screen" tag serves some purpose...but that's not my issue)

My problem is that you can't overwrite an already existing file in the "standard" workflow:
1. Press "save"
2. Select the file to overwrite (e.g. "T2_screen.png")
3. Press "ok"

with this approach you create a third file with the name: "T2_screen_screen.png"
(see screenshots)

If you want to overwrite a file, you have to manually delete the "_screen" tag from the file name before saving,
or type in the name "T2" again.
(and maybe there should be also a warning before overwriting an existing file)

There is a reason for the suffix: Quick Save can be configured to save several different items at once, for example setup, waveform data, FFT, Bode plot data, decode data, masks, references and screenshots. The filename selected in the Quick Save menu is therefore treated as a base filename, and a suffix is added for each selected file type. This is necessary because some of them can also use the same file extension.

So if T2_screen is selected as the base filename, the screenshot currently becomes T2_screen_screen, while FFT data would become T2_screen_fft.

We agree that adding the suffix is not really necessary when only a single file type is selected. With the upcoming update, suffixes will therefore only be added when more than one item is saved with Quick Save. This will also avoid the duplicated _screen suffix in your example.

You probably already know this, but for everyone following along: Magnova also supports {date}, {time} and {counter} in filenames. These can be quite handy for Quick Save and help avoid accidentally overwriting previous captures.

[KungFuJosh]

You probably already know this, but for everyone following along: Magnova also supports {date}, {time} and {counter} in filenames. These can be quite handy for Quick Save and help avoid accidentally overwriting previous captures.

I would suggest an option to avoid overwrites. If File Exists - Option 1a: Overwrite filename if no variables exist to avoid overwrite. Option 1b: Automatically add a counter suffix to avoid overwrites.

Thanks,
Josh

[Andre77]

Hi everyone,

today we are releasing Magnova firmware version 1.9.6.

Changelog (with respect to version 1.9.3):

Optimizations:

• Single acquisitions no longer invalidate the acquisition history.
• Changing the y-cursor position now disables cursor tracking.
• Added a warning when decoder triggers are unavailable.
• Added a unit for the amplitude in the FFT peak table.
• Added SCPI commands for :BPLot:CONTrol.

Bugfixes:

• Fixed an issue where cursor tracking could temporarily use an incorrect time position.
• Fixed an issue where cursor tracking remained active while its source was inactive.
• Fixed an issue where text input in the trigger number editor could no longer be used after changing the number base.
• Fixed an issue where loading settings or default settings did not reset the trigger time in roll mode.
• Fixed an issue with parallel decoder triggering when signals were inverted in the corresponding trigger configuration.
• Fixed missing SCPI cursor commands.

As always, thank you for all the feedback, bug reports and feature suggestions. Your input continues to shape the development of Magnova and is greatly appreciated.

Please do not hesitate to contact Batronix support if you have any questions or comments.

Best regards
Andre

[rf-messkopf]

Thanks for the update. This has been discussed before, but the problem of the limited y-resolution of the cursors still seems to be present in the latest FW 1.9.6.

See the attachment: Cursor A is set to track the magenta curve, and it is consistently below it. This is apparently due to the y-resolution of the cursor position being limited to 1 µV.

Also the offset position of the math channel is limited to 1 µV. This is not a problem here, but it could be a problem if a different scaling is used on the math channel.

[blackdog]

Hi,

I loaded the new firmware onto the Magnova scope this afternoon.
I was trying to figure out why the frequency counter wasn't working; it turned out to be the "Level" was set to "0."
I think it would be handy to set this to (auto) by default, so you can always see that the counter for the channel you’re setting is working—then you can adjust it to the desired setting later if needed.

2e
I was a bit disappointed with this firmware, though; after 8 months of firmware updates, it still have the pre... abberation with fast pulses.

I first connected the 50-ohm cable carrying the fast pulse from a generator at the end to a -20 dB attenuator and then connected it to the 50-ohm input of three different oscilloscopes,
and only the Magnova displays the pre-aberration. (One oscilloscope at a time, of course.)
The pre-attenuation is not visible on a Siglent or a Hameg oscilloscope, both with 500 MHz bandwidth and 50 input impedance.
Will this issue be addressed in the next firmware update, please... 
 
See the picture below for the pre-ringing with a fast puls in the red box.


I haven't had time yet today to test all the other features.
By averaging the counter readings and also averaging some of the acquisition data, the counter readings become quite stable, which I'm happy about.

Kind regards,
Bram

[KungFuJosh]

I was a bit disappointed with this firmware, though; after 8 months of firmware updates, it still have the pre... abberation with fast pulses.

You think it's a problem with the Magnova, because scopes with slower waveform update rates didn't catch it?

[rf-messkopf]

I first connected the 50-ohm cable carrying the fast pulse from a generator at the end to a -20 dB attenuator and then connected it to the 50-ohm input of three different oscilloscopes,
and only the Magnova displays the pre-aberration. (One oscilloscope at a time, of course.)

I don't see any preshoot or pre-ringing with a similar setup (50 ohms output and a 10 dB attenuator) on the Magnova. The ringing after the edge is real and not an artifact.

The pre-attenuation is not visible on a Siglent or a Hameg oscilloscope, both with 500 MHz bandwidth and 50 input impedance.
Will this issue be addressed in the next firmware update, please... 

Which scope models and which settings did you use? This effect may have been masked due to limited vertical resolution. Certainly, this is nothing firmware related.

[blackdog]

Hi KungFuJosh,

I don't think there's a huge difference between the waveform display on my 500 MHz Siglent scope and the Magnova.

I think it has to do with the digital filtering that takes place during and after sampling.
I only have a cheap USB scope that exhibits pretty much the same behavior.
Of all my oscilloscopes (except for the cheap USB one, that is), none of them have this pre-ringing aberration.

I hope Andre77 can take a look at this and tell us what Magnova thinks might be causing it... 

Kind regards,
Bram

[john74]

Of all my oscilloscopes (except for the cheap USB one, that is), none of them have this pre-ringing aberration.

Hi Bram,

the Magnova has a 12bit ADC.
Could it be, that on your other two scopes the y-resolution is lower or you don't have used the same y-setting (50mV/div)
and therefore the measurements are different?

[Martin72]

Hi Bram,

Do you have any more detailed data about your signal input?
The frequency is clear, but what about the amplitude and slope?

[john74]

As follow-up:
if you zoom into your screenshot, the "ringing" has a delta of only 4 pixel in height (see screenshot).

An oscilloscope with the same display resolution and hardware specs as the Magnova but with a 10bit ADC instead of 12bit
would show here a flat line with the height of 1 pixel, because the resolution is only 1/4.

[KungFuJosh]

I don't think there's a huge difference between the waveform display on my 500 MHz Siglent scope and the Magnova.

Whether this is the reason you catch it or not, there's no competition between your 500MHz Siglent and the Magnova. There isn't a 500MHz Siglent model that comes close. I made this comparison before:

SDS2504X HD: Normal mode up to 100,000 wfm/s
SDS3000X HD: up to 200,000 wfm/s in normal mode
SDS5000X HD: up to 160,000 wfm/s in normal mode
SDS6000A: up to 170,000 wfm/s in normal mode
SDS7000A: up to 1,000,000 wfm/s in normal mode, but only 1,100,000 wfm/s in sequence mode

Magnova ≥ 300,000 wfms/s in normal mode, ≥ 12,000,000 wfms/s in history mode

[blackdog]

Hi KungFuJosh,

I still don't think it has much to do with the number of waveforms per second.

The effect I'm seeing after some experimentation depends on the sample clock and the waveform being measured.
I'll post some pictures later today; also, the effect only occurs if the waveform being measured has very steep edges—say, less than 2 nsec.

I am currently using my HF generator (Siglent SSG3021X) to measure the frequency response of the Magnova and the Siglent SDS2104X with the 500 MHz bandwidth option installed.
The Siglent SDS2104X HD does not exhibit the pre-aberration I indicated.
However, the bandwidth profile between 50 MHz and 600 MHz is clearly different on the Siglent SDS2104X HD then the Magnova.

I also see other anomalies that I don't see in the same way on the Siglent oscilloscope.

With a 200 MHz sine wave and approximately 100 mV rms applied to the oscilloscope, I again see something that shouldn't be there at a time base of 50 nsec.
See the two images below with different time base settings.

I didn't scale down the image with the 50 nS time base because doing so would cause too many image processing errors.

200MHz ~100mV RMS and 2nSec time base

.

Same signal and now 50nSec time base, and no there is no modulation on the signal from my HF generator.

.

Lets compare with the SIGLENT SDS2104X HD
200MHz ~100mV RMS and 2nSec time base

.

Look Ma! no amplitude variation on the Siglent 

.

Then there's another counter issue: I've tried a variety of combinations, and while not all of them result in an error, the two measurements below do.
Again, the 200 MHz sine wave signal of 100 mV from the RF generator.
The fact that the reading isn't exactly 100 mV is due to the frequency response of the oscilloscope.

In the first image, everything is OK; the counter accurately displays nearly 200 MHz.
Here, the signal to be measured is fed into channel 4, and the counter function is also set to channel 4.

.

It's the same situation, but now I've also turned on channel 1—which I'm not using for anything else—and then the value of the counter function is no longer correct...
If I now turn on channel 2 as well, the counter still shows incorrect values.

.

And now for the fun part: if I turn on channel-3, the counter is correct again—Bingo!  Always fun with Magnova!

.

Time is up for now, but more to come.
Let me know what my measurement aberations are. 


Kid regards,
Bram

[tautech]

Ouch ! 
Is the Averaging (10) affecting the measurements ?

[blackdog]

Hi tautech,

When i'am back from lunch i will test it whitout averaging.
And if there is time, also some pre-aberation pictures.

Kind regards,
Bram

[nctnico]

I was a bit disappointed with this firmware, though; after 8 months of firmware updates, it still have the pre... abberation with fast pulses.

You think it's a problem with the Magnova, because scopes with slower waveform update rates didn't catch it?

AFAIK pre-ringing shouldn't exist in the real world. It likely is a problem with the sin x/x reconstruction because that can introduce pre-ringing.

The waveform modulation effect blackdog shows looks like a display decimation issue to me.