[USRP-users] B200mini scheduled RX & TX; Tx attenuated

Steven Knudsen ee.knud at gmail.com
Wed Oct 4 21:06:57 EDT 2017


It’s been a while since I’ve said anything about the problem discussed below, namely burst scheduled Tx being attenuated when receives are scheduled. I found that it did not matter which STREAM_MODE was used, the attenuation always happened.

As it turns out, this is related to B200mini/B205mini re-work for the full-duplex TDD transient behavior issue (#1655). The capacitors around the RF switches (C15, C17, C23, C25, and C26) need to be reduced from 100 uF to 470 pF.)

I have been working with Ettus to get my B200mini’s RMA’d, but the fix was so simple that I decided to just try it. A local RF expert, Dan Bobyn (dbf.com) helped out by analyzing the schematic and then testing the fix with me. The results were, not surprisingly, remarkable. 

All the details are provided in the attached PDF for your interest.

We have not tested at higher frequencies, mostly because I have a 500 MHz scope. But I think it’s a turn on/off issue anyway, so the carrier frequency should not matter much.

Thanks for the support with this issue.

steven





On September 19, 2017 at 22:01:18, Steven Knudsen (ee.knud at gmail.com) wrote:

Hello again.

Regarding the problem I have scheduling both transmit and receive in a simple TDMA scheme. See the image below for a simple diagram of it.

Data is scheduleD one cycle ahead of time to transmit in slot 0 and for separate receptions in slots 1, 2, and 3.

As you may recall, for transmit-only or receive-only everything works fine. The transmit packet looks okay on a scope.

When I put the two together, the transmit packet looks distorted, though I cannot tell if it’s attenuated or the data is corrupted (though, you’d think that on average the amplitude would be the same as for the transmit-only case).

I had thought that maybe there is some buffer collision between the transmit and receive streams, but could not find anything in the source or via experiment to confirm.

I did notice that if I made the number of samples to receive in each slot very small, the transmit waveform looked okay again.

For whatever reason, I tried increasing the time between the last slot and the start of a new cycle, which I’ve labeled Tis, aka Time Inter-slot. making that time larger attenuated the Tx waveform less. Making it very large, and the attenuation was pretty much gone.

The first image below is with Tis = 6 ms (total cycle time = 10 ms), while the second is with Tis = 996ms (total cycle time = 1 s). For reference, the third image is with recv disabled, so Tx-only.

The last scheduled reception ends 3 ms after the end of the first slot. 

Clearly, if Tis is short, the Tx waveform is attenuated; if Tis is very long, the waveform looks fine.

If I was to guess, I’d say there is some kind of bias that decays with time following the reception. Looking at the schematic, there’s no obvious C to blame, but I am no expert on the circuit.

Any comments, ideas?










On September 16, 2017 at 08:25:12, Steven Knudsen (ee.knud at gmail.com) wrote:

No change using UHD 3.9.7 :-(


On September 16, 2017 at 07:19:05, Steven Knudsen (ee.knud at 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. Aber auch in jene Weite führt der Weg. - Franz Kafka

On Sep 15, 2017, at 16:16, Steven Knudsen <ee.knud at gmail.com> wrote:

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 reception scheduling to issue two stream commands, the first with the number of samples to receive, STREAM_MODE_NUM_SAMPS_AND_MORE, and a time spec, and the second stream command with STREAM_MODE_NUM_SAMPS_AND_DONE and the number of samples to receive = 1. In a receive-only test that approach worked fine.

However, when I put it back into the TDMA radio where transmissions are scheduled in slot 0 followed by scheduled receptions in slots 1, 2, and 3, I see the same problem. The transmitted signal is distorted or attenuated. Comment out the recv function, and all is well again.

I wondered about some kind of buffer overlap, so tried really short receptions. For example, a full slot represents about 15000 samples. If I set the stream command number of samples to receive to 500, everything works properly. Samples are received as and when expected and the transmitted waveform (as seen on a scope) looks fine. Up the number of samples to receive to 5000, and back to the ugliness.

So, either there is some kind of “collision” between the tx and rx streamers because of the rx number of samples to receive, or there is a shortage of time between scheduled receptions that somehow affects the transmit waveform.

I also looked at the UHD example txrx_loopback_to_file.cpp for any clues, but nothing popped out at me. It is, of course, a little different in that the transmit worker operates in its own thread while the recv operates in a separate thread and neither is scheduled (well, the receive is delayed a bit to allow “settling”). But what I take away from it is that transmit and receive can run simultaneously without interfering with each other. Indeed, when I look at the transmit waveform on a scope it stays the same before and after the receive starts.

Don’t know if any of the above will twig anything for you, but do appreciate all your help so far.

thanks,

steven

Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
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:22, Marcus D. Leech <mleech at ripnet.com> wrote:

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
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 <mleech at 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
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 <mleech at 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.








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171004/1b0ee7ae/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CBC73CB2-AF5C-4EF6-88C4-4CBACF5CFC66
Type: application/octet-stream
Size: 31793 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171004/1b0ee7ae/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 74D05FAE-B46E-4446-AA7B-669380BC79D0
Type: application/octet-stream
Size: 32148 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171004/1b0ee7ae/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0C45194F-628F-49A0-B9BC-598BFC020948
Type: application/octet-stream
Size: 32287 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171004/1b0ee7ae/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CE78674C-F83E-4392-8C66-5478E17A548A
Type: application/octet-stream
Size: 12112 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171004/1b0ee7ae/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: B200mini Transient Fix 2.pdf
Type: application/octet-stream
Size: 294952 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171004/1b0ee7ae/attachment.pdf>


More information about the USRP-users mailing list