Author Topic: Hantek 6022BE 20MHz USB DSO  (Read 852487 times)

0 Members and 8 Guests are viewing this topic.

Offline marm496

  • Newbie
  • Posts: 6
  • Country: mx
Re: Hantek 6022BE 20MHz USB DSO
« Reply #50 on: October 05, 2013, 08:19:49 pm »
I've been reading the spec sheet of the  AD9288, this same integrated circuit comes in 3 different flavors, 40, 80 and 100 MSPS, it seems that according to this data sheet we may replace 40 MSPS  AD9288 IC with a 100 MSPS AD9288 one, so that we could increase  6022BE's bandwidth to 100 MSPS.
It could be just great.
 

Offline Rick Law

  • Super Contributor
  • ***
  • Posts: 3423
  • Country: us
Re: Hantek 6022BE 20MHz USB DSO
« Reply #51 on: October 05, 2013, 10:43:17 pm »
I've been reading the spec sheet of the  AD9288, this same integrated circuit comes in 3 different flavors, 40, 80 and 100 MSPS, it seems that according to this data sheet we may replace 40 MSPS  AD9288 IC with a 100 MSPS AD9288 one, so that we could increase  6022BE's bandwidth to 100 MSPS.
It could be just great.

Hey thanks for the datasheet.  I found it very interesting.  It would be interesting if it does work.  If I am reading the sheet right, looks like +-15mV is about their typical conversion accuracy (volt match).

Anyone tried voltage calibration?  There is the VR1 sitting there looking like it is for voltage calibration.
 

Online FraserTopic starter

  • Super Contributor
  • ***
  • Posts: 13148
  • Country: gb
Re: Hantek 6022BE 20MHz USB DSO
« Reply #52 on: October 06, 2013, 12:00:11 pm »
The 6022BE hardware so is so 'simple' as to almost be a development board for experimentation and improvement. Sadly that hardware is very reliant upon the appropriate firmware and software to exploit such improvements. Increasing the ADC clock would be needed to increase the sample rate. I have no idea what changes would then be required to the firmware to accept a higher sample rate, but I doubt it is a trivial task, especially for anyone not very familiar with the processor used. I bought one of these for a simple task and half hoped that this little DSO would become a popular 'project' in the development and hacking community so that better software would become available. That has no happened yet.

As has been said before. Decent hardware, pity about the firmware and software.
If I have helped you please consider a donation : https://gofund.me/c86b0a2c
 

Offline marm496

  • Newbie
  • Posts: 6
  • Country: mx
Re: Hantek 6022BE 20MHz USB DSO
« Reply #53 on: October 09, 2013, 07:07:17 am »
I already bought my cypress Usb microcontroller and I am been trying to get the usb hub chip to make the logic analyzer with my HANTEK 6022BE oscilloscope, I  found a company call  RS Components Ltd that is selling this chip(right now this chip is obsolete),well I ordered one at RS web site but they are asking me for call them with my credit card info ,I don't think I want to give this information  by phone to someone in UK,you can call me paranoid but I prefer to buy it somewhere else online ,although , get this IC doesn't seem to be an easy task, now a days,I will keep looking.
Increase this oscilloscope bandwidth it's not a trivial task, I agree but I think that it's worth trying. I have to learn to program the 8051 microcontroller but someday I am going to try to decipher this firmwere, somehow,it's just matter of time,well I can't promise anything but I am going to try.
 

Online FraserTopic starter

  • Super Contributor
  • ***
  • Posts: 13148
  • Country: gb
Re: Hantek 6022BE 20MHz USB DSO
« Reply #54 on: October 09, 2013, 09:22:41 am »
Radio Spares aka RS Components is like Farnell / Element14, Digikey or Mouser. They are a huge component supplier to inducstry and Government organisations. RS are a very much respected company that has been around many decades. They can be expensive but they are a convenient parts source. I can state with absolute confidence that they are not a dodgy organisation  ;)

I have bought rare ICs from UTSource in Hong Kong. Cheap shipping, reliable and no problems to date. They accept PayPal.
« Last Edit: October 09, 2013, 01:22:47 pm by Aurora »
If I have helped you please consider a donation : https://gofund.me/c86b0a2c
 

Offline marm496

  • Newbie
  • Posts: 6
  • Country: mx
