Feature request: T/R switching (real time half duplex) via gr-osmosdr

[kpreid]

This is fairly off-topic as it relates entirely to gr-osmosdr code and not libhackrf code, but I haven't seen any active issue tracker or other forum actually used for gr-osmosdr, and I'm hoping that there is interest from this community (precedent being issue #87).

I would like to be able to use the HackRF in a half-duplex fashion from GNU Radio. Unfortunately, as currently implemented, TX or RX operations can only be stopped by destroying the gr-osmosdr sink or source object. This makes it very tricky (but possible) to perform the switch (making sure that the lifetimes of the sink and source do not overlap), and makes it impossible to query the capabilities of the device (sample rates, filter bandwidths, gains) without entering TX mode.

I would like to be able to have both source and sink objects around, and set the hardware to TX mode only on request. The request could be explicit, or implicit based on the availability of samples to transmit, or on the running state of the flowgraph containing the sink.

┆Issue is synchronized with this Basecamp todo by Unito

[miek]

I'd really like to see this too.

As far as I can tell, the standard (as used by uhd) seems to be to use the tags tx_sob and tx_eob at the start and end of a TX burst. Then the sink doesn't expect any samples between bursts, and the flowgraph can stall without lots of underflow errors.

Another benefit I see is that it makes bursty transmission a lot easier since you don't need to generate silence between packets (or drop to python to switch off between packets). It should also reduce latency since the sink isn't working through silent buffers to get to the actual burst.

[dragonyzl]

Yes! This feature is very useful for me! In order to implement the feature, I bought two hackrf one to implement the full duplex for Transciever the signal. If hackrf one can switch TX and RX with deterministic latency. It will be very very nice for me! ^_^.

Because of lack of the knowledge of hardware, I'm looking forward the feature very much and hope to take part in the development of implementation with someone's help, thanks for hints!

[KC5CQW]

Please escalate the priority on this!

[herrfeuer]

+1

[argilo]

I hacked T/R switching into gr-osmosdr and hackrf a while ago while building contest-sdr. See these branches:

• https://github.com/argilo/hackrf/tree/allow-tr-switching
• https://github.com/argilo/gr-osmosdr/tree/allow-tr-switching

I took some shortcuts, but it works as long as you don't need the T/R switching to be fast. My branches would probably be a good starting point for getting proper T/R support built.

[guruofquality]

So I would like to give this feature a shot with the SoapyHackRF wrapper if users are interested in testing it with me. The description in the issue below, but what I am proposing is doing the automatic switching when the user provides transmit data by starting and stopping the streams.

• https://github.com/pothosware/SoapyHackRF/issues/7
• https://github.com/mossmann/hackrf/issues/221

One of the advantages of doing this in SoapyHackRF is that all of the data structures and synchronization is in one place. The Osmo source and sink blocks are just a layer on top of this, sharing the same handle to the underlying SoapySDR device.

[zeroXzero]

@guruofquality +1. So what's the best way to add tag support for this feature in gnuradio? Is it better to add it in gr-sdr when compared to gr-osmosdr (a gr-uhd style "stream tag" and command port support). It seems like SoapySDR already shares the same device handle if same arguments are used (So that sink and source block can coexist).

[guruofquality]

@zeroXzero Thats correct, since the device handles are in the same SoapySDR device object, its straightforward with some mutexes and a few extra indicators to implement the switching using the existing API for burst flags, etc.

Although not implemented yet, the issue is on my radar: https://github.com/pothosware/SoapyHackRF/issues/7 And I will be revisiting SoapyHackRF soon to implement some of the new calls that I have added to SoapySDR recently.

As far as supporting the switching in GNU Radio blocks using tags, we have a few options here:

1) We can add tag support to the soapy source and sink blocks in GrOsmoSDR. They are just ordinary GrBlocks that happen to get instantiated when Soapy SDR supported devices are used. So all of the tag handling glue can go into these two blocks. And any Soapy SDR devices that support timestamps and/or bursts will be able to take advantage of this.

• http://git.osmocom.org/gr-osmosdr/tree/lib/soapy/soapy_source_c.cc
• http://git.osmocom.org/gr-osmosdr/tree/lib/soapy/soapy_sink_c.cc

2) We can do exactly the same work to gr-sdr. I made gr-sdr before making the soapy block support in GrOsmoSDR. So they are similar projects. As much as I like the idea of set of clean, streamlined, and minimal dependency SDR blocks for GNU Radio, its really a matter of whatever the community wants, and GrOsmoSDR is by far more popular with the folks :-)

3) Or use gr-uhd. Just like GrOsmoSDR, Soapy SDR devices should be usable from within this wrapper as well using SoapyUHD (https://github.com/pothosware/SoapyUHD/wiki) Users may not be comfortable with the additional layer of redirection, but that tags and timestamp features are already implemented here, which is a plus.

4) Don't implement any tags. The SoapyHackRF async thread could detect the cessation of transmit packets within a time window and automatically switch back. That may sound a little lazy, but on the other hand, if we switch immediately when a EOB tag is consumed, will the outgoing samples become truncated before they are completely transmitted? We may need a carefully calculated timeout in any case. I will have some experiments to do.

Quite a few options here. So I would love to know what others think about this.

[guruofquality]

Update: If anyone wants to try this out, @jocover implemented this feature for SoapyHackRF. It might need some additional tweaks, but it appears to work: https://github.com/pothosware/SoapyHackRF/issues/7

[shaky1024]

+1. Seems strange to me that this still hasn't happened.

[guruofquality]

I should have posted another updated after giving this a live test. This was a while ago, but I gave this BTLE transceiver app a go with the hackrf using SoapyHackRF. The demo continuously receives BTLE advertisement packets, but it can be interrupted with a GUI click to transmit a control signal to a wireless remote.

So its not an app that transmits often, nor is it very sensitive to the timing of the switching. But it was pretty cool to see it work on the hackrf without issue. Although this is a Pothos demo, you should be able to have simultaneous gr-osmosdr source and sink block with intermittent transmits using the args "soapy=0,driver=hackrf"

Basically the act of transmitting forces the wrapper to switch. And on the receive side, it waits for tx buffers to be totally transmitted before switching back... All within the SoapyHackRF streaming implementation, no changes to libhackrf. And you shouldn't need any tags or labels to indicate end of burst on transmit.

[mike01]

The TX/RX-switch does actually relate to libhackrf code and doesn't seem to be solvable just changing host code. The reason for this is that the libhackrf code does not make sure that samples sent in TX are fully sent out when switching mode to RX. You can observe this problem when doing a TX->RX->TX switch and receiving the signals using a 2nd SDR. The picture below shows a TX-round sending 32000 samples on a low frequency and the same amount on a high frequency. The marked section (~300us) shows the area where the SDR is in RX mode. It can be seen that the full samples are not entirely sent out before switching. Solving this probably includes changes on the host and firmware side especially regarding the USB-signalling code.

[argilo]

@mike01 Indeed. In my prototype I swept this problem under the rug by appending silence to the TX samples:

https://github.com/argilo/gr-osmosdr/blob/6e67be09da9f2e40996edb2ca8688e474946ff73/lib/hackrf/hackrf_sink_c.cc#L281-L293

But clearly that's a dirty hack that only works if you can tolerate very slow T/R switching.

[eejake52]

@guruofquality: I tried with gnuradio companion: "you should be able to have simultaneous gr-osmosdr source and sink block with intermittent transmits using the args "soapy=0,driver=hackrf" ". I have both source and sink blocks using the same args. The source block transmits a burst of morse code with no repeat, so I expected the sink block would then take over. If I disable the sink, then the source works fine, and if I disable the source, then the sink works fine; but if both are enabled, then only the source block (rx) works, the rx LED comes on and I get an error from GRC as follows: gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.9 built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy redpitaya Number of USB devices: 6 USB device 1d50:6089: 0000000000000000909864c8343e0ecf match Using HackRF One with firmware 2015.07.2 gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.9 built-in sink types: uhd hackrf bladerf redpitaya file Number of USB devices: 6 USB device 1d50:6089: 0000000000000000909864c8343e0ecf match

FATAL: Failed to open HackRF device (-1000) HACKRF_ERROR_LIBUSB

So, is there a trick to getting a source and sink working? Thanks, Jake

[guruofquality]

So, is there a trick to getting a source and sink working?

@eejake52 So my suggestion was to try out the SoapyHackRF module. To use that with gr-osmosdr, make sure that the following steps are taken care of first:

1) Install SoapySDR 2) Install SoapyHackRF, make sure that hackrf appears in SoapySDRUtil --info 3) Install gr-osmosdr (soapy sdr support will be included when the development files are present), and make sure that 'soapy' appears in the supported options like the ones printed previously:file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy redpitaya

Then "soapy=0,driver=hackrf" should work. Sorry, I wish there was a failmode in the gr-osmosdr device selection, but when the key is not found it just picks the first available device.

FATAL: Failed to open HackRF device (-1000) HACKRF_ERROR_LIBUSB

This was the error we were seeing with the hackrf wrapper from gr-osmosdr (SoapyOsmo) because both the source and the sink were being instantiated at once. So that was actually the impetus for someone to contribute the SoapyHackRF support in the first place. :-)

[eejake52]

@guruofquality: thanks for the pointers. I now have the SoapySDR source and sinks installed and recognizing the hackrf. However: if I just enable the sink, run the flowgraph, it works fine; but if I stop and restart the flowgraph, it hangs. I have to reset the hackrf to get it working again. Same issue with source; i.e. have to reset the hackrf to get it to work again.

Meanwhile, if I enable both source and sink, I see the tx LED flicker briefly, then the rx LED, then the tx LED comes on steady; I expected to see the tx LED for about 10 seconds, then the rx LED. I looked at your BTLE example, and I couldn't see anything obvious that I could be doing wrong. If you have any suggestions on how to go about testing, I'd appreciate that.

[eejake52]

I eventually got the issue resolved. I was running Ubuntu on a virtual machine, and that was causing silent glitches on the USB connection.

[ly2ss]

guruofquality, i did everything as you instructed few posts above. Separate graph parts work ok but once I put everything in one place I am getting this:

Executing: /usr/bin/python2 -u /home/osmo/Desktop/ok/top_block.py

gr-osmosdr v0.1.4-91-gcf954948 (0.1.5git) gnuradio 3.7.12git-119-g0e32fcaf built-in source types: file fcd rtl rtl_tcp hackrf rfspace soapy redpitaya [INFO] Opening HackRF One #0 406464c82332614b... gr-osmosdr v0.1.4-91-gcf954948 (0.1.5git) gnuradio 3.7.12git-119-g0e32fcaf built-in sink types: hackrf soapy redpitaya file

FATAL: no hackrf device matches

Trying to fill up 1 missing channel(s) with null sink(s). This is being done to prevent the application from crashing due to gnuradio bug #528.

[guruofquality]

gr-osmosdr v0.1.4-91-gcf954948 (0.1.5git) gnuradio 3.7.12git-119-g0e32fcaf built-in source types: file fcd rtl rtl_tcp hackrf rfspace soapy redpitaya [INFO] Opening HackRF One #0 406464c82332614b... gr-osmosdr v0.1.4-91-gcf954948 (0.1.5git) gnuradio 3.7.12git-119-g0e32fcaf built-in sink types: hackrf soapy redpitaya file

For whatever the reason is, hackrf_device_list() doesnt report the device once its been opened the first time. SoapyHackRF isnt trying to open a new device handle, but it relies on discovering the HackRF, even though its already opened to find and use the same device handle. This might not be anything different in libhackrf, it could just be due to the SoapyHackRF open by serial support. Looks like the solution is to stash the discovered result and use it in find_HackRF() when the device handle is claimed. brb

[ly2ss]

Just for curiosity I disabled all possible sinks/sources in gr-osmocom except soapy but the result is same: FATAL: no hackrf device matches

[oathyan]

How long does T/R switching takes? My project requires T/R switching times less than 3 us.

[WangMinSSS]

How long does T/R switching takes? My project requires T/R switching times less than 3 us.

hi, do you have found the answer? I want to know the minimum switch time of hackRF also.

[inoxxvictor]

How long does T/R switching takes? My project requires T/R switching times less than 3 us.

Hi, got any answers? I'm trying to build a software defined radar and the switching time should be relatively low. Also, I have implemented the soapy=0,driver=hackrf in an other flow graph and it doesn't give me any errors, which is good. But my hackrf LEDs don't switch from Tx to Rx, any clue why? Thanx

[eejake52]

T/R switching is fairly slow - several 10s of ms. I worked on the code a few years back and so I had to understand the details. Here is how it works. If there is data available at the Osmocom Sink block (i.e. data to transmit), the driver will stop the receive streaming, adjust the frequency and gain settings to match the Sink parameters, and then start transmit streaming. Once all the data has been streamed out, the driver will stop the transmit streaming, adjust freq and gain to match the Source block, and then start receive streaming. This all takes time.

You can see the switchover happening by starting gnuradiocompanion with the debug log level, as follows: `

!/bin/bash

echo "Setting Debug level for SoapyHackRF"

SOAPY_SDR_LOG_LEVEL="DEBUG"

export SOAPY_SDR_LOG_LEVEL

gnuradio-companion

echo "Done Debug level for SoapyHackRF"

` Here is the flowgraph I use for my 2m voice application: Notice that the gain settings in the sink & source block behave differently than the non-soapy hackrf driver (i.e. native osmocom). You need to verify that data is coming out of the Select Block port 0. I suggest temporarily bypassing the Select block (i.e. hardwiring for tx, and then rx), to make sure each case works on its own. Then move on to switching.

Hope that helps.

Jake

[inoxxvictor]

T/R switching is fairly slow - several 10s of ms. I worked on the code a few years back and so I had to understand the details. Here is how it works. If there is data available at the Osmocom Sink block (i.e. data to transmit), the driver will stop the receive streaming, adjust the frequency and gain settings to match the Sink parameters, and then start transmit streaming. Once all the data has been streamed out, the driver will stop the transmit streaming, adjust freq and gain to match the Source block, and then start receive streaming. This all takes time.

You can see the switchover happening by starting gnuradiocompanion with the debug log level, as follows: `

!/bin/bash

echo "Setting Debug level for SoapyHackRF"

SOAPY_SDR_LOG_LEVEL="DEBUG"

export SOAPY_SDR_LOG_LEVEL

gnuradio-companion

echo "Done Debug level for SoapyHackRF"

` Here is the flowgraph I use for my 2m voice application: Notice that the gain settings in the sink & source block behave differently than the non-soapy hackrf driver (i.e. native osmocom). You need to verify that data is coming out of the Select Block port 0. I suggest temporarily bypassing the Select block (i.e. hardwiring for tx, and then rx), to make sure each case works on its own. Then move on to switching.

Hope that helps.

Jake

Cheers Jake By what you've said, the osmocom sink has a priority over the source, regardless of what the selector is switched into. The change between TX and RX is then done when the sink does not receive any data, if I understand correctly. I was wondering if the switching would be done if the data streamed into the sink is provided by a file source, which would be set to "not repeat". Both TX and RX work by themselves, I've changed the circuit into a simple 2MHz transmitter and receiver so I don't depend on my crappy microphone to provide a steady signal for the sink. Here's the bypassed graph: I get a switching between TX and RX, or so do the LEDs say, but it doesn't correspond with the length of the 2MHz tx file, which is 5 seconds long (There where two switches in the LEDs, about 1.5 seconds between them) Any clue why? Thanks Víctor

[jnunezortuno]

T/R switching is fairly slow - several 10s of ms. I worked on the code a few years back and so I had to understand the details. Here is how it works. If there is data available at the Osmocom Sink block (i.e. data to transmit), the driver will stop the receive streaming, adjust the frequency and gain settings to match the Sink parameters, and then start transmit streaming. Once all the data has been streamed out, the driver will stop the transmit streaming, adjust freq and gain to match the Source block, and then start receive streaming. This all takes time. You can see the switchover happening by starting gnuradiocompanion with the debug log level, as follows: `

!/bin/bash

echo "Setting Debug level for SoapyHackRF" SOAPY_SDR_LOG_LEVEL="DEBUG" export SOAPY_SDR_LOG_LEVEL gnuradio-companion echo "Done Debug level for SoapyHackRF" ` Here is the flowgraph I use for my 2m voice application: Notice that the gain settings in the sink & source block behave differently than the non-soapy hackrf driver (i.e. native osmocom). You need to verify that data is coming out of the Select Block port 0. I suggest temporarily bypassing the Select block (i.e. hardwiring for tx, and then rx), to make sure each case works on its own. Then move on to switching. Hope that helps. Jake

Cheers Jake By what you've said, the osmocom sink has a priority over the source, regardless of what the selector is switched into. The change between TX and RX is then done when the sink does not receive any data, if I understand correctly. I was wondering if the switching would be done if the data streamed into the sink is provided by a file source, which would be set to "not repeat". Both TX and RX work by themselves, I've changed the circuit into a simple 2MHz transmitter and receiver so I don't depend on my crappy microphone to provide a steady signal for the sink. Here's the bypassed graph: I get a switching between TX and RX, or so do the LEDs say, but it doesn't correspond with the length of the 2MHz tx file, which is 5 seconds long (There where two switches in the LEDs, about 1.5 seconds between them) Any clue why? Thanks Víctor

Hi Victor,

Did you make any progress in this issue? I have the same problem here. I built the same graph in PothosSDR with similar result. It seems that T/R switching will not be possible until either gr-osmosdr or SoapyHackRF are modified. Now this is not a real half-duplex operation.

Please, contact me to exchange some impressions: jnunezortuno@gmail.com

Regards, José

[copslock]

Changing only the host code will not help anything,the modification to the NXP controller firmware is mandatory

[antonyscerri]

Curious where things now stand on this? I've seen mention that using SoapySDR with osmosdr in GNU Radio you can have it switch between TX and RX. I've tried and its unclear if its working. I was hoping to be able to switch to TX to transmit a small burst and back to RX without any real delay and leverage the half-duplex nature given i'm largely dealing with a handshake and acknowledgment scenario.

As other have mentioned here and on a couple of related issues, things like the TX led sometimes goes red but mostly not. When it has flashed red it only seemed to do it the once, so i wasnt sure what that indicated. Also my transmission is relatively small (short) and wasn't even sure if it would have time to indicate it. I've also now experience the RX led dim briefly which may also be indicating the switch but hard to tell. The remainder of the time i just want to be in RX mode.

I also enabled debug in Soapy and the messages it output to show switching on TX or RX seemed to be very delayed and also very inconsistent with relation to messages i generate when data is being sent.

Finally I wasn't sure if switching to TX and back to RX stopped receiving correctly as a signal i know to be present and can record separately failed to show up when run in this combination.

Another question I had, assuming this is supported in some fashion, was what is the delay in switching between TX and RX or vice versa. For my application response may be sent back in ~3ms.

[eejake52]

Curious where things now stand on this? @antonyscerri - You can get a copy of my working flowgraph here: https://wiki.gnuradio.org/index.php/Talk:HamRadio#Saturday_12_December_2020_16:00_UTC It works on GNUradio 3.7.* and uses a custom OOT block, but you can see how it connects. Also, one of the attendees at that presentation, said that the OSMOSDR native hackrf driver, now supports half duplex, without using soapy. I haven't tried it.

Another question I had, assuming this is supported in some fashion, was what is the delay in switching between TX and RX or vice versa. For my application response may be sent back in ~3ms. @antonyscerri - The switching time between TX & RX is very difficult to predict. GNUradio top level is a Python program compiled from the flowgraph, which drives the GNUradio scheduler based on samples available at the input & output of each block. The details of the scheduler are understood by a select few programmers (NOT including me), but I gather the scheduler tries to optimize for throughput rather than response time. Each block runs in a separate thread and how the threads are blocked & unblocked isn't really clear to me. So, the osmosdr/soapy/hackrf sink and source blocks each execute in a separate thread, but the soapy/hackrf code and variables are common to both threads. When the sink block receives data to transmit (from the gnuradio scheduler), it switches the hackrf into TX mode and continues to stream out data until there are no more samples at the input to the sink; at that point it switches the hackrf back to RX mode. Meanwhile, the source block thread just stops generating output until the sink block thread puts the hackrf back in RX mode. Switching the hackrf from RX to TX and back is done over the USB port, and implemented in the hackrf CPU/FPGA. If you put an oscilloscope probe on the hackrf tx LED and measured the duration of the TX pulse, I expect it would be much longer than (#samples/stream rate), but how much longer will depend on the GNUradio scheduler, the OS scheduler, the OS/USB driver, the hackrf CPU/FPGA firmware, and the hackrf RF components. I don't know any other way to measure the turnaround time.

For your application, I'm not optimistic that you could get from TX back to RX in < 3ms. If you have control of the transceiver that gives a reply to your hackrf poll/response, I suggest you implement a variable delay in the response, and just determine empirically how long you have to wait; ie start at about 1 second and work down until the hackrf misses the response.

Hope that helps, Jake

[antonyscerri]

Hi Jake

So i've been working in GNU Radio to build out a workflow. I initially started with gr-osmosdr and what I believe was the native lib hackrf device support. I've since switched to the SoapySDR wrapper as it handles switching, but as noted above i seem to have observed a few different issues. I'm assuming i have managed to get all versions to align correctly.

