New toy(?) scope Fnirsi DPOX180H, claimed 180MHz/500MSps (May 2023)

[infino]

I don't understand your situation? Do you have the trigger set on channel one or channel two?
I emulated your situation and set all settings on the first channel and everything works without errors.


According to your screenshot, you have the sensitivity set to -5mv on channel 2,
and the oscilloscope probe is reacting to interference.
Either disconnect the probe or short the probe.

And 200mv is the setting in your first channel.

I would like Fnirsi to correct the information on the screen, if the second or first channel of the oscilloscope is off, it should not be displayed on the screen and not misleading.
In my example, the second channel of the oscilloscope is off in the menu and the screen shows its sensitivity as 5mv

[csuhi17]

I tried the other settings a bit and uploaded the picture from CH2, I tried to see if the error was the same on both channels.
I made a video, although the focusing didn't work out, if it's not clear I can try to make a better recording.

Turn the volume down a bit, I didn't manage to record the button being pressed.
https://youtu.be/Yu_mY6qaujg

They behave a little differently, CH1 is denser while CH2 is less frequent.
If both channels are active, there was no error.

I also did the factory reset and then the calibration.


I changed the video link, the old one was of very poor quality.

[battlecoder]

I tried the other settings a bit and uploaded the picture from CH2, I tried to see if the error was the same on both channels.
I made a video, although the focusing didn't work out, if it's not clear I can try to make a better recording.

Turn the volume down a bit, I didn't manage to record the button being pressed.
https://youtu.be/lXHz0NwcT0w

They behave a little differently, CH1 is denser while CH2 is less frequent.
If both channels are active, there was no error.

I also did the factory reset and then the calibration.

Couldn't replicate this, but I assume it's just picking up noise from the environment. If you are doing this near strong switch-mode DC supplies, LED strips or AC halogen lights try turning them off and see if it makes any difference. Normally oscilloscopes wouldn't pick up much noise without probes attached (which would them act like antennas) but I don't think this device has a lot of shielding other than the tin can covers on both channel inputs (which is honestly more shielding than I was expecting from a device like this).

[Nik]

Found a way how to edit FNIRSI's custom wave that is used for scope generation. it is by drawing samples in an audio software and tweaking in hex editor due to a bug in audio editor

https://youtu.be/OiMUORkPghE

Below are screenshots before and after modification.

There upto 298 samples per capture that you can edit and then supply into Fnirsi DPOX180H back to use as output for its generator.
The format of samples is 8 bit. Low values corresponds to high amplitude. So to output max amplitude, draw waveform down. That is why the picture in audio editor looks mirrored vertically. Samples with values (low amplitude) will be clipped in output up to the values that shown on the screenshot below. It seems the very first 4 bytes in file are not samples as they have following format: 2 bytes is waveform number shown in built-in browser and the next 2 bytes is the length of waveform. I prefer to do not touch it as I am afraid it can broke or hang the scope. Sample number starting from 4 are the ones that safe to modify for the first Capture. I noticed that last sample in waveform is 0. Not sure does it go to generator to make waveform or used for other reason. All captures are stored in one file.

I tried to find its limit by output single sample at a highest frequency. Rise time is 20ns per volt.

I found that sometimes this audio software mess up with the file by incrementing every byte by one when it save file, including the metadata such as capture number and length of waveform making it useless. Sometimes it works fine. Not sure what cause issue. Sounds like an issue in that particular audio software. So final tweaks I made in hex editor, otherwise FNIRSI hangs upon opening captures browser.

How to modify:
- Capture some waveform with the scope
- connect scope to pc
- copy file Captures\data.cap to Captures.raw
- open the file Captures\data.raw with the audio software WavaPad as unsigned 8 bit raw data. That software accepts file extension raw, so before loading file needs to be renamed as .raw.
- Click on the draw button and draw by holding down the mouse button over waveform starting from sample number 4 upto the amount of samples written in bytes 3 and 4 (u16). There also audio effects, including filters and a form generator to have more fun.
- You will also see your previous captures there and be able to adjust them.
- When finish, save the file
- Open in hex editor to make a final tweak with data if necessary as audio software can mess up with indexes and frame length by incrementing data by 1.
- Rename back to data.cap.

Which waveform would be cool to see?

I also looked at the format of saved waveforms, the ones that creates by pressing SAVEW button. It seems 16 bit, 48k samples per file and can also be seen with the audio editor using the same technique. I guess audio data can be played, but might need some speed and pitch effect to be applied.

[battlecoder]

Found a way how to edit FNIRSI's custom wave in scope generator by drawing in an audio software 

I also looked at the format of saved waveforms, the ones that creates by pressing SAVEW button. It seems 16 bit, 48k samples per file and can also be seen with the audio editor using the same technique. I guess audio data can be played, but might need some speed and pitch effect to be applied.

