@mc955 Nice going! I’m pretty surprised you have to do that - it seems very odd that there’s something ok with having 75 packets delay with no data, but not longer… But maybe there’s something more subtle going on. With my setup, I send some packets, leave long delays with nothing, the send a few more packets, and things seem to work. Though maybe what you’ve found is related to the problems I started seeing with a later LimeSuite library. I’ll have to get back to that someday, though it will be a while.
For the question of odd numbered packets, I did find a solution to have odd numbered samples recorded. Then if I want transmit to start on an odd numbered packet, I just include a zero or three at the beginning of the TX packet, and set the packet to go 1 or 3 samples early.
The modification to the gateware I made is a little more invasive that what I posted earlier. Basically I’ve got a new register in the rx_path_top that keeps track of how many clock ticks have passed since the sample packet number was incremented. Then when the GPIO trigger is observed, you can tell if you’re on an even or odd numbered sample. I tried to make this so it would work generally, but there appear to be several different modes (SISO, MIMO, DDR etc) for which there are several flags. And honestly from the documentation in the code, I couldn’t quite resolve all of what all of those flags do.
You can see the changes to rx_path_top.vhd here:
http://www.phas.ubc.ca/~michal/Lime/rx_path_top.diff
and the complete file here
http://www.phas.ubc.ca/~michal/Lime/rx_path_top.vhd
There are some bits in there that you don’t need. Anything involving trigger_seen, last_bit3, trigger_time, trig_pulse_duration, trig_out_pulse, trig_sync, trig_sync_sync, and div_clk shouldn’t matter to you and can be removed. I’ll apologize for the faulty indentation in this code - Quartus seems to mess it up whether I use tabs or spaces…