Date   
Proficio Experiment: HDSDR in Linux with voice, fldigi and wsjt-x, running on an old PC

ag5gt@...
 
Edited

I took this on mostly as a personal challenge, not at all certain it would all work in the end. I wanted to see if a Proficio could be made to work with HDSDR in Linux, thereby avoiding purchase of the latest and greatest from Microsoft and its PC hardware ecosystem. I was familiar with Quisk, liked it for its comprehensive collection of ham transceiver features, and understood it had already been proven to be cross-platform compatible. But, to my knowledge, HDSDR was still regarded as a Windows-only option. I can report that, for the last several days, I have been exercising my proficio in a variety of modes without ever having hooked it up to a Windows-based PC, all with HDSDR as the SDR core. So, for those willing and able to deal with Linux systems, I'd now suggest HDSDR is an option. With more scripting to automate installation and configuration, it might even become an option with substantial appeal, given HDSDR's receive-mode features and refined user-interface.

This was enabled by availability of some important pieces of code. First of course is the WINE compatibility layer in Linux. It is my understanding that HDSDR's developers made a particular effort to avoid coding techniques not compatible with WINE's api. As a result, HDSDR loads and looks right, processes I/Q signals, and passes audio to and from the Linux sound system. The HDSDR developers also made available a very basic dll that adds TX capability and is platform agnostic, ExtIO_SRlite.dll. What all that does not do is support USB control of softrock or proficio hardware. Enter usbsoftrock, a Linux command-line utility that can set the radio's LO frequency and ptt state, among other things. Since the proficio was built with softrock compatibilty in mind, usbsoftrock can be recompiled to do the essentials with a proficio, too.

My code contribution at this point is a tcl/tk script and related rigdef file to overcome the awkwardness of a command-line method of tuning and rx/tx control. What the script does is communicate with HDSDR through its CAT interface, using virtual serial ports. It relays tuning and ptt commands to the radio by invoking usbsoftrock. For voice-mode operation, the script sets up a virtual teletype terminal to talk to HDSDR. It periodically asks HDSDR for the frequency being displayed on its GUI. When a change is noted, it calculates the needed LO frequency, correcting for offset and calibration and sends that to the radio. The script also pops up on-screen a small window with two buttons for controlling ptt; one toggles the rx/tx state and the other acts as a momentary-contact TX switch. Hovering the mouse pointer over that window also causes the keyboard space-bar to act as a TX switch (HDSDR’s TX button is presently used only as an indicator). In digital modes, the script invokes native-linux versions of fldigi or wsjt-x and supports CAT communications between HDSDR and those app’s. It monitors virtual serial port traffic, looking for tuning or rx/tx commands. Those are relayed to the radio after formatting and adjustment similar to voice mode operation. In the case of fldigi, a few tested rig definitions proved poor surrogates, so a custom rigdef file was built to implement HDSDR’s CAT commands exactly (afaik). In wsjt-x, the Kenwood TS-2000 rig definition appears workable, apparently not relying on features available on a TS-2000, but not supported by HDSDR.

The result is a means to operate with HDSDR in Ubuntu 14.04 on a PC of ~2005 vintage, using native-linux features for virtual audio and serial cables. That virtuality results in a (relatively) clean desktop, with minimal spurious RF radiation or coupling and no signal degradation from non-essential d/a or a/d conversions. Incidentally, it occurs to me this might be particularly useful to folks building portable systems using micro-form-factor PC hardware having limited i/o. Except for the necessity to lock HDSDR’s tuning to a fixed offset from the LO, operation seems to me essentially un-compromised. Both fldigi and wsjt-x native-linux app’s appear to operate normally (they each have their own quirks...). Even with only 5 watts and 13 characters, I’m  finding JT65 to be oddly addictive, but I digress...

Below  are screen captures of the thing in various modes of operation. I’m happy to share code, configuration data, notes, etc., if somebody can advise on the best place to post a directory full of that stuff. I don’t have a step-by-step installation document. If there’s interest, I can put that on my to-do list.

****Edit****

The source files are available here:
https://drive.google.com/open?id=0B0QDZpLElJ4tZ2JnTXBFUmtZR1E

****Edit****

The pop-up dialog at start-up of the script:



Voice/CW mode:



Fldigi:



Wsjt-x:



Cheers, Bruce, AG5GT

Re: Proficio Experiment: HDSDR in Linux with voice, fldigi and wsjt-x, running on an old PC

K7AZJ <jdawgaz@...>
 

of course, this will never work on the raspberry pi.
wine only works on x86 architecture.

personally, anything I do, has to work on the raspberry pi, because, I take it out portably. I can do everything with a 12v battery.

but it was a good exercise that you did. And shows what can be done.

Jerry



--
Extra Ham Operator: K7AZJ
Registered Linux User: 275424
Raspberry Pi and Openscad developer

The most exciting phrase to hear in science - the one that heralds new discoveries - is not "Eureka!" but "That's funny...".
- Isaac. Asimov


On Thu, Aug 24, 2017 at 1:17 PM, <ag5gt@...> wrote:
I took this on mostly as a personal challenge, not at all certain it would all work in the end. I wanted to see if a Proficio could be made to work with HDSDR in Linux, thereby avoiding purchase of the latest and greatest from Microsoft and its PC hardware ecosystem. I was familiar with Quisk, liked it for its comprehensive collection of ham transceiver features, and understood it had already been proven to be cross-platform compatible. But, to my knowledge, HDSDR was still regarded as a Windows-only option. I can report that, for the last several days, I have been exercising my proficio in a variety of modes without ever having hooked it up to a Windows-based PC, all with HDSDR as the SDR core. So, for those willing and able to deal with Linux systems, I'd now suggest HDSDR is an option. With more scripting to automate installation and configuration, it might even become an option with substantial appeal, given HDSDR's receive-mode features and refined user-interface.

This was enabled by availability of some important pieces of code. First of course is the WINE compatibility layer in Linux. It is my understanding that HDSDR's developers made a particular effort to avoid coding techniques not compatible with WINE's api. As a result, HDSDR loads and looks right, processes I/Q signals, and passes audio to and from the Linux sound system. The HDSDR developers also made available a very basic dll that adds TX capability and is platform agnostic, ExtIO_SRlite.dll. What all that does not do is support USB control of softrock or proficio hardware. Enter usbsoftrock, a Linux command-line utility that can set the radio's LO frequency and ptt state, among other things. Since the proficio was built with softrock compatibilty in mind, usbsoftrock can be recompiled to do the essentials with a proficio, too.

My code contribution at this point is a tcl/tk script and related rigdef file to overcome the awkwardness of a command-line method of tuning and rx/tx control. What the script does is communicate with HDSDR through its CAT interface, using virtual serial ports. It relays tuning and ptt commands to the radio by invoking usbsoftrock. For voice-mode operation, the script sets up a virtual teletype terminal to talk to HDSDR. It periodically asks HDSDR for the frequency being displayed on its GUI. When a change is noted, it calculates the needed LO frequency, correcting for offset and calibration and sends that to the radio. The script also pops up on-screen a small window with two buttons for controlling ptt; one toggles the rx/tx state and the other acts as a momentary-contact TX switch. Hovering the mouse pointer over that window also causes the keyboard space-bar to act as a TX switch (HDSDR’s TX button is presently used only as an indicator). In digital modes, the script invokes native-linux versions of fldigi or wsjt-x and supports CAT communications between HDSDR and those app’s. It monitors virtual serial port traffic, looking for tuning or rx/tx commands. Those are relayed to the radio after formatting and adjustment similar to voice mode operation. In the case of fldigi, a few tested rig definitions proved poor surrogates, so a custom rigdef file was built to implement HDSDR’s CAT commands exactly (afaik). In wsjt-x, the Kenwood TS-2000 rig definition appears workable, apparently not relying on features available on a TS-2000, but not supported by HDSDR.

The result is a means to operate with HDSDR in Ubuntu 14.04 on a PC of ~2005 vintage, using native-linux features for virtual audio and serial cables. That virtuality results in a (relatively) clean desktop, with minimal spurious RF radiation or coupling and no signal degradation from non-essential d/a or a/d conversions. Incidentally, it occurs to me this might be particularly useful to folks building portable systems using micro-form-factor PC hardware having limited i/o. Except for the necessity to lock HDSDR’s tuning to a fixed offset from the LO, operation seems to me essentially un-compromised. Both fldigi and wsjt-x native-linux app’s appear to operate normally (they each have their own quirks...). Even with only 5 watts and 13 characters, I’m  finding JT65 to be oddly addictive, but I digress...

Below  are screen captures of the thing in various modes of operation. I’m happy to share code, configuration data, notes, etc., if somebody can advise on the best place to post a directory full of that stuff. I don’t have a step-by-step installation document. If there’s interest, I can put that on my to-do list.

The pop-up dialog at start-up of the script:



Voice/CW mode:



Fldigi:



Wsjt-x:



Cheers, Bruce, AG5GT

Re: Proficio Experiment: HDSDR in Linux with voice, fldigi and wsjt-x, running on an old PC

ag5gt@...
 

Right you are about RPi compatibility. The RPi series has certainly set a standard for price/performance and power-effciency. Impressive, actually.

But, there is some x86 competition. I was thinking of an x86 micro-board, something more like this:
https://liliputing.com/2017/06/core-quad-core-x86-mini-pc-thats-smaller-raspberry-pi-crowdfunding.html
There are others. Some claim to be Win10 capable, though I'd probably stick with Ubuntu linux, for better support of us tinkerers. I'm imagining porting the set-up from my giant, acoustically noisy, power-hungry, 2005 NoName PC mid-tower to a little box that has in it the proficio radio hardware, an HF amplifier and one of these little PC boards. It could also be kept 12V compatible, though likely a little more of a power consumer than an RPi version. Anyway, so far, the exercise I reported has been quite educational w.r.t. what's likely workable and how.

An immediate goal is to make the setup behave as "instant-on"; i.e., no switching, reconfiguring, level-setting, etc., when starting in one config after having been running in another. It is pretty close right now. HDSDR's profile feature helps a lot with that, by remembering its setup on a per profile basis.

One remaining annoyance is wsjt-x and port-audio not always cooperating immediately on power-up, as others have observed. I have to believe there's a scriptable, not-too-complicated solution to that. Maybe the user's preferred pavu configuration needs to be explicitly activated at the start of the radio script, before wsjt-x, for example. There can't be too much in it because fldigi starts right up every time, no fuss no muss, using the same virtual audio devices.

Bruce, AG5GT

Re: Best settings for Multus SDR Proficio for JT65 with WSJT-X (not for initial setup, for operating)

ag5gt@...
 

Interesting discussion. I had made the same observations of spectral clutter displayed by HDSDR during TX, but concluded I was being faked out by the log scale of signal strength. The transmitted fundamental was way, way above the spurious components. I guess we need a feature in HDSDR that re-scales the spectrum when switching between TX and RX. Maybe that would put the spurs in proper perspective. Come to think of it, maybe that scaling feature is already there and we're not using it properly. Hmmm... Maybe also the spurs are totally an artifact of HDSDR's display fft and/or decimation and don't exist in the RF out.  Maybe that's Ron's point.

