Retrieving receiver mode over cat

[David Ricciardi]

When using the `m` and `M` commands to set and retrieve the current receiver mode I can set this to any mode that SparkSDR supports like `FT8` etc and it works fine, but if i retrieve the current mode it will return `USB` for example when running as DigiU.  I assume this is so 3rd party applications don't freak out with some unsupported mode.  Would it be possible though to get a new command that would return the actual mode SparkSDR is in?

Also seeing additional SparkSDR specific commands would be nice going forward.  Being able to list/add/remove receivers via CAT/or some kind of API would be super handy. Would also like to get access to data like power/swr/temps.

[Alan Hopper]

Hi David,

yep I return usb for some modes to keep wsjtx and fldigi happy, I'm not sure if they really mind but I was being cautious.  The cat has not been developed much beyond supporting the common digimode programs.  I made cat a 'per virtual transceiver' thing as most other programs have no concept of multiple receivers and radios from one source and to allow multiple instances to connect. I could add a master cat that gave access to the bigger picture but am more tempted to create a more general remote option. I have an architecture sketched out to allow networked copies of spark to share radios and receivers between each other (control and iq data), that could also be used by other sw.  What are you wanting to do, maybe I can start the remote stuff gently to fit your project.

73 Alan M0NNB

[David Ricciardi]

