Official bladeRF forum

I'm working on a weak signal station and would like to switch TX and RX lines based on a PTT signal. Is there something on the board that would indicate when TX switches to/from activated? If so, how do I access that signal?

There's no signal driven out to any particular pins by default; you'd have to modify the HDL to do this.

However, if you're writing the software, you're in full control of when you are and are not transmitting, right? There's a slew of functions for controlling GPIO pins -- perhaps you could include a GPIO call wherever you call bladerf_enable_module() to start/stop the TX stream.

I am writing the software, so to speak, using gnuradio companion. So while I am controlling TX / RX switching, I'm not aware of any interface in GRC to control GPIO pins. I suppose I'll need to roll my own software to get the functionality I'm looking for unless I overlooked some binding in GRC to control the BladeRF's GPIO pins.

A few folks, including myself had discussed adding GPIO support to gr-osmosdr (the block that provides sources and sinks for bladeRF and numerous other devices) at one point, but no one's working on it as far as I know.

I think adding GPIO support would be a very well-received contribution to gr-osmosdr -- I know other people have expressed interest in the ability to control a TR switch from within a flowgraph.

One easy way to do it would be via message passing. From what I understand, there's some support for having Qt GUI widgets (e.g., a button) emit messages. It looks like Tom Rondeau wrote a blog post on this.

For GPIO outputs, I envision there being a PMT input port. A simple name/value pair could be used to assign a value to the named GPIO. The bladeRF source/sink could then make the appropriate libbladeRF call.

I'm looking into adding GPIO support to gr-osmosdr but have to admit I'm starting from ground zero in terms of familiarity with programming for GRC (I'm a programmer by day, so I'm not starting from zero). Any pointers to where to look would be helpful.

It's been a while since I've been in the gr-osmodr code.

I would start with reviewing the source_impl.c/h and sink_impl.c/h and then the code in the lib/bladerf directory.

• As a quick test, you could probably register a message handler in the bladeRF source or sink, and then print out messages (from a GUI button) as you receive them.
• After you get that working, look at the libbladeRF GPIO calls.
• Once you've got that working, perhaps look at whether it makes sense to move any functionality "up a layer" to be more generic and applicable to other devices. You may want to send proposed patches to the gr-osmosdr maintainer for feedback at this point.