Products > Test Equipment

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

<< < (109/113) > >>

lfldp:

--- Quote from: csuhi17 on July 27, 2024, 11:09:24 am ---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.

--- End quote ---
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:


--- Quote from: radiolistener on June 22, 2023, 11:53:04 pm ---But 5 GS/s looks crazy even if they used equivalent time sampling, so I'm not sure if I decoded it properly...  :)

--- End quote ---

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

--- End code ---


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

--- End code ---

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:

--- Quote from: imyxh on July 31, 2024, 08:55:06 am ---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.

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod