Magnova oscilloscope

[wandering_traveler]

I’m very interested in the Magnova scope. I understand that Batronix has plans to make this available in the US for personal use- are there any updates on this? I know that with our “dear leader” handing out tariffs like candy, it’s hard for any company to make long term plans- US or international. But it would be nice to have a rough idea of a timeline.

As a side note, I sent an email to service@batronix.com with this question, but never got a reply. So a couple of weeks later I tried with a different email account, and still no answer.

[KungFuJosh]

Likely this year.

Besides the dumbass tariffs, there's also a tedious process for getting goods approved / certified for consumer sales.

Thanks,
Josh

[Gadolinium]

One idea would be to highlight the upper and/or lower grid boundary in red whenever a clipping event occurs. This would provide a subtle yet effective visual warning without cluttering the display.

 Another Idea:
Do it the way the newer tektronix scopes do it - give the channel button on the right side of the screen a bright red box around it if the signal is out of range or was out of range in the last x seconds. If you have multiple traces on the Screen you need to know which of them went out of range - and when looking to that red box around the channel button, you can also immediatly see it's current V/div setting.

[Andre77]

I’m very interested in the Magnova scope. I understand that Batronix has plans to make this available in the US for personal use- are there any updates on this? I know that with our “dear leader” handing out tariffs like candy, it’s hard for any company to make long term plans- US or international. But it would be nice to have a rough idea of a timeline.

As a side note, I sent an email to service@batronix.com with this question, but never got a reply. So a couple of weeks later I tried with a different email account, and still no answer.

Thank you for your interest in the Magnova scope.

We had planned to complete the required U.S. approvals by the middle of last year. However, due to a period of significant regulatory and economic uncertainty, we decided to pause the project rather than move forward under unclear conditions.

We recently restarted the process, and we’re cautiously optimistic that we can complete it within the next three to four months.

Not everything was put on hold during the pause. For example, we had already begun the US trademark registration for “Magnova” at that time, and that lengthy process has since been completed.

Regarding your emails, that’s definitely not our goal. All inquiries should be answered, and I’d like to look into what went wrong in this case.

If you're comfortable doing so, please send me a private message with the email address you used (or the name you included in the message), and I'll look into it internally.

[Thomas]

One idea would be to highlight the upper and/or lower grid boundary in red whenever a clipping event occurs. This would provide a subtle yet effective visual warning without cluttering the display.

 Another Idea:
Do it the way the newer tektronix scopes do it - give the channel button on the right side of the screen a bright red box around it if the signal is out of range or was out of range in the last x seconds. If you have multiple traces on the Screen you need to know which of them went out of range - and when looking to that red box around the channel button, you can also immediatly see it's current V/div setting.

I like how Rohde & Schwarz do it.
Little red arrows indicating clipping top and bottom.
These indicators are readable through remote interface too. Useful.

[john74]

here another bug (version: 1.7.2),
this time in SPI decoder with "compact" view of the data

when MOSI and MISO are enabled in the decoder, then the compact view is listing both data frames
(here as example with the same content) as expected

when only MOSI or only MISO is enabled, the decoding is ok but the compact view
no longer shows the data frames.

also the caption of the data always shows "MOSI"
(in compact and detailed mode) ...should be "MISO" when only MISO is enabled.

[john74]

Some kind of overload or clipping indicator would be helpful, especially when focusing on the FFT, as it's easy to miss an occasional clipped peak in the time domain. It's easy to misinterpret a distorted FFT if you don't notice that the ADC has been saturated.

the same "problem" goes with a math channel, when the corresponding source channel is either clipping at the top or bottom
of the visible window.

[Andre77]

when MOSI and MISO are enabled in the decoder, then the compact view is listing both data frames (here as example with the same content) as expected

when only MOSI or only MISO is enabled, the decoding is ok but the compact view no longer shows the data frames.

Thank you for letting us know. You are right - at the moment, the new compact table view requires both MOSI and MISO to be enabled in order to display data frames. We will fix this bug (together with the MOSI/MISO table header) with the next update.

We will also address the issue you previously reported where the x-grid time labels disappear after tapping a decoded element in the table view. The root cause is that the time position is currently set with excessive precision (too many decimal places) when jumping to a decoded element. These extra decimal places do not fit within a grid label, which causes the labels to disappear.

To fix this issue, we will limit the number of decimal places to a reasonable number when selecting decoded elements in the table and when moving vertically using touch.

[kaspich]

Basic settings:
Roll mode: on
Resolution: high/16bits