Re: Hantek 6022BE 20MHz USB DSO
« Reply #55 on: October 09, 2013, 09:41:11 am »
Thanks Aurora,I  feel more confident now.
 

Offline tinhead

  • Super Contributor
  • ***
  • Posts: 1918
  • Country: 00
    • If you like my hacks, send me a donation
Re: Hantek 6022BE 20MHz USB DSO
« Reply #56 on: October 09, 2013, 10:37:30 am »
Increasing the ADC clock would be needed to increase the sample rate.

Increase this oscilloscope bandwidth it's not a trivial task, I agree but I think that it's worth trying.

check the PCB, it looks like the second CY7C68013A can clock the second ADC (180° phase shifted) when you solder it. Of course you will need to solder R7 as well, remove i think R37 (or R35 - you have to check this first which of them is connecting together both ADC clock inputs). With two CY7C68013A the USB hub ic need to be soldered as well, and R75/R76 removed (but then R122/R12 soldered).

The missing VID/PID you will find in device driver.

So that's so far for higher sample rate, the analog bandwidth could be easy as well. There is low pass filter, R20/C25 and for second channel R25/C30. That's are 49R9 resistors and some pF caps. This need to be however evaluated for best result.
The ADC itself have 2pF on input pin, so add this as well for calculations.

Typically Hantek was using CD4051 for input att/mux, however here is aready NXP 74HC4051D, with good frequency response, so no need to change anything here.

Regards the CY7C68013A, watch out the I2C, there seems to be more than one combination (one EEPROM, two on same bus, separate chip per CY7C68013A), you will have to evaluate this as well.

And finally don't forget t check current consumption.
I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ...
I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.
 

Offline marm496

  • Newbie
  • Posts: 6
  • Country: mx
Re: Hantek 6022BE 20MHz USB DSO
« Reply #57 on: October 12, 2013, 06:58:20 am »
After all I bought the USB 2512B,instead of USB2512A,footprint it's the same and this is a direct replacement of USB2512A, I ordered it from microchipdirect as sample for 7.5 dollars for two pieces,well I couldn't pay 50 dollars for shipping(low budget). I have been looking around 6022 pcb,locating all  resitences and paths you mentioned,I am doing it slow and carefully ,so it's taking time to finish.
When I have results, I will post them here. Do you know that Rigol is using five AD9288-40 to perform 1GSPS in their scopes?
Thanks, Aurora and Tinhead for your answers and advices. ;D
« Last Edit: October 12, 2013, 09:59:26 am by marm496 »
 

Offline marm496

  • Newbie
  • Posts: 6
  • Country: mx
Re: Hantek 6022BE 20MHz USB DSO
« Reply #58 on: October 12, 2013, 07:47:37 am »
Talking about EEPROM 24LC02B on the second uC,it seems  to be connected  directly to SDA pin and SCL pin on uC,it's just needed a pair of 2.2K pullup resistors and a 0.1u cap as far I could see. But it's necesary  check the address pins of the 24LCxx for proper usb configuration. This memory configure uC VID&PID values at boot time as well as boot code loading. LC02B is not the only eeprom type allowed,We could use any of this:

24LC00    16    Bytes
24LC01    128  Bytes
24LC32     4K   Bytes   
24LC64     8K  Bytes
24LC128   16K Bytes

To use another memory type  we just need to adjust A0, A1, A2  values according to CY7C68013A-100AXC datasheet.
« Last Edit: October 12, 2013, 09:55:35 am by marm496 »
 

Offline Mark_O

  • Frequent Contributor
  • **
  • Posts: 939
  • Country: us
Re: Hantek 6022BE 20MHz USB DSO
« Reply #59 on: November 20, 2013, 03:42:31 am »
At 2us or below is when it captures at 48msps and at merely 1060 datapoints.  At 5us or slower, it goes to over 100K datapoints at 16msps.  The slower the more datapoints.

Rick, did you notice at what point it acquires the full rated 1M samples?  And is that split between the two channels?
 

Offline Rick Law

  • Super Contributor
  • ***
  • Posts: 3423
  • Country: us