Anyway, WRT JT 65, I' have only been playing with it for a few days, when band conditions have been mostly poor. But, I have a couple of observations:

- When I respond to a DX CQ, I never win. A closer or higher power station always draws the response.
- When I choose an inactive spot on the band and send CQ, I usually get a quick response.

My guess is that this mode has a property similar to the capture effect in wide-band FM (I should look for some technical spec's to study...). That's where a station 1.5 db stronger totally blocks reception of the slightly weaker station. If so, and all other things are equal, a 20 watt station will generally block reception of a 5 watt station. The 5 watter gets treated as noise. That's in contrast to AM or SSB where both stations can be heard, along with QRN.

That said though, I did have a case where I saw two simultaneous responses to my CQ, several HZ apart in frequency, one being several db stronger than the other. That was surprising, based on the above guesswork. Thinking about it though, maybe there's enough sparseness of tone frequencies in this mode that the ~200hz bandwidth of one signal can just about totally overlap another and still be reliably separable at the receiver. Maybe you only get treated as noise when your 5 watts is spot-on the same frequency, or close enough to be inseparable due to phase noise. Incidentally, avoiding non-essential a/d and d/a conversions and sample rate interpolations, is good for minimizing phase noise. That's an argument for virtual audio cables as opposed to physical and an extra sound card, but that's another topic...

I too have been having fun with this mode. Considering not only the 5 watt power, but also my makeshift antenna, it works great. A couple of nights ago, after sending CQ on 40m, I completed a QSO at a distance of 5,500 miles, for example! Just to make you laugh, I'll tell you how makeshift it really is: At my operating position, there was an RG-59 cable TV outlet installed during the original construction of the house. Having never had cable TV hooked up, that cable goes up the wall, runs across the attic trusses, near the peak about 20 feet up, and stubs out 40 or 50 feet away. On the opposite side of the wall, 3 or 4 feet away, there's a copper water pipe coming up out of the slab foundation, feeding a bathroom fixture. That actually may be part of a decent ground plane, but I don't know for sure. To get on the air, I hooked a tuner to the braid of the RG-59 and gounded the tuner to the copper pipe with a piece #12 wire and a pipe clamp. The tuner is connected to the proficio by 9 inches of RG-58. It tunes to a 1.0 swr on 40m. It may be only 5 watts into a crummy antenna, but the whole 5 watts gets radiated somewhere and, sometimes, it goes quite a long distance.

Bruce, AG5GT

Re: Success!

ag5gt@...
 

Ron,

If Linux stand-alone support is a goal, I would advocate a stand-alone EEPROM calibration means; i.e., one that is not embedded in another application such as Quisk. A stand-alone, command-line utility could be used in linux very flexibly, including being invoked from inside quisk. That would support linux app's not even cooked up yet, as well as quisk, without demanding more of the team here.

Someone in this thread mentioned "usbsoftrock" in the context of calibration. From my perspective as a linux-radio-app-hacker, the perfect linux support would be a "usbproficio" that does for a multus-proficio the same things "usbsoftrock" does for a softrock. That could be a foundation for creation of lots on interesting app's in linux.

Full disclosure: I use usbsoftrock (recompiled to recognize the proficio) in my tcl/tk scripted method of operating HDSDR in linux. I can leave the proficio uncalibrated and instead adjust the local oscillator frequency each time a "set freq" command is sent to the proficio through usbsoftrock. Were it possible in linux to set the EEPROM, I might do that just to make my control loop a little cleaner/faster.

However, the best reason to support a usbproficio utility would be avoidance of the need to have customized calibration (or tuning, ptt, etc.) support in each present and future linux sdr application. Multus could support just one chunk of code specialized to Multus' hardware and enable every other application to invoke it as a shell command, or even manually on a command line.

The fellow who figured out usbsoftrock had the right idea, imho.

My $.02

Bruce, AG5GT

Re: Success!

Ron / W4MMP
 

Hi Bruce,

Thank you for your insights and comments.  I agree a stand alone utility will be useful.  That is one of my goals for MSCC.   MSCC is the core for everything I do from here on out.  It is a visual studio C# application.  One of the things I find really cool is that it will run on Linux unmodified using a facility called Mono.  Showing my ignorance of host side application programming,  I did not realize until recently that applications developed for .Net actually run inside .Net (Common Language runtime).  Mono is a .Net implementation for both Windows and Linux.   Microsoft actually shares .Net source code with the Mono team.   So what does this mean?  All applications developed by Multus SDR will be cross platform. 

My first target was a DLL for HDSDR for MSCC to communicate with.  HDSDR has a very robust real API.  And because HDSDR is the Multus SDR recommended host application (for the time being) it was a nature choice.  This effort is more or less complete. 

The long term goal is to have a complete cross platform Multus SDR authored host application.  That is a long road to follow.  In the mean time MSCC will be "hooked" into other SDR applications.  I am currently investigating how to hook MSCC into Quisk as we all know Quisk is one of the few cross platform SDR host applications.   To be honest I am not really enamored with any current host SDR application.   They are all monolithic,  the GUIs of some are way too cluttered and some are just a pain in the but to install and use.  One of my highest priorities is to take the "geek" out of SDR. 

73,
Ron / W4MMP
On 8/26/2017 18:38, ag5gt@... wrote:

Ron,

If Linux stand-alone support is a goal, I would advocate a stand-alone EEPROM calibration means; i.e., one that is not embedded in another application such as Quisk. A stand-alone, command-line utility could be used in linux very flexibly, including being invoked from inside quisk. That would support linux app's not even cooked up yet, as well as quisk, without demanding more of the team here.

Someone in this thread mentioned "usbsoftrock" in the context of calibration. From my perspective as a linux-radio-app-hacker, the perfect linux support would be a "usbproficio" that does for a multus-proficio the same things "usbsoftrock" does for a softrock. That could be a foundation for creation of lots on interesting app's in linux.

Full disclosure: I use usbsoftrock (recompiled to recognize the proficio) in my tcl/tk scripted method of operating HDSDR in linux. I can leave the proficio uncalibrated and instead adjust the local oscillator frequency each time a "set freq" command is sent to the proficio through usbsoftrock. Were it possible in linux to set the EEPROM, I might do that just to make my control loop a little cleaner/faster.

However, the best reason to support a usbproficio utility would be avoidance of the need to have customized calibration (or tuning, ptt, etc.) support in each present and future linux sdr application. Multus could support just one chunk of code specialized to Multus' hardware and enable every other application to invoke it as a shell command, or even manually on a command line.

The fellow who figured out usbsoftrock had the right idea, imho.

My $.02

Bruce, AG5GT


--
Thank you for your support and business,
73,
The Multus SDR,LLC Team,
Ron / W4MMP

Re: Success!

K7AZJ <jdawgaz@...>
 

if you want truly cross platform, then you need to stop relying on microsoft languages in their entirety.

if you want to do a gui, then rely on something truly cross platform. gtk, or qt.

If you just need utility functions, then don't do C#, just do c or c++. This way gcc or gcc++ can be used.

If you do all your development in C# or rely on mono or something else, then it only causes problems down the line.

As more and more hams do linux, this would be really appreciated.

Just my $0.02,

Jerry



--
Extra Ham Operator: K7AZJ
Registered Linux User: 275424
Raspberry Pi and Openscad developer

The most exciting phrase to hear in science - the one that heralds new discoveries - is not "Eureka!" but "That's funny...".
- Isaac. Asimov


On Sun, Aug 27, 2017 at 7:06 AM, Ron / W4MMP via Groups.Io <w4mmp@...> wrote:

Hi Bruce,

Thank you for your insights and comments.  I agree a stand alone utility will be useful.  That is one of my goals for MSCC.   MSCC is the core for everything I do from here on out.  It is a visual studio C# application.  One of the things I find really cool is that it will run on Linux unmodified using a facility called Mono.  Showing my ignorance of host side application programming,  I did not realize until recently that applications developed for .Net actually run inside .Net (Common Language runtime).  Mono is a .Net implementation for both Windows and Linux.   Microsoft actually shares .Net source code with the Mono team.   So what does this mean?  All applications developed by Multus SDR will be cross platform. 

My first target was a DLL for HDSDR for MSCC to communicate with.  HDSDR has a very robust real API.  And because HDSDR is the Multus SDR recommended host application (for the time being) it was a nature choice.  This effort is more or less complete. 

The long term goal is to have a complete cross platform Multus SDR authored host application.  That is a long road to follow.  In the mean time MSCC will be "hooked" into other SDR applications.  I am currently investigating how to hook MSCC into Quisk as we all know Quisk is one of the few cross platform SDR host applications.   To be honest I am not really enamored with any current host SDR application.   They are all monolithic,  the GUIs of some are way too cluttered and some are just a pain in the but to install and use.  One of my highest priorities is to take the "geek" out of SDR. 

73,
Ron / W4MMP
On 8/26/2017 18:38, ag5gt@... wrote:
Ron,

If Linux stand-alone support is a goal, I would advocate a stand-alone EEPROM calibration means; i.e., one that is not embedded in another application such as Quisk. A stand-alone, command-line utility could be used in linux very flexibly, including being invoked from inside quisk. That would support linux app's not even cooked up yet, as well as quisk, without demanding more of the team here.

Someone in this thread mentioned "usbsoftrock" in the context of calibration. From my perspective as a linux-radio-app-hacker, the perfect linux support would be a "usbproficio" that does for a multus-proficio the same things "usbsoftrock" does for a softrock. That could be a foundation for creation of lots on interesting app's in linux.

Full disclosure: I use usbsoftrock (recompiled to recognize the proficio) in my tcl/tk scripted method of operating HDSDR in linux. I can leave the proficio uncalibrated and instead adjust the local oscillator frequency each time a "set freq" command is sent to the proficio through usbsoftrock. Were it possible in linux to set the EEPROM, I might do that just to make my control loop a little cleaner/faster.

However, the best reason to support a usbproficio utility would be avoidance of the need to have customized calibration (or tuning, ptt, etc.) support in each present and future linux sdr application. Multus could support just one chunk of code specialized to Multus' hardware and enable every other application to invoke it as a shell command, or even manually on a command line.

The fellow who figured out usbsoftrock had the right idea, imho.

My $.02

Bruce, AG5GT


--
Thank you for your support and business,
73,
The Multus SDR,LLC Team,
Ron / W4MMP

Re: Success!

Ron / W4MMP
 

Why?

73,
Ron / W4MMP

On 8/27/2017 11:36, K7AZJ wrote:
If you do all your development in C# or rely on mono or something else, then it only causes problems down the line.


--
Thank you for your support and business,
73,
The Multus SDR,LLC Team,
Ron / W4MMP

Re: Success!

ag5gt@...
 

Hi Ron,

Being a proud geek, I'm not quite sure how to take that last point ;-)

But, I am learning something here. I dislike and distrust MS for reasons ingrained and undiminished over decades of experience, but I do own a Win10 laptop for business purposes-- no real alternative, unfortunately. That said, I must admit the more engineering-oriented, open-source, *n*x systems that I prefer, have weaknesses, too. Mainly, there's fragmentation in the community, leading to inefficiencies. My very quick, cursory look at mono, prompted by your comments, suggest it might be a practical middle-of-the-road approach, theoretically supporting everybody with one development platform. But, I will have to learn way more and, apparently, learn yet another programming language before I become a true believer ... or not. I just hope Mr Gates' associates are not in a position to cut off the air supply to mono if/when their mood changes.

In the near term, do you envision enabling linux shell command line access to proficio control through mscc? Asked another way, will we be able to replace in a tcl/tk script the line, "exec usbsoftrock -a set freq 7.080", with a line referencing mscc and accomplish the same thing? I realize your goal for mscc is to do way more, and do it with a common-sense GUI, but can you do that and also keep the essential "hooks" accessible according to *n*x tradition? If so, I'm OK until I learn c#, and I will also immediately be able to interface multus hardware with other open-source stuff.

Incidentally, I recently enjoyed listening to a presentation by Gerald Youngblood of Flex fame. He chronicled the evolution from an sdr hobby project to accidentally starting the business and then growing that. He mentioned the evolution of thought regarding app's, from open-source to an approach that is more proprietary and comprehensive; somewhat similar to your longer term thinking. However, even proprietary Flex software has to work nicely with fldigi, wsjtx and the shell.

Bruce, AG5GT

Re: Success!

K7AZJ <jdawgaz@...>
 

Well, the reason I said what I said, is that doing things in MS, and then trying to make it compatible by relying on software that might not work in the next iteration, because MS decides to change something, is not a good solution.

I was a programmer for 40 years, before retiring, and I can attest to how many things MS did to change working standards (ever so slightly, so that we had to change the standard just because), to making changes in software that no one could account for, just to make things difficult for open source projects. And many other things over the years, that made it difficult to "work with MS".

I could go on and on, but developing something that relies upon something else (like mono for instance) to make your software work on  another platform, is not the same thing as making it cross-platform from the very start. Without the need for that reliance.

That was my point.

Not trying to throw water on what was done. It was nicely done, but merely pointing out that developing for one platform, and relying on something else, to make it work on others secondarily, doesn't make it cross-platform development.

I didn't mean to ruffle any feathers, here.

Jerry



--
Extra Ham Operator: K7AZJ
Registered Linux User: 275424
Raspberry Pi and Openscad developer

The most exciting phrase to hear in science - the one that heralds new discoveries - is not "Eureka!" but "That's funny...".
- Isaac. Asimov


On Sun, Aug 27, 2017 at 3:31 PM, <ag5gt@...> wrote:
Hi Ron,

Being a proud geek, I'm not quite sure how to take that last point ;-)

But, I am learning something here. I dislike and distrust MS for reasons ingrained and undiminished over decades of experience, but I do own a Win10 laptop for business purposes-- no real alternative, unfortunately. That said, I must admit the more engineering-oriented, open-source, *n*x systems that I prefer, have weaknesses, too. Mainly, there's fragmentation in the community, leading to inefficiencies. My very quick, cursory look at mono, prompted by your comments, suggest it might be a practical middle-of-the-road approach, theoretically supporting everybody with one development platform. But, I will have to learn way more and, apparently, learn yet another programming language before I become a true believer ... or not. I just hope Mr Gates' associates are not in a position to cut off the air supply to mono if/when their mood changes.

In the near term, do you envision enabling linux shell command line access to proficio control through mscc? Asked another way, will we be able to replace in a tcl/tk script the line, "exec usbsoftrock -a set freq 7.080", with a line referencing mscc and accomplish the same thing? I realize your goal for mscc is to do way more, and do it with a common-sense GUI, but can you do that and also keep the essential "hooks" accessible according to *n*x tradition? If so, I'm OK until I learn c#, and I will also immediately be able to interface multus hardware with other open-source stuff.

Incidentally, I recently enjoyed listening to a presentation by Gerald Youngblood of Flex fame. He chronicled the evolution from an sdr hobby project to accidentally starting the business and then growing that. He mentioned the evolution of thought regarding app's, from open-source to an approach that is more proprietary and comprehensive; somewhat similar to your longer term thinking. However, even proprietary Flex software has to work nicely with fldigi, wsjtx and the shell.

Bruce, AG5GT

Re: Success!

Ron / W4MMP
 

Hi Bruce,

Trust me,  I am a geek too!  There has to be some geek there somewhere to be able write firmware,  GUIs and such.  But I also have a business side to me also.   That is the side that is driving me to try and take the geek out of SDR.  My somewhat educated conclusion is that many folks just want use it and don't give a hoot about how it works.  They just want it to work.  And I that I totally agree with. 

For the die hard geeks,  the source code is available for everything Multus SDR produces.  It may not be up to date at the moment, but it is available (if not available, ask me for it).

As for the MS verse Linux,  I do not subscribe to any particular operating system dogma.  I am a pragmatist and will use whatever suits the need at any given moment.  Windows will be with us for the foreseeable future.  For all the grousing about MS, Windows has been and remains relatively stable.  Perfect, no, nothing ever is.   And to your point,  Linux has be come extremely fragmented.  How many versions exist at the moment?  Too many!  I have lost count of the number of emails that talk about XYZ application will not work on a particular flavor of Linux and how to make XYZ work.  And backwards compatibly is almost non existent. 

But,  the amateur radio community has a somewhat strong push towards Linux so it is important that Multus SDR address Linux. 

On Mono,  there is nothing really to learn.  It is simply a cross platform implementation of .Net.   The learning comes in when developing a GUI with visual studio.  I began learning it when developing MSCC.  Trust me I am no fan of object oriented languages such as C#.  But the upside is developing the stuff the user sees is actually very straight forward and there is little extra coding that needs to be accomplished to make it work.  I needed to put a stick in the ground and learn "something" to so that I can produce a GUI.  Jim, one of our team members is very knowledgeable with VS,  so he is a great and direct resource for me when I hit the proverbial wall on something.  So, VS was the shortest path for me to take so that is what I am sticking with. 

To the issue of, if MS will stop giving its toys away, I highly doubt that will happen.  Large companies such as MS are very strategic in their planning.  They seldom do things simply on a whim. 

A command line interface is something I will give thought to.  It is not really in my sights, but it might be something worth doing down the road a bit.  If it does happen it will be implemented in the server (shared library) that the GUI interfaces with.  Just a bit of explanation.   The current Windows implementation is:   GUI -> DLL -> HDSDR.   On Linux it will be the same but the implementation is with a shared library.  Just off the top of my head,  I suppose the server can keep stdin open.  Tcl/tk scripts can open the server and send commands.  Obviously I have not given it much thought.

73,
Ron / W4MMP
On 8/27/2017 18:31, ag5gt@... wrote:

Hi Ron,

Being a proud geek, I'm not quite sure how to take that last point ;-)

But, I am learning something here. I dislike and distrust MS for reasons ingrained and undiminished over decades of experience, but I do own a Win10 laptop for business purposes-- no real alternative, unfortunately. That said, I must admit the more engineering-oriented, open-source, *n*x systems that I prefer, have weaknesses, too. Mainly, there's fragmentation in the community, leading to inefficiencies. My very quick, cursory look at mono, prompted by your comments, suggest it might be a practical middle-of-the-road approach, theoretically supporting everybody with one development platform. But, I will have to learn way more and, apparently, learn yet another programming language before I become a true believer ... or not. I just hope Mr Gates' associates are not in a position to cut off the air supply to mono if/when their mood changes.

In the near term, do you envision enabling linux shell command line access to proficio control through mscc? Asked another way, will we be able to replace in a tcl/tk script the line, "exec usbsoftrock -a set freq 7.080", with a line referencing mscc and accomplish the same thing? I realize your goal for mscc is to do way more, and do it with a common-sense GUI, but can you do that and also keep the essential "hooks" accessible according to *n*x tradition? If so, I'm OK until I learn c#, and I will also immediately be able to interface multus hardware with other open-source stuff.

Incidentally, I recently enjoyed listening to a presentation by Gerald Youngblood of Flex fame. He chronicled the evolution from an sdr hobby project to accidentally starting the business and then growing that. He mentioned the evolution of thought regarding app's, from open-source to an approach that is more proprietary and comprehensive; somewhat similar to your longer term thinking. However, even proprietary Flex software has to work nicely with fldigi, wsjtx and the shell.

Bruce, AG5GT


--
Thank you for your support and business,
73,
The Multus SDR,LLC Team,
Ron / W4MMP

Re: Success!

Ron / W4MMP
 

Hi Jerry,

No feathers ruffled here :-) I was genuinely interested to understand your position on this.   

