Hantek DSO-5200A PC oscilloscope teardown

[Uwe Hermann]

Hi everyone,

We're working on getting support for oscilloscopes in sigrok (an open-source software for logic analyzers), hence the need for some test hardware such as this. So here's a quick teardown of the Hantek DSO-5200A PC oscilloscope, in case anyone is interested.

For more photos and info see the respective sigrok wiki page, don't want to re-upload every file here:

http://sigrok.org/wiki/Hantek_DSO-5200A

The main CPLD or FPGA is under a heatsink unfortunately (which I wasn't able to remove without risking to damage the device so far). There seem to be two ADCs on there (markings were removed, though), some SRAM, and one Cypress FX2 for transferring the data to the PC.


Have fun, Uwe.

[Bored@Work]

For more photos and info see the respective sigrok wiki page, don't want to re-upload every file here:

http://sigrok.org/wiki/Hantek_DSO-5200A

You know that people have already written Linux drivers for this DSO, including firmware extraction tools?

http://sourceforge.net/projects/openhantek/

And a second one

http://sourceforge.net/projects/hantekdso/

Do you really think it makes sense to re-invent the wheel a third time? Or is there something fundamentally wrong with the existing software?

[free_electron]

 i wouldn't call any of those supported devices 'logic analyzer'. They are streamers that capture at a fixed interval with some simple protocol decoders in software.

Here's a couple of key problems that make them unworthy of the name Logic Analyzer.

- Virtually none of the 'analyzers' like the Salea, Usbee and all the other clones can run in lock-step with a clock. They are self clocking. Debugging a synchronous system becomes a problem as you see all the intermediate states and need to filter this out.
- Virtually none of these devices have sequence triggering: If this condition is true , and within this time frame ,that condition becomes true , while another condition has not occurred ... or some other crazy sequential/ timed pattern. Such trigger systems require a complex programmable sequencer that can react on the incoming data on-the-fly. If you want to do that flat-out you need serious horsepower. Real analyzers often have a custom programming language or come with a flowchart-like gui where you can setup these crazy conditions. This stuff needs to be done in hardware as it happens during the capture

Other problems :
-Almost none of these machines have internal memory , making them dependent on USB throughput. Jiggle the mouse and there is a risk of packet drop.

[Uwe Hermann]

For more photos and info see the respective sigrok wiki page, don't want to re-upload every file here:

http://sigrok.org/wiki/Hantek_DSO-5200A

You know that people have already written Linux drivers for this DSO, including firmware extraction tools?

http://sourceforge.net/projects/openhantek/

And a second one

http://sourceforge.net/projects/hantekdso/

Do you really think it makes sense to re-invent the wheel a third time? Or is there something fundamentally wrong with the existing software?

Actually, there's also Digital Soda and Oscope2100, and probably others.

http://sourceforge.net/projects/dsoda/
http://sourceforge.net/projects/oscope2100/

So yes, we're aware of them. Most of them support some Hantek device but maybe not others, and that's OK. No, there's nothing fundamentally wrong with them, they all have their uses, and they're all open-source so it's all nice and dandy.

There's also no reason for us (as in "the sigrok project") to not support these Hantek devices, however. Just as we already support many different logic analyzers from various companies, we also want to support many different PC oscilloscopes (and DMMs, and MSOs, and...) from many different companies in the nearer future. This includes those Hantek devices, of course. Why would we not support them? But this also includes various other scopes too, Velleman PCSU1000, PicoScope 2203, Voltcraft DSO-3062C, Rigol DS1052E, and whatever else we can get our hands on.

sigrok is intentionally designed to not be restricted to one specific (set of) devices, but rather to be a generic framework which can support all kinds of devices via a flexible "driver" mechanism. So yeah, there will be some overlap with other projects and we will also support some hardware which is already supported by other projects, but we don't see that as a problem really.

Cheers, Uwe.

[Bored@Work]

i wouldn't call any of those supported devices 'logic analyzer'. They are streamers that capture at a fixed interval with some simple protocol decoders in software.

They are happy little boxes, available for little money, some in the pocket money range. Most important, they provide a useful function for those working in the supported low frequency ranges with relatively simple signals.

Why would we not support them?

Because someone has to maintain all the code. Judging from the list of planned device support you are going to pile up a huge amount of code for a lot of devices. It is for sure fun to rule such an empire, but you need subordinates, too, to do the work. You project is a niche project, I don't think you have to fend off developers with both hands. Maybe it is better to concentrate on a few things, do them right and complete them, instead of starting 20 things, and promising a lot.

[free_electron]

i wouldn't call any of those supported devices 'logic analyzer'. They are streamers that capture at a fixed interval with some simple protocol decoders in software.

They are happy little boxes, available for little money, some in the pocket money range. Most important, they provide a useful function for those working in the supported low frequency ranges with relatively simple signals.

oh, absolutely, and i have a few of them myself.. (usbee).

But i would not call them logic analyzers. They are very weak compared to what my 16750A blades can do.

[Uwe Hermann]

i wouldn't call any of those supported devices 'logic analyzer'. They are streamers that capture at a fixed interval with some simple protocol decoders in software.

They are happy little boxes, available for little money, some in the pocket money range. Most important, they provide a useful function for those working in the supported low frequency ranges with relatively simple signals.

oh, absolutely, and i have a few of them myself.. (usbee).

But i would not call them logic analyzers. They are very weak compared to what my 16750A blades can do.

Yeah, well, that's an entirely other league, of course

But even so, your 16750A blades are pretty weak compared to how a USBee SX can happily sample away at some long SPI or UART or whatever signal for 17 hours non-stop ;-) And saving the whole thing to disk for additional analysis later (or for archival and documentation purposes, and so on).

