Re: [Discuss-gnuradio] half duplex set_auto_tx timing problems

[Miklos Maroti]

Hi Marcus,

On Mon, Jun 3, 2013 at 9:20 PM, Marcus Leech <address@hidden> wrote:
> The 1PPS is used only to latch-in a time-of-day update from the host--it is
> used when doing time synchronization across multiple devices, and in fact is
> critical for that function to work correctly.
>
> The problem with set_time_now() is that you can't precisely model the delay
> through the TCP/IP stack on the host, across the ethernet, etc.
>
> With set_time_next_pps(), you typically get your local time on the host
> (possibly as managed by NTP) and then do a set_time_next_pps(host_time+1).

I understand, but then the precision of your PC clock will be the
limiting factor and still you are going to get cycle slips because if
your FPGA is sometime going to accumulate more a 1 cycle drift, and
the next set_time_next_pps will introduce a cycle shift. If you count
everything in FPGA cycles on the host, then this is not a problem (and
of course you have to keep separate timelines for each FPGA if you
have more than one connected to your host).

Miklos

> You do this once
>   at the start of your session.  On USRPs equipped with an in-skin GPSDO,
> you can query the GPSDO time, and synchronize to GPSDO time.
>
>
>
>
> on Jun 03, 2013, Miklos Maroti <address@hidden> wrote:
>
> Hi Marcus,
>
> On Mon, Jun 3, 2013 at 8:15 PM, Marcus D. Leech <address@hidden> wrote:
>>> You say that it switch from TX to RX if the next timestamp is in the
>>> future and switch from RX to TX just when the timestamp is triggered.
>>>
>>>>> You see "L" because you are sending your bursts far enough advance. In
>>>>> my
>>>>> applications, the bursts are sent to the USRP about ~5ms before the
>>>>> actual
>>>>> transmission.
>>>
>>> Ok, I will try to send them 5ms before transmit time, that should
>>> work. But then synchronizing the FPGA clock with the PC clock will be
>>> more trouble.
>>>
>> You can use set_time_now() to set the FPGA clock to whatever you want.
>>
>> In fact, without such synchronization of ideas of time, it's pretty hard
>> to
>> build a TDMA-type system. The USRP and the host delivering time-stamped
>> samples have to agree on what time it is. If you have 1PPS pulses going
>> in, you can use set_time_next_pps() to align times on the next PPS pulse.
>
> Thanks for the idea of using set_time_now(). Setting the time to zero
> (at the start of the flowgraph) makes a lot of sense (by the way,
> USRP1 resets the time automatically when you start the flowgraph, but
> USRP2 does not). However, you cannot use the set_time_now
> periodically, because you will loose synchronization between host and
> fpga. I do not think 1PPS would help either if you want to achive
> cycle correct TX/RX switch. I want to let the FPGA to use its internal
> timer and count everything in FPGA cycles on the host and do an
> implicit time sync between the host and FPGA in order to send the next
> packet 5ms before it times comes on the FPGA.
>
> Best,
> Miklos