-
#125 Reply
Posted by
psynapse
on 02 Nov, 2014 01:27
-
Donut6
I have a small problem with the code. The data buffer is constantly overwritten. This means that you cannot search the data for start points and you must expect to see one or more splice points of new data .
A couple of approaches are possible:- Tell the scope to stop sending data (but we all know that it does not like that, and if we are to support continuous modes on the DDS120/140 this is a problem .
Lock the input buffer whilst data is copied out from it.
Support multiple buffering in order to give enough time to read a buffer.
I do not know enough about libusb to know which are possible, do you have any sage words please?
EDIT
I do have a trigger of sorts working now. (It is important to remember that the first 27 bytes of "data" are not in fact scope data!)
I also seem to have sufficient control (by using the 34 command) to avoid buffer overwrite, but that is a provisional finding! 5If I have not noted it before 34 00 and 34 FF are start and stop
-
#126 Reply
Posted by
donut6
on 02 Nov, 2014 20:12
-
psynapse,
Support multiple buffering in order to give enough time to read a buffer
The function scope_usb::scope_get_buffer writes into the buffer. I imagined this running in a thread, populating a large ring of buffers instead of the single "scope_data" array.
The "app" thread can then take it's time doing any sort of analysis, rendering, etc
I expect there is open source scope that already does this, so perhaps no point reinventing the wheel here.
Feel free to progress things any way you see fit as I haven't had time to spend on this project.
Although I may have a quick attempt at writing a proof of concept sdcc/fx2lib firmware.
-
#127 Reply
Posted by
psynapse
on 02 Nov, 2014 22:41
-
Donut6
Thanks, yes, seems a good way forward. I can write the code to fill a ring of buffers, but what I am less clear about is how I spawn an autonomous thread to fill those buffers. I know you are short on time, so can you point to some example code which can bring me up to date (I note that your code already has "THREAD" in it, how far advanced is that please?). I will also look at the triplespark guys code, maybe he has a ring of buffers (although as I recall he has a "layer" between the App and libusb to do the buffering).
And "no reply" is also entirely acceptable :-)
-
#128 Reply
Posted by
doctormord
on 03 Nov, 2014 16:11
-
Why not having an array in an array to create a ringbuffer.
I.e. 1024byte array in a 32 field array built as a ringbuffer. I use something similar in a microcontroller to have float averaging.
-
#129 Reply
Posted by
psynapse
on 04 Nov, 2014 11:06
-
Doctormord,
Yes, that would be my solution of choice too. The trouble is working out exactly how to pass a pointer to the OS (copying the data from the OS buffer to the application buffer represents too much of an overhead)
Mmark,
I have looked at both wxwidgets and qt and prefer qt I think! So my current plan is to port elements of the donut6 code into qt and then add to it. But to avoid us both doing the same thing, what are your plans/progress please?
and I need to patch the firmware and look at the jtag!
-
#130 Reply
Posted by
mmark
on 05 Nov, 2014 01:15
-
Some progress:
Got OpenHantek to compile on my Mac with Qt5.3 & clang and added some initial code to talk to my DDS120:
Neither range setting, voltage scaling, sample rate setting or triggering works yet, but I was quite excited to see some real oscilloscope data on my screen today for the first time... It's a start!
Don't know how to share this in the best way. Do you guys want a github project or should I just zip up the src and post it somewhere? Just in case someone wants to play with the code (it in rough shape..., you will need to change the OpenHantek.pro for sure to get it to compile), but I'll attach a zip just in case.
mmark
-
#131 Reply
Posted by
psynapse
on 05 Nov, 2014 01:38
-
MMark
Well done, have just downloaded your code to play with. Your problems on scaling etc ... it is late, and I have not checked but Donut6 and I have been working on DDS140 codes and I am not sure that we have 100% verified that they are the same, similar yes, but ... so beware
I have been working on getting a platform for firmware modification. Getting the tools together etc. For those that are interested "cycfx2prog" (at least in the Ubuntu repository, and source available) will download an Intel hex file into the RAM of the FX2 (if it is started with its eeprom jumper off) and from there will allow the code to execute. This is much faster than loading the eeprom each time, and more importantly gives you a fall back to a working device at the flick of a jumper. To verify this I have turned the original eeprom dump into an intel hex format file, which can be reloaded to the DDS140 and works.(attached) More importantly (for me), I have also generated annotated assembly code which is bit perfect with the original .... meaning of course that firmware additions can now be added very easily.
-
#132 Reply
Posted by
mmark
on 05 Nov, 2014 02:13
-
Psynapse,
I don't have any problems with the codes (I am using the codes for the DDS120 as identified by doctormord, which seem to work in my test120.cpp application as expected). It's just that the code inside openhantek is --- aehh ---- somewhat complicated to say it politely
.
So I need to figure out how I need to scale the data in the way openhantek wants it to be scaled and add functions to actually change the gain and the sample rate of the SainSmart scopes. So far I just removed all the code for the Hantek scopes and just implemented the getSamples methode. In the meanwhile I also implemented the setCoupling methode, which seems to work correctly, but I need to find a clean way to remove options (like GND coupling) which are not supported by the SainSmart scopes...
-
#133 Reply
Posted by
doctormord
on 05 Nov, 2014 09:13
-
Great work guys!
^-^
-
#134 Reply
Posted by
psynapse
on 05 Nov, 2014 10:58
-
mmark,
Well, that you have got good DDS120 codes is good news (so well done to Doctormord as well). I know what you mean about the openhantek code. I looked as well and decided that it would be quicker to use Donut6's code to get the data (and control the scope) and then to write a whole new front end in QT ..... that way I have a working system I can improve (by adding buffers as previously discussed, as well as extra features). That decision as to whether it is better to adapt existing code or write new code is always hugely difficult.
For me (with a DDS140) the new code route seems better, because there is a second operating mode which does not exist in the basic Hantek and because some of the features I want to add exist neither in the hantek, dds120 or dds140. In particular something resembling an external trigger, or at least a signal outputted to mark beginning / end of sampling
Doctormord;
I have looked at your photos of the DDS120 board, and as far as I can see INT4 INT5 is not connected anywhere ..... Please could you confirm that I am right .... My intention is to use INT4 INT5 as an external trigger (of sorts). Also, what advice do you have on buffering the pin .... which series of devices gives the best isolation, do I need clamp diodes etc (Not Int4 because there is a potential clash with FIFO interrupts, although these are not currently used in the DDDS140)
-
#135 Reply
Posted by
doctormord
on 06 Nov, 2014 12:12
-
-
#136 Reply
Posted by
sandos
on 06 Nov, 2014 13:34
-
I was looking at DDS120 before buying the Hantek6022, but it seems the community around the sainsmart is even more lively than that around the Hantek!
I assume you people have already seen
https://github.com/rpm2003rpm/HT6022_Driver which is a libusb based driver for the 6022. You guys seem to have an even better grasp of things, so this might not change anything. I am curious though what the exact differences are between the DDS120 and the 6022? I am planning on writing an android app to talk to the Hantek, by simply translating the libusb code to androids native usb host API. Was planning on doing it in java to start with, even though performance is likely to suffer. I was also planning on using the 1Khz square wave to try ascertain any "dead periods", but I will have to see how that works out.
-
#137 Reply
Posted by
doctormord
on 06 Nov, 2014 15:28
-
The 6022 got no AC-coupling.
-
#138 Reply
Posted by
doctormord
on 07 Nov, 2014 13:40
-
I would suggest that (for DDS120 users) channel interleaving might be really useful, doubling the maximum acquisition rate, but wouldn't that need a small hardware modification? There are several ways of tackling that problem, which one are you thinking of?
Sure, we need to double the ADC-frequency at first, i.e.:
http://www.maximintegrated.com/en/app-notes/index.mvp/id/3327and then attach a phase-splitter (0/180) to feed both channels seperately. The AFE might some compensation due to lower the (now) lowered input impedance.
Alternatively, the clock needs to be shifted by 1/2 clock-cycle to feed into ENCA/ENCB. (Without frequency doubling)
Should work with "data aligning enabled" - or the delay needs to be corrected in the host-app.
-
#139 Reply
Posted by
psynapse
on 08 Nov, 2014 01:28
-
All,
Sorry I have gone quiet a couple of days, I have been improving my Qt skills (which did not exist). Except for the all important trace display, I now have Donut6 code running under Qt, which is probably easy for all you young guys out there , but has proved very difficult for me. When I have graphics up and running, I shall go back to the firmware.
Doctormord,
Obviously phase inverting the clock to one ADC is the easiest solution conceptually, but I rather guess it demands taking the ADC off the board in order to cut the trace beneath the chip itself. That is something you are capable of, but it is way too difficult for me! Perhaps lift a leg (but a pretty poor engineering solution).
Also, not sure whether you have seen this information from the ADC datasheet
"The other option allows the user to skew the B channel output
data by 1/2 of a clock cycle. In other words, if two clocks are fed
to the AD9288 and are 180° out of phase, enabling the data
align allows Channel B output data to be available at the rising
edge of Clock A. If the same Encode clock is provided to both
channels and the data align pin is enabled, then output data
from Channel B is 180° out of phase with respect to Channel A.
If the same Encode clock is provided to both channels and the
data align pin is disabled, both outputs are delivered on the
same rising edge of the clock.
Table 4. User-Selectable Options
S1 S2 Option
0 0 Standby Both Channels A and B.
0 1 Standby Channel B Only.
1 0 Normal Operation (Data Align Disabled).
1 1 Data Align Enabled (data from both channels avail-
able on rising edge of Clock A. Channel B data is
delayed a 1/2 clock cycle).
Badly expressed, but seems to suggest that programming the S1 S2 pins might get us what we want
-
#140 Reply
Posted by
mozart5474
on 08 Nov, 2014 07:36
-
i have got the same problem as gambit 58 on my win7 64bit. device not be found error. any help how i might get it running? i have tryed it on a 32 bit machine and had no troubles but at this machine it is not going anywhere. tryed installing reinstalling over and underinstalling sideinstalling screaming and crying at it, begging snobbing and of course the good old delete it and make it anew from the root to the top but no luck. "Device not be found." anyone?
-
#141 Reply
Posted by
psynapse
on 08 Nov, 2014 11:09
-
Mozart5474,
Sadly I am not a windows expert, far from it. The generic answers are likely to be
1) the device does not work (though not in this case)
2) that it is not plugged in (although it might appear so. Note in particular the high current needs of the device, machines differ in their USB current delivering capacity)
3) that the driver is not installed (does it appear correctly in what I continue to call "control panel")
4) access permissions, the device might function, be connected, have a driver installed but not be accessible to you as a user.
-
#142 Reply
Posted by
mmark
on 09 Nov, 2014 05:52
-
Update:
timebase setting, y-scaling and switching between AC and DC coupling works for me now at least somewhat for my DDS120. I didn't do any real calibration yet (traveling right now and only have the DDS120 with me). And still no triggering, but at least it starts to get somewhat useful...
There seems to be a problem with sample sized > 2048 bytes. If I try to read more then 2048 bytes, then there is always a jump in time at sample 1024 (e.g. at 2048 bytes). You can see that if you set the sample size to large (which is 32768 for now...) and select a time base of 1ms or longer. I tried sending 0x33 cmd before reading the data with various delays, but the discontinuity stays there no matter what. The data after this point seems to be continuous again... I am wondering if the OEM software discards the first 2048 bytes for buffer sizes > 2048...
Also, my 5 year old mac book is somewhat struggling keeping up with redrawing the screen if the small buffer (2048) is selected. I added a 10 ms delay to the end of getSamples() to relief this a bit, but the GUI still get sluggish after a few seconds. Either switch to the large buffer or start/stop the sampling only for short times. And there is a display error in the lower right part of the DSO widget, but this goes away after toggling the zoom mode once (I have only seens that on my mac and not on linux) .
Anyhow, the updated code is attached.
here is a complied binary for ubuntu 14.04 (in fact it is compiled under xubuntu 14.04)
https://drive.google.com/file/d/0B4k4TyIzvHKANXdlSTQ4bDZaaHc/view?usp=sharingand here a dmg for those with a mac:
https://drive.google.com/file/d/0B4k4TyIzvHKATW1rb1VpOXVpbzQ/view?usp=sharingTo compile und linux/ubuntu, you need to have libqt4-dev (or libqt5-dev) and fftw3-dev installed. To access the device as a user, add this to /etc/udev/rules.d/50-sainsmart.rules:
#add SainSmart DDS120 and DDS140 to group plugdev
#DDS120
SUBSYSTEM=="usb", ATTR{idVendor}=="8102", ATTR{idProduct}=="8102", GROUP="plugdev"
#DDS140
SUBSYSTEM=="usb", ATTR{idVendor}=="8312", ATTR{idProduct}=="8312", GROUP="plugdev"
and make sure that your user is member of the plugdev group.
-
#143 Reply
Posted by
jimon
on 09 Nov, 2014 13:20
-
Hi guys,
When playing around with it, I connected signal, that is suppose to be square with freq around 4.8 mhz, to both channels.
Probe connection is made to exact same points (both signal and ground connections).
And I got what on screenshot.
First I thought that it's a probe compensation difference, but then I switched probes on oscilloscope side (so just swaped bnc's).
And guess what, I got same result - more sin-ish on second channel, and more square-ish on first channel.
What it could be ?
PS. siqnal source is an attiny13a that I playing with now, it runs this simple program
http://pastebin.com/HH1sscZN and fuses are set to 7A FF
-
#144 Reply
Posted by
doctormord
on 09 Nov, 2014 13:36
-
Well, at 50Msps, you'll get 10 datapoints per periods (at 5MHz signal). - that's what you see. Additional errors are from the non compensated AFE (analog frontend).
The shifting, timewhise, might be a result of the increased propagation delay on one channel due to the bigger pcb-loop.
To interpret correctly, the signal waveform, generated by the attiny, should be checked with a proper scope. (rise-/fall-times)
-
#145 Reply
Posted by
Guizmo
on 09 Nov, 2014 23:48
-
Hello, I have the same problem of gambit 58 and Mozart5474 and have a W7 64 laptop. But I found a little solution.
Not "The" solution I wanted but ...
It is as simple as it is anoying... I have 4 USB and only one is working with the DDS.
I tries to uninstalled, install by another port but this is always the same USB which is working.
So.. you shoud try all your USB port!
Viewing how simple is my "solution" I am not sure at all it will work for you.
This must be a little parameter causing all this trouble but I am unable to find it !
Hoping this will help you,
cya
I
-
#146 Reply
Posted by
ganzuul
on 10 Nov, 2014 01:40
-
Update:
You are a rock star!
Compiles with QtCreator at the click of a button, once the build path is defined. This is on Ubuntu 14.04 LTS.
Amazing update rate... This is so cool!
I'll try to keep up with you... and contribute something useful. lol.
-
#147 Reply
Posted by
doctormord
on 10 Nov, 2014 05:35
-
Any chance to run this under windows?
-
#148 Reply
Posted by
ganzuul
on 10 Nov, 2014 08:48
-
I think so. QtCreator only complains about libusb1.0 and fftw3 being missing. I'll see if I can figure out this Win32 stuff.
-
#149 Reply
Posted by
doctormord
on 10 Nov, 2014 13:06
-
Thanks in advance.