Magnova oscilloscope

[rf-messkopf]

Just a minor suggestion to improve the FFT markers. The displayed amplitude of a marker seems to refer to a single FFT bin, so when using them with a high resolution FFT, their setting accuracy can be well below much coarser than the FFT bin size. See, e.g., Markers 2 and 5 in quicksave_1_screen.png. They show different amplitudes at seemingly the same frequency. It is also impossible to manually set a marker to a certain peak when the FFT resolution is high.

I suggest to take the maximum of a certain range of bins around the marker center frequency as the displayed amplitude value. This range could be a percentage of the currently displayed FFT span, and could even be configurable; there is still some room left in the FFT marker configuration menu (quicksave_2_screen.png).

This is the way most spectrum analyzers do it. Also, a "move to next peak left/right" would be a nice feature.

Edit: Corrected the post.

[john74]

I have also a request for an improvement:

in the table view of a decoded CAN message (compact and detailed) the data field is packed too tight.
In all other decoder types the data bytes are seperated...see screenshot)

the 'compressed' form leads also to the bug, that the
data can't be shown as 'DEC' or 'ASCII'
(when the data contains only 1 byte, the conversion is ok)

also in the trigger options for CAN it should be posible to trigger at specific message-Ids
or data values (like in SPI or I2C)

and a vertical scroll bar would be handy if there are more entries in the table then the
height of the screen can show at once.
(this would eliminate the need to delete items from the list, when the time scale has changed afterwards)

and finally the minor "copy&paste" bug that says "write"
in the decoded message-id in the scope view instead of "ID"

[Andre77]

Just a minor suggestion to improve the FFT markers. The displayed amplitude of a marker seems to refer to a single FFT bin, so when using them with a high resolution FFT, their setting accuracy can be well below much coarser than the FFT bin size.

We have considered displaying the highest amplitude within all FFT bins of the selected display pixel column at the marker (and cursor). But this approach would have the disadvantage that it would no longer be possible to evaluate a specific frequency (and only this frequency) by entering a number in the “control selection” next to the rotary encoders, as all FFT bins in a pixel column would always be evaluated.

Your suggestion to evaluate an adjustable percentage of the span range for the markers is better. It may, however, not be suitable for logarithmic frequency axis displays. With a logarithmic frequency axis in the low frequency range, for example, a selection width of 0.2% of an 800 MHz display range could already be significantly too large. This could be mitigated by applying the percentage selection width to the marker frequency instead of the span width when using a logarithmic display.

All variants, however, still have the problem that the marker value can change when the view is changed (Span/Center or Start/Stop). We would therefore also allow 0% in the new percentage range selection (possibly even as the default value) to continue enabling the current precise frequency specification (single FFT-bin selection).

Also, a "move to next peak left/right" would be a nice feature.

Yes, that would be useful. Currently, in the marker table at the top right, you can use “set to peaks” to set the markers to all peaks in the peak table. But I understand that you would prefer something to jump from peak to peak.

Thank you very much for your suggestions and comments!

[Andre77]

I have also a request for an improvement: in the table view of a decoded CAN message (compact and detailed) the data field is packed too tight. In all other decoder types the data bytes are seperated...see screenshot) the 'compressed' form leads also to the bug, that the data can't be shown as 'DEC' or 'ASCII' (when the data contains only 1 byte, the conversion is ok)
[...]

Thank you for your detailed post and for highlighting these items. We’ve reviewed them: some were already tracked in our development ticket system, and the others have now been added.

[Gadolinium]

Hello there,

another Feature Suggestion:
Scopes that are used by different Users for different Setups would benefit from having presets. So that one can simply load a presets saved before and Not have to be Like "xy borrowed my scope and Set everything different".
I currently do this by using scpi commands to restore a certain setting, but having that in the scopes itself would be neat.

[jusaca]

So that one can simply load a presets saved before [...] in the scopes itself would be neat.

You can already do that: Go to
Save / Load (at the top menu bar) --> Setup --> Either save (and name) your preset or load an existing one.
You can either store on the internal memory or on external one to transfer you setup to another scope (or back it up)

[KungFuJosh]

Yup. You can already save/load complete setups, and also measurement setups.

[Gadolinium]

Ah, i totally missed that one, thanks for the heads up!

[KungFuJosh]

There's a lot of features to find in the scope.

I love the measurement setup saving separately too. Sometimes I want a clear screen, and others I want an exact set. Two seconds to setup either way!

[john74]

Has somebody tried to decode a CAN-FD data frame with bitrate switching above 1Mbit/s ?

When I try this, the scope can't decode the data field any more.
(I attached three screenshots with different data field bitrates...500kbit, 1Mbit, 2Mbit)