It all depends on your use-case. The streaming functionality of all Cypress FX2 based logic analyzers is one of their strong points IHMO, compared to most of the other devices out there, even if they do have various disadvantages of course.

[free_electron]

If i teach the 16750 what the protocol looks like by building the state machine for it it will automatically throw away all the dead-time.
Those protocols exist for the machines. Of course i may still run out of memory but i can always cascade channels. with 48 channels... each having 4 megapoints and up to 10 blades per chassis...
And for faster protocols the Usbee will die. Go beyond 20Mhz clockrate and you start seriously dropping packets.
Good luck capturing a SPI stream to and from an SD card for example. Clocks reach 120MHz. My 15 year old 16750 laughs at 120Mhz ... its only 1/6 of what it can do ... ( it tops out at 800MHz )

Anyway, those machines are out of touch for most people and i do realise that. But still it does not make the USBee a 'logic analyser'.
Then again, the days of really tracing the address and databus of a system and running a processor disassembler are gone as well. Although i have done that a few times when making the Quicksilver core. ( A custom processor i designed )

Like i said the little logic sampler like USBEE and Salae are great little tools and i often use one as well. But for some serious work you need a little bit more oompf ...

[T4P]

Yeah, i agree the USbee's and the saelae's are to be called logic samplers not any analyzer by a far shot.

How about the OHS?

[giubin]

Hi everyone,

We're working on getting support for oscilloscopes in sigrok (an open-source software for logic analyzers), hence the need for some test hardware such as this. So here's a quick teardown of the Hantek DSO-5200A PC oscilloscope, in case anyone is interested.

For more photos and info see the respective sigrok wiki page, don't want to re-upload every file here:

http://sigrok.org/wiki/Hantek_DSO-5200A

The main CPLD or FPGA is under a heatsink unfortunately (which I wasn't able to remove without risking to damage the device so far). There seem to be two ADCs on there (markings were removed, though), some SRAM, and one Cypress FX2 for transferring the data to the PC.


Have fun, Uwe.

still no Hantek DSO-5200A support in sigrok? Any news? Thanks.