Re: Hantek 6022BE 20MHz USB DSO
« Reply #60 on: November 21, 2013, 08:27:35 am »
At 2us or below is when it captures at 48msps and at merely 1060 datapoints.  At 5us or slower, it goes to over 100K datapoints at 16msps.  The slower the more datapoints.

Rick, did you notice at what point it acquires the full rated 1M samples?  And is that split between the two channels?

Mark,

At 50ms (1Mhz) it starts acquiring at full 1M samples (1,047,552 for each channel total 2x1047552)
At 20ms (1Mhz) it is at 523264 samples each Channel
At 10ms (1Mhz)= 523264
At 5ms (1Mhz)= 523264
At 1ms (1MHz) = 130048
At 100us (1Mhz) = 130048
At 20us (4Mhz) = 130048
At 10us (8Mhz) = 130048
At 5us (16Mhz) = 130048
At 2us (48Mhz) = 1016

Anything faster than 2us, it is still at 48MHz at 1016 samples each channel (2032 total)

Rick

Edit:
Adding this:  My 1060 earlier was wrong and was probably trans-positioning the number in my mind.
Ten-sixty (1060) is incorrect.  Ten-sixteen (1016) is the right one.


« Last Edit: November 21, 2013, 08:31:09 am by Rick Law »
 

Offline Mark_O

  • Frequent Contributor
  • **
  • Posts: 939
  • Country: us
Re: Hantek 6022BE 20MHz USB DSO
« Reply #61 on: November 21, 2013, 09:46:24 am »
At 50ms (1Mhz) it starts acquiring at full 1M samples (1,047,552 for each channel total 2x1047552)
At 20ms (1Mhz) it is at 523264 samples each Channel
At 10ms (1Mhz)= 523264
At 5ms (1Mhz)= 523264
At 1ms (1MHz) = 130048
At 100us (1Mhz) = 130048
At 20us (4Mhz) = 130048
At 10us (8Mhz) = 130048
At 5us (16Mhz) = 130048
At 2us (48Mhz) = 1016

Anything faster than 2us, it is still at 48MHz at 1016 samples each channel (2032 total).

Thanks a lot, Rick.  I really appreciate the info, and have made a note of it. 

Surprisingly, not only does Hantek not document this info, you can't even get it on request.  Though with 2M of sample RAM, I'd think they'd want to brag about it.  Apparently, they don't know.  :) 

EDIT:  Turns out I was wrong.  They do know, there's 2K of sample RAM (not 2M), and there's nothing to brag about.   :-[
« Last Edit: November 29, 2013, 10:52:31 am by Mark_O »
 

Offline rpcope1

  • Contributor
  • Posts: 16
  • Country: us
Re: Hantek 6022BE 20MHz USB DSO
« Reply #62 on: November 25, 2013, 06:59:43 pm »
  Hello everyone,

I've been watching this thread for a while, and I just wanted to say thanks for putting up all the cool information. I bought this scope a few months ago, thinking I'd do like what Aurora was talking about and mod it out. I've been writing a Python front-end for the API Hantek provides (I'm not huge on the provided scope software), and was thinking about doing the same in C++. I saw the OpenHantek project but it doesn't look like it supports the 6022BE scope. Is this something you all might be interested in? My big issue with the scope right now is the noise level. In reading this, I thought I read that a DC/DC converter was causing the roughly 10 mV noise seen in the channels? Do you all think it's possible to clean up the noise and get slightly better resolution as far as the signal goes, or is that asking too much from this scope? Maybe I just need to pony up and buy a dedicated spectrum analyzer (that's what I was hoping to accomplish). :)
 

Online FraserTopic starter

  • Super Contributor
  • ***
  • Posts: 13148
  • Country: gb
Re: Hantek 6022BE 20MHz USB DSO
« Reply #63 on: November 25, 2013, 07:31:48 pm »
rpcope1,

Thanks for you post. I would certainly be interested in any alternative software as I really do not get on with that supplied with the unit. The DC-DC converter was raised as a likely source of noise and the channels are not well screened. The 6022 would be a good basis for developing a cheap DSO for the masses  :)

I look forward to hearing how you get on with a better GUI for this well made little DSO. It has much potential and is a real pity that Hantek appear to have no interest in improving their software.
If I have helped you please consider a donation : https://gofund.me/c86b0a2c
 

