Did you change the Hardware number? 001 means generator present, and will work in any model.
Original "C" models have HW version .000
So you can enable the generator in both ways.
Yes, you are absolutely right. 2C10 with HW .001 has generator. I did not know this. And changing the model number only to 2D15 without changing HW number from .000 to .001 - 2D15 with HW .000 also enable generator. So to enable generator on 2CXX devices it's enough to change model number to 2D15 or to change HW number to .001. Thanks.
Another weird thing: 55 dots / division at 2ns.
That's 25GSps, something went crazy here!
Another weird thing: 55 dots / division at 2ns.
That's 25GSps, something went crazy here!
Perfectly normal for a Run/Stop capture. Try a Dot mode Single shot if you really want to see what's going on.
That was a single shot...
That was a single shot...
So what does a capture slow and then zoom in show ?
Here's a couple from a SDS1104X-E.
Hi guys, new to the forum. I'm in the market for an O-scope mainly for NTSC analog video. I wanted to see how the Hantek performs in this regard, displaying a CVBS signal. I want to see how good the resolution is in displaying it for noise issues and such. Thank You in advance.
Another weird thing: 55 dots / division at 2ns.
That's 25GSps, something went crazy here!
I think all is ok, except strange shift of waveform to the right from trigger position.
When you did not change the model number of your device from 2D10 to 2D15 could you please try to do it using the dso3kb_2D15_conversion.upk and say if there is the auto-reboot problem with black display? Thanks.
Sorry, I would not like to do any experiments with my device now, since I am using it intensively right now and I definitely need it on the weekend
So even the smallest probability of getting problems is not acceptable to me.
I understand. I send you a package dso3kb_reboot.upk which script has only one command - reboot
#!/bin/sh
reboot
This package does nothing - only reboots device. if you find a couple of minutes and run this package I would be very grateful to you.
Reboots correctly, as expected.
I think all is ok, except strange shift of waveform to the right from trigger position.
Yeah, mine was like, then at some point something weird happened. As you see it shows 25x more dots.
What about the 8ns steps when moving the Horizontal position? Does yours move in ~1 pixel steps?
Reboots correctly, as expected.
I would be happy to hear the same from
hcp.
My device reboots correctly with dso3kb_reboot.upk
Yeah, mine was like, then at some point something weird happened. As you see it shows 25x more dots.
What about the 8ns steps when moving the Horizontal position? Does yours move in ~1 pixel steps?
Yes, looks like minimal X step is really equal to 8ns..
Another question: what means"Realtime" and "Equ-time" option in dso2x1x? In many attepmts to use "Equ-Time" I found that it makes.. nothing.
No idea, I also asked that myself when I got the dso, but the manual doesn't say a word about it.
Another question: what means"Realtime" and "Equ-time" option in dso2x1x? In many attepmts to use "Equ-Time" I found that it makes.. nothing.
Interesting. Equivalent time sampling would mean phase shifting the sample moment over time to obtain a higher sample rate. Only works on repetitive signals. In this case of the Hantek hardware the question is if the FPGA is capable of making a small enough phase shift to make it worth while. With the max sample rate being 1GHz the phase shift needs to be in the order of 100 pico second range to make it usable. All depends on the PLL's and the speed of the interconnect fabric in the FPGA if this is possible. The external clock is most likely 50MHz, so the PLL has to crank this way up.
In the end I decided to make something with the unused Ethernet port.
I tried to run the Phoenix binary from another hantek model (4072C I think).
As expected, lots of errors happened, but it had enough time to wipe my eeprom.
Luckly I had a backup. In any case, I made a new package, "Eeprom backup".
It's similar to Backup builder, packs the required binaries and builds a restore package to make it simple.
Also added compiled i2c-tools and eeprog to the binaries section.
Signal generator square wave - is it normal
Signal generator square wave - is it normal
Well, "normal" depends on your measurement setup. Can you show a picture of it, and the specs of the probe?
See this thread I started on that subject
https://www.eevblog.com/forum/programming/oscilloscope-bandwidth-simulated-with-octavematlab/. It ended that I understood few important things about DSO and high-frequency measurements (and other about simulations).
Last but not least, I am building a 1 ns rise-time test generator
(according to the chip datasheet, an ICS512 that popped out a small drawer). BTW, ideas for a faster DIY rise-time test generator are welcome.
Paolo
bxxx firmwares are the same as 3xxx.
Ex. b000=3000, b101=3101. 3102 will probably show b102.
This must be something related to the fpga itself.
Today I was fighting with the SPI decoder, which decided to not work under any circumstances. Finally, I found it to only work at 5V/div.
Not really a problem, but
HANTEK COULD TELL THAT in their manual so we don't lose hours figuring out how to make it work.
3102 will probably show b102.
Yes, 3102 shows b102. Initially b000. Calibration OK.
Yep. Clearly, there're 2 FPGA types.
Copied from my FAQ, these are equivalent:
» 2013_A013
» 2015_A015
» 3000_B000
» 3101_B101
» 3102_B102
» 3200_B200
» 3202_B202
Yep. Clearly, there're 2 FPGA types.
Copied from my FAQ, these are equivalent:
» 2013_A013
» 2015_A015
» 3000_B000
» 3101_B101
» 3102_B102
» 3200_B200
» 3202_B202
If I change initial b000 to 3200 or to 3202 I've got b200 or b202 and calibration error. Only 3000, 3101 and 3102 - b000, b101 and b102 are without calibration error.