09-09-2008 12:04 PM
I opened up the "ni5660 Fetch IQ Data.vi" and ran it with the default bandwidth of 100khz and it seems to work fine. It continues to work fine up to a setting of 400khz. Then past 400 khz, i.e. 800khz, i get the error listed below. To the best of my knowledge i have the 64 MB 5660 model. I thought i should be able to do continuous acquistion for signals <1.25 MHz?
I ultimately would like to be able to capture i/q data to file for a signal <1.2 MHz running in continuous mode.
Any suggestions would be much appreciated. Thanks.
Error -1074118653 occurred at Error occurred at: niScope Initiate Acquisition.vi:2
Possible reason(s):
Driver Status: (Hex 0xBFFA4003)
Insufficient on-board memory available to perform the acquisition.
09-10-2008 11:10 AM
This example is a little confusing. There is a 'Time Duration' control, and also a 'Samples to Read' control. Both matter. It seems like only one of these should be a control, and the other an indicator, but perhaps there is a use case for having both that I don't know about. Also seems like the time duration should not have an effect if the acquisition type is set to continuous, but apparently it does matter.
So maybe these oddities are part of what is tripping you up. The bandwidth selected corresponds to a particular IQ rate. For example, 1.25 MHz bandwidth setting uses an IQ rate of 2 MS/s. Find this info in the NI PXI-5660 help (search for 'iq rate'--page title is 'Small Span Signals and Sample Rates'). The IQ rate times * time duration * 4 bytes per IQ sample cannot exceed the memory on your 5620, or you will get the error you mention.
09-10-2008 04:16 PM
Thanks for the reply.
Other things I've observed:
I put a property node in the vi to look at some things. The "IF Digitizer (562x)->Combined Decimation" matches with what I found in the 5660 help document:
For 400khz bw, decimation = 128, 200khz->256, 100khz->512. I also believe that the Time Duration input doesn't really do anything when set up for continuous acquisition. I believe this because when I set the "Samples to Read" value to something, say 1000, the total duration of the Y plot changes as I would expect:
BW = 400k -> 1000 / ( 64 Msa/s / 128 ) = 2.0 ms
BW = 200k -> 1000 / ( 64 Msa/s / 256 ) = 4.0 ms
BW = 100k -> 1000 / ( 64 Msa/s / 512 ) = 8.0 ms
I tried reducing the "Samples to Read" and "Time Duration" when trying the 800khz bw, but nothing seems to convince it to work.
Or to work it another way, even at 1.25 MHz:
64 Msa/s / 32 = 2.0 Msa/s. Shouldn't I be able to get 64 MB / ( 4 Bytes/Sample) / 2.0 Msa/s = 8.38 seconds? Or worst case if I'm wrong and I have 32 MB, still >4 seconds worth of samples.
Is there perhaps some kind of 'frame buffering' or something that needs to be accounted for when calculating the memory budget?
Thanks
09-15-2008 02:03 PM
If you still get this error with a small time duration (say 30 ms) and a small samples to aquire (say 1000), then I'm at a loss to explain why. Perhaps it would help if you reply and attach the VI with the settings you are using, including the error. Just run VI, then choose 'Edit -> Make Current Values Default'.
Also please indicate the driver version and LabVIEW version that you are using. An easy way to grab a snapshot of all installed software is to create a report in MAX. Chosse 'File -> Create Report'. A simple report is enough. Include the .html in your reply (the generated folder just has icons, which aren't important).
I suspect that there is something wrong on your system, perhaps an installation problem. If so, the above may not be enough to get to the bottom of this, but it is a start.
09-17-2008 06:57 AM
Again, thanks very much for your assistance on this. I attached an image of the vi with the settings that don't work. All that is changed from the default values is the BW to 800K and number of samples to 1000. The vi with default settings is included also. I would not be surprised if i had some installation issue. My unit went out for calibration and when it came back they had conveniently wiped the hard drive clean. I had to reinstall labview and the 5660 drivers myself. It seemed straightforward but perhaps i missed something.
09-17-2008 12:37 PM
Hum. The MAX report doesn't include any version numbers. When I create a report (using MAX 4.5.0), I see the version numbers of the installed software. Maybe you are using an old version of MAX? I see you are using LV 8.2. Which version of RFSA and SMT do you have installed?
I'm attaching a VI that will report how much memory (the driver thinks) is on your scope. I saved the defaults with the values I get on my 5620.
Do you know how many samples the VI is asking for? Inside ni5660 Configure for IQ.vi, there is a 'number of samples' output. Probing that wire may help you track this problem down. However, there are some hoops to jump through before you can probe a wire in this VI:
1) open 'ni5660 Configure for IQ.vi'. I just double-click on the instance in the diagram for your top-level VI.
2) type 'ctrl-m'. This opens a new copy of the VI in edit mode (notice 'clone' in the window title goes away).
3) On the edit-mode copy of the VI, choose File -> VI Properties -> (Set 'Category' to) Execution -> enable 'Allow degugging'.
4) save the VI
5) now you can close the edit mode copy of the VI and add probes to the original clone.
I have no idea why debugging is turned off for these VIs. Turning it back on shouldn't hurt anything, and will allow you to see what's going on in the VI. You might also enable 'Retain Wire Values' in this VI (up by the run button, just to the right of the lightbulb). That allows you to probe after the VI has finished executing (without it, you need to probe a wire before running the VI). This is basic stuff that you should probably already know.
Anyway, good luck. You should probably get in touch with NI techical support to resolve this. This doesn't look like a problem with the example. There's a problem that is specific to your system, and you'll need some debugging to figure it out.
09-22-2008 09:13 AM
The vi you attached confirmed i've got the 64MB model. I grabbed the latest driver for the 5660 and installed it, and surprisingly it actually started working now. Something must have been fixed in that driver version, or maybe i just a weird install situation and re-installing fixed it.
Thanks