You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: