On 09/08/2017 11:53 PM, Steven Knudsen wrote:
Okay, I can accept that.
What it means is that since my customer has not settled on a USRP
platform, I should put some checks in that enforce timing constraints.
Stuff like looking at the number of samples for the max expected
packet length times the sample rate and comparing to a max allowable
packet time. Of course, I have some such checks already, but I guess
not enough… Too bad…
thanks,
steven
I'll point out that one could simply just receive all the time, and only
pay attention to the RX samples that are within the RX timeslots....
Steven Knudsen, Ph.D., P.Eng.
www.techconficio.ca <http://techconficio.ca>
www.linkedin.com/in/knudstevenknudsen
<http://www.linkedin.com/in/knudstevenknudsen>
/Der entscheidende Augenblick der menschlichen Entwicklung
ist immerwährend. Darum sind die revolutionären geistigen Bewegungen,
welche alles Frühere für nichtig erklären, im Recht, denn es ist
noch nichts geschehen. - Franz Kafka/
On Sep 8, 2017, at 21:47, Marcus D. Leech <mle...@ripnet.com
<mailto:mle...@ripnet.com>> wrote:
On 09/08/2017 11:38 PM, Steven Knudsen wrote:
Let me see if I understand you correctly. Are you saying that
turning on the first reception takes significant time?
In my case, the receive loop is running before the scheduling
starts; it just times out and spins around again. So I am not sure
that the receive startup is the problem.
But if it was, then could I simply not do a “dummy” receive and then
start scheduling?
I can live with the 350 us pre-receive dead time.
However, without digging into the FPGA code, I would have thought
that a command queue would be periodically checked to see if the
next command time has arrived and then the waiting command would
execute right away. But, if there was a set number of events that
needed to execute for a reception, that might explain things. E.g.,
if things were disabled after NUM_SAMPS_AND_DONE and needed to be
re-enabled the next time receive is invoked, that could and would
take time.
At this point I am just speculating…
steven
PS You work long hours!
In general, starting the receive process takes a finite amount of
time, because various bits of hardware need to be turned (back) on.
Tuning is the most
notoriously slow part in the B2xx series--the chip wasn't designed
for frequency-hopping, for example. But other bits and pieces need
to be initialized.
I'm just not sure how many such bits and pieces and what the
latency is.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
