FGEN error -1074115896

[TimS.]

Can anyone please explain the error listed below? I'm using the PXI-5761 and the NI streaming API to stream float 32 IQ files. I've added code to the API to modulate the data while streaming. My options are no modulation, AM, or FM. I can stream the files perfectly with the selections of no modulation, FM, and AM-DSB. However, whenever I select AM USB or LSB I receive the error below. I've checked all of my array sizes when writing to the hardware and they are the same for all of my modulation selections. I've even tried setting the write location of my waveform handle manually to the start but I still receive this error.


"Error -1074115896 occurred at niFgen Write Waveform (Complex DBL).vi:

Possible reason(s):
Driver Status:  (Hex 0xBFFA4AC8) DAQmx Error -200311 occurred:
Measurements: You cannot write data outside the boundaries of your waveform.

Make sure you are not trying to write more data than your waveform can accomodate and that your write location and write offset are set correctly.

Status Code: -200311"

Thanks,

Tim S.

[Chris_D]

Hey Tim,

One thing to note is that the size of the waveform buffer divided by the number of samples you are attempting to write must be an integer. That is to say, that you must be able to write an integer number of bytes to the buffer without going over. If you selected an arbitrary number of samples and attempt to write to the buffer, you would eventually have to write outside your waveform (the error you are seeing). Say you wanted to write 7 byte samples into a 20 byte buffer. The third write would exceed the buffer size.

Let me know if this helps!

[TimS.]

Hi Chris,

I'll try to keep that in mind as it wasn't something I was really checking for in my code. However, just to experiment, I played a couple of files to get exact numbers on block sizes and such. It's not really possible for me to post code that would make any sense but I'm still basically following the ni.com/streaming API. I've just added AM and FM modulation to the incoming data from files. Anyways, here are some numbers for you that might make more sense of things.

My block size for writing samples to the Arb is initially 16384 samples. I needed to add upsampling for very low IQ rate files so I have an upsample factor that varies based on the sample rate of the file. For my test file the upsample factor was 5. So I am always writing to the arb with (16384)*(5)=81920 samples/block.  I set the number of blocks to be 5 so that the buffer size when I use the niFGEN Allocate Waveform VI I set the buffer size to (81920)*(5)=409600 samples. I'm writing to the arb using Complex Double data type for a total of 16 bytes in each IQ pair. So, after doing a manual math check It seems like I am writing to the arb as you've detailed. The only time I would expect to see that error is at the end of a file when the number of samples remaining does not equal the block size that I set. But I'm seeing the error long before the end of the file and only when I use AM-SSB. Playing the file out with no modulation, FM, and AM-DSB all work fine. What baffles me the most is that I'm always writing 81920 IQ samples to the arb regardless of modulation type.

(Just for more background information)...Using the same file I prime the arb with 409600 samples before I even start generating RF. Then, after initiated, the code checks to make sure that there is greater than 81920 samples of space available in memory before writing another block.

Let me know if you have any other thoughts,

Thank You,

Tim Sileo

[Chris_D]

Hey Tim,

I did some tests with the modulation VI's and it looks like FM, AM-DSB, and of course no modulation will produce a modulated waveform with the same number of samples as the message signal. However, when you use AM-SSB it produces a waveform with less samples than the message signal. For example, with a message signal of 1000 samples, the modulated waveform always had 1000 samples with FM and AM-DSB, but only had 918 samples with AM-SSB. Since the number of samples it less, it seems like you have allocated correctly, but you may want to look into this to make sure.

[TimS.]

I'm glad that you brought that up. I thought that I fixed this a while ago by setting the "reset?" boolean to false on the AM-SSB block. After I read your post I played back another file and this time I kept track of the array size for every block read/write of the file. Sure enough, any time I switched from another modulation type to AM-SSB it would fail. Just for some numbers from my test, the buffer size was 163840 samples with a block write of 32768 samples. This gives 163840/32768=5 which holds true to what you mentioned previously. However, when I switched to AM-SSB the size of samples became 32640 and 163840/32640=5.0196 which is definitely causing the error that I'm seeing.

After popping open the AM-SSB block I noticed that the "reset?" boolean is OR'ed with a "first call" and it appears that this is the root of my problem. I set the "reset?" to false because I'm streaming and I don't want to reset the Hilbert filter everytime that I modulate a block of samples. Since it makes sense to reset the Hilbert filters on the very first call to the AM-SSB function I suppose that my only option is to insert samples, up to the appropriate block size, into the first block of samples that I write to the Arb.

Thanks for giving me a nudge in the right direction. I'll post back when I've added some code that makes it work fully.

Regards,

Timothy Sileo
Systems Engineer
Argon ST, Inc.

[TimS.]

I've added code that subtracts the incoming IQ data array size from (block size)*(upsample factor), which is the data transfer block size to the arb. The difference between these two is how many zeros I pad the data with before writing it to the Arb. In the grand scale of millions of samples, this difference is usually around 100 samples so adding zero's has no noticeable effects on my IQ data. Generally, zero's are only ever added upon the first block of samples when AM-SSB is selected and are not added in any other modulation selection.

The 32640 samples that I was seeing before in my example is now zero padded up to 32768 samples which is an integer multiple of the buffer size. Since I've added the code I have not seen this error since.

Again, thanks for the help.

-Tim Sileo

[Chris_D]

Hey Tim,

I'm glad to hear it works and thanks for posting back the solution!