73,
Ron / W4MMP
On 8/27/2017 19:46, K7AZJ wrote:

Well, the reason I said what I said, is that doing things in MS, and then trying to make it compatible by relying on software that might not work in the next iteration, because MS decides to change something, is not a good solution.

I was a programmer for 40 years, before retiring, and I can attest to how many things MS did to change working standards (ever so slightly, so that we had to change the standard just because), to making changes in software that no one could account for, just to make things difficult for open source projects. And many other things over the years, that made it difficult to "work with MS".

I could go on and on, but developing something that relies upon something else (like mono for instance) to make your software work on  another platform, is not the same thing as making it cross-platform from the very start. Without the need for that reliance.

That was my point.

Not trying to throw water on what was done. It was nicely done, but merely pointing out that developing for one platform, and relying on something else, to make it work on others secondarily, doesn't make it cross-platform development.

I didn't mean to ruffle any feathers, here.

Jerry



--
Extra Ham Operator: K7AZJ
Registered Linux User: 275424
Raspberry Pi and Openscad developer

The most exciting phrase to hear in science - the one that heralds new discoveries - is not "Eureka!" but "That's funny...".
- Isaac. Asimov


On Sun, Aug 27, 2017 at 3:31 PM, <ag5gt@...> wrote:
Hi Ron,