Signal (transient/noise) captured in Roll mode (1sec/div). Stopped. Zoomed in.
Problem: incorrect replay when a 200us Time scale is selected.
Pay attention to the two spikes marked in red.

[kaspich]

The same signal.
Time Scale 200us.
Time Offset changed step by step

[kaspich]

And one annoying nuance. Numbering/sorting/displaying of saved screenshots.
Screenshots are correctly numbered/saved (their numbers are incremented correctly), but displaying is… How to correctly say…
Guys, please try to save, let’s say 30..50+ screenshots and you will see the problem (1;2;20;21…29;3;30, e.t.c).
Please add an option to sort them by date/time at least.

[KungFuJosh]

Please add an option to sort them by date/time at least.

That is an option already. Go to your file save settings and click on the file name default. You'll see options to add date and/or time to the filenames. When time is added, the consecutive numbering will only apply if multiple screenshots are taken at the same time.

[john74]

The same signal.
Time Scale 200us.

you can't display/analyse such a high frequence signal (in your case ~70kHz or higher)
with a time resolution of 200us/div

use 20us/div or 10us/div to display the signal
and this "artefacts" should be not visible anymore

[S13]

Basic settings:
Roll mode: on
Resolution: high/16bits

Signal (transient/noise) captured in Roll mode (1sec/div). Stopped. Zoomed in.
Problem: incorrect replay when a 200us Time scale is selected.
Pay attention to the two spikes marked in red.

Not sure about the Magnova scopes, but in general this is what Peak Detect sampling mode is designed for. Maybe try that?

[john74]

Maybe I was wrong with the "aliasing effect".
I measured noise with 1Gs/s and 100us/div (without roll-mode).
And here you can see the same artefact when moving the x-axis at 100ns/div.
When interpolation is set to "S&H" the artefact is gone....

[kaspich]

Guys,
Everything is fine when 1ms; 500us; 100us; 50us, 20us Time Scale is selected. Peak detect, aliasing – everything works perfectly! So, something is wrong exactly at 200us!
Anyway, regardless of peak detection and aliasing, the signal shape should remain the same when I am scrolling (changing Time Offset). And again – the problem persists only in 200us!!!
About files/their names. I am talking about sorting.
I am fine with auto-numbering, and I would prefer not to waste my time renaming captured screens. The problem is – when the list is displayed, all captured files are displayed ‘’by name’’. By name (in this case) means – 1;10;11..19;2;20;21..29;3;30; etc. So, ‘’old’’ files are mixed with ‘’new’’ ones!

[kaspich]

Guys,
Everything is fine when 1ms; 500us; 100us; 50us, 20us Time Scale is selected. Peak detect, aliasing – everything works perfectly! So, something is wrong exactly at 200us!
Anyway, regardless of peak detection and aliasing, the signal shape should remain the same when I am scrolling (changing Time Offset). And again – the problem persists only in 200us!!!
About files/their names. I am talking about sorting.
I am fine with auto-numbering, and I would prefer not to waste my time renaming captured screens. The problem is – when the list is displayed, all captured files are displayed ‘’by name’’. By name (in this case) means – 1;10;11..19;2;20;21..29;3;30; etc. So, ‘’old’’ files are mixed with ‘’new’’ ones!

