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

[RAPo]

Old in the sense of the initial offering or v1.

[iceek]

Is there posibility to change menu language in menu or by flashing new FW?

[RAPo]

Is there posibility to change menu language in menu or by flashing new FW?

press move+power-on buttons together, choose language and press mod/ok

[csuhi17]

After a couple of hours of use, I wanted to turn it off and the screen crashed.
after pressing the power button again, it turned off normally.
I hope they release a bug fix soon.

Have they already replaced the incorrectly chosen capacities in the newer sold versions?

[ptluis]

I hope they release a bug fix soon.

Have they already replaced the incorrectly chosen capacities in the newer sold versions?

[battlecoder]

Have they already replaced the incorrectly chosen capacities in the newer sold versions?

I sold my "old" version and bought the new one a couple of months ago. I have not disassembled it, but considering what I saw in my tests after receiving the unit I don't think they did.
I didn't bother modding this new unit because even with "better" caps the problem wasn't fully gone. It was better, but still there.

I can check by opening the unit tomorrow, assuming people here are truly interested in knowing whether they made any change to the caps they picked for the new version 

[infino]

What's the sense of replacing it then?

[battlecoder]

What's the sense of replacing it then?

Just to be clear, the problem occurs when measuring low-frequency waveforms (up to a couple of KHz) in AC coupling mode, with the probe at 10x. If you don't replace the caps, you get a severely attenuated signal under those conditions. Replacing the caps improves the situation and lowers the attenuation by a lot, making it a lot more useful in those scenarios BUT it doesn't eliminate it entirely.

After I sold my old unit and got a new one I couldn't be bothered to do the mod, mostly because I've not used the device a lot, and but also because I'm already aware of the problem so I can avoid it by not using the probe at 10x with low frequency signals if I want AC coupling.

I might still do the mod, but it's not in my priority list.

[Randy222]

What's the sense of replacing it then?

Just to be clear, the problem occurs when measuring low-frequency waveforms (up to a couple of KHz) in AC coupling mode, with the probe at 10x. If you don't replace the caps, you get a severely attenuated signal under those conditions. Replacing the caps improves the situation and lowers the attenuation by a lot, making it a lot more useful in those scenarios BUT it doesn't eliminate it entirely.

After I sold my old unit and got a new one I couldn't be bothered to do the mod, mostly because I've not used the device a lot, and but also because I'm already aware of the problem so I can avoid it by not using the probe at 10x with low frequency signals if I want AC coupling.

I might still do the mod, but it's not in my priority list.

So in this case where 10x is an issue, is it better to use 1x with a divider network? Example pic.

[battlecoder]

So in this case where 10x is an issue, is it better to use 1x with a divider network? Example pic.

Well if you want to start adding external circuitry it would be simpler to try external ac-blocking first, since it's their selection of ac-blocking cap what is questionable (although I think at one point it was determined that the ac-blocking is happening after the input resistor that forms the voltage divider with the probe, and thus it's not as simple).

Now, I don't really do a lot of AC probing. At most I use AC coupling when measuring noise in switching supplies, but the frequency in those scenarios is usually is high enough for this to not be an issue, and if they were really low-frequency (in the <10 KHz range), I still could get around this problem by not using the probe at 10x.

If I had a need to measure high voltage low frequency AC signals regularly, I would definitely prefer to mod the unit over adding external circuitry or ignoring the issue.

[lfldp]

Hello I wanted to ask how long does this oscilloscope need to fully charge? The red diode has never changed color during charging or gone out, only the indicator at the top showed a higher battery charge - is this normal or did I buy a damaged model? Best regards.

[csuhi17]

in 3-4 hours.
If you turn it on, you can see it in the upper right corner of the indicator.

[lfldp]

in 3-4 hours.
If you turn it on, you can see it in the upper right corner of the indicator.

Ok thanks for the instructions. Yes I see the arrow and the increasing battery capacity while charging but the power button still lights red so what is the full battery indicator in this oscilloscope? How do I know that the battery is fully charged?

[lfldp]

in 3-4 hours.
If you turn it on, you can see it in the upper right corner of the indicator.

The problem is that the charge indicator increases to maximum after 30 minutes of charging - does this device have any battery charge detection?

[csuhi17]

To be honest, I don't know, I rarely use it, I mostly work with my Owon HDS272s.
I'm used to putting it on the charger and taking it off after a few hours.
I don't pay much attention.

I noticed that I have some charger that does not want to charge it.
It is possible that this is also a bug.

What you can possibly try, I just don't know with mine right now, because it's fully charged,
If it is almost completely drained, put it on a charger and turn it on after half or  an hour.
If it shows full, you disconnect the charging cable.
In theory, the charge level indicator will then dropt back down.

But I repeat, I have not dealt with such things, I just use it and charge it.
If the battery is half full, then 2 hours. If empty then 3-4 hours.

If you're really interested, you can monitor it with an external device or with a charging cable that displays current or power.

Or make something that disconnects the scope from the charger and tells you with an LED that charging is complete.

[lfldp]

To be honest, I don't know, I rarely use it, I mostly work with my Owon HDS272s.
I'm used to putting it on the charger and taking it off after a few hours.
I don't pay much attention.

I noticed that I have some charger that does not want to charge it.
It is possible that this is also a bug.

What you can possibly try, I just don't know with mine right now, because it's fully charged,
If it is almost completely drained, put it on a charger and turn it on after half or  an hour.
If it shows full, you disconnect the charging cable.
In theory, the charge level indicator will then dropt back down.

