Hantek - Tekway - DSO hack - get 200MHz bw for free

[tinhead]

I must be out of my mind for doing this, but

I plugged in a USB Flash Drive in the retrofitted USB Host connector:

"usbctl: zombie --> [reset] --> default. Device in default state."

So, no luck - but the good news: Everything else still works! ;-)

this should work, normally the host/device usb port is jumpered (like in attached pic), however you have to tell the S3C2440 what
will be used. The 4053 seems to be connected to them (from what i can see) to act as "mux", or in detector.

Next, instead of measuring some test-signals:

The 28-pin footprint shown in P1170503 is connected to the "PHONE1" jack footprint. After some investigation in the Mini2440 schematics (http://www.friendlyarm.net/dl.php?file=mini2440_schematic.zip) it is for 100% sure that this can be used to retrofit a UDA1340: http://www.datasheetcatalog.org/datasheet/philips/UDA1340.pdf

Looking at the SDIO Pinout I am sure we just have to find the right SD-slot. Unfortunately, the buzzer right in front blocks changing the SD-card, so I guess I will go for some flat ribbon cable... Only thing missing could be the missing pullups.

yep, that's what i found out too.

I still can't find a way to see how a Davicom DM9000 or another Ethernet-PHY could be attached to the board to make use of the ethernet-jack. So to make a sophisticated guess I say the ethernet-part is implemented in the FPGA I can't identify due to its heatsink...

Hantek told me DM9000, and yes it would be (like once designed by Tekway) a addon-pcb connected to i/o header. From mechanical point of view
the new hw revision is designed much better (RJ45 jack mounted to big PCB instead to "weak" addon).

But hey, you have the hw there, you can easily check if the RJ45 jack (on these parts around it on bottom PCB side) are connected to
the long I/O port.

[RobertB]

Hi!

No luck with the micro-SD... Soldered a flat ribbon cable to the footprints and to a micro-SD slot. No matter if I insert the start before power up or after powering up - nothing happens. The resistors on the bottom side of the pcb are fine - so I guess software is not capable?

BR
Robert

[tinhead]

Hi!

No luck with the micro-SD... Soldered a flat ribbon cable to the footprints and to a micro-SD slot. No matter if I insert the start before power up or after powering up - nothing happens. The resistors on the bottom side of the pcb are fine - so I guess software is not capable?

BR
Robert

of course it need to be enabled, via sd card driver or evt. via direct GPIO access, but it is good to have it routed to the S3C2440.

[RobertB]

Yes, looks like the same (missing piece of software) for the USB-mux. Soldered the resistor I supposed to be the signaling pin in (2.2k, just to make sure not to destroy the S3C2440). Consequently it changes from approx. 0V to 3.3V if there is a cable plugged in on the back (USB B jack) and therefore the xY1 are routed to xZ connecting the USB B jack with the S3C2440.

Wasn't able to figure out how exactly the 1.5k pullup works. The missing resistor is kind of unclear, as it connects 3Y1 and 3Z. Guess 3Z is routed to the S3C2440 as well and gets switched to 3Y1 is the cable is inserted. I have no clue why this is switched at all as this can always be the case even when using the USB A jack at the front (does not harm anything). Maybe because of this there is a bypass as well.

Is there any tool to check what pin toggles when the USB A cable is connected/disconnected? Maybe it would be possible to reconfigure the S3C2440 on the fly...

BR
Robert

[tinhead]

it works very simple - these 3 input selectors (4053 pin 9,10,11) are connected via 10k resistor (near usb client jack) to VUSB, cap to GND (giving some delay) and missing resistor to unknown GPIO port.
This missing resistor (that's where you soldered the 2.2k) is used (i gues) only if the firmware is forced switching the USB client off and USB Host2 on (no matter if there is VUSB on USB client).
Without this resistor (there is currently no support in firmware for this anyway - btw, what fw version is istalled on your DSO?) this circuit still works, but only via VUSB detection.
By default 4052 is selecting X inputs, so the second host is enabled if no VUSB. If VUSB exists, 4052 is switching USB signals to USB client and the USB_Enable (actually another one GPIO port)
to the 1.5k resistor (which is soldered near USB client jack and routed to 3Y1). This signal (actually the 1.5 resistor between D- and the GPIO port) is necessary to allow proper USB client functionality.
The 3rd resistor between 3Y1 and 3Z is probably for hysteresis.


To monitor GPIO port status there are 3 ways
- boundary scan over JTAG (which is always the best way)
BSDL files are available on Samsung website, but if you have no hardware and knowledge how to use it, then you lost.

- via test app loaded instead of linux.
There are many such test applications for S3C2440 to show the GPIO port status (some over USB which didn't make sense here, others via shell/uart),
but you have to compile them and load to NAND or even better to memory over JTAG.

- via what already on the DSO
Normally you can read GPIO under linux, you will need an GPIO driver and application calling such driver.
Luckily there is such driver availble on HanTekway DSOs - /dso/driver/dso-iobank.ko and there is application calling this driver /dso/app/setio
The "setio" is being used by default like that /dso/app/setio g12 o 1 (where G12 is GPG12 port/pin, "o" is output and "1" the actual data which will be written to that port/pin).
However this app can be user like /dso/app/setio g12 i to display the port value.

So all you need is to connect via UART to the Linux shell, kill the dso.exe by ctrl+c, to connect 3.3V via 2k to the unknown GPIO pin (i mean the one where you soldered 2.2k resistor)
and monitor what changed ... lot of ports/pins to monitor, but you can write a script to loop until change and display what changed.

[RobertB]

it works very simple - these 3 input selectors (4053 pin 9,10,11) are connected via 10k resistor (near usb client jack) to VUSB, cap to GND (giving some delay) and missing resistor to unknown GPIO port.

Yes, this is exactly what I've said and showed in the picture.

This missing resistor (that's where you soldered the 2.2k) is used (i gues) only if the firmware is forced switching the USB client off and USB Host2 on (no matter if there is VUSB on USB client).
Without this resistor (there is currently no support in firmware for this anyway - btw, what fw version is istalled on your DSO?) this circuit still works, but only via VUSB detection.

I don't agree on this. The missing resistor connects to an INPUT, this is where the USB-driver should look at to reconfigure the USB core on the S3C2440. Working against the 4.7k/10k voltage divider of VBUS of USB A jack would work somehow, but would be a design flaw. This is supported by measurements I did when the DSO was running: you get ~0V when no USB-A is in (10k to GND) on BOTH sides (so not even a pullup) and ~3.3V when connected (voltage divider to VBUS) on BOTH sides (so again no pulldown). The pin is not driven at all - this will be the pin to consider for reconfiguring the S3C2440. By the way, I was looking at the Mini2440 - I saw somebody asking about the SEL_USBPAD bit (http://www.armkits.com/download/s3c2440.pdf) but I doubt this is enough for reconfiguration. Never saw somebody telling it actually works. To be honest, it is of course more tempting to stick in a small 4-port-hub and avoid the hassle.

By default 4052 is selecting X inputs, so the second host is enabled if no VUSB. If VUSB exists, 4052 is switching USB signals to USB client and the USB_Enable (actually another one GPIO port)
to the 1.5k resistor (which is soldered near USB client jack and routed to 3Y1). This signal (actually the 1.5 resistor between D- and the GPIO port) is necessary to allow proper USB client functionality.

To be precise, by default it connects/selects xY0 with xZ. The jacks' Dx lines are connected to the xY1/2 pins, the S3C2440 Dx lines are connected to the xZ pins.  

The 3rd resistor between 3Y1 and 3Z is probably for hysteresis.

I don't think so. To do this, it would have to have a connection to Sx. This is not the case. I guess 3Z is connected to the pin controlling the 1.5k pullup in the original design. By soldering a zero-ohm resistor to this location you ALWAYS have the pullup-control connected to the USB A jack. Using the actual configuration, its only connected if VBUS is applied. I guess 3Y0 (default) is open (so the 1.5k is flowing on one side in default state).

To monitor GPIO port status there are 3 ways
- boundary scan over JTAG (which is always the best way)
BSDL files are available on Samsung website, but if you have no hardware and knowledge how to use it, then you lost.

- via test app loaded instead of linux.
There are many such test applications for S3C2440 to show the GPIO port status (some over USB which didn't make sense here, others via shell/uart),
but you have to compile them and load to NAND or even better to memory over JTAG.

- via what already on the DSO
Normally you can read GPIO under linux, you will need an GPIO driver and application calling such driver.
Luckily there is such driver availble on HanTekway DSOs - /dso/driver/dso-iobank.ko and there is application calling this driver /dso/app/setio
The "setio" is being used by default like that /dso/app/setio g12 o 1 (where G12 is GPG12 port/pin, "o" is output and "1" the actual data which will be written to that port/pin).
However this app can be user like /dso/app/setio g12 i to display the port value.

So all you need is to connect via UART to the Linux shell, kill the dso.exe by ctrl+c, to connect 3.3V via 2k to the unknown GPIO pin (i mean the one where you soldered 2.2k resistor)
and monitor what changed ... lot of ports/pins to monitor, but you can write a script to loop until change and display what changed.

I will do this when I have time. Have a Segger J-Link, so this is not a problem at all. More of a problem is that we don't have 2.00mm headers on stock in the lab. I don't like to solder plain cable to this socket. I think I will tackle this when upgrading the analog parts, because I don't want to srew/unscrew the frontpanel frequently (the threads in the plastic get stale way to fast even if you're cautious).

Quite probable I will try to get some WiFi-stick running with the DSO to allow ssh (dropbear?) access to avoid the hassle of designing an addon-card we don't have to connections for. I think it takes a broken unit to unsolder the BGAs and "beep" all connections. - And I prefer it won't be mine... ;-)

So, does anybody has some kind of toolchain ready? Some kind of BSP available? What about triggering Hantek/Tekway or - if they are not nice, which I don't think - let FSF making them releasing the relevant sources?

BR
Robert

[tinhead]

I don't agree on this. The missing resistor connects to an INPUT, this is where the USB-driver should look at to reconfigure the USB core on the S3C2440. Working against the 4.7k/10k voltage divider of VBUS of USB A jack would work somehow, but would be a design flaw. This is supported by measurements I did when the DSO was running: you get ~0V when no USB-A is in (10k to GND) on BOTH sides (so not even a pullup) and ~3.3V when connected (voltage divider to VBUS) on BOTH sides (so again no pulldown). The pin is not driven at all - this will be the pin to consider for reconfiguring the S3C2440. By the way, I was looking at the Mini2440 - I saw somebody asking about the SEL_USBPAD bit (http://www.armkits.com/download/s3c2440.pdf) but I doubt this is enough for reconfiguration. Never saw somebody telling it actually works. To be honest, it is of course more tempting to stick in a small 4-port-hub and avoid the hassle.

what Input ? Thie is an SoC I/O port, so you can configure for input or output function. As it is not configured right now by currenty firmware it is acting probably "as input".

Design flaw, hmm, depends. Let's imagine there is option in firmware to switch between "backside client and frontside host", with warnning to the user - in that case there will be no 4.7/10k voltage divider, and even if user plugs in
wrong port nothing will get destroyed. So it is cheap but working solution (however with user asistance).

The SEL_USBPAD is working, however by default most s3c2440 boards developers are too lazy to drive proper drivers, they instaling hard jumpers or even better USB hub chips.

I don't think so. To do this, it would have to have a connection to Sx. This is not the case. I guess 3Z is connected to the pin controlling the 1.5k pullup in the original design. By soldering a zero-ohm resistor to this location you ALWAYS have the pullup-control connected to the USB A jack. Using the actual configuration, its only connected if VBUS is applied. I guess 3Y0 (default) is open (so the 1.5k is flowing on one side in default state).

maybe, was only a gues. The 1.5k is only necessary for usb client port detection.

I will do this when I have time. Have a Segger J-Link, so this is not a problem at all. More of a problem is that we don't have 2.00mm headers on stock in the lab. I don't like to solder plain cable to this socket. I think I will tackle this when upgrading the analog parts, because I don't want to srew/unscrew the frontpanel frequently (the threads in the plastic get stale way to fast even if you're cautious).

j-link works, but don't forget to save NAND dump with OOB blocks in case you wish to restore it some day.

Is it 2mm or 1.27mm header? Looks like 1.27 on pic, but maybe i just saw the dimensions wrong.

Quite probable I will try to get some WiFi-stick running with the DSO to allow ssh (dropbear?) access to avoid the hassle of designing an addon-card we don't have to connections for. I think it takes a broken unit to unsolder the BGAs and "beep" all connections. - And I prefer it won't be mine... ;-)

There is 2.6.13 linux installed (i think, still no idea what firmware you have and what linux version ..see my PM), WiFi-stick like VNT6656 based might work but there is some effort in driver compilation for
2.6.13 kernel. SSH might work too, but telnet is already there, so enough for me.

Beep all conections, this is what i did for the whole DSO. As i had to replace the SoC i shot picture of it, FPGA scanned via boundary scan. But sure, that was for the old hardware revision, for the new you have
we can start from scratch (almost, input and trigger part are same, but conected to different FPGA pins)

So, does anybody has some kind of toolchain ready? Some kind of BSP available? What about triggering Hantek/Tekway or - if they are not nice, which I don't think - let FSF making them releasing the relevant sources?

i know this thread is long, the information about is somewhere in it. To make it shorter - no, no toolchain available for now. You have to build your own, QQ2440 with 2.6.13 is good starting point.

[Igor]

Russification Tekway DST1102b (or DST1202B?   ) is over!







Posted in Tekway, and invited them to a Russian.lan.  They even failed to respond...  
Perhaps they are not interested in the Russian market.

[tinhead]

hey Igor, beautiful!

Tekway maybe not really present, but Hantek have some russian distributor, so i'm sure they will be happy about the translation.

[Igor]

Thanks, Tinhead.  Your assessment of my modest work very important for me. I know Hantek's distributors in Russia. People who aren't very nice chat. Sorry.

[ccatt]

Happy every day!Sorry to trouble you, but I need your help.

My DSO firmware version is 2.6.3,
 by measurement,the last pin of  UART  is 3.3v on the picture,not 0v. if USB UART converter 's "gnd "to the last pin of  UART in DSO , can't  this instrument  be damaged ?  now  rx0 : 0.1v   rx1: 0v

just buy H-JTAG and USB UART converter ,   but the  USB UART converter not  work,

I felt very strange: fw2dump.zip can dump 3   files(boot.bin kernel.bin root.bin  ),but  fw_backupV3.zip  can't.

If only use H-JTAG, What should I do?  How do you define the offset of the 3 file  .

How do I  downgrade to 2.6.2 or  lower?

(dst1kb_2.06.3_1202b_fact(110118.0).up  ) IS THIS ONLY FOR TEKWAY DST1202B?
 
How did the "bin" file compile or decompile?
 
What's changed, Where's changed, Every version firmware?

And finally analyze this, What will I need to access and read for this course?

[RobertB]

Hi!

Linux version is still 2.6.13. So this is actually totally outdated. I even had problems finding linux-2.6.13-QQ2440-xxxxxx.tgz, which seems to be a working kernel for the mini2440 board. If anybody happens to have hold on this, an upload would be highly appreciated.

My firmware is exactly (even the "build-numbers") what is distributed right now by Hantek as an update.

The JTAG-header is 2.00mm, the 60- (64?) pin IO-connector is 1.27mm.

I am a little concerned about the old kernel. While it should be possible to compile the sd-driver supplied with qq2440, any new drivers will be hard. For example, compat-wireless only supports >= 2.6.24, compat-wireless-old supports 2.6.21. So it will be very hard to get for example AR9170usb to work (or any other recent USB wlan stick).

Further, I was not able to get hold of any hint on the actual kernel config used in the DSO.


BR
Robert

[rf-loop]

I'm not concerned about Linux version. It is embedded linux and for user it is Oscilloscope (not linux entertainment machine).  User do not need even know about system behind display and knobs. It works and linux version do not make any problem afaik. Of course if people want make some modifications and if he want make it as game box or tv or music box he need use 2.6.13 compaible things.

If I'm concerned something it is analog channel and ADC system design and quality. But then I remember - if I think this quality... it is <1k$ scope and in this class it is really unexpected good.

Building guality (main board) seems littlebit better now in these new HW. (I have look only some old and new units so I can tell only these units what I have checked)

[Igor]

just buy H-JTAG and USB UART converter , but the  USB UART converter not  work

I broke into the brains oscilloscope through such devays:



http://cgi.ebay.com/USB2-0-RS232-TTL-Converter-Module-PL2303-4pcs-cable-/270726085956?pt=LH_DefaultDomain_0&hash=item3f08883d44

You can apply the service cord from your old mobile phone.

[Mechatrommer]

oscilloscope through such devays:

how?

[tinhead]

My DSO firmware version is 2.6.3,
 by measurement,the last pin of  UART  is 3.3v on the picture,not 0v. if USB UART converter 's "gnd "to the last pin of  UART in DSO , can't  this instrument  be damaged ?  now  rx0 : 0.1v   rx1: 0v

yes, +3.3V is correct, my very first picture was wring - updated already to correct pinout.

just buy H-JTAG and USB UART converter ,   but the  USB UART converter not  work,

did you set right paramters in your terminal application ? com port number (the one assigned to your usb uart adapter), 115200 8/N/1 for baudrate are proper values.
If these things are ok you should see something during DSO boot process - if not maybe txd/rxd are connected vice versa - change them and try again.

Which H-JTAG ? USB or LPT version ? It dind't really matter for function, but for speed ...

I felt very strange: fw2dump.zip can dump 3   files(boot.bin kernel.bin root.bin  ),but  fw_backupV3.zip  can't.

this is interessting, you have Tekway right ? I got no issues here on both Hantek and Tekway DSOs.
Can someone test it ? I mean this backup utility:

https://www.eevblog.com/forum/index.php?topic=1571.msg35683#msg35683

If only use H-JTAG, What should I do?  How do you define the offset of the 3 file  .

with H-JTAG, or actually H-Flasher software you can backup the whole NAND or restore it. If you backup via h-jtag/h-flasher you have to ensure that OOB blocks are also saved,
H-Jatg software have be default no drivers doing this - but you can find some here:

http://www.mikrocontroller.net/topic/163836

If you wish to restore a backup created with the in here posted fw_backup utility (these 3 files) you
will have to merge them to one file (together with 2 other files which ar common for all), as described here:

https://www.eevblog.com/forum/index.php?topic=1571.msg26926#msg26926

The resulting file can be restored via h-jtag/h-flasher (with loaded s3c2440 + OOB drivers)

How do I  downgrade to 2.6.2 or  lower?

in generally if you have already 2.6.3 you can just copy the dso.exe from earlier firmware version to you DSO root file system (a good idea is to make a copy of your existing dso.exe)
You will have to connect via uart to the shell, kill dso.exe process (which will actually happens during login to the shell) , insert usb stick with the older version of dso.exe (in will get mounted automatically into /mnt
and copy the old dso.exe to /

You can download older Tekway firmware (2.5 something) and extract it to get the old dso.exe version.

Additionally to this you will have to copy language files, they are version dependant, they located in /OurLanguages directory. the older firmware version does not have these files, so it is enough to
replace the dso.exe file.

After reboot the you will be ready with downgrade.

(dst1kb_2.06.3_1202b_fact(110118.0).up  ) IS THIS ONLY FOR TEKWAY DST1202B?
[/quote]

yes, it is. Tekway and Hantek are using exact the same dso.exe, help files, almost all drivers ... but not all.
display driver ( /dso/driver/dso-lcd.ko) and logo files (/logo directory) are manufacturer dependant, so don't mix them.

How did the "bin" file compile or decompile?

which bin ? you mean the dso.exe (which is the main dso application) or you mean the 3 files created during backup ?

For the dso.exe any ARM disassembler will be good, for example IDA

For these bin files, you can't them just decompile

Actually the boot.bin is single boot loader, it can be decompiled with some advanced tricks, but there is no need to do it.
Kernel.bin is just a copy of kernel, sure this can be extracted but for what reason ?
root.bin is copy of the linux root file system, it is binary copy, with OOB blocks !!!, you can only mount it to other linux computer (look for how to mount YAFFS)
To get the root file system files it is easier to connect over uart to shell and create a tarball to usb stick (or even just copy if you don't care about broken permissions)

What's changed, Where's changed, Every version firmware?

ohh, this is very bad question, actually for 2.6.3 there is description of changes on chinese Tekway website, as you from china it will be easy for you to read it.
What's in older version is writen down in user manual ... unfortunately both Hantek and Tekway are not smart enough to post firmware changes (for each version) on their websites ...

If you wish to see my bug report (having some infos about what inside which version) look here :

http://www.mikrocontroller.net/topic/205820?page=1#2036474

And finally analyze this, What will I need to access and read for this course?

honestly i don't know what you mean ?

[tinhead]

I'm not concerned about Linux version. It is embedded linux and for user it is Oscilloscope (not linux entertainment machine).  User do not need even know about system behind display and knobs. It works and linux version do not make any problem afaik. Of course if people want make some modifications and if he want make it as game box or tv or music box he need use 2.6.13 compaible things.

good point, i have even some other (almost new) devices having linux 2.4.18, as long they work i don't really care what kernel version on it.
Sure, 2.4.18 is overkill today, but it works.

For these HanTekway DSOs, 2.6.13 is good enough, for sure it sucks to compile drivers for new hardware line wlan-sticks, but to be very honest it is still possible with some effort.
for all "older" hardware revisions i do have working Ethernet-addon board solution, for the new hardware revision Elec3i is producing addon boards (and Hantek / Tekway as well, but no idea if they will ever sell them to existing customers - which Elec3i will do). Btw, Ele3i is also working on Wireless solution, so you can ask Pascal when they will be available.

But then I remember - if I think this quality... it is <1k$ scope and in this class it is really unexpected good.
Building guality (main board) seems littlebit better now in these new HW. (I have look only some old and new units so I can tell only these units what I have checked)

oh yeah, i saw these pictures posted by Robert and the quality seems to be now much better, overall design seems to be also optimized to remove some hardware bugs (like skew time between channels).
Even the old hardware was worth the money, the new revision is even better.

[ccatt]

 What's changed, Where's changed, Every version ?  
 Not different apparatus, is firmware(include High to low).
How to decompose the  firmware project?   IS bin ,*.up or other?How do you get the DSO.exe .Have you,the source program?
Use C Language  or  assembly language ?
How to analyze the every part of file ?

[ccatt]

not answer?why? Email to me, if it is not inconvenient to you.
Because I wants to do by myself .But I can't. Have no way of doing it; not know where to start.
Finally ,Thanks a lot  .

[SoftwareSamurai]

@ccatt

The best place to start is at the beginning of this thread. Read every post. Then you'll have the answers to your questions.

This DSO's internal workings are pretty easy to understand, so if you read this entire thread and still don't understand how this DSO works, you should move onto something else.

Please understand that I'm not trying to be mean or anything. It's just that your questions have already been answered in this thread.

FYI: No, no one here has the source code to the DSO.exe file, so we can't tell you what language it was written in. (I'll take a guess and say C, but what does that matter?)

[tinhead]

here we go ...

Attached LAN-Addon board files (Eagle 5.11 format) for the hardware revision 0, so all Hantek / Tekway DSOs produced
before April 1st 2011.

The Addon board is CS8900A based, the necessary Linux driver is already preinstalled in all firmware versions.
Network setup here :

https://www.eevblog.com/forum/index.php?topic=1571.msg36087#msg36087

As you can see the PCB is monted with two screews/distance spacers (Harwin Spacers R30-3001102).

It works so far up to 10Mbit, no issues except the fact that the driver is not doing CS8900 reset during soft-reboot,
so for clean reboot i have to power off/on.

The attached Eagle files can be used free/commercially, so no issue if someone (from China?) wish to produce some PCBs.
I will not, just because Hantek/Tekway changed hardware revision no idea how many ppl would buy the Addon-board.

EDIT: hmm, attached files got removed while forum was migrated, so here they are again:

[e-pirate]

Hi, folks!
First of all I would like to thank all of you for this topic. I was searching for inexpensive DSO to replace my old analog Russian 60 MHz single channel 65A that I've got for less than 60 backs 5 years ago right before I found this topic. My first choice was Rigol, but after reading of all ~28 pages, I decided to get HanTekWay. So, I've ordered mine Hantek DSO5102M (actually B) from Mr. Pioneer Huang from Aliexpress/Alibaba cause it was only available with English front panel and I'm to lazy to make one by myself. I would strongly recommend Mr. Pioneer as a honest seller and a very helpful person. I received my DSO in a perfect new condition, except the box, but I don't care. I wasn't lucky to get a "new" hardware, but I was lucky enough to get Tekway's 1.00.3 mainboard with 200 MHz ready out of the box. I can see all input stages resistors are 200 MHz version, so, seems that no soldering needed at all. The thing I definitely don't lake at all, is how it all soldered. I thinks kids in kindergarten do better! Resistors and capacitors sometimes are more than a half case out of there place, flux is everywhere and I wasn't able to wash it out with isopropyl alcohol and even with FluxOff! It's sticky and as I'm going to install fan, all this will get tons of dust. One of 4 ADC radiators is missing. Despite all that I'm satisfied with how this thing work and especially screen.
I haven't made any software/hardware upgrade before I get some very-very fast rising edge generator like http://www.i9t.net/fast-pulse/fast-pulse.html to be able to see difference and good probes.
For now, I like to know is at a good idea to apply Cramolin FluxOff to wash PCBs and where SN is stored?

[tinhead]

I wasn't lucky to get a "new" hardware, but I was lucky enough to get Tekway's 1.00.3 mainboard with 200 MHz ready out of the box. I can see all input stages resistors are 200 MHz version, so, seems that no soldering needed at all.

aha, so check the i2c.log, maybe it is rebranded 200MHz model.

The thing I definitely don't lake at all, is how it all soldered. I thinks kids in kindergarten do better! Resistors and capacitors sometimes are more than a half case out of there place, flux is everywhere and I wasn't able to wash it out with isopropyl alcohol and even with FluxOff!

take a picture of that ...

One of 4 ADC radiators is missing.

that's ugly

For now, I like to know is at a good idea to apply Cramolin FluxOff to wash PCBs and

... avoid using PVC and polysterene. ... hmm, i would use pure Isopropanol (99.7%).
Everything except the cap trimmers would have no problems with it.

where SN is stored?

in the EEPROM, located between display connector and front USB.
Additionaly you can see all model changes in the i2c.log file (directly in root dir).

[project]

For wash the flux, isopropyl alcohol won't work good. Most industrial flux, no clean flux are harder than rosin flux, not dissolved in alcohol or water too much. USE lacquer thinner, banana oil, paint thinner, acetone, xylene, all smell bad and dangerous. a little brush will work faster. take the battery off, wash two or three times, till no sticky feelling. blow dry before power it on.  I think this caused by product line wasn't adjust properly, and QA not good too.

 

[tinhead]

I think this caused by product line wasn't adjust properly, and QA not good too.

^^ maybe that's why this one was suposed to be for chinese market.