Why not do the converse, exempt a receiver from scanning, program the websocket interface to support using a receiver for I/Q-spectrum, with Cat Control. Then another SparkSDR, Quisk, LinHPSDR, PowerSDR/Thetis, piHPSDR, SDR Console could use that receiver or two for access to the RF.
I am running the last known OSX version of SparkSDR v2.0.4.3 as a scanner with 10 receivers on an i5 ethernet connected MacMini which runs nicely. 23K spots a day monitoring with gateware 72P on hardware build HL2B9. Previous gateware would fail after a few hours.
Simon either already has, or will have a network interface to SDRconsole. It would be really cool if Spark either could connect to SDRconsole or the other way around.
It will be interesting to see what Jim Ahlstrom N2ADR Quisk, Alan Hooper M0NNB SparkSDR, Matthew Balmer M5EVT LinHPSDR, Reid Campbell Gi8TME/Mi0BOT PowerSDR/Thetis, Christoph v Wullen DL1YCF piHPSDR, Simon Brown G4ELI SDR Concole, Jim Ancona N1ADJ openwebrx, and others have to say.
..jpw J P Watters
KC9KKO
Morris, IL USA
Hi jpw,
All you suggest should be possible, the thought for skimmer server is that spark is the master and talks to the radio, an alternative skimmer server dll then connects to spark rather than to the radio and is given virtual receivers that share hw receivers with spark and anything else connected.
My idea for the websocket interface is to cover everything that is traditionally done by cat, vac and logging interfaces plus client/server stuff.
The protocol design is very much a prototype and will be evolved as real uses are explored, there is nothing to stop others adopting it or adding to it.
the current things shaping the design are :-
I'm working on spark connecting to spark,
I'll post a 2.0.4.8 osx version shortly,
73 Alan M0NNB