Being a proud geek, I'm not quite sure how to take that last point ;-)

But, I am learning something here. I dislike and distrust MS for reasons ingrained and undiminished over decades of experience, but I do own a Win10 laptop for business purposes-- no real alternative, unfortunately. That said, I must admit the more engineering-oriented, open-source, *n*x systems that I prefer, have weaknesses, too. Mainly, there's fragmentation in the community, leading to inefficiencies. My very quick, cursory look at mono, prompted by your comments, suggest it might be a practical middle-of-the-road approach, theoretically supporting everybody with one development platform. But, I will have to learn way more and, apparently, learn yet another programming language before I become a true believer ... or not. I just hope Mr Gates' associates are not in a position to cut off the air supply to mono if/when their mood changes.

In the near term, do you envision enabling linux shell command line access to proficio control through mscc? Asked another way, will we be able to replace in a tcl/tk script the line, "exec usbsoftrock -a set freq 7.080", with a line referencing mscc and accomplish the same thing? I realize your goal for mscc is to do way more, and do it with a common-sense GUI, but can you do that and also keep the essential "hooks" accessible according to *n*x tradition? If so, I'm OK until I learn c#, and I will also immediately be able to interface multus hardware with other open-source stuff.

Incidentally, I recently enjoyed listening to a presentation by Gerald Youngblood of Flex fame. He chronicled the evolution from an sdr hobby project to accidentally starting the business and then growing that. He mentioned the evolution of thought regarding app's, from open-source to an approach that is more proprietary and comprehensive; somewhat similar to your longer term thinking. However, even proprietary Flex software has to work nicely with fldigi, wsjtx and the shell.