This is very useful information! We can totally make a waveform editor with this.
 

[csuhi17]

I apologize for my poor wording and the poor quality of the video.

It is true that there is a lot of noise where I recorded the first video, 100V/m measured with ER02. I don't know how accurate this value is and how much it can be confusing.

I recorded the video again, this time sitting in my car, with a phone that at least has auto focus.

https://youtu.be/Yu_mY6qaujg

Unfortunately, I don't know the language well, I use the translator, I hope I can write intelligibly.

The error appears for me when only one channel is active.
The CH1 channel manages to produce up to this level. The CH2 rarely does it.

I reduce the time to 5ns-50ns and the voltage to 5mv/Div.
I press an ORIG button, then move the trigger line up and press the STO/RET button, while moving the trigger line even higher.

There is a part in the video when I set the voltage of CH1 to 10V/Div and the error is still there.

The error is after 1:30 in the video, I was a bit unlucky before that.
And around 2:30 you can see that when I increased the voltage to 10 Volts.

I first noticed the error when I was looking at the trigger delay in single-shot mode.
None of my scopes behave this way, so I'm interested in what the reason is.

[battlecoder]

I apologize for my poor wording and the poor quality of the video.

It is true that there is a lot of noise where I recorded the first video, 100V/m measured with ER02. I don't know how accurate this value is and how much it can be confusing.

I recorded the video again, this time sitting in my car, with a phone that at least has auto focus.

https://youtu.be/Yu_mY6qaujg

Unfortunately, I don't know the language well, I use the translator, I hope I can write intelligibly.

The error appears for me when only one channel is active.
The CH1 channel manages to produce up to this level. The CH2 rarely does it.

I reduce the time to 5ns-50ns and the voltage to 5mv/Div.
I press an ORIG button, then move the trigger line up and press the STO/RET button, while moving the trigger line even higher.

There is a part in the video when I set the voltage of CH1 to 10V/Div and the error is still there.

The error is after 1:30 in the video, I was a bit unlucky before that.
And around 2:30 you can see that when I increased the voltage to 10 Volts.

I first noticed the error when I was looking at the trigger delay in single-shot mode.
None of my scopes behave this way, so I'm interested in what the reason is.

Ok so after playing with this A LOT, I managed to reproduce the issue but not consistently. It happened to me very rarely, and it was normally after using ORIG and 50% and then moving the trigger line or the waveform manually and re-arming the trigger again, at which point it would do what it's doing to you for a couple of seconds, and then it would behave normally.

So you might be right, there could be something weird there. Maybe the sampling buffer it's just treated as a circular buffer and any remnants of previous readings actually trigger the capture. But that would be me just randomly guessing at this point.

[csuhi17]

Unfortunately, it's rare for me when it works well.
with the given setting.
But since I already know about it, I will be able to handle it.
fortunately, there is no such error at 100nS.

I hope it's just some software glitch.

I looked at several waveforms to upload. But the mistake was independent of that.

I am patiently waiting for the next firmware

[Nik]

I played more with FNIRSI's custom generator and created in a software some test waveforms that anybody can use by copying attached Captures.zip into FNIRSI's internal disk:

1. Sweep sine 1 to 10. Good stuff to check built-in filters or get frequency response out of something.

2. Peaks to see built-in generator resolution. It can handle just a bit over 20 MHz.

3. Interleaved Hi-Lo to see the highest frequency sine the generator can make.. 44 MHz. Can be used in case if default 20MHz not enough.

As they were made with software, they are precise, ie in wave3 hi and low goes strictly one by one making whole waveform perfectly cycled. In wave1 Sweep sine is also precise as it was generated by a software and values have no noise. In wave 2 there is a pattern where you can see how much you can squeeze built-in generator as there is a pattern with hil-lo-hi samples and lo-hi-lo and single hi and single lo.

It seems generator supports a bit more than 300 samples at low freq, but FNIRSI software has some limitation.

Another thing is upon pressing SAVEW device records upto 48k points into file. 48k points for 5uS/div 1x Probe whereas on screen device shows only 48k/(5us*12divs*2ns per sample)=30k points for that time base and hides others.

[infino]

Either the oscilloscope is defective or there is a lot of interference.
You can also short-circuit the input and check.

My oscilloscope stopped charging a couple weeks ago, was the culprit ip2312
Already repaired,  who will face the problem, pay attention, the chip has a ground pad on the body, unsolder with a hot air

[csuhi17]

I have already tried, if there is noise, it should not occur at 10V/Div sensitivity, and the error only occurs if the above conditions are met.
By moving the baseline lower, the error is eliminated.

My fast edge generator arrived today, 50kHz 180ps rise time, 300Vrms. 300mVrms.

