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

Michael West michael.west at ettus.com
Mon Oct 9 17:04:44 EDT 2017


Hi Steven,

I updated the other post, but I will repeat my comments here.  The final
capacitor changes have been made and the new rev C boards are now being
built.  The necessary capacitor changes on the rev B boards are as follows:

C15, C23, C25, C26:  470 pF
C14, C17:  220 pF

Regards,
Michael

On Wed, Oct 4, 2017 at 6:06 PM, Steven Knudsen via USRP-users <
usrp-users at lists.ettus.com> wrote:

> 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.
>
>
>
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171009/ea189400/attachment-0002.html>
-------------- 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/20171009/ea189400/attachment.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/20171009/ea189400/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/20171009/ea189400/attachment-0002.obj>
-------------- 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/20171009/ea189400/attachment-0003.obj>


More information about the USRP-users mailing list