I’ve managed to store a sample set on the FPGA and transmit it
periodically. The problem I’m experiencing is that the transmitted pulse
is shorter than what I expected.
I worked out that by setting an interp value of 500 from python, that
the FPGA interpolator would basically be set to 125 to go with the
AD9860s x4. This would mean that to obtain a total rate of 32
Msamples/sec to the DAC, the data rate of the I and Q channels would
have to be 16 Msamples/sec each, and thus 128 000 samples/sec each into
the txchain modules. This should mean that if I provide a samples set of
128 I samples, and 128 Q samples, I should get 1 msec worth of complex
output signal.
Is this correct? I’m not sure if I overlooked something. The result I
get when monitoring the output is about 750 microseconds instead of
1 msec. Is there perhaps something I didn’t take into account in the
calculations? If anyone can assist it would be greatly appreciated.
Regards
Lance
seph 004 wrote:
This would mean that to obtain a total rate of 32 Msamples/sec to the
DAC, the data rate of the I and Q channels would have to be 16
Msamples/sec each, and thus 128 000 samples/sec each into the txchain
modules. This should mean that if I provide a samples set of 128 I
samples, and 128 Q samples, I should get 1 msec worth of complex
output signal.
The bus carrying IQ data to the 9862 TX runs at 64 MHz, so it is 32 MS/s
for each.
Matt
Matt E. [email protected] wrote: seph 004 wrote:
This would mean that to obtain a total rate of 32 Msamples/sec to the
DAC, the data rate of the I and Q channels would have to be 16
Msamples/sec each, and thus 128 000 samples/sec each into the txchain
modules. This should mean that if I provide a samples set of 128 I
samples, and 128 Q samples, I should get 1 msec worth of complex
output signal.
The bus carrying IQ data to the 9862 TX runs at 64 MHz, so it is 32 MS/s
for each.
Matt
Thanks for the reply.
I see what you are saying about the bus. It means that the pulse is
longer instead of shorter, which makes more sense. Going with this
though, I have done tests with the new numbers and I still get a longer
pulse than expected. I thought the problem might have been a delay from
the cic shifter or the DAC, but even those should only have added a few
microseconds, not over 100 microseconds.
From the logic analyser , it seems that the counter I use for
advancing the read pointer for the RAM might be running slow, though
the Quartus simulator shows it running at the right speed. Would such a
problem stem from using an interp rate like 125 within the FPGA? Has
anyone who has done USRP FPGA builds that use counters noticed a
similar variance?
Regards
Lance