Direct BNC connection, I don't have to fiddle with the wire.
It's a bit tricky because you can't screw it onto the connector because it's countersunk, but fortunately the contact is good.

I tried it with AUTO trigger and in Single, unfortunately it didn't work as I wanted.

The rise time, if I managed to get it right, is 2.8ns at best, based on 0.35/rise time = 125Mhz.
My TO1104 gave the same result.

Could it be a result of replacing the capacitor? Kerry Wong got 1.8ns.

The other picture is with STO2202C.

[battlecoder]

I have already tried, if there is noise, it should not occur at 10V/Div sensitivity, and the error only occurs if the above conditions are met.
By moving the baseline lower, the error is eliminated.

My fast edge generator arrived today, 50kHz 180ps rise time, 300Vrms.

Direct BNC connection, I don't have to fiddle with the wire.
It's a bit tricky because you can't screw it onto the connector because it's countersunk, but fortunately the contact is good.

I tried it with AUTO trigger and in Single, unfortunately it didn't work as I wanted.

The rise time, if I managed to get it right, is 2.8ns at best, based on 0.35/rise time = 125Mhz.
My TO1104 gave the same result.

Could it be a result of replacing the capacitor? Kerry Wong got 1.8ns.

The other picture is with STO2202C.

To rule out the capacitor as the culprit for this result, you can just set the CH1 coupling to DC (the capacitor was, supposedly, the AC blocking capacitor so shouldn't be part of the circuit when set to DC).
Having said that, considering the lack of horizontal timebase resolution, and the fact that rise-time measurement has to be done by hand with cursors over a span of a handful of pixels, I don't think we can get any real bandwidth measurement this way.

I tried with mine, and got somewhere in the vicinity of 150Mhz, for example. Keep also in mind that the probe could be affecting the result. I assume that you used the supplied probe in x10 (because I don't think it would've been wise to connect 300Vrms directly with a coax), and that probe, in my opinion, is not great. In my admittedly limited testing, it looks very non-linear over the 200Mhz range that should cover. If you sweep a generator over that range, you will see the amplitude go up and down by a considerable margin (or at least mine do).

[csuhi17]

It behaves in the same way in AC and DC mode, I managed to find out based on many tests.
voltage sensitivity does not matter.
The first two are that the trigger is set to single shoot and falling edge.

The third is that only one channel should be active.

The fourth is that the base line should be in the top 4 pieces /Div, that is, the middle line and above. with the ORIG button, e.g.

The fifth is that the trigger line should be above the base line.

The sixth is the time setting.
5ns-50ns 200ns, 2us

It does it almost all the time at 5ns-50ns and 200ns.

It is probably what you wrote that something remains in my memory and triggers it, but that signal is not visible on the display.

I did not use a cable, it is connected directly to the BNC input.

Oops, sorry, not 300Vrms but 300mVrms.

[solidhit]

The new version v40 of the firmware has been uploaded to the official FNIRSI support page.

[battlecoder]

The new version v40 of the firmware has been uploaded to the official FNIRSI support page.

Thanks for the heads up. I ran a binary comparison between the file on FNIRSI's website, and the one that was posted in this thread, and they are identical.

[infino]

The rising edge of the signal is now better visible,
but I would like it to be even brighter.

[csuhi17]

Another comment,

If I start setting the time base with the H- button, the display update apparently freezes at 20s/div, even if I press the V+, V-, H+, H- buttons, it does not respond. more precisely, it doesn't respond to anything except the arrows!

If you reach 20s/Div.
Try to set the voltage sensitivity in any direction, it is best if you set it to half where you should hear the relay click.
You will not.
Then you press one of the buttons and it sets all values to the way you pressed the buttons. be it voltage or time value.

[infino]

I'll have to write to them and have them fix it.

[Nik]

I'll have to write to them and have them fix it.

I have seen it once week ago.
Now it disappear. Not sure is it related, but  I updated firmware and format internal disk.

Maybe you can record the issue on video with exact steps to reproduce from scratch and show on video your settings and probe settings in case if it is related.

[battlecoder]

Another comment,

If I start setting the time base with the H- button, the display update apparently freezes at 20s/div, even if I press the V+, V-, H+, H- buttons, it does not respond. more precisely, it doesn't respond to anything except the arrows!

If you reach 20s/Div.
Try to set the voltage sensitivity in any direction, it is best if you set it to half where you should hear the relay click.
You will not.
Then you press one of the buttons and it sets all values to the way you pressed the buttons. be it voltage or time value.

Just tested this and it happens to me as well. I truly hope they fix bugs like this soon.

I really want to like this oscilloscope. The display is a treat, the menus are also very well organized and close to what you would get on a bench scope (at least closer than other handheld scopes). temp-coloring of the waveform is also a huge thing. Being able to capture parts of a wave to use in the generator is also fantastic, and the bandwidth seems to be pretty high for something of this price range and size. But the bugs are very frustrating (also after playing a lot with the probes I realized that I definitely need to change them. They are extremely bad).

Bugs aside, I really dislike how hard they made it to use the cursors, since they only a delta between vertical and horizontal for both channels (even when the other channel is disabled). I'd like to have X1, X2, Y1 and Y2 values, as well as ΔX and ΔY. Since there's a single timebase the readings of X1, X2 and ΔX don't need to be done "per channel". The Y measurements will of course depend on both the vertical offset of the channel, as well as the scale, so they could either display only the measurements on the currently selected channel (so if you switch to CH2 it would measure on CH2 params) OR, they could add a setting in the "cursors" menu that allows you to select the channel on which the cursor measurements are performed. Alternatively, they could display two small windows, one for CH1 and another one for CH2. That would waste screen space, but it's kinda what they are doing now by showing you measurements of CH2 even when it's not even enabled.

[csuhi17]

I think the vertical cursor is a big bug, I don't see any point, especially if the two channels have different sensitivities.
Has anyone been able to use it for anything?
The question is why they haven't fixed it yet, even though they know.

I hope they add a persistence feature, then it will be possible to use it at least as much as the DSO2512G.

However, it is a good thing that they at least deal with it and have it repaired,
I have an instrument of a higher quality manufacturer, which I bought when it was released, but they added a new series and it went to the compressor... it has functional shortcomings, although the hardware could handle it, no updates...

[battlecoder]

I think the vertical cursor is a big bug, I don't see any point, especially if the two channels have different sensitivities.
Has anyone been able to use it for anything?
The question is why they haven't fixed it yet, even though they know.

I hope they add a persistence feature, then it will be possible to use it at least as much as the DSO2512G

Yeah, the cursors are nearly unusable like this. I also hate that you can "move" and change CH2 or CH1 params even when a channel is not enabled, but that's a minor annoyance.

Persistence would be great, really.

I still can't believe that the DSO2512G, which is more basic in every possible way; has a simpler, crude trace display, extremely basic menu system (although shortcuts massively help), severely limited bandwidth (doesn't get anywhere near the claimed 120Mhz), no capture-and-replay arbitrary waveform functionality, no 20Mhz bandwidth limit, no temperature-colored trace, etc, still outmatches this scope when it comes to actually using it to make measurements or debug circuits  , but that has also been my experience so far.

