Fractional seconds in timestamp

[windytan]

It would be useful to have fractional seconds in the rx_time timestamp. Currently this is not directly possible, as C strftime doesn't support that.

• What should the precision be? Hard-coded or adjustable? (Perhaps hard-coded 1/100 s is fine)
• Should the fraction be its own format character, like %f? This would require some custom string formatting code.
• Or should there be just a new command-line option to concatenate a fraction to the end of the timestamp? Or to format the whole timestamp in a hard-coded format familiar from RDS Spy?
• Ideally, buffer delays should be taken into account and subtracted from the timestamp, because these can be 64 milliseconds at worst. We could use an end-of-buffer timestamp in the MPXBuffer objects and the read offset into that buffer upon complete reception of a group. (Of course we can't know anything about buffer delays external to redsea.)
• An unexpected consequence: When MPX is being read from a source that is faster than its sample rate (e.g. a local file), this calculation will produce incorrect results. The timestamp can even end up referring to a time just before the program was started, and the timestamps won't be in monotonic order. Maybe a fast source could be automatically detected?
• The timestamp should also be properly determined for hex or ASCII inputs. But that's more straightforward I think.
• According to RDS specifications, the transmitted seconds-precision timestamp in group 4A refers to the end of the group, +/- 100 ms. So the rx_time should ideally also refer to the end of the group.

For reference, here's one way to calculate the fractional time itself: https://stackoverflow.com/questions/15845505/how-to-get-higher-precision-fractions-of-a-second-in-a-printout-of-current-tim

[windytan]

Initial results with the buffer timestamping are looking very nice (by specification, these 4A groups should be exactly on the minute +/- 0.10 sec):

$ airspy ... | csdr ... | redsea ... | grep clock_time

{"pi":"0x6203","rx_time":"18:57:59.99","group":"4A","clock_time":"2020-05-18T18:58:00+03:00","prog_type":"Varied","tp":true}
{"pi":"0x6203","rx_time":"18:58:59.99","group":"4A","clock_time":"2020-05-18T18:59:00+03:00","prog_type":"Varied","tp":true}
{"pi":"0x6203","rx_time":"18:59:59.99","group":"4A","clock_time":"2020-05-18T19:00:00+03:00","prog_type":"Varied","tp":true}
{"pi":"0x6203","rx_time":"19:00:59.96","group":"4A","clock_time":"2020-05-18T19:01:00+03:00","prog_type":"News","tp":true}
{"pi":"0x6203","rx_time":"19:01:59.96","group":"4A","clock_time":"2020-05-18T19:02:00+03:00","prog_type":"News","tp":true}
{"pi":"0x6203","rx_time":"19:02:59.96","group":"4A","clock_time":"2020-05-18T19:03:00+03:00","prog_type":"Varied","tp":true}
{"pi":"0x6203","rx_time":"19:04:00.03","group":"4A","clock_time":"2020-05-18T19:04:00+03:00","prog_type":"Varied","tp":true}
{"pi":"0x6203","rx_time":"19:05:00.03","group":"4A","clock_time":"2020-05-18T19:05:00+03:00","prog_type":"Varied","tp":true}
{"pi":"0x6203","rx_time":"19:06:00.02","group":"4A","clock_time":"2020-05-18T19:06:00+03:00","prog_type":"Varied","tp":true}
{"pi":"0x6203","rx_time":"19:07:00.00","group":"4A","clock_time":"2020-05-18T19:07:00+03:00","prog_type":"Varied","tp":true}
{"pi":"0x6203","rx_time":"19:08:00.00","group":"4A","clock_time":"2020-05-18T19:08:00+03:00","prog_type":"Varied","tp":true}

[sm3ulc]

Very nice! Useful to measure delays in upstream transport chain, apart for verification of the clock accuracy. Audemat has had some very interesting clock sync with +- 2-3 secs.. // David

…

On Mon, May 18, 2020 at 6:10 PM Oona Räisänen ***@***.***> wrote: Initial results with the buffer timestamping are looking very nice: $ airspy ... | csdr ... | redsea ... | grep clock_time {"pi":"0x6203","rx_time":"18:57:59.99","group":"4A","clock_time":"2020-05-18T18:58:00+03:00","prog_type":"Varied","tp":true} {"pi":"0x6203","rx_time":"18:58:59.99","group":"4A","clock_time":"2020-05-18T18:59:00+03:00","prog_type":"Varied","tp":true} {"pi":"0x6203","rx_time":"18:59:59.99","group":"4A","clock_time":"2020-05-18T19:00:00+03:00","prog_type":"Varied","tp":true} {"pi":"0x6203","rx_time":"19:00:59.96","group":"4A","clock_time":"2020-05-18T19:01:00+03:00","prog_type":"News","tp":true} {"pi":"0x6203","rx_time":"19:01:59.96","group":"4A","clock_time":"2020-05-18T19:02:00+03:00","prog_type":"News","tp":true} {"pi":"0x6203","rx_time":"19:02:59.96","group":"4A","clock_time":"2020-05-18T19:03:00+03:00","prog_type":"Varied","tp":true} {"pi":"0x6203","rx_time":"19:04:00.03","group":"4A","clock_time":"2020-05-18T19:04:00+03:00","prog_type":"Varied","tp":true} {"pi":"0x6203","rx_time":"19:05:00.03","group":"4A","clock_time":"2020-05-18T19:05:00+03:00","prog_type":"Varied","tp":true} {"pi":"0x6203","rx_time":"19:06:00.02","group":"4A","clock_time":"2020-05-18T19:06:00+03:00","prog_type":"Varied","tp":true} {"pi":"0x6203","rx_time":"19:07:00.00","group":"4A","clock_time":"2020-05-18T19:07:00+03:00","prog_type":"Varied","tp":true} {"pi":"0x6203","rx_time":"19:08:00.00","group":"4A","clock_time":"2020-05-18T19:08:00+03:00","prog_type":"Varied","tp":true} — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#70 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AELU6KIWAHPKAYR62GQ5MDTRSFMXXANCNFSM4ND3YWOA> .