refactoring with desperado

[xoolive]

This PR is similar to the effort made in xoolive/ship162#17

So now, we have three different features: rtlsdr, soapy and pluto.

The main part left to deal with would be the support of configuration parameters:

• as cli arguments (see refactoring with desperado ship162#17 (review))
• as options in the toml config file

I see following patterns:

• rtlsdr:// (now means device_id equal 0, but that should be the first available one, in Windows it is often device_id 1)
• rtlsdr://device_id=0
• rtlsdr://manufacturer=...&serial=...
  (see ccostes/rtl-sdr-rs@c787722 in feat: device enumeration and sensor API ccostes/rtl-sdr-rs#26)
• soapy://serial=... (similar to rtlsdr)
• pluto://ip:192.168.2.1, (pluto://ip:pluto.local) or pluto://usb:1.27.5,
  note that this is not valid url syntax, maybe consider plutoip:// and plutousb://

with in the configuration file:

[[sources.rtlsdr]]
device = 0
gain = 49.6

[[sources.soapy]]
manufacturer = ...
sample_rate = 2_400_000

Note that in the specific case of rtlsdr, it doesn't make sense to have a lower gain, at least for ADS-B

This edit should be the same in ship162, so maybe there's a way to factorize it in desperado. We have the specific config structures like this one that could be made serializable, although:

• that's probably not the best option since the expected options are slightly different.
• the option of a config.rs in desperado could contain the proper struct with From/Into traits implemented could make sense
• but default values for center_freq need to be different across projects.

Other open questions/work:

• Should we make the rtlsdr feature default? It's a pure Rust crate after all, although rtl-sdr-rs depends on libusb in the end.
• The jet1090 release process should include it anyway, that would simplify installation in Windows
• soapy makes sense because it's generic to support many SDR types; I think the point behind other features would be to support more SDR types with full Rust implementations (so that things just work without any extra dependencies), which is not the case for Pluto now, depending on libiio.

cc @abc8747

[abc8747]

• Can we unify the representation of gain as enum { Auto, Manual(f64) } in desperado and set a consistent default? Right now:

  source	desperado dtype	jet1090 default	ship162 default
  rtlsdr	Option<i32>	49.6, cast to Some(i32) later	None, should be made configurable, see refactoring with desperado ship162#17 (review)
  soapy	Option<f64>	Some(49.6)	Some(40.0)
  pluto	f64	50.0	20.0

• expanduser in jet1090 and ship162 should use desperado::iqread::expanduser (maybe move it to desperado::utils or just the top level)

• jet1090/src/source.rs populates config structs immediately, ship162/src/sources/mod.rs stores raw strings and configures later. The Address enums are also duplicated, can we centralise URL parsing in desperado, perhaps impl FromStr for DeviceConfig so it parses rtlsdr:// etc. into a unified config enum?

• In desperado, should bias tee be made configurable? right now it is hardcoded to be false

• re whether to keep rtlsdr feature on: tangram_ship162 depends directly on rs162 to deserialise the JSON, so it would be nice if rtlsdr feature is off-by-default. But I am perfectly happy with on-by-default and setting default-features = false in tangram_ship162

[xoolive]

Thanks, I agree with all the comments though they mostly refer to desperado here.

Just a point of attention: Gain in i32 is multiplied by 10 for rtlsdr: Some(496) is for a gain of 49.6 (the max value)

Then, this max value should be default in jet1090 + ship162

Let's do that when we can

[xoolive]

@abc8747 I think this current state is not too bad, any further comment?
Otherwise I will merge soon

[xoolive]

@abc8747 I merged, easier to move on, but just comment if needed and we can open issues

[abc8747]

Sure I will take a look at it later today

[abc8747]

@xoolive I've just tested and it works well, just a minor point:

fb9bb79#diff-c914f1f4fdad905d05b49772bb8a20de37a17f0e7f81e90fe0f5599034e3ac6bL118-L122 removed the --discover option but the docs still reference it:

jet1090/docs/sources.md

Lines 13 to 24 in 77b7193

	You can check whether `jet1090` detects your dongle:
	```sh
	$ jet1090 --discover=rtlsdr
	Detached kernel driver
	Found Rafael Micro R820T tuner
	Reattached kernel driver
	[INFO] Opening Generic RTL2832U OEM :: 00000001...
	Detached kernel driver
	Found Rafael Micro R820T tuner
	Reattached kernel driver
	```