Currently I have just dipped my toes in a little bit and wrote a small tool to allow me to switch all my receivers to different bands based on the time of day (https://github.com/nricciar/rigcycle).  SparkSDR already has pretty much everything I need to support this, but the one thing I would like for this tool though would be the ability for it to spin up its own receivers instead of requiring a user to setup each receiver before hand.

My other project is a bit more ambitious but not much to show for it yet. Was thinking about a lightweight web interface to control SparkSDR remotely. Ability to manage the receivers, and potentially push the audio in/out over a websocket as well.

[Alan Hopper]

Hi David,

That's neat, I know Steve was after something like that, did you know you can start up a profile from the command line in spark, that might give you other options for now.  I'll look to see if I can make the rigcntrld stuff work a bit better for you but don't want to deviate from the spec for that, I've already been told off by the wsjt-x devs for using it at all and keeping them on side is important.  

Part of my wish list for remoting was a web interface, I'd like a receiver on my smartwatch and that is probably the simplest way.  I'm keen to help you get that working. I have a long standing hatred of serial based cat and virtual audio cables for sdr, the multipsk interface was a step in the right direction as it coped with iq and control but until yesterday I'd had had no interest in it so it is unfinished.  Have you any thoughts on your ideal solution to this?

Great to see a bit of software written to talk to spark, that has made my day

73 Alan M0NNB

[David Ricciardi]

I think a pretty nice solution would be to add a websocket port to SparkSDR that served a similar purpose to the CAT port but on a higher level.  At the most basic level you could use this interface to send commands and get responses, hopefully in a format better than the serial protocol (json would be nice here i think).  I would also like to see support for events either automatic or requested (being able to request SparkSDR to send you frequency updates as the receiver frequency changes, or swr/power while transmitting)

(pseudo commands, what they look like doesn't really matter)

>> { "command": "getFrequency"}

<< { "frequency": 3573000 }

>> { "watch": ["swr","power","frequency"] }

<< { "frequency": 7074000 } // when frequency changes

<< { "swr": 1.50 } // updates every X period while transmitting

Being able to send audio/iq? tx/rx data over a websocket would be pretty slick as well.  If SparkSDR could do all this natively it would make writing a web interface around it pretty easy.

[Alan Hopper]

Hi David,

that all makes sense to me. I'd definitely want to use something self describing like json. I'll have a ponder and start adding it as an experimental feature so we can knock something into shape without worrying about backwards compatibility.  Nothing beats a prototype to find out what you really want.

73 Alan M0NNB

[David Ricciardi]

So I had some time to play with this some more over the weekend, and I have a little proof of concept demo app running to control the SparkSDR receivers.  I had some time to think a little bit more of what the websocket protocol would look like, and with some trial and error this is what I have been using.

Made it with the idea in mind that you should not need the original request to act on any replies from the server.  Its still probably very far from perfect, but so far its been working pretty well.

```

Connected to wss://rig.kk4wjs.com/ws
<< {"cmd":"getReceivers","receiver":null}
>> {"receiver":null,"response":{"ReceiverList":[{"id":0,"frequency":3573000,"mode":"FT8"},{"id":1,"frequency":7074000,"mode":"FT8"},{"id":2,"frequency":14074000,"mode":"FT8"},{"id":3,"frequency":10140000,"mode":"FT8"},{"id":4,"frequency":3580000,"mode":"PSK"},{"id":5,"frequency":7070000,"mode":"PSK"},{"id":6,"frequency":14070000,"mode":"PSK"},{"id":7,"frequency":10141000,"mode":"PSK"},{"id":8,"frequency":3575000,"mode":"FT4"},{"id":9,"frequency":7047500,"mode":"FT4"},{"id":10,"frequency":14080000,"mode":"FT4"},{"id":11,"frequency":10140000,"mode":"FT4"}]}}
<< {"cmd":{"setFrequency":7069000},"receiver":5}
>> {"receiver":5,"response":{"FrequencyResponse":{"frequency":7069000,"vfo":""}}}
<< {"cmd":{"setFrequency":7070000},"receiver":5}
>> {"receiver":5,"response":{"FrequencyResponse":{"frequency":7070000,"vfo":""}}}
<< {"cmd":{"setMode":"NFM"},"receiver":5}
>> {"receiver":5,"response":{"ModeResponse":{"mode":"NFM","width":16000}}}
<< {"cmd":{"setMode":"PSK"},"receiver":5}
>> {"receiver":5,"response":{"ModeResponse":{"mode":"PSK","width":3000}}}
```

The code for this can be found in the v0.3 release of rigcycle at https://github.com/nricciar/rigcycle `rigcycle ws 1234` if you want to run a websocket service on localhost. 

There is also a working demo of using this through a public webservice as well.  You could for example run `rigcycle proxy /path/to/my/lotw/cert.p12` which will then forward authenticated websocket traffic from https://rig.kk4wjs.com/ws to your SparkSDR.  Authentication is also handled by your LoTW certificate in the browser and there is a very simple UI at https://rig.kk4wjs.com you can then use to control SparkSDR remotely.

My next goal is to try and get audio from portaudio through a binary channel in the websocket.

[Alan Hopper]

Hi David,

this is looking like a good start. I've been giving it some thought and have started to put the server core in, I'll try and recreate your protocol and we can take it form there.

We need to consider that Spark can have multiple radios and any or all can run at once each with any number of virtual receivers.

There could be cases where the controlling program is on the same computer and there is a single user who expects the user interface of Spark to change, i.e when you add a reciever it should appear on the screen, your initial use case I guess.

There are other uses like web sdr or remote/shared access where multiple clients could connect and want iq, audio or spectrum data, in this case you probably don't want them to pop up in the server spark ui.  Part of my plan is for Spark to be able to connect to another copy of spark and allow sharing of radios.

So maybe there could be two levels of access, one just gives you access to the receivers you create and another that gives everything.

I can give the radios persistant ids (already used for saving profiles) so scripts can get the radio they want.

For Identifying receivers we might have to think how best to deal with the ids as they are added and removed, maybe just a simple incrementing number but I think they need to be treated as keys and not indexes.

73 Alan M0NNB

[David Ricciardi]

One improvement might be to use Guids for receiver ids instead. That way they are pretty much guaranteed to be unique even across multiple SparkSDR instances.

[ahop...@googlemail.com]

Hi David,

I finally got round to this, there is a test version here http://www.ihopper.org/radio/download.aspx?file=SparkSDR2_0_3_7_win64.zip just to see if I'm going in the right direction, it only has a get receivers command for now.  There is a test webpage that shows the response.

73 Alan M0NNB

[David Ricciardi]

Is there a linux build for this test version? I don't have a windows machine I can test this with atm, but I definitely would like to give it a spin.

[ahop...@googlemail.com]

Hi David,

I'll set a linux build going :)

73 Alan M0NNB

[ahop...@googlemail.com]

David,

http://www.ihopper.org/radio/download.aspx?file=SparkSDR.2.0.3-7.linux-x64.deb

[David Ricciardi]

Cool, thanks for the linux build, was able to update and run your websocket example without any issues.  Looks like I could almost drop it in as a direct replacement for what I was using which is certainly nice (for me at least :) )

If your looking for potential suggestions on what to add next and sticking with just the concepts already exposed here in your example [receivers,mode,frequency] id like to see this example expanded to the following:

1) commands to set frequency/mode of a receiver

2) commands to add/remove receivers

3) real time updates for frequency/mode changes. { "cmd": "frequencyResponse", "receiverId": "uuid", "response": { "frequency": 3573000 } } or something similar.

After those though the options are virtually limitless, ptt, audio in/out over websocket, data modes [FT8 over websocket :)]...  I certainly look forward to seeing where this goes.

[David Ricciardi]

So I started a little demo project on github using the new websocket interface.  Its not much but it it uses the getReceivers command to create a list of html receivers in the browser. https://github.com/nricciar/sparksdr-websocket-demo.  There is also a compiled demo of the code hosted at https://nricciar.github.io/sparksdr-websocket-demo/index.html this, like your example, expects sparksdr to be running on localhost:4649.

The only issue I had with the current implementation is the frequency being represented as a "float" and deserialization but i was able to work around it.

[ahop...@googlemail.com]

Hi David,

that's neat. I've put a new version here http://www.ihopper.org/radio/download.aspx?file=SparkSDR.2.0.3-8.linux-x64.deb it allows getting receivers, radios, setting mode and frequency and adding receivers. There is also a version command and a first cut at subscribing to digimode spots.  This is very much a prototype to work out what we really want so I'm open to all changes and also might change stuff. Let me know what would be most useful to you as you can't beat a real application to help define this sort of thing.  It should not be too hard to get a waterfall and audio feed going and then we have a web client.

73 Alan M0NNB

[Steve, G4GXL]

Awesome stuff :-)

I don't know if it's just me, but I sometimes reset the decode counts on receivers to get a quick view on which bands are currently active.
Would it be possible to reset all of those counts and interrogate the value for each receiver ?
Then maybe close a receiver or assign it to a new band when activity is low (rather than at a preset time).

The ability to check the EP6 count would also be useful - then maybe shut down the receiver with lowest activity if EP6 count is climbing.
Again, might not be of interest to most people but I am currently having intermittent problems with lost packets so tend to keep an eye on it.

73
Steve, G4GXL

--
You received this message because you are subscribed to the Google Groups "SparkSDR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sparksdr+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sparksdr/518dd6a3-4666-4744-92f8-27ab0d44c12en%40googlegroups.com.

[ahop...@googlemail.com]

Hi Steve and group,

the possibilities appear to be endless:) I'm pondering some automatic code generation to allow access to almost everything (and auto documentation) so that would allow what you want. I want to keep the protocol/api  easy to use so it would be good to get some examples working in other languages but so far js, c# and rust seem ok. 

I also have plans for better stats on spots within Spark, I've been promising Sven this for years.

73 Alan M0NNB

[ahop...@googlemail.com]

Hi Steve,

that got me thinking, I could host a web browser within spark and people could load any html based plugin that would have access to the api.

73 Alan M0NNB

[Matthew]

Hi all,

This is very interesting stuff. As Alan says, endless possibilities.

With telnet type access, most (good) logging programs can then do filtering/alerts on telnet spots (LoTW user, needed DXCC, band slot, contest multiplier etc.). I do feel, much like serial ports, the ham community needs to move on from telnet. But as Andy points out in the other thread, there is so much existing software with great functionality that uses this.

As well with most logging software you can then click on a spot and it can take you to that frequency. SparkSDR would probably need to handle this command in a special way to change the tx audio and not the RF tx freq? I suspect N1MM integration with WSJT-X for FT4 must do something similar?

Great to read these sort of discussions and then see the prototypes appear.

73 Matthew M5EVT.

[David Ricciardi]

Updated my demo to include i think every new command except the spot stuff (have some ideas for that, but the code will take longer). https://nricciar.github.io/sparksdr-websocket-demo/index.html

Currently the only issue I think is the lack of feedback from the addReceiver command, no straightforward way to update the ui with the new receiver.  The commands so far though seem perfectly usable. I think with whats implemented now I could completely rewrite my rigcycle tool to use this websocket interface instead of the rigctl.

One thing I might change about the getRadios response is to include IP/mac as separate keys.

[ahop...@googlemail.com]

Hi David,

much nicer than my test page:)

Good to see mode works , I had not tested that.

We could certainly add a respose to addReceiver, it would probably have to be delayed as this happens asynchronously in spark i.e the ui fires an addreceiver and some time later gets an event saying it has been created but this would be invisible to the remote client. You could poll getReceivers in the very short term, it is possible that a getReceivers directly after an addReceiver would not detect the new receiver.

I  just put the minimum into getRadios for now as it was needed for addReceiver, in the long run it should provide far more info, I also keep meaning to add a user setable friendly name for each radio. Spark is designed to work with more than hpsdr radios so we also need to allow for that.

The spot format will certainly change, I just serialized the internal format for a quick prototype.

Matthew,

I'm aware logging is a very weak area in Spark, hopefully this might help either with adapter programs in the middle, or convincing logging programs to move on or by simply reusing some of this code/hooks to implement  other protocols.

All

I think it is worth pointing out that the use of websockets does not limit this to access from web apps/pages.

73 Alan M0NNB

[ahop...@googlemail.com]

I've just put a win 64 version here http://www.ihopper.org/radio/download.aspx?file=SparkSDR2_0_3_8_win64.zip in case anyone wants to experiment.

73 Alan M0NNB

[Mark Wild]

This is pretty cool :-)

BTW, command window stays open in this win 64 version for me.

73 Mark G6DDX

[J P Watters]

Alan,

Greetings, A wish that you, your friends and family are doing in well in these times. 

Using SparkSDR is cool, just so you know, maybe we can tell a few friends. :)

Is it possible to generate a OSX version that I could tinker with. The idea of tinkering with CAT control of receivers is so cool.

I think running a html page on my iPad would be cool, especially if a tap of the screen could do things.  I really like the idea of changing the bands based on time of day. 

I have yet to get JTDX to run connected to one of my HL2's for FT8 QSO's. One day....or maybe SparkSDR evolves with some of the JTDX features, like AutoSEQ

The other thing on my ToDo List is to figure out the better, or best way to couple a pair of HL2's one with the 10rx gateware and the other with the standard 4rx (and is TX capable ) gateware to make a better FT8 Machine. 

[ahop...@googlemail.com]

Hi jpw,

there is a completely untested mac build here http://www.ihopper.org/radio/download.aspx?file=SparkSDR2_0_3_8_osx.app.tar.gz

73 Alan M0NNB

[David Ricciardi]

I moved the demo I've been working on to https://rig.kk4wjs.com/spark/ so I could also host the fcc callsign database along with it to have some fun with the spot data.  For all spots in the US it will also pull in name/state, and if you have an adif log file imported it will also show if the country/state has been worked before. It's all pretty basic atm and very incomplete, but it was fun to put together.

For the adif log file stuff its all client side and no log file is uploaded anywhere for those that care about such things.

[J P Watters]

Definately REALLY COOL. It works

I loaded the OSX version 2.0.3.8 on a mac mini running Catalina, Installed MAMP to get web service. 

installed the sparkservetest.htm 

..jpw J P Watters

KC9KKO

Morris, IL USA

[ahop...@googlemail.com]

Hi David,

very nice, I like the country/state bit, is there a good data source to do this for the world? I'm going to spend a little while looking at sending audio and waterfall data and will then get back to adding all the other settings.

jpw,

interesting that you used MAMP, on windows I can just open the .htm locally in chrome and it runs, I sometimes have to refresh once as I think I have a bug in the server.

73 Alan M0NNB

[J P Watters]

Alan,

I used MAMP on my Mac Mini so that I could edit the "sparkservetest.htm" and access it from my iPad.

With running Apache and MySQL I might be able to do some cool things. I would like to log the "Spots" and analyze the bands, time of day and direction from the receiver. If I can get my second antenna hung before the weather sets in for the winter, I can start tinkering with beam forming. 

--
You received this message because you are subscribed to a topic in the Google Groups "SparkSDR" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sparksdr/zCPYaqpSyvE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sparksdr+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sparksdr/dee9ffc8-8e82-49d6-8352-c32c459a0a21n%40googlegroups.com.

[ahop...@googlemail.com]

Hi jpw,

cool, you are ahead of me, I've not actually tried connecting from another device. There might be a case to allow Spark to respond to http and serve up html.

73 Alan M0NNB

[J P Watters]

Alan,

I guess I only thought I posted this. 

Edited "sparkservetest.htm"

<html>

<head>

    <script>

//        var url = "ws://localhost:4649/Spark";

//              Changed localhost to IP address of Spark

//              add later a query for to auto use IP Address

        var url = "ws://10.0.1.185:4649/Spark";

        

        var output;

..jpw J P Watters

KC9KKO

Morris, IL USA

[David Ricciardi]

Getting country can be done using only the callsign, although its basically a big giant if statement.  My implementation is only partial atm as I have only added a small section of the ITU reservations so far https://github.com/nricciar/ham-rs/blob/pre-release/src/countries.rs#L191 been working from this list https://en.wikipedia.org/wiki/ITU_prefix.

As far as other data sources for callsigns/the rest of the world... There is qrz's api and probably others, but these have issues in qrz's instance you will probably need a paid subscription :(  Perhaps other countries publish callsign lists like the FCC does, but that's only a partial solution i suspect as its probably not all that common.

[AndyZ K1RA]

Regarding country tracking, another useful country tracking file used by many logging programs can be found here

https://www.country-files.com/big-cty/ 

You can read more about its format here

https://www.country-files.com/cty-dat-format/

I have used this file for scoring countries in the Virginia QSO Party with a PERL script I threw together for parsing that text file into the various and numerous prefixes that are associated with each country name.

You can get the latest ZIP files holding this country/prefix info here

http://www.country-files.com/category/big-cty/

73

andyz - K1RA

[ahop...@googlemail.com]

Hi all websocket users,

there are new test versions here 

http://www.ihopper.org/radio/download.aspx?file=SparkSDR2_0_4_2_win64.zip

http://www.ihopper.org/radio/download.aspx?file=SparkSDR.2.0.4-2.linux-x64.deb

http://www.ihopper.org/radio/download.aspx?file=SparkSDR2_0_4_2_osx.app.tar.gz

and test page/documentation http://www.ihopper.org/radio/sparkservetest.htm

This allows starting and stopping radios, removing recevers(except last per radio) and changes to radios, receivers, mode and frequency are fed back. wspr should be reported, spots that fail the internal filter have a blank call and frequency for spot is absolute
73 Alan M0NNB

[David Ricciardi]

Everything seems to work well with the new version, I very much like that i don't have to poll for receiver updates any longer.  I did notice one small casing issue though with `ReceiverResponse` all other commands start lower cased except this one, does not affect implementation really, but it probably should be kept uniform no matter which way you decide to go.

I updated my demo script at https://rig.kk4wjs.com/spark/ to use these new commands, and also added a few more features here and there (can specify sparksdr hostname to connect to, additional spot filtering).  I also started playing around a bit with the WebAudio browser support and the client code will now attempt to decode/play any binary audio data sent over the websocket connection.  This support is still pretty broken though as there is no buffering of the incoming data, nor sequencing.

[ahop...@googlemail.com]

Hi David,

yep the internal coding standard uses upper case starts for classes and properties and that one leaked out, from my perspective it is simpler to do that for everything but I'm happy either way. I also wonder if 'cmd' should be 'Type' . I'll try to do any changes like this all at once with the next significant addition to minimise the pain to other's code.

I've started on the other end of the audio, what format are you expecting?

I have wondered if this can be made to work with openwebrx as a client and was going to look at the audio there.

73 Alan M0NNB

[David Ricciardi]

Currently I am just using the built in decodeAudioData provided by the WebAudio apis: https://developer.mozilla.org/en-US/docs/Web/API/BaseAudioContext/decodeAudioData  which seems to support at least most of the common audio formats (wav,mp3,etc).  My mostly broken implementation can be found https://github.com/nricciar/sparksdr-websocket-demo/blob/master/src/model.rs#L430-L504.  Currently the biggest problem is getting the chunks of audio data to play one after another in sequence. 

Looking at openwebrx makes a lot of sense though, no point in re-inventing the wheel.   I just briefly looked at a openwebrx instance in the browser and it looks like they are sending chunked audio data over a 2nd websocket connection (curious why they don't use the primary websocket connection here) so it might be similar to what I was attempting anyways.

[ahop...@googlemail.com]

Hi David,

so each chunk of audio data needs to be formated as a complete audio file I guess. I found one example that told the web audio library when it wanted the sample played like this

 let audioContext = window.AudioContext || window.webkitAudioContext;

       

        var startTime;

        let count = 0;

        function newAudioData(event) {

            if (count == 0) {

                startTime = audioContext.currentTime;

            }

            audioContext.decodeAudioData(event.data, function (data) {

                count++; // Keep a count of how many messages have been received

                var playTime = startTime + (count * 0.2) //Play each at file 200ms

                playSound(data, playTime); //call the function to play the sample at the appropriate time

            });

        }

        function playSound(buffer, playTime) {

            var source = audioContext.createBufferSource(); 

            source.buffer = buffer;

            source.start(playTime); 

            source.connect(audioContext.destination); 

        }

[David Ricciardi]

Yea to use decodeAudioData it needs to be a complete audio file, but I have seen at least one example of putting raw samples right into the buffer though so I don't think audio files are strictly necessary.   That example you have looks simple enough though hopefully I will get some free time this week to experiment with it.

[ahop...@googlemail.com]

Hi David,

this http://www.ihopper.org/radio/download.aspx?file=SparkSDR.2.0.4-4.linux-x64.deb has a first attempt at sending audio, I've updated the test page on the server. It is far from perfect and I suspect the way the test page uses the audio is not the right way to go but it basically works with the odd click.  At the moment I don't identify the receiver that the audio comes from, I'm pondereing dropping the guids and using an int that simply increments on creating receivers. The audio is currently 512 samples of 16bit 48k mono in a .wav, we probably want to allow asking for different bandwidth and encoding.

This now means a didgimode program could connect to spark, ask for a receiver and decode audio without touching spark or using vac or virtual serial cables.

My plan is to add spectrum and IQ feeds and then think about how to do it properly :)

If anyone wants a test build for a different platform just shout.

73 Alan M0NNB

[David Ricciardi]

This is super cool.  Your test page seems to work very well.  I ran into some issues trying to implement the same thing in my demo code currently, but I suspect I just have a weird race condition or something going on, it worked fine with larger chunks sent from my test ws server, but the smaller chunks sent by SparkSDR seem to give it trouble.  Think my rust inexperience is finally catching up to me :)

For waterfall you could use webaudio's analyser support.  I was playing around with https://bl.ocks.org/d3noob/6760590814296b89574a8999309204b4 a bit today  which looks like a good starting point.  Although using this, the bandwidth would be limited to the current audio, not sure if you were looking to provide a wider view like in SparkSDR or not.

Either way, kudos on all the work, its really starting to turn into something cool i think.

[ahop...@googlemail.com]

Hi David,

 The chunk sizes are rather small, we probably need a setting for preffered chunk size as well as bandwidth and encoding.

This http://www.ihopper.org/radio/download.aspx?file=SparkSDR.2.0.4-5.linux-x64.deb has an option to subscribe to spectrum data and uses the code from your link for the waterfall. I've also switched to ints for the ids and include it in the audio and spectrum data.

My next step is to let spark connect to another spark.

73 Alan M0NNB

[David Ricciardi]

Updated https://rig.kk4wjs.com/spark/ with the changes in 2.0.4-5 and also got audio mostly working I think.  The audio can be a bit glitchy though with ui updates/incoming spots/etc so its certainly not perfect... I think maybe buffering a few incoming audio chunks before playing may help with that though.

Using SparkSDR as a client for another SparkSDR sounds pretty cool, also along those lines I think it would be nice to have a headless mode as well for SparkSDR.  Run a SparkSDR server in headless mode on a server somewhere, and connect to it via another SparkSDR or web client.

Looking forward to getting that spectrum api integrated as well as that will make a mostly complete (or maybe i should say usable) receiver demo.

[ahop...@googlemail.com]

Hi David,

just had a play and see you have the spectrum going, very nice, it makes my test harness look like a test harness:)

Lots of things to think about on the server side, for the case of a single user wanting to remotly access their radio there probably need to be different options to the use as a multi user websdr. In the multi user use things like stopping radios probably need to be blocked and some limits on the number of virtual receivers, also you should probably only see receivers that you create. Maybe some sort of login to get to some options ( including tx ).

I must try installing a browser on my watch and see if it runs there.

73 Alan M0NNB

[David Ricciardi]

Yea, I managed to get the spectrum data working mostly, but I think there are some issues still with the spectrum data.  The header data does not seem to be encoded properly in the samples.  Or at least for me the frequency start/stop are always 0.  Also I seem to only be able to retrieve the first receivers spectrum, this seems to be the case in your example script as well so I don't think its me.

Yea, having multiple levels of user privileges would make for some interesting use cases.  Like if a user could add receivers (but not be able to affect the primary receivers receive range), and remove only receivers they created, and other than that be pretty much read only that would be a nice way to be able to share access to your SparkSDR instance.

[ahop...@googlemail.com]

Hi David,

there is a bug with audio and spectrum with multiple receivers that I have fixed and will release soon, I had not got around to properly tracking which receiver on which websocket was subscribed. I think the frequency  problem is because I'm sending them little endian (view.getFloat64(5,true) fixes it in javascript), I know the tradition is to use big endian/network order but it always seems crazy to me when everywhere this is likely to run is little endian. I'm open to change on this. I don't really like the binary encoding here, you loose the advantages of json in the other packets, I had though of packing json in a string at the head of these binary packets for the meta data, on the other hand there are a lot of these packets so the binary encoding may be worth it from a performance perspective.

73 Alan M0NNB 

[David Ricciardi]

Cool, your fix did the trick for getting the frequency start/stop.  I don't mind it being encoded in the binary data, but if you wanted to move it into a json message that would work as well I think, but one thing I would do is only send the frequency start/stop data if it changes which should keep the data usage in check.

Also when it comes to spectrum/frequency data there are a few more pieces of info that would be nice to have on the UI side: receiver width, filter low/high, and maybe others I am forgetting about.  That way I can draw the current receiver onto the spectrum etc.

[ahop...@googlemail.com]

Hi David,

this http://www.ihopper.org/radio/download.aspx?file=SparkSDR.2.0.4-6.linux-x64.deb should fix the multiple receiver bugs and has filter data and an initial raw IQ feed.

73 Alan M0NNB

[David Ricciardi]

Nice, mostly works although there is still one issue with the spectrum data.  The rate the spectrum data is sent to the client seems to be determined by which receiver is currently active in the SparkSDR application itself.  The currently active receiver works fine, and every other receiver is super slow.

Started using the filter data to highlight the current receiver on the spectrum, which will also be expanded to "click to tune" as well as time permits.   Being able to "visually" tune around the dial though should be a huge help.

Also I recently put together some docs/notes on possible improvements on the current websocket api https://github.com/nricciar/sparksdr-websocket-demo/wiki/WebSocket-API.  If you would like to use all/part of that for any official documentation please feel free.

[ahop...@googlemail.com]

Hi David,

wow on the documentation, that is very impressive, thanks very much. I noticed a comment on using 'cmd' in the receiver packet, this is really to allow/ease strongly typed deserialization and a way to manage inheritance if we need to, so my plan was to have it for all compound objects.

The issue with the spectrum data is a side effect of an optimization that reduces spectrum processing on receivers not in the main big display, quite significant when skimming with many tens of receivers. I probably need to add a requested update rate to the subscribe command. I've started on the spark client mode which should force me to catch these things and flesh the missing bit out.

Thanks for all your work on this.

73 Alan M0NNB

[david.wi...@gmail.com]

This websocket protocol is interesting.

I am thinking about two things:

a)  Replace my homebrew USB/MIDI based tuning/volume/filter/PTT interface with an ESP32 using wifi and websockets.  It could be rechargeable so no wires on the desk in use, and could possibly include a small display to show a few things.

b)  Implement some sort of interface to Log4OM which I use for logging.  No idea how to do this but it sounds like it should be possible.  A bodged way of doing this would be to emulate say FT817 cat so any piece of software could interface, a better way would be to add SparkSDR websockets into rigcntrl or hamlib.

Do websocket commands exist to control PTT, volume, filter settings etc?  If so I couldn't see them in the documentation.  Some method of establishing which receiver is "on Top" ie the one that a user uses for receive/transmit in a QSO would also be needed, and I didn't see that covered either.

73

Dave M0WID

[ahop...@googlemail.com]

Hi David,

that is a very interesting idea, I wonder if it could eventually become something like this H60 Wireless Handset | B&G Sailing Electronics (bandg.com).  The last release did have filter settings and I can certainly add the other stuff. Spark internally has the concept of which receiver is the 'active' one so that is easy to expose.  I'm also looking at some form of discovery for the websocket which might save some configuration on the esp32.  

I hope we can get a good logging solution out of this, I'm not very well versed in all that people expect from logging.

73 Alan M0NNB

[david.wi...@gmail.com]

Hi Alan.  All my projects suffer greatly from feature creep so maybe!  I really just want something simple so you can control the tuning, volume, mute, nr and ptt without changing application focus on the pc.  An indication of ptt state, filter settings, nr setting and frequency on the device might be nice but not essential.  My "shack" is cramped and shares the pc with the xyl so small size is a priority.

For logging I just need the logging software to know the frequency and mode. If I used a data mode such as psk or ft8 then the calling and signal reports would be good, as happens with wsjtx and jtalert.  Other data mode software would want to control ptt and be able to set and receive frequency and mode from the active tranceiver. 

73

Dave M0WID

[david.wi...@gmail.com]

Some more thoughts on some possible commands/responses.  Not sure how/if this would work if someone had multiple instances of Spark open, not a problem I can foresee myself having though.

cmd:subscribeToActiveReceiver

Parameter Enable true/false

When subscribed Spark would advise the current active radioID, radio name, receiverID, frequency, mode, volume, filters, mute, drive, compression and PTT state whenever there was a change.

If a CAT source sets the PTT for a receiver does that becomes the active receiver?

cmd:subscribeToLogs

Parameter Enable true/false

Spark would advise the current active radioID, radio name, receiverID, frequency, mode, the QSO partners callsign and signal reports sent/received when a digimode QSO completes 