The expected data packet is a single data byte with 0x55, and a crc with 0x339b.
I can't detect any timing problems and the general communication seems to be fine.
(data packets with 2Mbit and up to 64bytes length are transfered between two STM32 boards without any error)

Maybe the decoder in the BMO has a problem with BRS > 1MBit?
(besides...it would be a neat feature to be able to config the sample point (or visualize the data sampling points) of the scope :-)

[john74]

And me again...

I like the scope very much and not many companies
are willing to listen to their customers...so here I have another shot.

The reduced design philosophy with only 4 hardware knobs is fine with me,
the handling with touch/mouse is flawless.

But there are some trigger types where only 3 knobs are assigned.
At least in "Timeout", "Pulse", "Interval" the 4th knob could be used for something.
(e.g. to change the compare time value...would make sense for me)

And just curious is there a reason why the trigger coupling can't be set to "AC"?
(or am I too stupid to find the button)

[Ulrich.G]

And just curious is there a reason why the trigger coupling can't be set to "AC"?
(or am I too stupid to find the button)

My guess is, because the trigger logic is behind the ADC, there is no separate analog trigger signal path, therefore any coupling settings making no sense.

[Andre77]

Has somebody tried to decode a CAN-FD data frame with bitrate switching above 1Mbit/s ?
When I try this, the scope can't decode the data field any more.

Thanks a lot for pointing this out! We’ve already started testing this on our side and can reproduce the behavior. This is not what we expected to see, so we’re currently investigating the root cause. Once identified, we’ll address it in a firmware update. I’ll post an update as soon as we have more details.

I like the scope very much and not many companies are willing to listen to their customers...so here I have another shot.
The reduced design philosophy with only 4 hardware knobs is fine with me, the handling with touch/mouse is flawless.

But there are some trigger types where only 3 knobs are assigned. At least in "Timeout", "Pulse", "Interval" the 4th knob could be used for something.
(e.g. to change the compare time value...would make sense for me)

And just curious is there a reason why the trigger coupling can't be set to "AC"?

Thanks a lot for the kind words — really appreciated 😊

Regarding the 4th encoder:
Good point. For trigger types like Timeout, Pulse and Interval, it indeed makes sense to consider assigning the fourth knob to something like the compare time parameter. We’ll review this internally.

About AC trigger coupling:
As Ulrich already mentioned, this is related to the fully digital trigger architecture used in the scope. The trigger is derived directly from the ADC sample data.

One of the key advantages of this fully digital trigger approach is that it works directly on the real, sampled signal data. This allows:
- Low trigger jitter (no separate analog comparator path)
- High timing precision
- Freely adjustable hysteresis
- Complex trigger conditions implemented purely in the digital domain
- Perfect consistency between what you see and what the trigger “sees”

However, in this setup, there is no separate analog trigger path where an AC coupling could simply be inserted. With traditional analog trigger circuits, AC coupling can be implemented in hardware before the comparator.

Thanks again — feedback like this is super valuable for us.

[john74]

However, in this setup, there is no separate analog trigger path where an AC coupling could simply be inserted. With traditional analog trigger circuits, AC coupling can be implemented in hardware before the comparator.

Ahh, ok...I came up with that because all my digital scopes that I owned in the past and all the scopes in our lab at work have an "AC coupling mode" for the trigger.
But now I assume that all these scopes have an analog trigger path...'you never stop learning', thanks.

[rf-messkopf]

However, in this setup, there is no separate analog trigger path where an AC coupling could simply be inserted. With traditional analog trigger circuits, AC coupling can be implemented in hardware before the comparator.

Ahh, ok...I came up with that because all my digital scopes that I owned in the past and all the scopes in our lab at work have an "AC coupling mode" for the trigger.
But now I assume that all these scopes have an analog trigger path...'you never stop learning', thanks.

Well, you could also do that in the digital domain, i.e., subtract the DC component (mean value) of the samples over a suitable time interval before you feed them into the trigger engine. But I do not really see what benefit this would add with a digital trigger.

That said the Magnova trigger system and the frontend are truly awesome. 

[john74]

I myself rarely used this option. Last time was to probe different analog oscilator signal traces with different voltage offsets. In "AC" trigger mode you don't have to manualy adjust the trigger level at each trace and you still can measure the offset...but yes, this is a corner case.

[Ulrich.G]

On the yt channel https://www.youtube.com/@OsziWissen there is a detailed, several videos long, test of the Magnova scope. In one of the episodes it is noted, that Batronix might evaluate whether its possible to run all four TI ADC channels with 1.6MSamples/sec simultanous. If so, is there already any result of this evaluation?

[FloBX]