Bruce, AG5GT



--
Thank you for your support and business,
73,
The Multus SDR,LLC Team,
Ron / W4MMP

Re: Success!

ag5gt@...
 

Ron,

The thought about keeping stdin open may be on track. From a unix/linux command line, an "echo" command could send a text string via a command line pipe. I'm envisioning your gui with buttons that trigger various actions and, in parallel, a set of text strings that can trigger the same actions. Would that be doable? I'm trying to get to something here that meshes neatly with what you want to do anyway, so it can all be implemented at the same time, rather than part now and an add-on later.

About the linux vs ms debate, I tend toward pragmatism, too. I believe the interest in linux among hams, who are hands-on problem solvers almost by definition, is that open-source accommodates such folks better than proprietary solutions. Proprietors don't want to tell us enough to fully enable us. They want to retain an advantage, and generally do. Linux is a very pragmatic means to counter proprietary leverage, to enable solutions proprietary entities find uninteresting. Occasionally, leverage can pry loose something useful. Mono may be an example.

BTW, I see great potential in what's going on here. Thank you.

Bruce, AG5GT

Re: Success!

Ron / W4MMP
 

Hi Bruce,

You are welcome!

Yes that would be doable.  The idea is that via the various Linux facilities,  you may emulate what the GUI is sending to the server.  Essentially the server will have a command line interpreter that will accept commands on stdin.  But, would a named pipe be better?  That way client (whatever that may be) could receive data from the server.  Not being a command line/script kind of guy,  I really don't know what that entails. 