[Aldo22]

severely limited bandwidth (doesn't get anywhere near the claimed 120Mhz)

I wouldn't put it that harshly.
It is certainly no longer in its comfort zone "up there", there is some jitter and the amplitude drops, but mine can definitely trigger and measure 120 MHz sine.
That is at least something. E.g. OWON HDS272 can't do that.

Otherwise, I agree with you that the Zeeweii is a no-frills tool.

[battlecoder]

severely limited bandwidth (doesn't get anywhere near the claimed 120Mhz)

I wouldn't put it that harshly.
It is certainly no longer in its comfort zone "up there" and the amplitude drops, but mine can definitely trigger 120 MHz sine.
That is at least something.

Otherwise, I agree with you that the Zeeweii is a no-frills tool.

I like the Zeeweii, but at least my unit becomes very jittery above 50 Mhz, even with "overclock" mode enabled (which is according to the manual how it can get to >100Mhz). It' already a bad sign when the manufacturer recommends you to temporarily engage "overclock" mode to reach the claimed bandwidth). So I'm not willing to call the Zeeweii a 120Mhz scope. I tend to consider it more of a 50Mhz scope, and that's already more than acceptable for the form factor and price.

[Aldo22]

I like the Zeeweii, but at least my unit becomes very jittery above 50 Mhz, even with "overclock" mode enabled (which is according to the manual how it can get to >100Mhz). It' already a bad sign when the manufacturer recommends you to temporarily engage "overclock" mode to reach the claimed bandwidth). So I'm not willing to call the Zeeweii a 120Mhz scope. I tend to consider it more of a 50Mhz scope, and that's already more than acceptable for the form factor and price.

I know what you mean and it can be put that way.
It's a bit like asking whether the bottle is half empty or half full.
I also find that it works quite well up to 50MHz and a less well above that, but that's enough for me at this price.
Nevertheless, I can check with this cheap device on which frequency a FM test transmitter works (88.0 MHz - 108.0... MHz) and you can't do that with every toyscope.
It also does not need 3 volts at the input for that, like my AWG with "frequency meter", but a few millivolts are enough.
I find that for its price it is quite a useful device and it does not annoy me.

The Fnirsi costs at least $40 more and that is quite a difference at this price level. Almost not comparable.