-
Notifications
You must be signed in to change notification settings - Fork 96
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
Question about adding support for new SDRs #20
Comments
It is currently relying on SoapySDR for all receivers. However, for
specific devices (like AirSpy) I offer something called "gain presets" that
allow you to set many gains at once using a single slider, based on fixed
gain tables that are copied to /usr/local/share/suscan. These tables are
plain XML and hence easy to edit.
Note these tables are simply data files I wrote based on what I know about
the behavior of specific device models, so you don't have to bother setting
the gains manually. They are practical, but not required.
Regarding the test criteria, for now it's okay if you simply see the
waterfall and can browse the spectrum by setting the frecuency while the
radio is running. Channel inspection is absolutely device-independent, so
it will not be necessary to test it explicitly.
Thanks!
El mié., 2 oct. 2019 17:06, Mehdi <[email protected]> escribió:
… Hey @BatchDrake <https://github.com/BatchDrake>
Is SigDigger fully relying on SoapySDR or you also have to add
device-specific configurations to the code?
In a comment to issue #12
<#12> you said
For AirSpy (and hopefully more radios in the future) there are gain
presets that allow you ...
And I wondered what you mean by hopefully more radios in future? Because
in another comment you've said
... in the end, SigDigger just wraps around SoapySDR in order to detect
SDR devices.
I have access to some other SDRs like different SDRPlays and LimeSDR and I
can help in testing, but your comment made me wonder if you have to do some
changes in the code.
Can we define a simple test criteria as: if you can open a device in
SigDigger and observe the spectrum/waterfall and also open some inspector
tabs without any issues, then the test is successful for that SDR?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#20?email_source=notifications&email_token=AAEVET624A3L3EXMU3QVIXLQMS2HNA5CNFSM4I4XTY52YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HPFBPEA>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEVETZ3BZRF3REVJUFCKMTQMS2HNANCNFSM4I4XTY5Q>
.
|
Ok I tested it with different SDRs and the app worked with everything that has a SoapySDR binding. Here are the devices I tested:
There's a problem with antenna selection in RSP2 ( choosing "Antenna B" doesn't change anything and still Antenna A is the main one, but I think it's a SoapySDRPlay problem) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hey @BatchDrake
Is SigDigger fully relying on SoapySDR or you also have to add device-specific configurations to the code?
In a comment to issue #12 you said
And I wondered what you mean by hopefully more radios in future? Because in another comment you've said
I have access to some other SDRs like different SDRPlays and LimeSDR and I can help in testing, but your comment made me wonder if you have to do some changes in the code.
Can we define a simple test criteria as: if you can open a device in SigDigger and observe the spectrum/waterfall and also open some inspector tabs without any issues, then the test is successful for that SDR?
The text was updated successfully, but these errors were encountered: