Hantek DSO2xxx schematics

[pcprogrammer]

I decided to look into the Hantek DSO2xxx series because I like the hardware as a basis to play with.

To get an understanding of it all reverse engineering of the schematics seems the logical first step, so that is what I started with. First up is the "User Interface Board" as it is the simplest to tackle. In the other threads about the Hantek a touch panel connector was mentioned and there is indeed room for it on the board. I soldered a connector onto it and placed a touch panel in front of the display. The rubber push cushions can be turned to lower them. They have two slots in them to slide over the metal holder.

Will post some pictures of that later.

An observation of the schematics shows how they handle the buttons and the encoders. They scan them in a matrix. This might explain why the response sucks when turning an encoder.

For the user interface part I made three sheets. The first shows the connectors and the LCD power setup, the second shows the buttons and the encoders and the third shows the LED's.

[gnuarm]

I don't understand what they are doing with the pots.  They are pots, right?  So what is the point of the diodes?  Are they measuring the voltage on the wiper arm?  It makes no sense to me.  Can you explain?

[pcprogrammer]

They are not pots but rotary encoders, so just two switches that are closed and opened one after the other. That is why the diodes are there. It works as a key scanning matrix. A problem with this design is that the buttons don't have the diodes so pressing two at the same time could result in not detecting one of them. (When they are on the same scan data line)

The HC4051 ic's work for both analog and digital signals. U3 is used to pull the scan lines low in following order and U2 is used to connect the scan data lines to the scanner. The HC393 is setup as a six bit counter and controls the scanning.

[pcprogrammer]

Here are some pictures of the touch panel fitted into the housing.







The rubber stoppers need to be swapped. On the picture below you can see the top one in its original orientation and the bottom one in the swapped orientation.

[DavidAlfa]

Interesting, but really, don't waste too much time with it, Hantek uses customized kernel, there're no sources, so adding new features will be almost impossible unless the functionality and its dependencies can be build as module.
We've been trying to implement networking through USB (RNDIS/ECM), the usb gadget could be compiled and loaded, but the kernel was built without networking support, and this feature cannot be added as module.

AFAIK, the scope already includes and loads the module tp-adc.ko, which probably includes the touch functionality, but knowing hantek, it very likely doesn't...
The Goodix GT911 driver is disabled in the devicetree (Check it here)

Code: [Select]

touchscreen@14 {
compatible = "goodix,gt911";
reg = < 0x14 >;
interrupt-parent = < 0x0c >;
interrupts = < 0x04 0x0a 0x02 >;
pinctrl-names = "default";
irq-gpios = < 0x0c 0x04 0x0a 0x00 >;
reset-gpios = < 0x0c 0x04 0x09 0x00 >;
status = "disabled";
};


[pcprogrammer]

I'm more interested in the hardware as a development and play platform. So write software from scratch without linux. Not as a replacement for the Hantek firmware, just for me as a hobby. I'm also interested in playing with the GOWIN FPGA.

The FNIRSI-1013D code is also bare metal no linux and I like it that way, even though it means implementing a lot of things yourself.

I did notice someone on the forum informing about the schematics a while back, and that is why I thought, lets post what I'm making here. The main board will take a bit of time since I also have to draw the symbols for some of the parts. The F1C100s I already did for the FNIRSI

[DavidAlfa]

Definitely baremetal could boost things up, but also make it very complicated, as every function needs to be done at low level and probably from scrap!
I think you already know, made a basic connection list in the hacking thread... but the ADC/FPGA are massive and have a *ton* of pins...
Adding all the current DSO functions would take years of work. For sure, Hantek uses its existing library, common-for-all, porting it for each hardware and enabling/disabling different parts.
I'll gladly help in what doesn't risk my hw! I don't think I'm opening my scope anymore, had to re-solder many pins as the solder is very soft, will warp and short very easily when probing with the DMM tips...

Be prepared, you'll enter the dangerous infinite loop of "Plz do this for me" and "Your FW is crap, why doesn't do what a $2000 DSO can?" 

[pcprogrammer]

Oh, and you'll enter the dangerous infinite loop of "Plz do this for me" and "Your FW is crap, why doesn't do what a $2000 DSO can?" 

You are right, that is something I'm not going into If I manage to make something useful it will be "it is this and nothing more" in a github repository.

[pcprogrammer]

Was a bit of a search to get the FPGA pin out above board

Not sure if there is a proper pin out document from Gowin, but all I found was UG229E "GW2AR series of FPGA Products Package & Pinout User Guide" and UG206-1.1E "GW2A/GW2AR series of FPGA Products Schematic Manual" and neither gave a proper pin out. Resorted to the schematic of a development board they make. (DK_START_GW2AR-LV18EQ144PC8I7_V1.1) and made my own symbol in EasyEda.

Still a lot of work to be done, but here is a sample of the FPGA, ADC and DAC so far.

The connections between these IC's were easy. Just follow the traces on the top side and count the pins.

Next up is the processor and the connection to the user interface board.

[pcprogrammer]

@DavidAlfa: Hi David, have you ever tried to hook a SD card slot to the test points on the main board?

For as far as I can see and measure the SD card interface of the F1C100s is not used, and for me that seems a missed opportunity. Sure I know they are penny f..ers, but how much of a difference does it make. They could have used a xGB SD card instead of the winbond 25N01G FLASH chip. This would have meant a good amount of onboard storage for images and easier maintenance of the OS and firmware.

The test-point numbers are the actual pin numbers on the F1C100s.

[DavidAlfa]

Nope I haven't, thought about it then realized...why?
I still would have to deal with the kernel, devicetree, root data, filesystem... Nobody cares, why would I waste my time, f** it 

I don't think you need probing:

Here's the F1C200s pinout asignment:

PIN   GPIO         NAME    FUNCTION              CONNECTED TO

6      GPIO96      PD0      TWI0_SDA(I2C)      U9 5, LemonTree 118
7      GPIO97      PD1      LCD_D3                  LCD
8      GPIO98      PD2      LCD_D4                  LCD
9      GPIO99      PD3      LCD_D5                  LCD
10    GPIO100    PD4      LCD_D6                  LCD
11    GPIO101    PD5      LCD_D7                  LCD
12    GPIO102    PD6      LCD_D10                LCD
13    GPIO103    PD7      LCD_D11                LCD
14    GPIO104    PD8      LCD_D12                LCD
15    GPIO105    PD9      LCD_D13                LCD
16    GPIO106    PD10    LCD_D14                LCD
17    GPIO107    PD11    LCD_D15                LCD
18    GPIO108    PD12    TWI0_SCK(I2C)       U9 6, LemonTree 117
19    GPIO109    PD13    LCD_D19                LCD
21    GPIO110    PD14    LCD_D20                LCD
23    GPIO111    PD15    LCD_D21                LCD
24    GPIO112    PD16    LCD_D22                LCD
25    GPIO113    PD17    LCD_D23                LCD
26    GPIO114    PD18    LCD_CLK                LCD
27    GPIO115    PD19    LCD_DE                  LCD
28    GPIO116    PD20    LCD_HSYNC            LCD
29    GPIO117    PD21    LCD_VSYNC            LCD
37    GPIO140    PE12    PWM0                     LCD BACKLIGHT
38    GPIO139    PE11    Input                      R196, V USB detect from computer
39    GPIO138    PE10    SPI_MISO               LemonTree 87
40    GPIO137    PE9      SPI1_CLK               LemonTree 15
41    GPIO136    PE8      SPI1_MOSI             LemonTree 90
42    GPIO135    PE7      Output                   LemonTree 88
43    GPIO134    PE6      Input                      Buzzer signal from LemonTree 21, R19
44    GPIO133    PE5      Output                   LemonTree 20, R101
45    GPIO132    PE4      EINTE4                   LemonTree 22, R278
48    GPIO129    PE1      UART0_TX              UART0
49    GPIO128    PE0      UART0_RX              UART0
59    GPIO64      PC0      SPI0_CLK               SPI NAND FLASH U2
60    GPIO65      PC1      SPI0_CS                 SPI NAND FLASH U2
61    GPIO66      PC2      SPI0_MISO             SPI NAND FLASH U2
62    GPIO67      PC3      SPI0_MOSI             SPI NAND FLASH U2
63    GPIO3        PA3      UART1_TX              UART1
64    GPIO1        PA2      UART1_RX              UART1 
65    GPIO1        PA1      TP_X2                    ?_?
66    GPIO0        PA0      Output                   V OTG enable

GPIO Table: GPIO table (Page 14):

Code: [Select]

