Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Error] Could not find a handler for Airspy #1081

Open
b3rtdb opened this issue Dec 13, 2024 · 1 comment
Open

[Error] Could not find a handler for Airspy #1081

b3rtdb opened this issue Dec 13, 2024 · 1 comment

Comments

@b3rtdb
Copy link
Contributor

b3rtdb commented Dec 13, 2024

Describe the bug
I use an Airspy HF+ Dual port, the Serial number is detected by satdump.
However, in the logs, it states it cannot find a handler for source type; Airspy

Screenshots and/or logs
[07:14:00 - 13/12/2024] ^[[32m(I) 72 TLEs loaded!^[[m
[07:14:00 - 13/12/2024] ^[[36m(D) Device AirSpyHF 3652975d94bf3ff7^[[m
[07:14:00 - 13/12/2024] ^[[36m(D) Device File Source^[[m
[07:14:00 - 13/12/2024] ^[[36m(D) Device Network Source^[[m
[07:14:00 - 13/12/2024] ^[[36m(D) Device RTL-TCP^[[m
[07:14:00 - 13/12/2024] ^[[36m(D) Device SDR++ Server^[[m
[07:14:00 - 13/12/2024] ^[[36m(D) Device SpyServer^[[m
[07:14:00 - 13/12/2024] ^[[31m^[[1m(E) Could not find a handler for source type : airspy!^[[m

Running on a raspberry pi 3B with latest version of Bookworm installed
Server information (please complete the following information):

  • OS: Bookworm
  • Python version: Python 3.11.2 (main, Sep 14 2024, 03:00:30) [GCC 12.2.0]
  • SDR device: Airspy HF+ Dual Port

Is the dual port also supported?
I've seen in the scripts there are several types of Airspy mentioned, the only difference is the sample rate. The receiver type is set to airspy, but satdump makes a difference between airspy and airspyhf, can that mean anything?

running:
admin@piwesat:~ $ satdump sdr_probe
[13:19:04 - 13/12/2024] (I) Found devices (sources) :
[13:19:04 - 13/12/2024] (I) - AirSpyHF 3652975d94bf3ff7
[13:19:04 - 13/12/2024] (D) - type : airspyhf
[13:19:04 - 13/12/2024] (D) - id : 3914357454321696759
[13:19:04 - 13/12/2024] (I) - File Source
[13:19:04 - 13/12/2024] (D) - type : file
[13:19:04 - 13/12/2024] (D) - id : 0
[13:19:04 - 13/12/2024] (I) - Network Source
[13:19:04 - 13/12/2024] (D) - type : net_source
[13:19:04 - 13/12/2024] (D) - id : 0
[13:19:04 - 13/12/2024] (I) - RTL-TCP
[13:19:04 - 13/12/2024] (D) - type : rtltcp
[13:19:04 - 13/12/2024] (D) - id : 0
[13:19:04 - 13/12/2024] (I) - SDR++ Server
[13:19:04 - 13/12/2024] (D) - type : sdrpp_server
[13:19:04 - 13/12/2024] (D) - id : 0
[13:19:04 - 13/12/2024] (I) - SpyServer
[13:19:04 - 13/12/2024] (D) - type : spyserver
[13:19:04 - 13/12/2024] (D) - id : 0
[13:19:04 - 13/12/2024] (I) Found devices (sinks) :
[13:19:04 - 13/12/2024] (I) Done! Goodbye

Should I use the mentioned ID from the fond sources?

@b3rtdb
Copy link
Contributor Author

b3rtdb commented Dec 15, 2024

changed the receiver scripts to airspyhf instead of airspy.
I can confirm it is working now.
Is it possible to change this small bug?

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

No branches or pull requests

1 participant