Trigger and GPIO: Update

[reesebo]

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

[reesebo]

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

[reesebo]

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

[reesebo]

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