TX packets arrive late on DAC_timestamping when running srsenb

[angrammenos97]

I am trying to implement the zynq_timestamping solution by porting the existing implementation into ZC702/ZC706 + FMCOMMS5.
Having as reference the Block design of the ZCU102 and AntSDR, I managed to port the the solution into my hardware.
So far, I managed to make it work with the txrx and pdsch_enodeb/ue examples.

Although, when I tried to run the srsenb, I realized that the SDR didn't transmit any samples. I added some ILA debug cores on the FPGA to see what going on, and I saw that the timestamp of the TX packets where late with respect of the current sample counter and thus the packets were discarded.

My setup is a Host PC (i9 CPU, 32GB RAM) that runs the SRSRAN applications that exchange samples with the ZC702/ZC706 through Gigabit Ethernet using LibIIO.

From this code line I understand that the time between each RX and TX must be 4ms. So the latency of my setup (ADC timestamp insertion -> receive RX packet on srsenb -> add 4ms on the timestamp and create TX packet -> DAC timestamp control) is greater than 4ms.

The example pdsch_enodeb doesn't use timestamping that is why there is no late situation. On the other hand, the txrx example also has this 4ms interval between RX - TX, but it seems that the packets doesn't arrive late on the DAC_timestamping.

I tried to set in performance mode both Host PC and Zynq's ARM but still no success of running srsenb. Also tried different memory sizes on DAC_timestamping as well as different n_prbs (6 and 15) and ringbuffer sizes of the IIO plugin.

Is there anything else that am I missing or my setup isn't enough to run srsRAN? I appreciate any help.

[ofontbach]

Hi @angrammenos97,

Although it is possible to run the srsenb using the zynq as a front-end, it requires quite a lot of fine-tuning and some performance issues can be expected (e.g., see). On the other hand, if you have the zcu702/706, I would recommend trying the (fully) embedded approach. That is, the srsenb application will connect to the FPGA via a dedicated bus which should provide much lower latency than when using an external host + ethernet/usb.

The 4ms you point to is just an example, but the value is indeed an LTE requirement (i.e., HARQ). In the pdsch_enb example, there is only DL communication and, hence, as you say, there is no HARQ implemented.

Your setup should be more than enough to run srsRAN, yet if you want to use the zynq simply as a front-end then you should expect some fine-tuning to be required (the solution was implemented for a fully embedded use case and later ported to other smaller zynqs). An alternative might be using a this alternative from Phil Greenland.

Regards