Somewhere out there is a software engineer who understands the workings of the WaveVision DLL (wvdll.dll). If you could kindly provide some info on the following questions:
1) The newest DLL, which is compatible with Win7, does not completely conform to the .h and .lib files provided with the previous version. In particular, the new 'WvCaptureSetup' structure has four new elements: tot_num_acqs, num_bufs_used, num_acqs_per_buf, and num_bufs_per_set. These are not covered in the help file or programmer's guide, and the example found in the supplied Python code is a trivial case that makes it hard to intuit the purpose of these elements. Could you kindly provide some background on how these are used to effect multiple waveform capture?
2) The programmer's guide alludes to the possibility of using the DLL to change certain control elements, specifically the use of an external trigger, and reprogramming the sampling rate; however, no instructions are provided. There are low-level functions for manipulating registers, but it is not clear how to distinguish among registers for the ADC itself, the timing chip, or the FPGA itself. Could you kindly provide some information that would enable me to change the aforementioned controls using the API provided for the DLL?
3) The DLL appears to be rather slow when acquiring waveforms, on the order of only 10 Hz. Turning off the detailed debug output may help increase that speed, but there are no instructions on how to do so, and I expect the gain will be minimal. My particular application requires operating with an external trigger at 2 kHz, with each waveform requiring 1500 samples. These data rates are well within the capability of the chip, the USB interface, and the host PC; however, it would seem the rigid structure of the API is preventing operation at higher rates. Is it possible to push the reference board to higher rates? If this requires new firmware for the FPGA, is it possible this has already been done elsewhere, that I might avoid a lengthy development process?
Thanks in advance for any assistance you can provide.
Best regards,
--Ken
Hi Ken,
I have forwarded your question along to a software engineer who has been involved with this project in the past. (Otherwise, he does not follow this forum.) We will get back to you as soon as he has a response to your questions.
Kind regards,
Marjorie
Hi Ken
I have worked with our software engineer to gather the updated support files related to the newer WV5 DLL. That information has been combined with the earlier support information into this .zip file: 7144.Wavevision5 DLL API Support.zip (duplicate zip file contents removed 5/17/2012 by Jim Brinkhurst 84999)
I hope this is useful to address part 1 of your questions. Hopefully these will help you to configure your system as needed to complete your evaluations of the ADC.
I don't know if it will be possible to achieve the high trigger based capture rates (2kHz trigger rate) you are looking for. Unfortunately, the WV5 DLL was not optimized to achieve fast repetitive sampling. It was intended as a general purpose tool to allow customers to evaluate data converter products before proceeding to their own hardware design.
If you have a specific follow-up question about the DLL and how to utilize it with the ADC board you are using please let us know.
Jim B
Dear Ken,
it seems we are facing the same issues... Exactly as you wrote, we would like to program a custom application which should capture data from adc12d1800rfrb board with an external trigger and a refresh rate of about 1kHz or so (o.s. win7 x64).
I'm just debugging the low level messages in order to drive the adc12d1800rfrb board and, at first, I can tell you that a number of samples lower than the minimum specified leads to an error when calling the CaptureStart command (this addresses the fact that you want a vector of 1500 samples).
I saw that in the "capture_configs" struct array (under Wv_Capture_Request struct), the struct ID#3 is the DESI channel (i.e. the one that should be sampled at 3,6GSPS), so I'm trying to see if starting the capture with channelID = 3 gives the data sampled at high sample rate.
I'd like to ask you if you managed to set the external trigger and, in case, how because I'm running out of ideas..
Thank you very much,
Alessio
Jim,
Thanks for the updated files; however, they added little in the way of explanation, and in fact added some confusion -- the CaptureSetup structure still shows unused fields and does not match the Python example, plus it now adds the additional field 'num_acqs_per_strm'. I'm surprised I'm not getting stack corruption due to the larger structure, and I suspect these new files do not match the current WaveVision DLL, or if it does, I'm getting lucky. Is it possible there are multiple variants of this code that are specific to particular customer requests? If not, surely there is a specific configuration managed grouping of source files, libraries and DLLs that are self consistent.
I understand your comment regarding the acquisition rate; this is indeed a test tool, but I had hoped for a bit more performance. 10 Hz is a bit weak, but it does match the performance of the WaveVision software.
There still are no examples for changing the sampling rate or switching to the external trigger. I suspect these are controlled by FPGA registers, but there is zero documentation. I can glean some insight by deciphering the script files included with WaveVision, but that still doesn't help me understand which bus index and register address to use to effect these particular changes.
It would appear that Alessio is having similar problems, and that we both could use a little more documentation, as well as consistent, configuration managed source code. I again appeal to you for additional information to help us with our respective projects. I don't have a problem with "unsupported code," but need at least a good starting point from which to work.
Thanks, and best regards,
from some quick measurement, we got a 3.6GSPS sampling by selecting the channel identified by ID=3 (DESI), (see the programming's guide example, "req.ChannelDataIndex = 3 <<<<--- THIS ID;")
Again, no idea on how to select the external trigger...
If you have any clue and if you if want to share it, it would be very appreciated... I wouldn't like to go into a very long loop of FPGA registers dumping and checking before and after the H/W Trigger select in the WaveVision software. I'd like to consider this a last resort effort...
Best Regards,
..apart from the issues we are facing with, I'd like to remark the great capabilities of the ADC12D1800..... It is a real groundbreaking adc....
Alessio,
The channel index makes sense; it is helpful to look at the various strings returned in the DUT information structure. If I read it right, there are 4 "channels" : only I, only Q, both I & Q, and DESI.
Still waiting for insight from TI on the external trigger. I tried tracing the logs for WaveVision, and it looks like it may be buried inside the DLL's GUI handler. The log shows changes to the external trigger checkbox, but does not show subsequent register access. I may end up using their GUI control, hiding it inside my own dialog. I will try some more experimentation this evening, but I too tire of trying to reverse engineer the right steps. I am hopeful our friend Jim B will provide some answers soon.
Either way, if I figure it out, you can count on a post in this forum.
for completeness, I got 7 channels.... Yes, I also gave a look at the Log from WaveVision but I came to the same conclusion: the messages there only refer to the GUI... I've got a dump of the External Trigger bit, but I can't figure the correct address out... I'll give it another try later on..
I'll keep you udpated as well...
Regards,
Jordan or Jim,
First, thank you. The external trigger register makes sense now; however, I won't be able to test until week's end due to travel. I assume there is a similar sequence for controlling the sampling rate, but I'll research the scripts first before asking questions.
Regarding the various verions of the capture setup structure:
In the original driver, the WvCaptureSetup structure looked like this:
typedef struct { /** UNUSED */ WvDouble __u1__;
/** Size of capture in samples */ WvWord TransferSize;
/** Index to ChannelData in WvDutInfo */ WvWord ChannelDataIndex;
/** 0 is capture or DAC, 1 is histogram */ WvWord HistogramEnable;
/** Set histogram max bin value before stop */ WvWord HistogramMaxBin;
/** Data format */ WvDataFormat DataFormat;
/** UNUSED */ WvWord __u2__; /** UNUSED */ WvWord __u3__; /** UNUSED */ WvWord __u4__; /** UNUSED */ WvWord __u5__; /** UNUSED */ WvWord __u6__;} WvCaptureSetup;
But, according to the Python example, it should look like this:
typedef struct { /** UNUSED */ WvDouble DACFreq;
/** UNUSED */ WvWord tot_num_acqs; /** UNUSED */ WvWord num_bufs_used; /** UNUSED */ WvWord num_acqs_per_buf; /** UNUSED */ WvWord num_bufs_per_set; /** UNUSED */ WvWord MultiplexedChannelIndex;} WvCaptureSetup;
In the most recent version you sent (P2R1) it looks like this:
/** 0 is capture, 1 is histogram */ WvWord HistogramEnable;
/** UNUSED */ WvWord __u2__; /** UNUSED */ WvWord __u3__; /** UNUSED */ WvWord __u4__; /** UNUSED */ WvWord __u5__; /** UNUSED */ WvWord __u6__; /** Number of required loops for data stream */ WvWord num_acqs_per_strm;} WvCaptureSetup;
The first is identical to the third, except the third adds an additional element: num_acqs_per_strm.
The Python example seems to imply a capability for multiple sequential captures in a single acquisition, which could help mitigate the relatively slow performance.
Could you please clarify which structures go with which DLL revisions, and whether the multiple sequential acquisition capability exists, and if so how to use it?
Thank you for your continued patience and willingness to answer questions.
Dear Jim and Jordan,
thank you for your valuable support: following your informations, today I managed to run acquisitions with the external trigger enabled.
For Ken, I relied on the WvCaptureSetup as indicated in the wvdll_defs.h.. I had no errors and the application seems to be running in the correct way.
Thank you very much.
Hi Alessio
I'm glad you have things working as needed. If you have any questions regarding the ADC as your evaluations progress, please let us know.
I'm looking into the discrepancies between the Python example and the other documentation, but I don't have an answer right now.
I do want to point out the the on-board hardware limits the ADC clock frequency. the LMX' PLL device has very low phase noise, but by design operates over a fairly narrow range of frequencies. I'm not sure that the DLL controls will let you update the PLL parameters to choose a new frequency or not, and the loop filter components on board may further restrict things. If you want real flexibility in the clock rate you should use the external clock input. This will let you run the ADC over a larger part of its rated speed range. In addition, the FPGA image used may have a lower frequency limit that is higher than the ADCs low frequency limit. If you run into that as a boundary, let us know and I'll see if there is an alternate low-frequency FPGA image available. Finally, if you are using the external clock input, be aware that the relay, balun and traces on-board do attenuate the clock signal proportional to frequency, and therefore different external clock amplitudes should be used at different frequencies. This information will be included in the next revision of the board user's guide and is as follows:
Ext Clk Freq
To maintain 0.4Vpp
To maintain 2.0Vpp
1.0 GHz
-2 dBm
+9 dBm
1.2 GHz
+1 dBm
+11 dBm
1.4 GHz
+12 dBm
1.6 GHz
+3 dBm
+16 dBm
1.8 GHz
+2 dBm
+14.5 dBm
I hope this is helpful.
Jordan (or anyone listening in),
Sorry for the delay in following up.
Your explanation is straightforward, and I have implemented it accordingly; however, I am unable to get the external trigger to work.
Rather than fret over whether my implementation is correct, I am instead now using the WaveVision software to test the external trigger. I have set the checkbox in the Registers area, which (I think) should enable the use of the external trigger. The software continues to capture waveforms regardless of the HW Trigger setting. I have tried running without anything hooked up to the trigger (i.e. floating), forcing it to ground, and feeding it pulses -- no change. Does the firmware time out and capture a waveform regardless of whether an external trigger is present, or should it wait forever? Also, it could be that I am not feeding the board a good signal. As near as I can tell from the schematic, the external trigger is using PECL, with a Vcc of 3.3VDC. I would therefore expect that an input signal in the range of 1.5 to 2.0 VDC should be sufficient to trigger, and that less would not trigger. What should I be driving the external trigger input with? Will it take a TTL pulse? I haven't tried that, as the schematic seems to imply otherwise, although TTL would be preferable (and simpler in our test setup). I certainly don't want to blow it up, at least not yet <grin>.
Any helpful thoughts to get this working would be greatly appreciated.
Thanks!
I think you're running into an issue that the released FPGA .bit file for the ADC12D1X00RB does not support the trigger input. We have added it to the 'RF suffix boards, but it hasn't made it into the standard install for the earlier non 'RF boards. The file is attached here:
2234.adc10d1000_xc4vlx25_adc12d1000rb_supports_trigger.zip
There should already be a file with this same name in the folder below:
C:\Program Files\National Semiconductor\WaveVision5\hardware\fpga_images
Rename the existing file for safe keeping, and put the updated file in that folder. That should take care of the trigger being non-functional. If it still doesn't work for you. please let us know.