Metadata

[jynik]

Hi Jaco,

I believe it should be possible to have the RX and TX counters synchronized +/- 1 clock cycle.

There is a single timestamp enable bit from the FX3 -> FPGA that is turned on with the first bladerf_sync_config() call that enables timestamps. This implies that you'll want to have the sample rates already setup up before your bladerf_sync_config() calls (for either module), otherwise your counter would have drifted since it was operating at a different rate for some amount of time.

It sounds like you're working on some sort of TDD application? If your uplink and downlink are on the same frequency, I would advise you to ensure the RX and TX frequencies on the bladeRF are tuned at least 1 MHz apart, and digitally mix to the target frequency. I say this because we've found that if the PLLs in the LMS6002D are tuned within 1 MHz of one another, they may begin interfering with one another.

Fortunately, with 28 MHz of RF bandwidth, there's plenty of room to simply mix either RX or TX.

Best regards,
Jon

[Jaco]

Hi Jon, thanks for your reply.

I believe it should be possible to have the RX and TX counters synchronized +/- 1 clock cycle.

If I remember correctly, the FPGA clock runs at 100 MHz, is that correct?

There is a single timestamp enable bit from the FX3 -> FPGA that is turned on with the first bladerf_sync_config() call that enables timestamps. This implies that you'll want to have the sample rates already setup up before your bladerf_sync_config() calls (for either module), otherwise your counter would have drifted since it was operating at a different rate for some amount of time.

So, a call to bladerf_sync_config() will start the free-running counter from which the timestamps are derived? Does this mean that the TX and RX counters are inherently offset by the time it takes for the bladerf_sync_config() to complete for each module?

It sounds like you're working on some sort of TDD application? If your uplink and downlink are on the same frequency, I would advise you to ensure the RX and TX frequencies on the bladeRF are tuned at least 1 MHz apart, and digitally mix to the target frequency. I say this because we've found that if the PLLs in the LMS6002D are tuned within 1 MHz of one another, they may begin interfering with one another.

I'm developing a simple DRFM, but to do so I need a test radar. I have developed one before, but this was before metadata was introduced into libbladeRF, so there were some issues with TX/RX synchronization. What exactly do you mean by the PLLs interfering with one another?

[jynik]

Hi Jaco,

Hopefully my below comments clarify things for you.

Best regards,
Jon

If I remember correctly, the FPGA clock runs at 100 MHz, is that correct?

The clock cycle here is the time stamp clock running at the configured sample rate, not a master FPGA clock.

So, a call to bladerf_sync_config() will start the free-running counter from which the timestamps are derived?

Yes. As of FPGA v0.3.x there are separate free-running counters for RX and TX. However, they are both enabled via the same bit for reverse compatibility and for the reason below.

Does this mean that the TX and RX counters are inherently offset by the time it takes for the bladerf_sync_config() to complete for each module?

No, because the first bladerf_sync_call() will set the "timestamp enable" bit. Both counters will begin running and should be synchronized within +-1 clock of one another. This offset is fixed and will not change while they are running. It is simply the result of when the enable signal is seen by the time tamers, due to the crossing of clock domains.

Again, it's important to have the samplerates configured prior to calling bladerf_sync_config(). Failing to do so will cause a timestamp slip.

[Jaco]

Hi Jon,

Thanks, your comments are indeed extremely useful.

So essentially, I don't have to worry about individually configuring module timestamps since they're synchronized within +/- 1 clock cycle through the way they're defined. That also means that it doesn't matter whether I wait for a particular timestamp between RX or TX, since they both are synchronized, making it much simpler to schedule TX and RX bursts based on predetermined time intervals.

I'll update this thread if I come across anything interesting.

Sincerely,
Jaco

[jynik]

Hi Jaco,

It sounds to me like we're on the same page! If you find anything to not be operating as I've noted, let me know and I'll look into it.

One "fine print" detail to be aware of is sample-time ticks between something being scheduled to transmit from the FPGA's FIFO and the sample-time tick at which it actually leaves the LMS6 front end.

This may be totally negligible for your application, but I just wanted to make note of if in case you attempt to do some very tight timing. If so, you could try to experiment with quantifying this by putting the device into one of the RF loopback modes and sending some pulses.

Best of luck! If you're able to share info about your successes on this, I'd love to hear what interesting work you're doing (and I'm sure the community would too)!

Cheers,
Jon