Re: [USRP-users] USRP B200mini half-duplex 1 port
- Included message --- Message: 5 Date: Tue, 27 Oct 2020 20:28:12 -0400 From: "Marcus D. Leech" To: usrp-users@lists.ettus.com Subject: Re: [USRP-users] USRP B200mini half-duplex 1 port Message-ID: <5f98bb1c.7070...@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed On 10/27/2020 08:24 PM, Alvaro Pendas Recondo via USRP-users wrote: > Hello, > > I am trying to implement a half-duplex system with one antenna, > preferably using just one port in the USRP device. I have noticed that > the port that is labelled as TX in the B200mini can also receive (the > same as the TX/RX port in the "normal" B200). My question is, is it > possible to change modes in that port during execution time? I have > read that, as a rule of thumb, the port should receive as default and > transmit when it receives samples to do so. However, I do not know if > that functionality applies to the B200mini. > > If it is possible, do you have any general ideal about the best way to > do it in GNURadio? > > Best regards, > > Alvaro > > As far as I know the TX port on the B200mini is actually a TX/RX port, and the transmit/receive switching logic is implemented in the hardware. You might post to the discuss-gnuradio mailing list on topics related to Gnu Radio. I've never implemented a TX/RX application in GR myself, but I'm fairly sure the hardware supports it. --- Assuming you are using the B205mini - the TX/RX port switching appears to work on detecting samples in the transmit buffer (FIFO). When the Tx FIFO is empty it switches to receive. There are a number of problems with this, in that once in receive it is very difficult to fill the transmit FIFO enough to get it to transmit continuously again. What happens is that if the transmit source is throttled in any manner, a few samples get TX queued then the mini switches to TX and empties the FIFO enough to switch back to receive. So it goes into a high-speed Tx/Rx/Tx/Rx/Tx/Rx . mode.Using for example an audio source causes sample rate limiting to the rate of that source. If instead a source is provided that can burst a whole bunch of samples to the TX Fifo, then it gets into TX mode and stays. For example, a constant source with no throttling. Unfortunately this isn't so useful for actual information. All the above tested at a sample rates of 96 ksps and some lower.Higher sample rates have not been tried, probably the behavior would be different. Finding any documentation about what is going on, how it works, FIFO sizes, %FULL %EMPTY trigger levels, etc. has been fruitless so far. -- Tom, N5EG ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] CLUES : B205 Half-Duplex problem
Finally identified the B205 Half-Duplex problem I think. No packets involved here - everything is streaming. No Tags, no Messages. My hypothesis is that when the B205 transmitter starts (the 2nd and later times) it tries to fill up something like a TX FIFO, sucking samples out of the flowgraph way faster than they can be provided. This causes the TX to underrun going back to receive. Then it catches back up and switches to transmit, bouncing back and forth. The first time the TX starts (on flowgraph startup) it seems to pace the TX correctly. After switching to RX then back to TX (by stopping TX samples the restarting) is when the problem occurs. A number of different approaches seem to yield the same behavior: 1) I used an Audio Source block (microphone) to feed a multiplier (frequency shifter) that feeds the TX. If I remove that and replace it with a signal source block sinewave (something that does not involve real time) then the TX can suck samples as fast as it wants, and everything T/R switches correctly. 2) The original flowgraph used a Signal Source Block as a L.O. feeding two multipliers: one in the RX chain, and one in the TX chain. The receiver is feeding samples to it's multiplier at a constant rate, which limits how fast the buffer on the L.O. has samples pulled. That same L.O. is also feeding a multiplier in the transmit chain, which drains all the buffers in the TX path up to that point. I created two gnuradio Signal Source blocks, with identical input parameters but instantiated as two separate blocks in the flowgraph. One feeds the receiver multiplier, one feeds the transmit multiplier - this avoids any common path that could slow down samples to the TX. As long as the TX side has no real-time sources then it T/R switches correctly. Using the Audio Source block in the TX chain causes the problem to resurface. This seems to confirm the hypothesis. My opinion is that this is probably a BUG in the B205 FPGA code. It should attempt to pull samples at a rate close to the sample rate of the transmitter when restarting. -- Tom, N5EG ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] B205mini half-duplex? (GRC)
Hi Marcus - thanks for the link to the documentation. Messages don't have the required functionality, so I have tried to insert tx_sob and tx_eob tags. This unfortunately has not changed anything. This is what the tag debug shows, are these formatted correctly for UHD USRP sink? -- Tag Debug: Input Stream: 00 Offset: 139250 Source: burst_tagger4 Key: tx_sob Value: #t -- -- Tag Debug: Input Stream: 00 Offset: 196587 Source: burst_tagger4 Key: tx_eob Value: #t -- I have to stop streaming samples to the USRP Sink to get it to stop transmitting and switch TX/RX over to RX - the tags aren't enough. However the next time back to Tx, the problem with transmitter underruns and weird oscillating T/R behavior resumes. Still looking for advice as to how to T/R switch the unit without the TX going nuts? -- Tom, N5EG On 07/04/2019 11:14 PM, Tom McDermott via USRP-users wrote: >* I am trying to use a B205mini in half-duplex mode through the TX/RX *>* connector *>* from a GRC flowgraph. Gnuradio 3.7.13.4. Very slow switching, *>* manually implemented. *>>* The flowgraph implements a simple half-duplex transceiver. In order to *>* switch *>* the TX/RX antenna switch, I am starting and stopping samples to the *>* USRP sink *>* using the Copy block. When the Copy block is enabled it passes *>* samples to the USRP sink, *>* and when disabled it does not copy samples to the USRP sink. *>>* If the Copy block is statically enabled, then the USRP transmits (RED *>* led 'On' for TX/RX) *>* continuously without any underruns. *>>* If the Copy is statically disabled, then USRP goes into receive mode *>* (GREEN led 'On' for TX/RX) *>* and stays in that mode. *>>* So far so good. *>>* However if I toggle the enable/disable on the copy block to disable *>* the TX/RX switches as it should *>* from red to green, but after I re-enable the Copy block and leave it *>* enabled, the TX/RX LED goes red *>* for awhile, then rapidly flashes red/green/red etc. while printing *>* UUU on the GRC console, then *>* goes RED for about 5 seconds without underruns, then flashes RED/GREEN *>* rapidly for 5 or 10 seconds *>* and underruns, back and forth ad infinitum. *>>* So Copy appears not to be a good way to implement T/R switching. *>>* There is a message port on the USRP sink block. Can this be used to *>* implement T/R switching? *>* Is there some place that the messages that this port accepts defined? *>* I cannot seem to find *>* the syntax for the message definitions in the USRP documentation, so I *>* must be looking in the wrong place. *>>* -- Tom, N5EG *>>There's some documentation here: https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__sink.html ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] B205mini half-duplex? (GRC)
I am trying to use a B205mini in half-duplex mode through the TX/RX connector from a GRC flowgraph. Gnuradio 3.7.13.4. Very slow switching, manually implemented. The flowgraph implements a simple half-duplex transceiver. In order to switch the TX/RX antenna switch, I am starting and stopping samples to the USRP sink using the Copy block. When the Copy block is enabled it passes samples to the USRP sink, and when disabled it does not copy samples to the USRP sink. If the Copy block is statically enabled, then the USRP transmits (RED led 'On' for TX/RX) continuously without any underruns. If the Copy is statically disabled, then USRP goes into receive mode (GREEN led 'On' for TX/RX) and stays in that mode. So far so good. However if I toggle the enable/disable on the copy block to disable the TX/RX switches as it should from red to green, but after I re-enable the Copy block and leave it enabled, the TX/RX LED goes red for awhile, then rapidly flashes red/green/red etc. while printing UUU on the GRC console, then goes RED for about 5 seconds without underruns, then flashes RED/GREEN rapidly for 5 or 10 seconds and underruns, back and forth ad infinitum. So Copy appears not to be a good way to implement T/R switching. There is a message port on the USRP sink block. Can this be used to implement T/R switching? Is there some place that the messages that this port accepts defined? I cannot seem to find the syntax for the message definitions in the USRP documentation, so I must be looking in the wrong place. -- Tom, N5EG ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] LIBUSB_TRANSFER_ERROR on UHD v3.12
This happened to me as well after upgrading from 3.10 to either 3.12 or 3.13 (forget which). It will run normally, but in various gnuradio flowgraph terminate situations, it has this error and does not seem to recover without a device reinitialization. -- Tom, N5EG On Tue, Feb 12, 2019 at 7:25 AM Jimmy Uhing via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello, > > > I am using a USRP B205mini-i radio and keep receiving the following error > from version 3.12 of the UHD API: > > terminate called after throwing 'uhd::io_error' > > what(): EnvironmentError: IOError: usb tx2 transfer status: > LIBUSB_TRANSFER_ERROR > > > Sometimes the error will say "usb rx2 transfer status" and sometimes the > status will be "LIBUSB_TRANSFER_OVERFLOW". Not sure if this is related to > hardware or software. > > > Any ideas? > > > Thanks! > > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] UHD diverge from origin/master
Thanks for the advice, Martin. Did a git hard reset of UHD, Checked out master, updated uhd-images submodule, built. Ran uhd images downloader Then rebuilt gnuradio. It seems to run correctly. -- Tom, N5EG On Fri, Aug 24, 2018 at 4:35 PM Martin Braun via USRP-users < usrp-users@lists.ettus.com> wrote: > On 08/24/2018 10:14 AM, Tom McDermott via USRP-users wrote: > > I installed and built gnuradio and UHD some time ago from the SBRAC > script. > > > > I am at the head of gnuradio maint-3.7, and am on uhd maint. My > > version of uhd is 3.10.2.0 and my FPGA > > images are also 3.10.2. There appears to be 3.10.3 FPGA available (for > > B205Mini). > > > > However git tells me that UHD has diverged from origin/maint although I > > have not made any changes > > to my local version. I am 30 ahead and 1023 behind origin/maint. A > > guess would be that something in > > uhd origin/maint repository was altered after I pulled from it, and that > > it is necessary to do a git hard reset of > > my local copy. > > > > Assuming I stick with gnuradio maint-3.7 should I then checkout a > > specific tag of uhd, or the > > head of uhd maint? > > Tom, > > we deprecated the UHD maint branches a few weeks ago (Michael West sent > an announcement), but for your case, that shouldn't matter. You can use > a broad range of versions of UHD with GNU Radio, so if you're on > maint-3.7 for GNU Radio, you can still use master branch for UHD, for > example. > > -- M > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] UHD diverge from origin/master
I installed and built gnuradio and UHD some time ago from the SBRAC script. I am at the head of gnuradio maint-3.7, and am on uhd maint. My version of uhd is 3.10.2.0 and my FPGA images are also 3.10.2. There appears to be 3.10.3 FPGA available (for B205Mini). However git tells me that UHD has diverged from origin/maint although I have not made any changes to my local version. I am 30 ahead and 1023 behind origin/maint. A guess would be that something in uhd origin/maint repository was altered after I pulled from it, and that it is necessary to do a git hard reset of my local copy. Assuming I stick with gnuradio maint-3.7 should I then checkout a specific tag of uhd, or the head of uhd maint? -- Tom, N5EG ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] UHD release vs. gnuradio release - compatibility table?
Thanks for the announcement of the new UHD 3.10.3 release. I've noticed on the gnuradio mailing list some comments about possible incompatibility of certain UHD versions and Gnuradio versions (assuming I'm reading things correctly). Is there a table that lists compatibility of the various UHD branches and tags against gnuradio branches and tags? Or a table of recommended versions between the two release streams? I am running gnuradio 3.7.11.1 maintand UHD maint 122bfae (which is quite a few behind). -- Tom, N5EG ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
