Skip to content

Added goTenna Pro TX challenge Support - #11

Merged
dperret merged 10 commits into
rfhs:gotenna-pro-challengefrom
Dollarhyde:master
Jul 28, 2026
Merged

Added goTenna Pro TX challenge Support#11
dperret merged 10 commits into
rfhs:gotenna-pro-challengefrom
Dollarhyde:master

Conversation

@Dollarhyde

Copy link
Copy Markdown
Contributor

This pull request sets up goTenna Pro TX challenge

@dperret dperret self-assigned this Jul 14, 2026
Comment thread challengectl.py Outdated
Comment thread challengectl.py Outdated
Comment thread challengectl.py Outdated
Comment thread challengectl.py Outdated
Comment thread challengectl.py Outdated
Comment thread challengectl.py Outdated
Comment thread challengectl.py Outdated
@dperret

dperret commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

@Dollarhyde if you have the grc flowgraph for gotenna_pro_bladerf, can you add that? It would also be good to make this not specific to the bladeRF, and allow passing in an osmosdr device string as a parameter. Same thing with a parameter to allow specifying the antenna port.

Comment thread challengectl.py Outdated
@Dollarhyde Dollarhyde reopened this Jul 23, 2026
@Dollarhyde

Copy link
Copy Markdown
Contributor Author

@Dollarhyde if you have the grc flowgraph for gotenna_pro_bladerf, can you add that? It would also be good to make this not specific to the bladeRF, and allow passing in an osmosdr device string as a parameter. Same thing with a parameter to allow specifying the antenna port.

This flowgraph is only designed to work with bladerf. There are two other flowgraphs, one for hackrf and one for USRP. They are all available here: https://github.com/argilo/gr-tenna

We can add those if we want to use other SDRs to ensure full compatiblity.

@dperret

dperret commented Jul 24, 2026

Copy link
Copy Markdown
Contributor

@Dollarhyde if you have the grc flowgraph for gotenna_pro_bladerf, can you add that? It would also be good to make this not specific to the bladeRF, and allow passing in an osmosdr device string as a parameter. Same thing with a parameter to allow specifying the antenna port.

This flowgraph is only designed to work with bladerf. There are two other flowgraphs, one for hackrf and one for USRP. They are all available here: https://github.com/argilo/gr-tenna

We can add those if we want to use other SDRs to ensure full compatiblity.

gr-tenna has separate flowgraphs for different SDR devices, but all of the flowgraphs currently in challengectl work with multiple device types. We should have a single flowgraph or script for multiple device types before merging it into challengectl. If the flowgraph truly can't be updated to accommodate multiple types of SDR devices (at least bladeRF, hackrf, USRP), we need to include flowgraphs for each, and logic to select the appropriate flowgraph for the device type. Updating and simplifying the flowgraph to account for these is preferred, at least for now.

@dperret

dperret commented Jul 24, 2026

Copy link
Copy Markdown
Contributor

@Dollarhyde if you have the grc flowgraph for gotenna_pro_bladerf, can you add that? It would also be good to make this not specific to the bladeRF, and allow passing in an osmosdr device string as a parameter. Same thing with a parameter to allow specifying the antenna port.

This flowgraph is only designed to work with bladerf. There are two other flowgraphs, one for hackrf and one for USRP. They are all available here: https://github.com/argilo/gr-tenna
We can add those if we want to use other SDRs to ensure full compatiblity.

gr-tenna has separate flowgraphs for different SDR devices, but all of the flowgraphs currently in challengectl work with multiple device types. We should have a single flowgraph or script for multiple device types before merging it into challengectl. If the flowgraph truly can't be updated to accommodate multiple types of SDR devices (at least bladeRF, hackrf, USRP), we need to include flowgraphs for each, and logic to select the appropriate flowgraph for the device type. Updating and simplifying the flowgraph to account for these is preferred, at least for now.

The gotenna_pro_tx_bladerf.grc flowgraph in gr-tenna uses an osmocom sink with a static device string of "bladerf=0,biastee=1". Updating this flowgraph to add a deviceargs parameter, which then gets passed in to the osmocom sink's device arguments, is likely enough to make this work with all 3 of the main device types. We should also include the .grc in addition to the corresponding .py for the challenge in challengectl.

@ZeroChaos-

Copy link
Copy Markdown
Member

CI has been updated and passes. I'm leaving this to @dperret to approve though, because I know much less about how this works.

Comment on lines +331 to +338
def sig_handler(sig=None, frame=None):
tb.stop()
tb.wait()

sys.exit(0)

signal.signal(signal.SIGINT, sig_handler)
signal.signal(signal.SIGTERM, sig_handler)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These lines need to be commented out or removed so that the device can be released.

Comment on lines +307 to +314
def sig_handler(sig=None, frame=None):
tb.stop()
tb.wait()

sys.exit(0)

signal.signal(signal.SIGINT, sig_handler)
signal.signal(signal.SIGTERM, sig_handler)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These lines need to be commented out or removed so that the device can be released.

@dperret
dperret changed the base branch from master to gotenna-pro-challenge July 28, 2026 03:16
@dperret
dperret merged commit 79c2bc2 into rfhs:gotenna-pro-challenge Jul 28, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants