Koen, Sorry, yes, you are correct, recent > On Jun 15, 2018, at 1:06 AM, TIMMEN Koen <koen.tim...@thalesaleniaspace.com> > wrote: > > Ian, > > Thank you for the clear explanation. > > Luckily for me, I will not have to deal with bursts as I simple transmit I/Q > samples that fit into a single sample. By the way, they are generated > internally to the FPGA on a custom module. > > What you said about the radio is useful, however it raises a new question: > you said that the Radio block streams to the DUC stages.. but, as I > understand it you will need a separate DUC block for that correct? And > normally you place that block before a Radio Tx block? So then the order of > blocks will be Source à DUC à Radio. Or am I way off now? > > And you said that when I want a packet to contain a time value in the CHDR, I > will have to enable this on the host? I assume it should also be able to let > a custom rfnoc block do this internally to the USRP. In that way, I can > generate a sample and give it a time stamp I want it to be transmitted on and > then offload to the radio, which will handle timely transmission. > > Thank you for your patience. > > > Kind regards, > > Koen > > > > De : Ian Buckley [mailto:i...@ionconcepts.com <mailto:i...@ionconcepts.com>] > Envoyé : mercredi 13 juin 2018 20:18 > À : TIMMEN Koen > Cc : Michael West; Neel Pandeya; usrp-users@lists.ettus.com > <mailto:usrp-users@lists.ettus.com> > Objet : Re: [USRP-users] vita time > > Koen > OK a few low level H/W and CHDR hints to help you along: > > “Time” when we talk about the H/W and how it’s implemented is a 64bit value > that counts in units of 1/master_clock_rate which for X310 is generally 5nS. > > The reference for time is a 64bit counter that’s driven from a block called > “timekeeper.v” and you will see this time value passed around X310 generally > called “vita_time”. > > This counter can be set/reset via UHD API calls such as > “set_time”now/set_time_next_pps/set_time_unknown_pps” > > CHDR packets can optionally contain a 64bit time value as part of the header, > and a bit in the header indicates if the time field is present. > > When this field is present it represents an absolute time value for the first > sample in the packet. > > In general you will see time present in most CHDR packets, for example the > radio tags all RX samples with the time. > > From a transmit perspective, there is a stateful concept of “bursts”, that is > the radio can either be idle or actively transmitting. After startup the TX > Radio is in an idle state, and host software will generally use API calls to > adjust the absolute “vita_time” to closely track host time-of-day or exactly > track GPS time if it is available. When a sample packet arrives at the radio > with a time field inside, the radio compares this time value with the current > “vita_time” and providing that the packets time value is still in the > “future” will start buffering arriving sample packet data in order until the > time field of that first packet matches the “vita_time” as it advances. At > this point the state of the radio becomes active, and it will start streaming > de-packetized data into the DUC stages and hence out into the analog > transmitter. To leave the active state, ceasing transmission, and return to > the idle state, a bit in a CHDR packet header signals end-of-burst (EOB) and > the last sample in this packet shall represent a transition of radio state > back to idle. > > From the user application perspective then you need to annotate a time value > into your initial CHDR packet to the radio that is still “in the future” and > has a time delta from the current vita_time such that allowance is made for > that packet to arrive at the radio in a timely fashion. From then on your > application will need to generate CHDR packets at a rate that matches or > exceeds the sample rate. When you are done transmitting the last packet you > generate will have the EOB bit set. A lot of this functionality is presumably > already provided in the noc_shell to abstract you from the details, someone > else who is RFNoC conversant will need to comment on that mechanism though. > > -Ian > > > > On Jun 12, 2018, at 11:56 PM, TIMMEN Koen <koen.tim...@thalesaleniaspace.com > <mailto:koen.tim...@thalesaleniaspace.com>> wrote: > > Hello again, > > Thank you for answering my question. I do still have a few questions though. > > What do the timestamps in each packet serve for exactly? Are you talking > about the CHDR packets here? I saw that in the CHDR format ‘fractional time’ > was optional, but did not understand how to activate this option. I assumed > it would be handled internally in the AXI wrapper and NoC shell. But as I > understand now, one has to write his own code that adds this part of the > payload? > > My original plan was based on what you suggest as well, to make the time > available in a register and upon reaching some future start time, my block > will transmit the corresponding sample. However, this does not answer the > question of where to find the value to store inside the register and update > it as time actually progresses. Is it as simple as coding a counter and > counting the number of passed clock cycles? > > Sorry if I seem to ask for the obvious, it’s all still relatively new to me. > > Kind regards, > > Koen > > > > De : Michael West [mailto:michael.w...@ettus.com > <mailto:michael.w...@ettus.com>] > Envoyé : lundi 11 juin 2018 23:59 > À : TIMMEN Koen > Cc : Neel Pandeya; Ian Buckley (i...@ionconcepts.com > <mailto:i...@ionconcepts.com>); usrp-users@lists.ettus.com > <mailto:usrp-users@lists.ettus.com> > Objet : Re: [USRP-users] vita time > > Hi Koen, > > The way to achieve what you want is to set the device time and then have your > signal generator put timestamps in each packet relative to that time. To > tell your custom block what time to use, you can have a user register that > you also program with the time (or some future start time). > > Regards, > Michael > > On Wed, Jun 6, 2018 at 11:24 PM, TIMMEN Koen via USRP-users > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: > Hello, > > My block is a signal generator and each sample needs to be transmitted at an > accurately known instant. The samples themselves do not need to hold this > information. > > The device I am using is the X310. > > What Neel Pandeya is suggesting sounds like exactly what I’m trying to do. > > Thank you for your responses. > > Regards, > > Koen Timmen > > > De : Neel Pandeya [mailto:neel.pand...@ettus.com > <mailto:to%3aneel.pand...@ettus.com>] > Envoyé : jeudi 7 juin 2018 06:14 > À : TIMMEN Koen > Cc : usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com> > Objet : Re: [USRP-users] vita time > > Hello Koen: > > As Ian requested, could you please provide additional detail on exactly what > you're trying to do? > > Are you merely trying to access the 64-bit FPGA VITA time from within the > RFNoC block? > > Which device are you using? > > --Neel Pandeya > > > > > On 5 June 2018 at 09:24, Ian Buckley via USRP-users > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: > Koen, > Can you expand a little on the functionality you need pls, its not fully > clear enough to me to make a suggestion. > Are you trying to extract time from incoming samples or apply time to samples > you are processing? > -Ian > > > On Jun 5, 2018, at 7:36 AM, TIMMEN Koen via USRP-users > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: > > Hello all, > > Currently I’m working on a RFNoC block that requires a known time reference, > but I have trouble making this value available. Ideally I would like to have > the value available in a register designated to the block. > > As I understand, a time reference is available through the CHDR, but.. not > all the time? It is optional I read in the manual. Is this a toggle that can > be set by the user? > > Or is there another way that I am able to obtain the device time reference > available in a user register? > > Kind regards, > > Koen > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