On the yt channel https://www.youtube.com/@OsziWissen there is a detailed, several videos long, test of the Magnova scope. In one of the episodes it is noted, that Batronix might evaluate whether its possible to run all four TI ADC channels with 1.6MSamples/sec simultanous. If so, is there already any result of this evaluation?

Hello Ulrich,

currently, the Magnova switches to 1 GSa/s as soon as CH3 or CH4 is enabled.

We have evaluated the possibility of allowing 1.6 GSa/s on CH3 and CH4 when CH1 and CH2 are inactive. From a technical standpoint, this would be feasible. However, given other higher-priority improvements and feature developments, we have not yet decided to implement this enhancement in the near term.

From a hardware perspective, all four channels are equally capable of achieving the specified maximum bandwidth. That said, 1 GSa/s will remain the maximum sample rate whenever more than two analog channels are active.

There's a lot of features to find in the scope.

I love the measurement setup saving separately too. Sometimes I want a clear screen, and others I want an exact set. Two seconds to setup either way!

This feature originated from a conversation with a Magnova user at Embedded World 2025 (I'm not sure whether he is active here as well ). We discussed several options and ultimately agreed on the current solution.
Trade fairs such as EW are always a great opportunity to talk in person. We appreciate hearing your impressions and discussing suggestions.

If you're planning to attend, feel free to request free fair tickets at batronix.com: https://www.batronix.com/shop/batronix/free-tickets.html.

Best regards
Florian
Batronix

[KungFuJosh]

If you're planning to attend, feel free to request free fair tickets at batronix.com: https://www.batronix.com/shop/batronix/free-tickets.html.

I would love to! Does that include free airfare and a hotel too? 

[MASCH]

Hi,

I have just received a test unit of the Magnova BMO-350 for evaluation to compare it to my Yokogawa DLM2034.
Both scopes feature 350 MHz of bandwidth.

I also have the Batronix MSO demo board, which has some nice signals to help with the evaluation.

One of the signals is a relatively fast rise time square wave.
In comparison to the Yokogawa scope, I noticed that the signal representation of the Magnova with the Testec probe is not as good as the "old" Yokogawa scope, which is almost perfect.
I have also used the Yokogawa probe in combination with the Magnova oscilloscope, it is still not as good even though it has improved.

Has anyone noticed something similar?

BTW, I have checked if the probe compensation of the probe is the issue, but I was not able to improve the result beyond what is shown.

In general I like the Magnova, but it lacks a few features which the Yokogawa has like

- 16 different lowpass filters per channel
- Histograms
- Trend plots of single captured waveforms (pwm cycle-by-cycle duty cycle calculation and display in a graph)
- Separate windows for every channel

In the moment I am not sure if I can trade the features and the measurement quality of the Yokogawa for 12 bits and faster update rates.... Somehow the Yokogawa feels more professional

[kaspich]

Non-critical bug noticed.
Saved profile: Roll mode; Time Scale 1s; HiRes=ON
Right after powering up, the trace/picture is moving unevenly (like a push every 250ms). When the first screen is filled (after 12 seconds), the bug disappears.

[rf-messkopf]

Has anyone noticed something similar?

Just a very quick test with the signal generator, rise times set to 8.2 ns (the minimum on my Keysight 33521B). First a TESTEC MF-212 el cheapo probe (passive, 250 MHz) that I use as daily drivers, and second a R&S RTM-ZP10 500 MHz passive probe (the OEM is PMK, I don't know the model number offhand). Not as fast as your edge, but in both cases I see what I expect.

I don't have time right now (it's Saturday evening  ) but tomorrow or next week I could test this again with the probes supplied with the Magnova (TESTEC TT-HF 612RA) and a faster edge.

Maybe you have a grounding problem? How was the probe ground connected to the test board?

[MASCH]

Very interesting your measurements look so much better.

Maybe this is due to the fast rise time?

I don't think it's a ground connection issue, as you can see in the following picture, I have used a very small ground loop for all measurements.

[Martin72]

Very interesting your measurements look so much better.

In order to compare something, you have to create the same conditions, which was not the case here.
I measured it again, using the same probe type and the same channel with 1.6GSa/s.
I don't consider the result to be cause for concern, especially since a fast slope meets a 1M input resistance here.
This always depends on the interaction between the probe and the front end.
As a result, it looks significantly “better” with direct and 50 Ohm termination.
So that shouldn't influence your decision for or against Magnova.
Edit 50R pic new (500mV/Div)

[KungFuJosh]

I have just received a test unit of the Magnova BMO-350 for evaluation to compare it to my Yokogawa DLM2034.

I'd like to see a photo of the two scopes side-by-side.

BTW- Magnova is supposed to get separate windowing too (eventually).