Official bladeRF forum

Hi

I would like to trigger a transmit based on an external signal and would like some guidance as to where to do this. Should I be looking at NIOS and/or FPGA? I see there is DMA in the FX3, is there need to also look here?

Also, after the trigger is received, I would like to output a pattern on the GPIO pins. I would like to pass the pattern with the transmit data as a header word.


UPDATE:

My path without any input will be to use the NIOS to output the pattern on the xb gpio pins. I will model the code after retune. I will create a function that passes the timestamp and pattern to the nios; the timestamp will be used to schedule a burst. A nios isr will be fired using the time tamer/retune method and the pattern will be written to the gpio.

I will use 1PPS as my external signal and I will piggyback off of the vctcxo tamer code.

Thanks,

Reese

I would expect that you should not need to dive into the FX3 code. As you noted, HDL and some NIOS C code will probably need to get changed.

If you plan to hack on libbladeRF to add new functions, libbladeRF's host/libraries/libbladeRF/src/backend/usb/nios_access.c is where packets are sent to/received from the NIOS code. There's a top-level fpga_common/ directory that has the nios packet formats, and you can find more info about them here: https://github.com/Nuand/bladeRF/tree/m ... et-formats

Jon,

I started with the time tagging and have had some success. I modified time_tamer.vhd (attached) so that the top 32 bits of my time tag is the second and the bottom is the sample counter. I'm feeding in the 1pps to time_tamer from j71 and keeping a pps count which is appended to top of the timetag. When I use bladerf_sync_tx, I will read back the timetag (0xPPPP PPPP ssss ssss) and apply a second (P) at which I would like to trigger; this works fine. The only issue I have is that there seems to be an issue with the lms. After my burst completes, the carrier tone is still at the same power level as the signal. It seems that the output does not get the 0+0j at the end to set the DAC to minimum. If I send a subsequent burst of all zeros, the carrier power is reduced to the minimum. Do you know where I should look?

Thanks,

Reese

-----------

time_tamer_vhd is attached.
line 847 in bladerf-hosted.vhd is modified to route pps to time_tamer. e.g:
tx_tamer_ts_pps => ref_vctcxo_tune, -- RSB: using the ref 1pps taming the vctcxo, routes to time_tamer ts_pps

Hi there,

What you're describing is just the nature of the LMS6002D's DAC, as is what we've observed as well. If I remember correctly, we've found that three 0+0j samples are required to bring the DAC back to 0+0j at the end of the burst.

From the libbladeRF side of things, we just append these zero samples in our bursts. Perhaps you could do something similar?

Best regards,
Jon

Jon

I've tried appending 0's to the end of my message, but I'm not seeing any change. Could there be something in the LMS control that is reliant on a sample based timestamp rather than my custom version (perhaps in the FPGA)? I've looked at the verbose output of the bladerf lib particularly in the sync_tx function in sync.c, but when I compare the output with the custom timestamp vs that of the baseline, I don't see any differences that would show a clear problem. The RF output looks consistent between versions except for the post burst tone present using my custom version.

Thanks,

Reese

Hi Reese,

The LMS6 doesn't "know" anything about timestamps. These timestamps are basically just a means of determining when samples should be exiting the FPGA's FIFOs and being sent to the LMS6.

How many zeros are you flushing with? Just as an experiment, have you tried increasing this number?

Is there any chance that the samples aren't making it through the LMS6 RF path before you stop something in your code? For example, in some of the host side code, we poll the TX timestamp to give samples time to "flow" through the FX3, the FPGA, and out the LMS6 RFFE.

Hi Jon,

I gave up on the idea of using the upper half of the timestamp to count seconds. I instead decided to reset the timestamp counter on the first PPS past a ts_reset. It will allow me to account for time to PPS accuracy and does not exhibit the carrier issue. I'm not sure whether there might be something happening behind the scenes with the upper half of the clock, so if it grows beyond 32 bits we will see.

Thanks for your help.

Reese