04-07-2011 05:09 PM
I've set up a measurement with the following sequence of function calls:
niRFSA_ConfigureAcquisitionType
niRFSA_ConfigureReferenceLevel
niRFSA_ConfigureRefClock
niRFSA_ConfigureIQCarrierFrequency
niRFSA_ConfigureIQRate
niRFSA_ConfigureNumberOfSamples
niRFSA_Commit
Will a call here to:
niRFSA_CheckAcquisitionStatus
return isDone == VI_FALSE until the hardware has been setup?
niRFSA_Initialize // start the measurement
Will a call here to:
niRFSA_CheckAcquisitionStatus
return isDone == VI_FALSE until the block of IQ data (number of samples) is available for reading?
niRFSA_FetchIQSingleRecordComplexI16 // read the IQ data
niRFSA_GetScalingCoefficients // get the scale factors to convert 16-bit integer IQ to 32-bit real
I'm trying to use the niRFSA_* API in a non-blocking manner.
Thanks,
Gary Anderson
04-08-2011 02:44 PM
Hello Gary,
When looking for the function calls you are making, none of them are blocking calls except the niRFSA_FetchIQSingleRecordComplexI16 which contains a timeout where it waits to acquire the number of samples specified for the function. For a finite acquistion, you can prevent a blocking function call by calling in a loop the niRFSA_CheckAcquistionStatus to see if all the samples have been acquired. If it has, then the function should return a true. This function would instead return a false if you are performing a continuous acquistions because the acquisition is never completed. You will be setting the continuous or finite acquistion in the ConfigureNumberOfSamples.
Along with this the niRFSA_Initialize should initialize the session with the device so this should be started before configuring the session. From here you should call niRFSA Initiate.
04-08-2011 03:56 PM
Actually my call to niRFSA_Initialize is a typo -- should have been niRFSA_Initiate. I am calling niRFSA_Initialize
before all the configuration calls.
Sounds like I don't need the call to niRFSA_commit.
Could I also use niRFSA_GetFetchBacklog to see if sufficient data is available? This is probably no more/less efficient than niRFSA_CheckAcquisitionStatus.
Thanks for your quick response. I should be able to try this with hardware next week.
Gary
04-11-2011 04:47 PM
Hello Gary,
I thought the Initialize was a typo but I wanted to confirm. As the niRFSA_Commit and the niRFSA_GetFetchBacklog, I explain there purpose below:
1.) niRFSA_Commit: The purpose of this VI is to commit the settings you have created to the hardware which will check to make sure the hardware can do it. If there is any problems with this, it will report back errors. I find this function to be particularly helpful when trying to verify if the settings I have chosen will cause any unforeseen problems. Ultimately, this function is optional because the niRFSA_Initiate will perform this step behind the scenes.
2.) niRFSA_GetFetchBacklog: This VI will provide you the number that haven't been acquired yet. This will give you alot more information that the niRFSA_CheckAcquistionStatus in the sense that you can monitor how many more points have been acquired. This can be used in the polling senario where you wait to read until X number of samples are in the buffer. This will really though depend upon your application.
04-20-2011 01:42 PM
Hi Jim,
I'm finally getting back to working on this code. I don't have hardware yet so I've been trying to get things initially working using simulate mode. I'm calling niRFSA_InitWithOptions with resource=="" and options=="Simulate=1,DriverSetup=Model:5665;BoardType:PXIe". The function returns 0x3ffa4003.
I attempted to create a simulated device using MAX but the 5665 wasn't available as a choice in the RFSA dialog box.
What am I doing wrong?
Thanks,
Gary
04-20-2011 04:34 PM
The error returned by niRFSA_GetError is
The LO returned the following warning:
04-20-2011 05:07 PM
Hmmm, must be no such thing as a 5665. When I change to 5663 I get through the init' function.
Moving on.....