73,
Ron / W4MMP
On 8/28/2017 11:35, ag5gt@... wrote:

Ron,

The thought about keeping stdin open may be on track. From a unix/linux command line, an "echo" command could send a text string via a command line pipe. I'm envisioning your gui with buttons that trigger various actions and, in parallel, a set of text strings that can trigger the same actions. Would that be doable? I'm trying to get to something here that meshes neatly with what you want to do anyway, so it can all be implemented at the same time, rather than part now and an add-on later.

About the linux vs ms debate, I tend toward pragmatism, too. I believe the interest in linux among hams, who are hands-on problem solvers almost by definition, is that open-source accommodates such folks better than proprietary solutions. Proprietors don't want to tell us enough to fully enable us. They want to retain an advantage, and generally do. Linux is a very pragmatic means to counter proprietary leverage, to enable solutions proprietary entities find uninteresting. Occasionally, leverage can pry loose something useful. Mono may be an example.

BTW, I see great potential in what's going on here. Thank you.

Bruce, AG5GT


--
Thank you for your support and business,
73,
The Multus SDR,LLC Team,
Ron / W4MMP

Re: Success!

K7AZJ <jdawgaz@...>
 

Well, what you could do is allow a client that could connect via a localhost port.

Jerry 

On Aug 28, 2017 9:40 AM, "Ron / W4MMP via Groups.Io" <w4mmp=aol.com@groups.io> wrote:

Hi Bruce,

You are welcome!

Yes that would be doable.  The idea is that via the various Linux facilities,  you may emulate what the GUI is sending to the server.  Essentially the server will have a command line interpreter that will accept commands on stdin.  But, would a named pipe be better?  That way client (whatever that may be) could receive data from the server.  Not being a command line/script kind of guy,  I really don't know what that entails. 


73,
Ron / W4MMP
On 8/28/2017 11:35, ag5gt@... wrote:
Ron,

The thought about keeping stdin open may be on track. From a unix/linux command line, an "echo" command could send a text string via a command line pipe. I'm envisioning your gui with buttons that trigger various actions and, in parallel, a set of text strings that can trigger the same actions. Would that be doable? I'm trying to get to something here that meshes neatly with what you want to do anyway, so it can all be implemented at the same time, rather than part now and an add-on later.

About the linux vs ms debate, I tend toward pragmatism, too. I believe the interest in linux among hams, who are hands-on problem solvers almost by definition, is that open-source accommodates such folks better than proprietary solutions. Proprietors don't want to tell us enough to fully enable us. They want to retain an advantage, and generally do. Linux is a very pragmatic means to counter proprietary leverage, to enable solutions proprietary entities find uninteresting. Occasionally, leverage can pry loose something useful. Mono may be an example.

BTW, I see great potential in what's going on here. Thank you.

Bruce, AG5GT


--
Thank you for your support and business,
73,
The Multus SDR,LLC Team,
Ron / W4MMP

Re: Success!

Ron / W4MMP
 

Hi Jerry,

Yes, that is exactly what is used by the GUI to communicate with the server.  But, how would Linux utilities talk to a port?  I simply don't know enough about this.

73,
Ron / W4MMP
On 8/28/2017 13:07, K7AZJ wrote:

Well, what you could do is allow a client that could connect via a localhost port.

Jerry 

On Aug 28, 2017 9:40 AM, "Ron / W4MMP via Groups.Io" <w4mmp=aol.com@groups.io> wrote:

Hi Bruce,

You are welcome!

Yes that would be doable.  The idea is that via the various Linux facilities,  you may emulate what the GUI is sending to the server.  Essentially the server will have a command line interpreter that will accept commands on stdin.  But, would a named pipe be better?  That way client (whatever that may be) could receive data from the server.  Not being a command line/script kind of guy,  I really don't know what that entails. 


73,
Ron / W4MMP
On 8/28/2017 11:35, ag5gt@... wrote:
Ron,