It’s a software bug/problem! Yes, pretty popular for cheap China-made crap, but Magnova is a ‘’bit different’’ class tool! So, data are captured/stored. Moving of Time Offset – a steady/unchanged picture should move left/right. Without any exceptions! The only limitation – resolution of the display (which is HD version, pretty high resolution). And, even if the display is not capable of recreating an exact short/narrow spike (or this spike is ‘’between" the display’s pixels), the software should fix this problem. In my example – we clearly see that when 1ms; 500us Time Scale is selected, the software correctly recreates both spikes (marked in the first photo). It seems that at 200us all these peak detect/aliasing features are disabled. Why? That’s the question.  

[woody]

What I would do is send an email to Batronix with this question. They should be your first port of call.

In my experience they are very receptive when their clients encounter stuff that might be a bug. And, also in my experience, they take the time to explain stuff that might be caused by me not understanding something. Furthermore, if something turns out to be a bug they are very active in solving it asap. Very different from the 'China-made crap' you mentioned.

[kaspich]

What I would do is send an email to Batronix with this question. They should be your first port of call.

In my experience they are very receptive when their clients encounter stuff that might be a bug. And, also in my experience, they take the time to explain stuff that might be caused by me not understanding something. Furthermore, if something turns out to be a bug they are very active in solving it asap. Very different from the 'China-made crap' you mentioned.

People are using this forum to report bugs and make recommendations. I assume Andre B will see my posts soon

[john74]

Sorry, maybe my previous post was not clear enough. I also think that is a bug because the artefact is only visible at a single time scale. In all other time settings the data is shown correctly.
Let's wait what Batronix has to say about that.
The "problem" is very easy to reproduce.

[kaspich]

It seems I figured out what’s happening.
If the signal is captured in Roll mode, for slow Time Scale settings, linear interpolation is used. When a faster (closer to samplerate) Time Scale is selected, the scope selects Sine interpolation (if Sine/default interpolation is selected in the Display/Waveform menu). Moreover, some ‘’simplified algorithms are used for lower Time Scale settings, as the result – ‘’waving’’ of traces when Time Offset is changed.
Linear interpolation (if selected in the Display/Waveform menu) looks more predictable (no more overshoots and waviness).
Anyway, my opinion – the same/selected interpolation method needs to be used for all Time Scale settings, and bug with ‘’simplified’’ capturing also needs to be fixed.

[FloBX]

Hello kaspich,

what you are seeing is a display effect related to waveform interpolation.

At 200 µs/div with a sample rate of 500 kSa/s, the number of acquired samples is only slightly lower than the horizontal display resolution. This is right at the transition point where the oscilloscope switches from showing raw samples to using interpolation (in this case Sinc interpolation). In this “edge case,” small features such as narrow spikes can appear unstable or seem to shift because they fall "between display pixels" and the interpolated points vary depending on the time offset.

If you move slightly away from this setting (for example, to 100 µs/div or 500 µs/div), the behavior improves noticeably because there are either clearly fewer or clearly more samples per screen column. Alternatively, selecting Interpolation = None (Points) or Sample and Hold will always show the acquired samples directly and avoids this effect entirely.

We are aware of this transition region and evaluated alternative handling during development. In the end, we chose to follow the same interpolation behavior used by most modern digital oscilloscopes, where interpolation begins as soon as the displayed sample density falls below the rendering resolution.

Best regards
Florian
Batronix

[kaspich]

Hello kaspich,

what you are seeing is a display effect related to waveform interpolation.

At 200 µs/div with a sample rate of 500 kSa/s, the number of acquired samples is only slightly lower than the horizontal display resolution. This is right at the transition point where the oscilloscope switches from showing raw samples to using interpolation (in this case Sinc interpolation). In this “edge case,” small features such as narrow spikes can appear unstable or seem to shift because they fall "between display pixels" and the interpolated points vary depending on the time offset.

If you move slightly away from this setting (for example, to 100 µs/div or 500 µs/div), the behavior improves noticeably because there are either clearly fewer or clearly more samples per screen column. Alternatively, selecting Interpolation = None (Points) or Sample and Hold will always show the acquired samples directly and avoids this effect entirely.

We are aware of this transition region and evaluated alternative handling during development. In the end, we chose to follow the same interpolation behavior used by most modern digital oscilloscopes, where interpolation begins as soon as the displayed sample density falls below the rendering resolution.

Best regards
Florian
Batronix

Thanks for the feedback!
Question – if/when we are looking at the saved data, it’s a LOT of time, so, sinc interpolation can be used even for slower Time Scale settings (larger amount of data) instead of raw data displaying. This would fix this issue.
Also, there is one more issue. When sinc interpolation is enabled/used (in this example, at 200us, at 100us), the captured signal ‘’waves’’ when the Time Offset is scrolled. It seems some averaging/buffering (1/8; 1/4; ½)before using the sinc algorithm is used. Please check this, too! 

[kaspich]

Question to the community/Batronix: maybe it’s useful to add ‘’samples/div’’ [equivalent samples/div] on the screen?
Otherwise, to understand how trustable the data are, every time I need to take into account: samplerate; selected resolution (if hires mode is enabled; to check this setting, additional menu needs to be opened); BW limitation (again – BW sign is visible, but exact setting: no – additional menu needs to be opened); Time Scale.
I offer the following solutions:
Value ‘’equivalent samples/div’’ is displayed on the screen, or
If ‘’equivalent samples/div’’ is less than X [for example, 10], sampling points are additionally highlighted/added to the traces

[Ranayna]

Please add an option to sort them by date/time at least.

That is an option already. Go to your file save settings and click on the file name default. You'll see options to add date and/or time to the filenames. When time is added, the consecutive numbering will only apply if multiple screenshots are taken at the same time.

"FileShart"? Really?
Is that a specific term thats just flying *way* over my head right now, or an unfortunate typo?