doppler start time

[kng]

Hi, thanks for the nice block (: I'm testing it out on a new flowgraph but having issues getting it to run properly. In simulation/replay it seems to work just fine, but when running live the compensation just doesn't seem to run. ie the time is outside the beginning and end of the files timestamp. In the terminal it says doppler_correction :info: set time 0 at sample 0

We have a variable tstart=float(datetime.datetime.utcnow().timestamp()) and also tested a more convoluted extraction of the date in one filename. tstart=datetime.datetime.strptime(file_path[file_path.rfind('_') + 1:file_path.rfind('.')], '%Y-%m-%dT%H-%M-%S').replace(tzinfo=datetime.timezone.utc).timestamp() where file_path="/tmp/.satnogs/data/receiving_satnogs_12345_2023-01-01T00-00-00.out"

The doppler.txt has timestamps in utc and looks fine. observation starting at 2023-04-25 12:58:3

1682427518.0 5863.316350698471
1682427519.0 5854.487347066402
1682427520.0 5845.625949203968

edit: Setting the calculation in the start time field directly doesn't seem to work. Tested with writing 0 as start time and beginning with 0 in the doppler file, this works.

[daniestevez]

Are you using this with a USRP perhaps? If so, the UHD Source block emits rx_time tags that the Doppler Correction block uses to set its internal time (this is what causes the set time 0 at sample 0 you see). You can either set the USRP to the correct time using one of the set_time_*() methods or block the USRP tags with a Tag Gate block.

[kng]

No USRP, It's running rtl-sdr via soapysdr-0.8, gnuradio-3.10 Is there a possibility that soapy sends this ?

[daniestevez]

It could. You can use a Tag Debug block to find out.

[kng]

yep, that's it. now, I wonder if these can be controlled in a usable fashion... device arguments ?

Tag Debug: soapy tags
Input Stream: 00
  Offset: 0  Source: n/a     Key: rx_time   Value: {0 0}
  Offset: 0  Source: n/a     Key: rx_rate   Value: 1.024e+06
  Offset: 0  Source: n/a     Key: rx_freq   Value: 4.37322e+08