Ok then, thanks for the clarification!
I'll wait for the answer from product support.
Our product support engineer is requesting the simplest example we can give him in C/C++ He recomended starting with the RFSA Getting Started IQ project and adding in the niRFSA_ClearError function with the VI_NULL paramter. Would it be possible for you to create this so I can forward it to the product support engineer?
thanks again for your answer.
I won't be able to provide such example in the neat future, because I can't afford to spend enough time for it.
I thought you could easely reproduce the problem with the RFSA Soft-Panel:
I think you only need a minor modification of the source code (in IQ Acquisition mode, you must not do a Initiate/Abort at each loop).
I hope you (or the product support engineer) have access to the source code of the RFSA Soft-Panel.
The Soft Front Panel was written in LabVIEW and when in IQ mode stops the session after each read then starts a new session. I have reproduced this in LabVIEW and confirmed what you are seeing but the product support engineer is requesting a C or C++ example.
I've talked with Anthony about this issue and we spent sometime today developing code to reproduce this error in CVI (NI C development environment). We modified two examples and we are able to reproduce the behavior you were seeing. To confirm that we are seeing the same problem, I have listed out the following steps and the response from our application.
1.) Set the reference level to -70dBm.
2.) Generated a signal at -43dBm.
3.) Received Warning 1073364993 where the input was overflowing the digitizer.
4.) Lower the generated signal power to -95dBm.
5.) Continued to receive the same warning over and over again until it is aborted.
If this doesn't match the steps you have taken, we would definitely want to know this in order to get to the bottom of this issue. So far, I believe this is a bug with the RFSA driver but I'm going to discuss with some developers to confirm. Hopefully we can come up with a work around for you other than aborting the session. When I find out more information, I'll post back.
This seems slight different from your steps to reproduce because you receive the same warning (1073364993). Is this correct?
This is the same behavior that I have seen. I'm very confident that if you fix this problem, or if you find a work-around, it will fix my application (I will be able to report the warning correctly, without having to stop the digitizing).
I'll wait for your answer.
After researching into this issue, the niRFSA_ClearError will not be able to clear this warning. The reason for this is how the warning is generated.
When you perform a multi-record acquisition, the digitizer acquires and applies the digital gain and OSP necessary to generate the IQ pairs. During this process, the FPGA looks to see if the incoming signal rails the ADC. If it does, the FPGA through a "sticky bit" to tell the host that the data has railed the ADC. Due to the design, we can not change this flag unless the session has been aborted because the digitizer can't tell the host which bit or set of bits of the multi-record acquistion caused the ADC to overflow. Knowing this, the flag is used to inform the host that some or all the data might be corrupted due to the fact that the ADC has been overran.
The best solution at this point is to abort the session and restart the acquistion. From looking over the other posts, you are already implementing this design into your code. I'm sorry if this causes problems with your design. I hope the information helps you understand the digitizer functionality.
Thanks for the anwser. I now understand why we see this behavior... I suppose this will not be changed in the future, right? I understand it would require changes to the FPGA code.
On our side, we will implement our own algorithm to determine if the the input power is too high for the current Ref Level (this will warn the user to either lower the Amplifier gain, or to increase the Ref Level).
The algorithm will be based on a statistical observation of the incoming IQ data. That's the best we can do without stopping the digitizing.
You are correct that it would take driver/FPGA code changes. From the sounds of it, your ideas of preventing this sound like the best option.
The best solution at this point is to abort the session and restart the acquistion.
Jim - do you mean abort the acquisition using "niRFSA Abort", and then restart using "niRFSA Initiate"? Or, do you mean completely close the session "niRFSA Close" and then initialize again?
I'm wondering how this is done in the soft front panel. niRFSA Abort/niRFSA Initiate does not clear the warning for me.