The thought about keeping stdin open may be on track. From a unix/linux command line, an "echo" command could send a text string via a command line pipe. I'm envisioning your gui with buttons that trigger various actions and, in parallel, a set of text strings that can trigger the same actions. Would that be doable? I'm trying to get to something here that meshes neatly with what you want to do anyway, so it can all be implemented at the same time, rather than part now and an add-on later.

About the linux vs ms debate, I tend toward pragmatism, too. I believe the interest in linux among hams, who are hands-on problem solvers almost by definition, is that open-source accommodates such folks better than proprietary solutions. Proprietors don't want to tell us enough to fully enable us. They want to retain an advantage, and generally do. Linux is a very pragmatic means to counter proprietary leverage, to enable solutions proprietary entities find uninteresting. Occasionally, leverage can pry loose something useful. Mono may be an example.

BTW, I see great potential in what's going on here. Thank you.

Bruce, AG5GT


--
Thank you for your support and business,
73,
The Multus SDR,LLC Team,
Ron / W4MMP



--
Thank you for your support and business,
73,
The Multus SDR,LLC Team,
Ron / W4MMP

Re: Success!

Ron / W4MMP
 

Hi,
Perhaps I should start a new thread but it seems this seems like the right place for this.   Below is a screen shot of an unreleased version of MSCC. It goes to the heart of what I have been attempting to convey.   A clean simple user interface that contains just the basics of what is needed to operate a rig.  The main tab has just that.  This current version is rude, crude and not "pretty" but it gets the job done.  With this version you can "almost" minimize HDSDR and not need to look at it.  If I could convince the HDSDR developer to add a few more extensions such as controlling receive and mic transmit volume, filter bandwidth (and probably other things I have forgotten about at the moment),  HDSDR could be minimized and truly not needed to control the station. The same goes for Quisk once I figure out how to do this same thing with Quisk.

I believe this would display quite nicely on a 7 inch screen. 


--
Thank you for your support and business,
73,
The Multus SDR,LLC Team,
Ron / W4MMP

Re: Success!

ag5gt@...
 

Hi Ron,

I attempted a reply to your question about linux utilities talking, but do not see that here, so I must have messed up when posting. Essentially, my thinking was that a linux command-line utility would converse by both stdin and stdout. Then, when scripting in bash, csh, tcl, etc., command line pipes and re-direction operators could do the rest. An entire transaction could be completed on one line with simple syntax. If for example, I wanted your server to tell me the present LO frequency setting, so I could stuff it in a file, my shell command might look something like this:

echo "What is the LO Frequency" | server_name > file_name

That "echo" command works in bash. Other scripting languages have other means of spitting out text, but maybe that illustrates the general idea. One way or another, on a command line, we send your server a text message on stdin and it replies by putting a response on stdout, which we can re-direct for our own purposes.

Bruce, AG5GT

Re: Success!

Ron / W4MMP
 

Hi Bruce,

Yep, that makes sense.  Would you want the output of the server in ascii or binary?

73,
Ron / W4MMP
On 9/2/2017 13:21, ag5gt@... wrote:

Hi Ron,

I attempted a reply to your question about linux utilities talking, but do not see that here, so I must have messed up when posting. Essentially, my thinking was that a linux command-line utility would converse by both stdin and stdout. Then, when scripting in bash, csh, tcl, etc., command line pipes and re-direction operators could do the rest. An entire transaction could be completed on one line with simple syntax. If for example, I wanted your server to tell me the present LO frequency setting, so I could stuff it in a file, my shell command might look something like this:

echo "What is the LO Frequency" | server_name > file_name

That "echo" command works in bash. Other scripting languages have other means of spitting out text, but maybe that illustrates the general idea. One way or another, on a command line, we send your server a text message on stdin and it replies by putting a response on stdout, which we can re-direct for our own purposes.

Bruce, AG5GT


--
Thank you for your support and business,
73,
The Multus SDR,LLC Team,
Ron / W4MMP

Re: Success!

ag5gt@...
 

On the other line of thought in this thread, that being the longer term goal of creating a do-it-all Multus SDR, a couple of thoughts occur to me:

First, with respect to having more hooks into HDSDR, my own interaction with the HDSDR developers, a couple of years ago, left me with the impression they have a firm sense of the radio aesthetics they want to achieve. They are close to where they want to be. I wanted one more CAT command, but they had more of a minimalist's perspective; i.e., they wanted to do only what might be needed in a physical radio, no more, no less. What they have now looks nice and works well relative to its original purpose as a receiver, with efficient CPU usage, so they may be right to go slow making changes. To do otherwise risks creating a hairball that could be hard to unravel, or that might impair existing strengths. For my own HDSDR-in-Linux purposes, I made do with CAT as it exists and can't say the result suffered for the lack of my requested add-on, so they were probably right in my case. Bottom line: HDSDR is what it is, does some things really well, and ain't changing radically over time-- which is not all bad.

Second, I wonder if there are folks here who have the experience to assess the maturity and utility of libraries already created to support creation of custom sdr applications. I'm thinking that, instead of having HDSDR or Quisk reworked with more hooks to suit your purposes, might your goals be better served by building a custom signal processor, neatly integrated with mscc, using as foundation a body of work that is available open-source? Here's one candidate I discovered this week:

http://luaradio.io/  and https://github.com/vsergeev/luaradio

That appears to have been built around this:

https://github.com/jgaeddert/liquid-dsp

and this:

http://libvolk.org/about.html

both of which have somewhat limited external dependencies, and seem to have OS-portability as a focus.

I don't know much more than I can see on those two web pages, but am intrigued by the possibility we might be able to build our own sdr app, using existing lower-level building blocks. And, maybe those blocks are themselves OS and CPU-agnostic, as some of the verbiage hints.

Bruce, AG5GT