GPIOC
PC0    SPI0_CLK      SDC1_CLK
PC1    SPI0_CS       SDC1_CMD
PC2    SPI0_MISO     SDC1_D0
GPIOD
PD18   LCD_CLK       SPI0_CS EINTD18
PD19   LCD_DE        SPI0_MOSI EINTD19
PD20   LCD_HSYNC     SPI0_CLK EINTD20
PD21   LCD_VSYNC     SPI0_MISO EINTD21
GPIOF
PF0    SDC0_D1       DBG_MS
PF1    SDC0_D0       DBG_DI
PF2    SDC0_CLK      UART0_RX
PF3    SDC0_CMD      DBG_DO
PF4    SDC0_D3       UART0_TX
PF5    SDC0_D2       DBG_CK

So, SD0 pins seem to be free (PF5-PF0, pins 53-58).
There're no vias in these pads, and there's no space under the SoC to put them, so they seem to be completely unused.
Looks like they routed the unused pins to test points, just like UART1... good.

SD1 pins (PC0-PC2) are used by SPI0, for the SPI nand.
Alternative SPI0 pins are used for the LCD (PD18-PD21)

The easiest way to see the use of a pin is by reading Pn_CFG registers on the livesystem, then check the tables on the User manual (Page 117)

The registers can be accesed like normal memory from linux, so:
- PIO Base addr: 0x01C20800
- PF only has Configure Register 0 (Offset: 0xB4)

Code: [Select]

# devmem 0x01C208B4 32
0x00373733

Decoding 0x00373733:

Code: [Select]

RESV         DGB_CK    RESV    DIS    RESV    DGB_DO    RESV    DIS    RESV    DBG_DI    RESV    DBG_MS
000000000    011       0       111    0       011       0       111    0       011       0       011

So SD0 pins are used by the debugger. I don't think it's important, I'm sure you could set this register to interface the SD.
Reg bits for SD: 010  0  010  0  010  0  010  0  010  0  010

Code: [Select]

# devmem 0x01C208B4 32 0x222222

At least, I've tried and didn't got any issues.

[pcprogrammer]

Thanks David,

but my probing shows that

Code: [Select]

28    GPIO116    PD20    LCD_HSYNC            LCD
29    GPIO117    PD21    LCD_VSYNC            LCD

Are not connected to the LCD but to the touch panel as the reset and interrupt line. Apparently there are LCD panels that can operate without these sync signals. Have to verify it with both boards connected to be sure.

Also noticed that the other UART on the F1C100s is not used and fed into test points. They could have made a better design where the user interface hardware is not handled by the FPGA but with a separate MCU like FNIRSI did in the 1014D. Response would have been better for sure.

Your list does help on some pins I do not have yet, and confirm what I have so far.

Doing these reversals makes me wonder what designers are thinking. I can see better way's both in the Hantek and the FNIRSI's of doing things.

[pcprogrammer]

It is quite the job, but I'm getting along.

The digital side of the board is done, including the ADC and the DAC with it's amplifier circuit. Need to polish some sheets to finish things.

Verified that the LCD is indeed working without the vertical and horizontal sync signals. Pin 8 on the LCD connector is a mode pin that selects between just using the DE signal or the sync signals. Found the datasheet for it

This picture shows what I already incorporated into the schematics. Try to be accurate

[DavidAlfa]

AFAIK, I didn't probe the LCD signals, but extracted them from the config registers.
Check those pins with another dso to see if there're sync signals.
Sure, they might not be used or connected...

[pcprogrammer]

Did not do that yet, but have it on the list, because the touch panel won't like it if there is a signal on the reset line, and the MCU might not like being pulled low by the interrupt line of the touch panel when it is outputting a signal

I found some weird stuff done in the scope with the power supply TR line. Know it is a 50Hz signal (might be 60Hz in countries with this mains frequency) from the Hantek threads. It is routed to a 74 Schmitt trigger buffer and then routed to the FPGA on pin 128. Nothing weird there, but the output of the buffer is also used to control pull ups on the clock and load line for the led 74HC595 shift register. (U4 in the LED schematic)

Why I don't know, but it means they can only clock this shift register when the TR signal is high

[pcprogrammer]

For those interested, here is what I made of it so far.

On the FPGA I still need to fill in two pins which go to the analog part of the system.

What remains is the two analog channels with it's support hardware.

Edit: Fixed the capacitor polarity in the analog -5V supply.

[arturmariojr]

Wow! Great work! Many thanks for your big effort doing this!!!!

[pcprogrammer]

It is a bit of a mess that needs a lot of cleanup but here is the schematic for channel 1.

Was a bit of a job to find all the connections. Especially with these low value resistors beeping the connections is tricky. Have to look at the meter to see it being 0.000 instead of 0.005 or so.

