Requested timestamp is in the past. meta.curr_timestamp doesn't reset

[iperper]

I'm not sure if this expected functionality or not, as I'm still learning bladeRF, but essentially the issue is as follows.

I have a function that roughly does:

1. sync_config
2. enable both rx and tx
3. sync tx
4. sync rx
5. disable tx (disabling/not disabling rx doesn't impact the outcome of these tests)

If I run:

Open Device
Function() // first call
Function() // second call --> Requested timestamp is in the past

Any calls after the first will result in Requested timestamp is in the past error when sending tx samples (step 3). Looking at the origin of the error, it comes from timestamp_in_past() in sync.c. It compares user_meta->timestamp to s->meta.curr_timestamp, which is essentially comparing the requested send time in the tx metadata to the bladerf_sync struct's meta.curr_timestamp count of time.

The reason the error appears, is the second time tx is enabled, the times that get_timestamp outputs are reset to 0, while the s->meta.curr_timestamp doesn't appear to change ever (only goes up).

Example output

// After TX / RX enabled 1st time
// dev->board_data->sync[BLADERF_TX]->meta.curr_timestamp : 0
// dev->board_data->sync[BLADERF_RX]->meta.curr_timestamp : 0
// bladerf_get_timestamp()  : 2617

// After sync TX / RX commands 1st time
// dev->board_data->sync[BLADERF_TX]->meta.curr_timestamp : 104801
// dev->board_data->sync[BLADERF_RX]->meta.curr_timestamp : 110269
// bladerf_get_timestamp()  : 111018

// After TX / RX enabled 2nd time
// dev->board_data->sync[BLADERF_TX]->meta.curr_timestamp : 104801 <-- No change
// dev->board_data->sync[BLADERF_RX]->meta.curr_timestamp : 110269 <-- No change
// bladerf_get_timestamp()  : 2785   <-- Got reset to 0

// After sync TX / RX coomands 2nd time
// dev->board_data->sync[BLADERF_TX]->meta.curr_timestamp : 104801 <-- No change because bladerf_sync_tx had timestamp in past error
// dev->board_data->sync[BLADERF_RX]->meta.curr_timestamp : 110437 <-- New value because sync rx is fine
// bladerf_get_timestamp()  : 111013

The questions are: (1) Should s->meta.curr_timestamp reset at the same time the FPGA counter that get_timestamp reads does? (2) If not, should it be possible to enable and disable the TX frontend within the same script without this behavior occuring?

Thanks!

[rghilduta]

Currently, the timestamp registers should reset whenever any of the channels (RX or TX) are enabled or disabled, so #1 is expected behavior.
To avoid seeing "Requested timestamp is in the past" type messages, try to get the timestamp value for the channel of interest, and add enough of a delta for things to arrive to the FPGA in time.

[f4gkr]

Sorry to reopen this one, but the proposed approach to fix this does not work in my case or I am missing one point here.

I am having exactly the following behaviour :
`
function process()

configure tx center freq and tx sample rate ; // (same sample rate for tx & rx)
sync config for tx ;
enable module for tx;
configure rx center freq and rx sample rate ;
sync config for rx ;
enable module for rx;

fetch tx module time stamp ;
add 5 millisecond
schedule a tx transmission for "x samples"

fetch rx module time stamp ;
add 5 milliseconds
schedule rx reception for "y samples"

`

first call is alway ok. I have the correct synchronization between the tx & rx.
second call to "schedule a tx transmission for" always ends with Requested timestamp is in the past

Here the sampling rate is very low (4M), and blocks are short (14*10240)
I tried to add 100 millisecs instead of the 5 used above, no success.

Robert, in your comment just above you mentioned that calls to enable/disable module does a reset in the timestamp. but I do here as recommended : fetch value for the right channel before.

Any idea ?
Thanks

[f4gkr]

Just an additional info if helps : replacing the scheduled RX by a BLADERF_META_FLAG_RX_NOW in meta flag does not solve the issue, still getting a timestamp in the past error