[hpsdr] hpsdr protocols.

[David R. Wilson]

One bit that might be worth adding to the list:

On Ghpsdr3-alex if someone grabs master control it would be helpful if
they see the control panels.  As it is presently the only way that
happens is if they connect to the dspserver before anyone else.

Just a thought.  I don't know how much of a headache that would be.

Dave
KU4B


On Tue, 2014-10-21 at 22:22 +0200, Andrea Montefusco wrote:
> ***** High Performance Software Defined Radio Discussion List *****
> 
> On 10/21/2014 04:03 PM, AD0ES wrote:
> > I'm deep into the modifications necessary to make flrig play nice with alex hpsdr.  By scraping the code of
> > dsp server I've found 30-40 possible commands, and another dozen "hardware directed" commands in sdr server.
> >
> > It has occurred to me that it would be nice if I coded flrig so that it could support the different variants
> > of hpsdr, ie. hpsdr3, hpsdr3-Qt and hpsdr3-alex.
> >
> > Can anyone point me to CURRENT protocol documents for any of these dialects?  If I have to scrape the code of
> > each for that info it just wont get done.  If I can work from a set of accurate docs I can probably accommodate
> > all 3.
> 
> Steve,
> short answer: there is no documentation, but, good news, you can safely ignore that part of the 
> protocol.
> 
> Let me explain: on June 2012 I implemented a protocol revision in ghpsdr3-alex, adding STAR 
> messages, i.e.  end to end messages exchanged between QtRadio GUI and servers (dspserver is only 
> forwarding STAR messages back and forward).
> 
> Those messages were implemented for SDR-IQ, Perseus, HiQSDR and HPSDR, sdr-widget+SR and 
> PMSDR+sdr-widget servers and are aimed to control the several hardware features found in each 
> hardware (attenuators, filters, ADC controls, and so on).
> 
> The idea is that several hardware features, specific to each hardware, do exist and we need to allow 
> user to control them at will, without resorting to stop and restart the servers (that BTW is clearly 
> unfeasible on remote connections but pretty inconvenient on local setups as well).
> 
> So, quite arbitrarily, I defined that every message, originated from QtRadio, that has a leading '*' 
> character, is forwarded by dspserver directly to the server in use, without further investigations; 
> the same applies to the answers traveling in the opposite direction.
> 
> The first message that QtRadio emits is a query in order to see which kind of server (and thus of 
> hardware) is running: accordingly to info received back, QtRadio  select  the right class to 
> instantiate in hardware_xxxxx.cpp module (for C++ gurus: we have a small factory at work here); this 
> object is typically a small panel that contains the controls specific to the radio (it is acting 
> likewise the old QtRadio's hardware menu).
> Of course when the user closes the connections (or it is dropped due to network and/or server 
> fault), the panel disappears.
> In order to implement support for new radios, all you have to do is make the needed  change to the 
> server for that radio, and add a class in a new hardware_xxxx.ccp/.h in QtRadio where xxxx is the 
> hardware name of your choice.
> 
> 
> So, in order to do the same in your application, if you are using Qt, you can safely copy all the 
> hardware_*.* files and you are done (well, almost, you have to trigger the discovery process sending 
> the first "hardware?" message): a pop up will be shown when a supported hardware is connected.
> If not, you have to reimplement the GUI part using the library and/or API, that you are using in flrig.
> 
> 
>        *am*
> 
> ----------------------------------------------------------------------
> Andrea Montefusco iw0hdv   (ex FAI10655)     http://www.montefusco.com
> tel: +393356992791                                  fax: +390623318709
> ----------------------------------------------------------------------
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/