Hello Martin, Somehow I missed your reply.
In the meantime I’ve started from implementing what you described in the first point. If anyone is interested - it appeared that ‘keep_one_in_n‘ was a very good starting point. I left the last state\ machine that is responsible for forming output packets intact and I thrown away the state machines that\ are responsible for setting ‘keep_sample‘ signal and written my own. That state machine sets ‘keep_sample’ signal\ during some defined interval after sweep starts. This way it can work as long as pulse repetition interval isn’t changed\ or there is no loss of synchronization between Tx and Rx RFNoC blocks (I’m still trying to find out if such sync\ loss is possible i.e. when there is overflow). It is also possible to reuse ‘keep_one_in_n‘ testbench to develop my block. For this I thrown away most of the\ stuff that is responsible for automatic test stuff and just fed the block incremented integer in the ‘test_…’ task.\ Testing is just checking if the right numbers are appearing at the output.\ \ In case synchronization loss is possible I have at least two options:\ \- couple timestamps with the state machine that generates ‘keep_sample‘ signal,\ \- try to connect trigger from the replay blocks. As I can see in the specification RFNoC has some support for\ connecting miscellaneous signals to RFNoC blocks in YAML. Probably the best control in case of changes of pulse parameters could be obtained if the blocks passing\ the samples and generating pulses for TX side would be combined into one block. Best Regards,\ Piotr Krysik
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