If i went direct to libhackrf that's what im wondering what the theoretical switching delay may be. I've not had a chance to look much at this path yet. I'm slightly hampered only have one SDR to test with as well, hence i'm going of debug info and light indicators and the fact the device i'm trying to interact with isn't responding. This was all a bit of an experiment going beyond simply receiving data, which i've managed to get a decent recovery rate and built out the logic for handling the protcol used by the device, it looks like i may just have to give up on the final implementation using hackrf sadly.

Tony

[Jcwscience]

Assuming I have a fairly lenient delay requirement (say 0.5 to 1 second) is there any up to date info on how to handle a switchover? Eventually I’d like to filter and amplify the signal and use it to hit a ham radio repeater. But I would need something like an opera cake to switch between the transmit amp and the receive antenna.

Basically a push to talk. For now I’m just hoping to get a proof of concept working and get familiar with the process.

I have the latest build of gnuradio as well as up to date firmware, osmocom modules and, soapy modules.

[eejake52]

jcwscience, I have a hackrf and I have done exactly what you requested without using an opera cake; but it involved modifications to the hackrf. I made two changes:

1. added an SMA connector for tx rf
2. brought out the tx-led signal

I then used a homebrew RF amplifier to increase the tx power from 10 mw to about 5 W. The amp board also included a filter and a switch for rx/tx rf paths.

In gnuradio, I used the SoapyHackrf module called by the Osomocom sink and Osmocom source blocks. I had it all working about 3 years ago. In gnuradio 3.7 that was the only way to get tx/rx switching in a hackrf. Now, in gnuradio 3.10 they have Soapy sink and Soapy source blocks packaged specifically for the hackrf, so its a lot easier to use.

So, it is possible, but it takes a lot of learning about gnuradio and hackrf. I wouldn't recommend it as a beginner project.

Jake

---

From: Jcwscience @.> Sent: August 6, 2022 7:40 AM To: greatscottgadgets/hackrf @.> Cc: Gavin Jacobs @.>; Mention @.> Subject: Re: [greatscottgadgets/hackrf] Feature request: T/R switching (real time half duplex) via gr-osmosdr (#195)

Assuming I have a fairly lenient delay requirement (say 0.5 to 1 second) is there any up to date info on how to handle a switchover? Eventually I’d like to filter and amplify the signal and use it to hit a ham radio repeater. But I would need something like an opera cake to switch between the transmit amp and the receive antenna.

Basically a push to talk. For now I’m just hoping to get a proof of concept working and get familiar with the process.

I have the latest build of gnuradio as well as up to date firmware, osmocom modules and, soapy modules.

— Reply to this email directly, view it on GitHubhttps://github.com/greatscottgadgets/hackrf/issues/195#issuecomment-1207216946, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AE5JVBLLIAZEMXWS5ST5EQ3VXZTLFANCNFSM4BKW4Q7Q. You are receiving this because you were mentioned.Message ID: @.***>

[Jcwscience]

@eejake52 Thanks for the info! As long as I know it is possible I can focus some energy into learning more about soapysdr and gnuradio. I have been meaning to get more familiar with it and make some smaller flow graphs. Did you make a custom amplifier or buy one?

[eejake52]

jcwscience, I made a custom/homebrew amplifier using a Mitsubishi RA08H1317M amplifier module. If I had to do it all again, I would use a higher power module. If I were starting over today, I would use the ADALM Pluto instead of the Hackrf.

---

From: Jcwscience @.> Sent: August 7, 2022 6:38 PM To: greatscottgadgets/hackrf @.> Cc: Gavin Jacobs @.>; Mention @.> Subject: Re: [greatscottgadgets/hackrf] Feature request: T/R switching (real time half duplex) via gr-osmosdr (#195)

@eejake52https://github.com/eejake52 Thanks for the info! As long as I know it is possible I can focus some energy into learning more about soapysdr and gnuradio. I have been meaning to get more familiar with it and make some smaller flow graphs. Did you make a custom amplifier or buy one?

— Reply to this email directly, view it on GitHubhttps://github.com/greatscottgadgets/hackrf/issues/195#issuecomment-1207524773, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AE5JVBLZGYEF3YXWGZV5RMDVYBJIVANCNFSM4BKW4Q7Q. You are receiving this because you were mentioned.Message ID: @.***>