Offline Mark_O

  • Frequent Contributor
  • **
  • Posts: 939
  • Country: us
Re: Hantek 6022BE 20MHz USB DSO
« Reply #64 on: November 25, 2013, 11:39:29 pm »
Welcome to the Forum, rpcope.

I've been writing a Python front-end for the API Hantek provides...

Good luck with that.  From their (poor) SDK documentation, it's not even clear what some of the parameters are for, or how the functions actually behave.  I looked at it, and there were a few things I couldn't figure out.  It only took 3 emails to Hantek "Tech Support" :-DD over about a month, to net the response that "it's an inexpensive device", and "please read the SDK document" (which is what I was asking about in the 1st place).   |O

And yes, I'm stating publicly that Hantek tech support is a joke.

Quote
(I'm not huge on the provided scope software),

In that regard, you're now a member of the 100% 99.9% Club, since 100% 99.9% of owners/users find the software to be a piece of crap.   :--

[post-edit:  modified for fairness, since Rick says, "It's not that bad".]

Quote
My big issue with the scope right now is the noise level. In reading this, I thought I read that a DC/DC converter was causing the roughly 10 mV noise seen in the channels? Do you all think it's possible to clean up the noise...

Sure.  Though how much reduction you can achieve, for effort expended, remains to be seen.  You could be very successful, since no one AFAIK has taken the time to try.  You'd be exploring new territory.  Which is always fun.  :)  The first step would be to localize the source of the current internal noise (which would most easily be accomplished with a high sensitivity, low noise scope... though simple trial & error would work too!).

Quote
and get slightly better resolution as far as the signal goes, or is that asking too much from this scope?

I'm less certain on the resolution.  I vaguely recall someone reporting that both the 20 mS and 50 mV/div ranges were "fake" (zoomed), and the highest real sensitivity was only 100 mV/div(?).  I'm not sure you could increase that, and until you rectify the noise issue, there's no reason to try.

I'd encourage you to continue with your project.  Let us know what you come up with, and any questions you run into along the way.
« Last Edit: November 26, 2013, 04:56:44 am by Mark_O »
 

Offline Rick Law

  • Super Contributor
  • ***
  • Posts: 3423
  • Country: us
Re: Hantek 6022BE 20MHz USB DSO
« Reply #65 on: November 26, 2013, 01:05:52 am »
I sure would not mind a better software.  Truth be told, the native software is not that bad.  It has some annoying things but it is usable.

It is a useful one now; it could be a great one with just a few improvement:  If we can reduce the noise, implement a better trigger (which would probably improve greatly by removing noise alone), fix a few minor annoying thing with the software, add AC coupling, this would be a great low cost scope.

If it just fix these two things with the software, I would love it:

(1) Missing a better way to move around saved data:

The worst (in my view) is to hunting for the wave form.  For example (my recent use), I captured a 100ns burst that I want to look at more closely.  At the setting I captured, when zoom all the way out, I have about 42.5ms of data.  To find that 100ns requires a lot of dragging.  Worst is, one mistake (by rolling over some active buttons) and you are reset back to the end (or start) of the capture depending on where your mouse is.  Now you have to drag and drag and drag to find that noise burst again.  Great fix will be an option for a zoomed-out display of the entire captured data you click on the part you want to center/zoom.

(2) While it captures 2M data points, it is hardly useful:

The other annoying thing is related to the above but this one is probably in the firmware and not the PC side: what part of the wave it captures (after trigger) and it's relationship to the memory buffer is not controllable.  Say if you are capturing at 1016 points.  It is pure luck what the buffer pointer is at when you triggered.  It could be at (say) point 6 and you capture 1010 points after trigger.  But it could as easily be at point 1010 and you captured 6 points after trigger so you missed your entire waveform except the start.

I tried to capture something simple like a capacitor discharge.  I kept getting just a small portion of it when the whole discharge would have fit into merely a 1/2 to 1/3 the captured memory space.

A great solution would be if it treats the buffer as a ring buffer with indirect access: wrap the buffer array index back to zero so the trigger point is always at the center or a settable number.  So, you can set X to say 40, you get 40 points before trigger and 1016-40=616 points after trigger.  Simple arithmetic: display datapoint[Y] is really buffer[remainder((Y+x)/1016)].

Without this fix, you have to be really luck to capture the entire useful part of the wave form.
 

Offline Mark_O

  • Frequent Contributor
  • **
  • Posts: 939
  • Country: us
Re: Hantek 6022BE 20MHz USB DSO
« Reply #66 on: November 26, 2013, 03:14:09 am »
I sure would not mind a better software.  Truth be told, the native software is not that bad.  It has some annoying things but it is usable.

You're a more patient man than I, Gunga Din.  :)

Quote
A great solution would be if it treats the buffer as a ring buffer with indirect access: wrap the buffer array index back to zero so the trigger point is always at the center or a settable number.

That one may be a hardware constraint, not solvable at the SDK level.  :(  It's unclear from their docos what control you have over that, if any.  But you spec a few parameters, then tell it to go off and capture.  Wait for it to finish, then pull the data out of the buffer you gave it a link to.

If you want me to pull up my notes sometime, and we can discuss it here, I doubt anyone else would mind.
 

Offline tehmeme

  • Regular Contributor
  • *
  • Posts: 102
  • Country: gb
Re: Hantek 6022BE 20MHz USB DSO
« Reply #67 on: November 26, 2013, 03:18:03 am »
  Hello everyone,

I've been watching this thread for a while, and I just wanted to say thanks for putting up all the cool information. I bought this scope a few months ago, thinking I'd do like what Aurora was talking about and mod it out. I've been writing a Python front-end for the API Hantek provides (I'm not huge on the provided scope software), and was thinking about doing the same in C++. I saw the OpenHantek project but it doesn't look like it supports the 6022BE scope. Is this something you all might be interested in?

why not implement support for the 6022BE in the already existing openhantek instead of creating something from scratch and all the issues involved with that?
 

Offline Mark_O

  • Frequent Contributor
  • **
  • Posts: 939
  • Country: us
Re: Hantek 6022BE 20MHz USB DSO
« Reply #68 on: November 26, 2013, 05:01:40 am »
why not implement support for the 6022BE in the already existing openhantek instead of creating something from scratch and all the issues involved with that?

Does OpenHantek run on Windows?
 

Offline Rick Law

  • Super Contributor
  • ***
  • Posts: 3423
  • Country: us
Re: Hantek 6022BE 20MHz USB DSO
« Reply #69 on: November 26, 2013, 05:23:20 am »
I sure would not mind a better software.  Truth be told, the native software is not that bad.  It has some annoying things but it is usable.

You're a more patient man than I, Gunga Din.  :)


Nope, I just had no choice.  This is the only scope I have, so I accept the way it works and work around it.  I did help me found the problem I was looking for.

A great solution would be if it treats the buffer as a ring buffer with indirect access: wrap the buffer array index back to zero so the trigger point is always at the center or a settable number.

That one may be a hardware constraint, not solvable at the SDK level.  :(  It's unclear from their docos what control you have over that, if any.  But you spec a few parameters, then tell it to go off and capture.  Wait for it to finish, then pull the data out of the buffer you gave it a link to.

If you want me to pull up my notes sometime, and we can discuss it here, I doubt anyone else would mind.


You don't need to dig up your notes in the SDK.  I too think it is not at the SDK level.

You can't really link the data post capture.  To work with the data, you have to save it.  No one can click fast enough to do two consecutive trigger+save when working with even millisecond waves.  Even USB transfer with the SDK would not be able to handle 48MHz data transfer.  So if this is done, it has to be done inside the Hantek box itself.

I think that may be able to implement at the firmware level instead of hardware.  At capture of mere 48Mhz, there should be enough time to do an extra add, divide to calculate the memory address then access the memory for writing.

That one "little" change would make the captured memory so much more flexible.  As it is, capturing say a 100us burst by capturing 200us means you only have 50/50 chance of seeing the whole wave form.  So, to have a one in 10 chance of seeing the whole thing, I have to capture 10x the duration --- and then all that scrolling extra scrolling to find the darn burst...  That is damn annoying to use.  One really has to really really want to see it to go through that.
 

Offline uboot

  • Contributor
  • Posts: 25
  • Country: de
Re: Hantek 6022BE 20MHz USB DSO
« Reply #70 on: November 27, 2013, 06:14:46 pm »
Ok here are the pictures.

Nice PCB. It is laid out in a logical manner.

The parts count is relatively low and a CY7C68013 development board costs around $10 from China. But I still don't think I would bother to build one of these using such a board as the additional parts, case, scope probes and my time would make it far more expensive than GBP49. In those terms it is very good value for money. Next test will be to see how the unit performs with the infamous Hantek software package !

Looking at the PCB pictures I wonder if the 6022BE can be upgraded with an external trigger like 6052BE and 6082BE have...

http://hantek.com/en/ProductDetail_2_31.html

Might require new firmware, I'm afraid...
 

Offline RichardK

  • Regular Contributor
  • *
  • Posts: 157
Re: Hantek 6022BE 20MHz USB DSO
« Reply #71 on: November 27, 2013, 11:26:31 pm »
Looking at the PCB pictures I wonder if the 6022BE can be upgraded with an external trigger like 6052BE and 6082BE have...

http://hantek.com/en/ProductDetail_2_31.html

Might require new firmware, I'm afraid...

The hardware is there and the traces run into the pin one side of the USB Micro, all you need is a BNC, C62 and R13 and then it's all firmware from then on.

You would have to extract the firmware from the other model drivers and do some reverse engineering on the OP code to figure out what part is responsible and find a way to hack it into the 6022BE driver (which contains the firmware).

After all that, you still need to modify the software and the software used by the other models is vastly different from the software used on the 6022BE, just look at the SDK headers.
 

Offline RichardK

  • Regular Contributor
  • *
  • Posts: 157
Re: Hantek 6022BE 20MHz USB DSO
« Reply #72 on: November 27, 2013, 11:30:20 pm »
I just acquired one of these DSOs and I am going to be modifying it a bit, adding extra bypass capacitors, shielding the DC-DC and adding screening cans to both front ends and I will be posting my results here.

Also, I have been tinkering around with the crappy SDK provided by Hantek and I managed to get some framework code written in C++ Builder and I even managed to get some undocumented functions from both DLLs (HTDisplayDll and HTMarch) working, though I had to use IDA Pro to figure out what the function arguments were.

Anyway, will be back later with more.
« Last Edit: November 28, 2013, 12:04:23 am by RichardK »
 

Offline Mark_O

  • Frequent Contributor
  • **
  • Posts: 939
  • Country: us
Re: Hantek 6022BE 20MHz USB DSO
« Reply #73 on: November 28, 2013, 01:07:29 am »
I just acquired one of these DSOs and I am going to be modifying it a bit, adding extra bypass capacitors, shielding the DC-DC and adding screening cans to both front ends and I will be posting my results here.

Sounds good.  We'll be looking forward to it.

Quote
Also, I have been tinkering around with the crappy SDK provided by Hantek and I managed to get some framework code written in C++ Builder and I even managed to get some undocumented functions from both DLLs (HTDisplayDll and HTMarch) working, though I had to use IDA Pro to figure out what the function arguments were.

That's interesting.  I did have some documentation on the args to HTMarch, but still wasn't clear what they were all supposed to do.  I made the mistake of asking Hantek "tech support", instead of just doing some black-box testing.  Never did get an answer to any question, and never got back to it again.

If you feel like sharing your findings on the args, that would be helpful.  Or I could just PM you with the info I had on some, and the couple I couldn't figure out.  I'm sure that would be much more productive than the month I spent exchanging emails with Hantek for nothing.
 

Offline RichardK

  • Regular Contributor
  • *
  • Posts: 157
Re: Hantek 6022BE 20MHz USB DSO
« Reply #74 on: November 28, 2013, 03:05:08 am »
Here are some of the DisplayDll undocumented functions:

Code: [Select]
//Unducumented Functions
DLL_API int WINAPI HTDrawAcquireMode(HDC hdc, int x, int y, COLORREF h, __int16);
DLL_API int WINAPI HTDrawBottomPentagon(HDC hdc, int, int, COLORREF color);
DLL_API int WINAPI HTDrawCouplingImage(HDC hdc, int, int, COLORREF color, __int16);
DLL_API int WINAPI HTDrawCursorLine(HDC hdc, int, int y, int x, int, int, int, HGDIOBJ ho, int, int);
DLL_API int WINAPI HTDrawCursorTraceLine(HDC h, int x, int, int, int, int, int);
DLL_API int WINAPI HTDrawDefineText(HDC hdc, int, LPCWSTR pszFaceName, int mode, LPCWSTR lpString, int c, int x, int y);
DLL_API int WINAPI HTDrawEdgeSlope(HDC h, int, int, COLORREF hbr, __int16);
DLL_API int WINAPI HTDrawGeneratorRect(HDC hdc, int, int, int, int);
DLL_API int WINAPI HTDrawGridARB(HDC hdc, int, int, int, int, int, int, int, __int16);
DLL_API int WINAPI HTDrawGridBorder(HDC hdc, int, int, int, int);
DLL_API int WINAPI HTDrawGridLA(HDC hdc, int, int, int, int, int, int, int, int);
DLL_API int WINAPI HTDrawGridNew(HDC hdc, int, int, int, int, int, int, int, __int16);
DLL_API int WINAPI HTDrawGroupGridLA(HDC h, int, int, int, int, int, int, int, int);
DLL_API int WINAPI HTDrawKnob(HDC h, int, COLORREF color, int);
DLL_API int WINAPI HTDrawLABusSignal(HDC hdc, int, int Memory, int, int, int x, double, int, __int16, __int16);
DLL_API int WINAPI HTDrawLASquareSignal(HDC h, int, COLORREF color, int, int, int, double, int);
DLL_API int WINAPI HTDrawLATrigLine(HDC hdc, HGDIOBJ h, int, int, HGDIOBJ ho, COLORREF color);
DLL_API int WINAPI HTDrawLeftPentagon(HDC hdc, int, int, COLORREF color);
DLL_API int WINAPI HTDrawLevel(HDC hdc, int, int, COLORREF h, int y);
DLL_API int WINAPI HTDrawMeasLine(HDC h, int, int, int, int, int x, int y, HBRUSH ho);
DLL_API int WINAPI HTDrawPrintGrid(HDC hdc, HGDIOBJ h, HGDIOBJ ho, int, int, int, int, int, __int16);
DLL_API int WINAPI HTDrawPrintGridBorder(HDC hdc, HGDIOBJ ho, int, int, int, HGDIOBJ h);
DLL_API int WINAPI HTDrawPulseWidth(HDC hdc, int, int, COLORREF h, __int16);
DLL_API int WINAPI HTDrawRightPentagon(HDC hdc, int, int, COLORREF color);
DLL_API int WINAPI HTDrawSquareWaveInYT(HDC hdc, int, int, int, int, COLORREF ho, HGDIOBJ h, int, int, int, int, int, double, double, int, int);
DLL_API int WINAPI HTDrawTopPentagon(HDC hdc, int, int, COLORREF color);
DLL_API int WINAPI HTDrawWaveInXY(HDC hdc, void *Memory, int, int, int, int, int, int, int, int, COLORREF color);
DLL_API int WINAPI HTDrawWaveInXYNew(HDC hdc, void *Memory, int, int, int, int, int, int, int, int, COLORREF color);
DLL_API int WINAPI HTDrawWaveInYTNew(HDC hdc, int, int, int, int, COLORREF color, int, int, int, int, __int64, int, double, double, int, int);
DLL_API int WINAPI UserRound(double);

and some for HTMarch.dll that I have not got arguments for yet:
Code: [Select]
HTMARCH_API short WINAPI _dsoCloseFlashLight();
HTMARCH_API DWORD WINAPI _dsoGetPackageSize();
HTMARCH_API short WINAPI _dsoOpenFlashLight();
HTMARCH_API short WINAPI _dsoReadPackageData();
HTMARCH_API short WINAPI dsoSetSquareFreq();
HTMARCH_API short WINAPI _dsoStartDeviceCollect();

The rest of the documented functions are in the PDFs in the "Manual" directory that comes with the "SDK", with some chinglish but decipherable.

The comments in there mostly told me what arguments for the documented functions are and the integer range for some as well as the different options and modes. I turned most of them into enums for easier reading in the code and made a wrapper class for the DLL functions and it's still boiler plate at this point but when I get some more time after the holidays I'll try and get something more functional and put the code up here for anyone who wants to tinker with it.
« Last Edit: November 28, 2013, 03:13:05 am by RichardK »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf