On 09/09/2017 12:16 AM, Steven Knudsen wrote:
I am not sure that is an option. The TDMA scheme is such that the
TX/RX to inactive time duty cycle is low. During the “inactive” time,
other things are going on.
I suppose maybe I could just turn the RX gain to zero (and will be anyway)
But what you are really suggesting is more polling vs “interrupt”
driven programming. Polling is generally not a way I like to go,
especially when a) I can avoid it and b) I may be asked to host this
on lesser hardware…
Put another way, if polling was okay, why have the ability to schedule
receives?
Oh, I agree that it's a useful feature. I'm just not certain of the
hardware's ability to maintain sub-ms-scale scheduling abilities on the
B210.
Thanks for all the discussion and help!
steven
Steven Knudsen, Ph.D., P.Eng.
www.techconficio.ca <http://techconficio.ca>
www.linkedin.com/in/knudstevenknudsen
<http://www.linkedin.com/in/knudstevenknudsen>
/Von einem gewissen Punkt an gibt es keine Rückkehr mehr. Dieser Punkt
ist zu erreichen. - Franz Kafka/
On Sep 8, 2017, at 22:01, Marcus D. Leech <mle...@ripnet.com
<mailto:mle...@ripnet.com>> wrote:
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
