thor.py timing wrong for a while after a dropped packet

[jvierine]

I noticed recently that when using thor.py and receiving dropped packets, the timing can be wrong for several tens of seconds. This causes the virtual range in chirpsounder2 recordings to be wrong for a large part of the ionogram. I have no idea what the problem could be, but I suspect propagation of time tags in gnuradio is somehow delayed.

I wrote a simple C++ program that directly used the UHD driver. I read the time stamps from each packet and pad zeros into the stream accordingly. I didn't encounter this issue then. Unfortunately my simple program doesn't have all of the functionality that thor.py has, but it does work as a temporary fix.