cmd:getActiveReceiver
Spark would return the current active radioID, radio name, receiverID, frequency, mode, volume, filters, mute, drive, compression and PTT state.  If a digimode the QSO partners callsign and report could be included when a QSO completes 

cmd:setActiveReceiver

Parameter would be the receiver ID to be made active.  Could optionally include other parameters: frequency, mode, volume, filter high/low (ideally adjusted for the mode so parameter of 150 becomes -150 for LSB), mute, drive, compression and PTT state

This could perhaps be more generic - cmd:setReceiver with a receiverID as parameter

cmd:setActivePTT

Parameter would be the required PTT state On or Off for the active receiver

Alternative could be cmd:setPTT with radio ID as parameter

Does this sound sensible?

Would it be better to split the setActiveReceiver command into separate commands setVolume, setFilterHigh, setFilterLow, setDrive, setCompression and so on?

73

Dave M0WID

[ahop...@googlemail.com]

Hi David,

this all makes sense to me, I need to think about some of the details. I'm in the middle of getting spark to work as a client of another spark, this is a somewhat different use as I don't want the client just to echo the server, rather virtual receivers will be 'owned' by the client and not clutter up the display of the server, to do this I've added an addReceiverResponse that gives the id of the created receiver, this was needed to allow a client spark to create and share virtual receivers  among its own local receivers to reduce network bandwidth. My head is a bit full sorting this out at the moment:). I had thought of making active receiver commands work simply by not passing a receiver id, i.e. it defaults to the active rx if no rxid. Your suggestions are well timed as they are about control of the local sw in front of you and my mind is full of remote access to the radio and I need to keep both in mind. I shall try and incorporate at least some of this in the next release.

73 Alan M0NNB

 

[Thomas Beiderwieden]

Hi Alan,

has this (getting spark to work as a client of another spark) already been done and if yes, how to configure it. Sounds really cool.

vy 73 de Thomas, DL3EL

[ahop...@googlemail.com]

Hi Thomas,

it is in the current releases but very untested. The websocket tab in settings lets you put in a url to another instance of spark on your network, discover should then find it.  I have not tried it for ages and cannot remember the format of the url off the top of my head, it should be similar to that used for other websocket connections.  I do mean to get back to this soon.

73 Alan M0NNB

[Thomas Beiderwieden]

Hi Alan,

thanks for your answer. I tried all options, I could think of, it does not work. I have set up a websocket test client, that one could connect to the address "ws://192.168.xx.xx:4649/Spark". Commands work perfectly and give the expected answers. A SparkSDR Client on the same windows machine will not find the SparkSDR Client running on Linux, even when the address is entered in the same format as above.

vy 73 de Thomas, DL3EL

[Thomas Beiderwieden]

I did some more research and found the following. When I configure the windows machine to use the websocket server of the machine with the HL2 attached at port 4649, tcpdump on that macines shows:

22:29:24.336222 IP Arthur.fritz.box.59612 > 255.255.255.255.1024: UDP, length 63
22:29:24.336776 IP Arthur.fritz.box.59612 > 255.255.255.255.1024: UDP, length 60
22:29:24.337767 IP Arthur.fritz.box.63689 > PI4-HL2.fritz.box.1024: UDP, length 63
22:29:24.337831 IP PI4-HL2.fritz.box > Arthur.fritz.box: ICMP PI4-HL2.fritz.box udp port 1024 unreachable, length 99

In a different dump I have seen a lot of traffic using port 1024 between the HL2 and the PI, so I assume, that is the correct port. The windows machine runs with 2.0.8.18, the PI with .17

Hope that helps.

vy 73 de Thomas, DL3EL

[ahop...@googlemail.com]

Hi Thomas,

sorry I've not been more help with this,

I've been spending what spare time I have bringing all versions up to the level of the windows version. Once that is done I'll look at this, I could easily have broken it with all the performance tweaks recently.

73 Alan M0NNB

[Thomas Beiderwieden]

Hi Alan,

no problem, take your time. Performance is key. I have noticed that in my setup (12 radios on 4 bands with FT8, FT4 & WSPR on a Raspberry 4), the FT8 decoder is between 30s and 1 minute behind. So a qso in that config is not advisable. No Problem with 4 radios, one on each band.

Another point, which I wanted mention for a longer time. I do some network managemen at home for all my devices including the SparkSDR PI. On my MRTG graphs, I see that SparkSDR is constantly grabbing memory. It is not a problem, because I do a reboot every night, however, compared to my other raspberries, that does look strange.

vy 73 de Thomas, DL3EL