Topics

[QRPLabs] Software extensions


Jack, W8TEE
 

Absolutely!

I have the protocols used for Icom, Kenwood, and Yaesu which probably should give us a good starting point. We need to ask ourselves: Do we want to really create a unique command protocol, or do we want to take an existing protocol and make the "rig end" fit the radios we're interested in? In other words, write it in such a way that it can be used by the existing software base (e.g., Ham Radio Deluxe, Fldigi, etc.). I wrote a simple CAT program for the X1M xcvr years ago, but never went anywhere with it. The X1M used the same protocol that was used for the Icon 718, which could then be used with Ham Radio Deluxe. I was writing a PC program in VIsual Studio using C# so the user could avoid spending $100 on the PC-end software. Personally, I think it makes sense to work with at least a subset of one of an existing protocol, as that would give us software that we can use as a test bed. Personally, I don't use CAT right now, so I don't know what the "most popular" protocol is, but it can't be that hard to find out. That would simplify the "out" end of the link. My ultimate goal is to do away with the PC and have the output controlled by a TFT display and perhaps a 5" or 7" color display. (I don't want to have to take a tablet with me if I want to operate from a canoe.)

The "in" end would depend on the code that is to sit on the microcontroller. That code needs to be as skinny as possible and still do the work. Truth be told, that microcontroller will likely have other work to do, so we need this code to co-exist with the other code in the program. That suggests a library approach to the problem. While this won't be a requirement, I will be doing my work within the confines of the Arduino IDE since it uses C-C++,  is free, but supports multiple processors. Personally, I don't see a member of the Arduino family being up to the task. That leaves the STM32F, ESP32, and Teensy families from which to choose. My Projects book uses all three, but I'm losing interest in the ESP32, mainly because its boards and pin layouts are all over the map. (Some boards have 30 pins, others have 36 or 38 pins which makes it hard on the reader to buy the "right" one.) That's sad, because the ESP32 has great resource depth. The STM32F series are cheap, yet are markedly more powerful than the Arduinos. Hans chose the STM32F4 series for the QSX. The Teensy is an h-bomb for the task, but costs $20 for the T4. Rock...hard place...

I think the first task is to determine what software can work with which protocols. You guys doing CAT work already can help here. The next thing we need to do is determine the "must have" commands and get those working first. Once those work, extensions are easy. Then I would see the group working on an Application Programming Interface (API) that is generic enough to use with different controllers. That way, even if the code is not Open Source, someone like Hans might take our API and compile it into their code. We could then use those API hooks to control their xcvr.

Finally, I would suggest moving this thread either to a new group or the softwarecontrollerhamradio group, as someone has already suggested. (BTW, I own that group and started it several years ago, so moving this discussion to that group is fine with me.) There's no reason to clog Hans' group. If you want to participate in this discussion further and are not a member of that group, I hope you'll join it.

Let's close the thread here and consider it moved to the softwarecontrollerhamradio group.

Jack, W8TEE

On Friday, December 20, 2019, 6:06:03 AM EST, jmh6@... <jmh6@...> wrote:



Hi Jack,

    I would consider code size and simplicity for any protocol we consider.

    Lots of fun :).



On Thu, 19 Dec 2019, jjpurdum via Groups.Io wrote:

> We may have to start a separate group for this topic.
>
> Jack, W8TEE
>
> On Thursday, December 19, 2019, 2:26:51 PM EST, Jim Manley <jim.manley@...> wrote:
>
>
> Hi Jack, et al,
> I would love to contribute to this effort and will start perusing the links provided to get up to (some?) speed during the holiday break, while trapped at my in-laws for
> nearly two weeks in the place with the coldest average temperatures in at least the lower 48.  There isn't even skiable snow, although drifts can get to around 24 feet that
> allow skiing from upper-story windows ... assuming you're in a multi-story building!
>
> 73_Animated_GIF.gif
> Jim  KJ7JHE
> Lame Deer High School Amateur Radio Club  KJ7JKU
>  
>
> On Thu, Dec 19, 2019 at 11:46 AM Arv Evans <arvid.evans@...> wrote:
>      Jack
>
> This might be interesting.  It is open-source and readily available.
>
> https://www.systutorials.com/docs/linux/man/1-grig/
>
> https://hamlib.github.io/
>
> This has been around in UNIX and Linux systems for many years.  It is easy
> to use and is customizable for various rigs by simply linking to the appropriate
> Hamlib library.   Resistance to it may be because there is no glory in using
> already available methods. 
>
> Arv  K7HKL
> _._
>
>
>
>
>
> On Thu, Dec 19, 2019 at 9:17 AM jjpurdum via Groups.Io <jjpurdum=yahoo.com@groups.io> wrote:
> OK. We'll keep looking around...
>
> Jack, W8TEE
>
> On Thursday, December 19, 2019, 10:45:49 AM EST, <jmh6@...> wrote:
>
>
>
> Hi Jack,
>
>     The only docs I have are a very old product manual that does not have
> the whole thing. Gotta get into some 6502 and 8052 code and then do some
> writing.
>
>     Most stuff will be re-discovered once an open CAT protocol is being
> used.
>
>     Works well. It is still being used by a dual 3.25 inch floppy IBM PC
> Clone for automated product testing. PC code was written in Power Basic.
>
>     Very old stuff!! lol!!
>
>     Lots of fun :).
>
>
> On Thu, 19 Dec 2019, jjpurdum via Groups.Io wrote:
>
> > I'll start collecting stuff as I can. If you have docs on your NIWire, I'd
> > like to see it. If anyone else has related docs, please send them to me.
> >
> > Jack, W8TEE
> >
> > On Wednesday, December 18, 2019, 6:29:55 PM EST, jmh6@...
> > <jmh6@...> wrote:
> >
> >
> >
> > Hi Jack and All,
> >
> >     I think a new simpler open CAT type interface is all that will really
> > work? Right now there is a very confusing mess of different protocols all
> > of which seem radio-centric rather than CAT centric.
> >
> >     Since you are into writing documents, how about doing a first crack at
> > an 'open' CAT centric standard that we can all comment on?
> >
> >     Our products used a 'simple' protocol we called NIWire that worked
> > pretty well, had a small software footprint and seemed to work reliably. I
> > doubt that it would be suitable as a 'standard', but it was simple both as
> > to signals on the wire and code complexity.
> >
> >     Lots of fun :).
> >
> >
> > On Wed, 18 Dec 2019, jjpurdum via Groups.Io wrote:
> >
> > > Arv:
> > >
> > > I agree. I know there are products out there being sold that use Open
> > Source software, including my own. Still, I made that decision when I made
> > it Open Source. My theory
> > > is that, if someone stands on my shoulders and makes something I started
> > better for everyone, we all win. However, I do get a little miffed when
> > someone takes something
> > > that is not Open Source and either sells it (M0NKA's SDR transceiver) or
> > gives it away (my books on torent sites).
> > >
> > > I do think the CAT interface does offer a way to extend the software
> > without making all of it Open Source. It appears that we are slowly
> > standardizing the CAT protocol. I
> > > would like to see the community pull together and formalize a CAT
> > interface. It would require support from The Big Three and that could
> > dissolve into a pissing contest. If
> > > that happens, I say screw 'em and we as users form our own CAT standard
> > interface. (If this is all Greek to you, check out
> > http://www.plicht.de/ekki/civ/civ-p41.html for a
> > > simple way to specify a series of CAT commands.)
> > >
> > > For CAT to work, processors need to be on the "radio end" and the "user
> > end" of the CAT connection. For Hans QSX, the radio end will be a processor
> > in the STM32F4 family.
> > > On the user end, it could be whatever the user wants. Me? I plan on having
> > a touch screen waterfall display that doesn't rely on a PC. It will be a
> > self-contained SDR a la
> > > M0NKA or the G-90. For others, write a PC program in your favorite
> > language that can read ASCII data from a port and do whatever you want with
> > the data you get via CAT.
> > >
> > > All of this could be super cool stuff. I know Al and I are going to dig
> > into it when the dust settle a bit.
> > >
> > > Jack, W8TEE
> > >
> > >
> > > On Wednesday, December 18, 2019, 3:45:59 PM EST, Arv Evans
> > <arvid.evans@...> wrote:
> > >
> > >
> > > Jack
> > >
> > > Well-said.  You made it very clear what the pro's and con's are regarding
> > giving away
> > > intellectual property versus securing said property.   Micro-controller
> > based systems are
> > > particularly problematic because some of the micro-controller chips can be
> > read back
> > > and copied at the bit or byte level.  The AVR is one of the
> > micro-controller chips that
> > > does have fuse bits that can be used to help protect the device from being
> > copied. 
> > >
> > > We are seeing some of this problem over on the BITX discussion group,
> > where individuals
> > > have made their own junk-box variations of the hardware, modified the
> > open-source software,
> > > and now seem to expect that Farhan will troubleshoot their mistakes. 
> > >
> > > Micro-processor ICs that do not have built-in copy protection have to rely
> > on "mouse-
> > > traps" that use hidden code to erase or mutilate the code if it is
> > tampered with. 
> > >
> > > Since recent trends seem to indicate that even homebrew rigs need to
> > support some form
> > > of CAT control, maybe that is where the user customization needs to
> > reside.  If there
> > > is an adequate set of basic functions, then maybe user code in the CAT
> > software could
> > > allow those who want something else could add that feature or function?
> > >
> > > Arv
> > > _._
> > >
> > >
> > > On Wed, Dec 18, 2019 at 7:58 AM jjpurdum via Groups.Io
> > <jjpurdum=yahoo.com@groups.io> wrote:
> > > Everything I've written since I retired is Open Source and, for me at
> > least, doing so is a true dilemma. That is: Two choices, both bad. I'll bet
> > Hans has waded
> > > through the same decision-making process.
> > >
> > > If you make your code Open Source, you lose control of it and it does end
> > up being stolen, sometimes for profit. Even worse, some people will attempt
> > to modify your
> > > code and, when it doesn't work, they actually have the audacity to ask you
> > to fix it...for free! Not good...not fair.
> > >
> > > On the other hand, if you don't make it Open Source, some people think
> > you're a Grinch because they can't make your code do exactly whatever it is
> > they want it to
> > > do.  They, too, want you to add such-and-such a feature, but fail to
> > realize there are not a lot of deaf, blind, people who only speak Latin.
> > (The Grinch Factor, to
> > > me, is a myth. It's my code...you don't like it, write your own.)
> > >
> > > So, what's the answer? First of all, given what Hans has managed to stuff
> > into a Nano, there can't be more than a few bytes left. So, my guess is that
> > putting
> > > something in means taking something else out. For most of us, that means
> > "Leave it alone." However...
> > >
> > > The QSX is going to be another beast altogether, since it will be using
> > the STM32F4 series of microcontroller. Hans has some headroom there because
> > of the memory
> > > resource depth and a faster clock. Yet, from Hans' perspective, how does
> > he address the dilemma of lost control versus the Grinch factor? I think the
> > best solution is
> > > an API--Application Programmer Interface. An API provides entry points to
> > methods that allow you to extend the functionality of the program in much
> > the same way that
> > > libraries allow you to extend the Arduino core. The downside is that it
> > takes a lot more effort on Hans part to provide an API for us.
> > >
> > > So...what's the correct answer from everyones' standpoint? I don't have a
> > clue.
> > >
> > > Jack, W8TEE
> > >
> > >
> > >
> > > On Wednesday, December 18, 2019, 9:23:11 AM EST, R. Tyson via Groups.Io
> > <tysons2=btinternet.com@groups.io> wrote:
> > >
> > >
> > > Hi,
> > > As pointed out in another post I doubt there is sufficient memory left.
> > The radio has a remarkable set of facilities and Hans has done a brilliant
> > job on it.
> > >
> > > Someone suggested that the software should be open source... that would
> > enable others to produce cloned versions of Hans' work - in effect he does
> > the work and
> > > someone else steals it and profits from it.
> > >
> > > Tuning up and own the band is good exercise - I remember when we had to
> > get out of our chair and walk across the room to change T.V. channels and
> > there were only 2 or
> > > 3 of them.
> > >
> > > The facilities available from these little radios is amazing but there is
> > not the infinite capacity to keep adding stuff from "wish lists".
> > >
> > > Reg              G4NFR
> > >
> > >  
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>



--
Jack, W8TEE


Paul Galburt - K2AYZ
 

Jack,

Could you provide a link this this new group - I can't find it.

73,

Paul K2AYZ


Jack, W8TEE
 

On Saturday, December 21, 2019, 1:01:50 PM EST, Paul Galburt - K2AYZ <galburt@...> wrote:


Jack,

Could you provide a link this this new group - I can't find it.

73,

Paul K2AYZ

--
Jack, W8TEE