Hi All,
I am building a TDMA system based on the B200mini. TX is out the TRX port and
RX is on RX2.
I schedule both TX and RX using stream commands. Tested separately, they work
great. However, when I have them running together (separate threads for send
and recv calls), the transmit waveform
Fortschritt schon geschehen
ist. Das wäre kein Glauben. - Franz Kafka
Post hoc ergo propter hoc.
> On Sep 6, 2017, at 18:37, Marcus D. Leech via USRP-users
> wrote:
>
> On 09/06/2017 08:15 PM, Steven Knudsen via USRP-users wrote:
>> Hi All,
>>
>> I am buil
t be something in the new program, but not
>> UHD-related.
>>
>> I’ll keep looking…
>>
>>
>> thanks,
>>
>> steven
>>
>>
>> Steven Knudsen, Ph.D., P.Eng.
>> www. techconficio.ca <http://techconficio.ca/>
>> www.
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
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
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
Hi again, Marcus (and all).
I have continued to try and sort out this problem and may be able to provide
some more insight, or at least failed approaches.
Another reader suggested that using STREAM_MODE_NUM_SAMPS_AND_MORE may help if
there is a setup or latency issue. So, I changed the receptio
Hi yet again…I thought to see what would happen if I modified txrx_loopback_to_file.cpp to output scheduled transmit bursts.I modified the transmit worker function to schedule bursts. Up to the settling time (i.e., when the recv starts grabbing samples), the output on the scope looks as expected —
No change using UHD 3.9.7 :-(
On September 16, 2017 at 07:19:05, Steven Knudsen (ee.k...@gmail.com) wrote:
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
So fest wie die Hand den Stein hält. Sie hält ihn aber fest, nur um ihn desto
weiter zu verwerfen
Hey Michael,
throwing in my 2 cents, I found the same last year and implemented separate
logic to monitor RSSI and set thresholds. In my case I was receiving in
consecutive slots from different radios, so the RSSI varied a lot.
You also have to be careful with any loop tracking algorithms for
FWIW, I found the dynamic threshold set in the corr-est to be far too low. I
made some experiments using my custom sync sequence (a variant of m-sequences
that gave me a couple of dB extra) and determined that except in degenerate
cases, the core peak would be 8 times the average signal for SNR
Hi,
I have been scratching my head for a while on this one…
I have made a TDMA radio that has a simple 4 slot cycle with a relatively low
duty cycle (slots are 40% and the remaining 60% of the cycle the USRP is idle).
A radio transmits in it’s “owned” slot and receives in all others (3 of them)
whilst the USRP tries to
continue to transmit.
Late, on the other hand, is signaled when a TX command contains a time that is
later than the USRP’s local clock when it is executed.
Hope this is helpful,
-Ian
On Feb 8, 2018, at 1:33 PM, Steven Knudsen via USRP-users
wrote:
Hi,
I have been
Hi Mathieu,
You can certainly use the UHD to get the signal of interest, but what you are
asking is really a question of signal processing and independent of the UHD and
any USRP you may be using.
I suggest you focus on the signal processing problem of separating two
closely-spaced signals and
tries to
continue to transmit.
Late, on the other hand, is signaled when a TX command contains a time that is
later than the USRP’s local clock when it is executed.
Hope this is helpful,
-Ian
On Feb 8, 2018, at 1:33 PM, Steven Knudsen via USRP-users
wrote:
Hi,
I have been scratching my head
Hi,
This is a known problem with the B20xmini. Have a look at this thread and
then follow it up.
You are right, you are seeing caps charge and discharge, basically.
Since I made the changes myself on my units, I am not sure where things
were left with Ettus and their policy for fixing the proble
16 matches
Mail list logo