But I repeat, I have not dealt with such things, I just use it and charge it.
If the battery is half full, then 2 hours. If empty then 3-4 hours.

If you're really interested, you can monitor it with an external device or with a charging cable that displays current or power.

Or make something that disconnects the scope from the charger and tells you with an LED that charging is complete.

I understand you. I have a USB cable with a voltage monitor from what I remember after about an hour of charging the power dropped from 8-9W to 5W. I will repeat the tests today and describe what and how. Yes, it may be a bug and what is worse, if the voltage system does not disconnect the batteries, they may be damaged after some time.

[Dave_g8]

Hi,
Generally the charger will terminate at 10% of the preset charge current. So when initially charging a discharged battery, it will charge at a constant current of say 500mA.
As the battery is charged, the charging reverts to constant voltage and when the current falls to around 10% of the full charge current, 50mA in the example, the charging should terminate.
Many of the low-cost products may not support simultaneous charge and power, and therefor may not terminate the charge cycle if the device is turned on, this is because the current drawn is greater than the termination current.

[lfldp]

Thank you all for your help - I repeated the charging process and indeed the power dropped to 5W at first and after about 3 hours to 0W and the red power diode turned green, which means everything is working as it should.

[imyxh]

I just ordered a DPOX180H, and noticed those weird plots radiolistener was showing:

But 5 GS/s looks crazy even if they used equivalent time sampling, so I'm not sure if I decoded it properly... 

Very interesting! I decided to download some of the .wav data shared here. I'm no professional but I have a crazy idea about what's going on.

If you plot the .wav files in e.g. Python (try plt.plot(np.fromfile("foo.wav", dtype=np.uint16))), you will see that the noise seems to be an exact offset of 256 counts, up or down. See my attachment for an example.

In fact, it seems that bits 8:15 tend to flip too early. For example, here's an ascending sequence:

Code: [Select]

julia> string.([5323, 5631, 5428], base=2, pad=16)
3-element Vector{String}:
 "0001010011001011"
 "0001010111111111"    # <-- bit 8 flipped before it was supposed to!
 "0001010100110100"


where we can see that if we didn't flip bit 8 preemptively, it would've been a reasonable value. Similarly, a descending sequence:

Code: [Select]

julia> string.([10249, 9986, 10230], base=2, pad=16)
3-element Vector{String}:
 "0010100000001001"
 "0010011100000010"    # <-- bits 8, 9, 10, 11 flipped too early!
 "0010011111110110"

Hmm! My guess is that actually, somehow they are only measuring eight bits at a time of the uint16, starting at the least significant byte, and so there is a sort of race-condition where they check the lower byte, then the signal transitions to flip some bits in the upper byte, and then they check the upper byte. As a result you have a uint16 that is 256 too high or too low, depending on if the signal was increasing or decreasing at the time.

Is this a known trick? Maybe this is something that's happening in the FPGA? Or maybe they are using 8-bit ADCs and doing some clever switching?

Once my scope arrives I'll test and see if the same happens. If so I'll email FNIRSI, but I'm sure they already know about this. Maybe this is why they don't release info on the file format, and why they laser etch the ADC model....

In any case, for the purposes of data analysis on a signal much slower than your sample rate, this is probably trivial to fix in post—just scan along the data, and any time the upper byte increments, check if the lower byte is bigger than the lower byte of the next sample. If it is, decrement the upper byte. And same for the reverse.

[imyxh]

Hmm! My guess is that actually, somehow they are only measuring eight bits at a time of the uint16, starting at the least significant byte, and so there is a sort of race-condition where they check the lower byte, then the signal transitions to flip some bits in the upper byte, and then they check the upper byte.

Hahahaha. I'm stupid. I bolted awake to realize that this is not a race condition sort of thing, it's just that the data is big-endian, and starts at an odd offset.

Try np.fromfile("10MHz-1V.wav", dtype=">u2", offset=1) to read. Or increase offset if you want to skip all the metadata, etc.

I'll work more on the file decoding later but we have the basics down.

[imyxh]

I have found a new video showing a new bug/crash of this device when using the usb function. Try on your units to see if it happens.
https://youtu.be/NLNTrn9KVrk

Aha! I have this too on my Linux machine, but I fixed it.

After using Wireshark to capture the USB traffic, I found that the device was timing out after the host sent it an SCSI Read command, for 240 blocks. I then also found this: https://bugzilla.kernel.org/show_bug.cgi?id=219027

It seems like the DPOX180H can only buffer something like 128 blocks at a time over SCSI. Linux doesn't find out about this for interesting reasons (see bugzilla link) and the mass storage chip on the DPO fails to throw an illegal request error like it's supposed to but instead just completely crashes. This also explains the text disappearing afterwards. Windows is probably either playing it safe with low default maximum block limits or looking at the Block Limits VPD page.

So on Linux, one solution is to edit the udev rules like this:

Code: [Select]

$ cat /etc/udev/rules.d/fnirsi.rules
# DPOX180H seems to have a transfer limit of something like 128 blocks
ACTION=="add|change", SUBSYSTEM=="scsi", ATTR{model}=="F1Cx00S Disk    ", ATTR{max_sectors}="128"

and then of course do udevadm trigger. After doing that I was successfully able to mount the scope as mass storage and flash a firmware update to it.

I don't have a mac so I can't help there, sorry.