I'm not very good with analog stuff so no idea if it all makes sense

[DavidAlfa]

Holy s..  , that's a lot of work!
Are you able to measure those pF...nF little caps?

[pcprogrammer]

Measuring the caps probably needs removing them from the board, which I don't want to do.

I have a cheap component tester (LCR meter) but doing in circuit measurements won't yield good results I think.

[morgan_flint]

Hello, pcprogrammer! Great job!!

If you think it's worth it, and after you consider the work is finished, maybe it would be a good idea to create a single .pdf with all the schematics where the labels, components, etc. would be in searchable text form. I'm not familiar with the program but maybe just printing to pdf from EasyEda would do the trick.

The main advantage would be that it would be possible to search for the different circuit labels so it would be fast and easy to follow the signal path between the different sheets.

Thank you very much for your work!!

[morgan_flint]

...I found some weird stuff done in the scope with the power supply TR line. Know it is a 50Hz signal (might be 60Hz in countries with this mains frequency) from the Hantek threads. It is routed to a 74 Schmitt trigger buffer and then routed to the FPGA on pin 128. Nothing weird there, but the output of the buffer is also used to control pull ups on the clock and load line for the led 74HC595 shift register. (U4 in the LED schematic)

Why I don't know, but it means they can only clock this shift register when the TR signal is high

Could this be some kind of 50-60 Hz PWM for the LEDs in the display board?

Talking about battery power conversions, I remember somebody posted on one of the other threads that, in the absence of the 50-60 Hz signal from the power supply, the scope wasn't working correctly. Maybe it's related to this strange use of the signal. But I also remember that I experimented with disconnecting the TR from the power supply to the main board and didn't notice any misfunctioning...

P.S: Here is the post where crysti reported the problem and here is the post where I said I did that experiment. The previous post includes a simplified power supply schematic

[pcprogrammer]

Hi morgan_flint,

you are welcome. and yes I can make a single PDF per board. I'm gathering datasheets in a github repository and will add the EasyEda files there too.
https://github.com/pecostm32/Hantek_DSO2000

But I have to finish the analog schematics first, which may take some time due to laying a terrace with "lauze" which are thin stones. A hell of a job that takes a lot of energy. Unfortunately the guy we found to do the job for cheap got a MRSA infection in his right hand and is no longer able to do the job, so have to do it myself.

Due to an overlap in component numbering I have to keep the two boards in separate projects, but I guess that is not such a big of a deal when one needs to work on the scope.

As soon as it is done I will post it here.

Regards,
Peter

[pcprogrammer]

...I found some weird stuff done in the scope with the power supply TR line. Know it is a 50Hz signal (might be 60Hz in countries with this mains frequency) from the Hantek threads. It is routed to a 74 Schmitt trigger buffer and then routed to the FPGA on pin 128. Nothing weird there, but the output of the buffer is also used to control pull ups on the clock and load line for the led 74HC595 shift register. (U4 in the LED schematic)

Why I don't know, but it means they can only clock this shift register when the TR signal is high

Could this be some kind of 50-60 Hz PWM for the LEDs in the display board?

Talking about battery power conversions, I remember somebody posted on one of the other threads that, in the absence of the 50-60 Hz signal from the power supply, the scope wasn't working correctly. Maybe it's related to this strange use of the signal. But I also remember that I experimented with disconnecting the TR from the power supply to the main board and didn't notice any misfunctioning...

P.S: Here is the post where crysti reported the problem and here is the post where I said I did that experiment. The previous post includes a simplified power supply schematic

I don't think it is a PWM for the LED's. It only affects the clock and load signal for the LED shift register. No idea what is done with the signal in the FPGA, but it might well be that if the signal is tied to VCC it just works. When tied to ground the LED's may or may not function. Depends on the output strength of the FPGA. Pull-ups versus pull-downs.

I ordered a longer flat cable for between the main board and the user interface board to be able to do measurements on the scope. Once it gets here I plan to look into these things.

[pcprogrammer]

Did channel 2 and hope the redrawing makes it more readable.

I'm not to familiar with the user interface and have a question about two of the control signals.

The first control signal switches the input relay and I named it CHANNEL2_FILTER, but I'm not sure to what menu item this belongs to. Then there is also a control signal I named CHANNEL2_X, which enables a capacitor to ground right after U28, so also looks like a filter. But again the question which menu item this belongs to.

Still need to cleanup channel 1 and the control signals sheet and number the sheets before it is done.