Radio firmware version

Doug - K3TZR

I'm working on a new client program for the Mac (based on a Mac version of SmartSDR API). I'm trying to understand how the firmware versioning works.

I know that the radio reports a Version Number when you send it a "version" command. I also know that your API has a version number. I've read here on the site that the first three numbers must match (e.g. with radio version a.b.c.d, and API version e.f.g.h, therefore a=e, b=f, c=g is the test for "version is acceptable").

My question is are they always in "lock-step", i.e. strict equality or would a newer (higher number) API be expected to work with an older (i.e. lower number) Radio? Another way of saying, are the changes cumulative and do they leave the older functions "as-is"?

I haven't looked yet but I'm assuming that the firmware code is buried somewhere in the download of the latest Windows client. That's my next step, to find it and see if I can incorporate the update process in my client's code.

Thanks for your help.

Walt - KZ1F

If you run on Windows the answer is a guarded yes as you can't install the latest ssdr without updating the radio.
If you use a Linux, Mac, Android, iPad they almost certainly become different. People will almost need to keep a Windows image around just to upgrade the radio's soft/firmware. My core library will upload the new firmware however that is more for 100% compatibility than any expectation someone would want to.

Doug - K3TZR

Hi Walt,

So where is the firmware? I took a look at the SmartSDR API download and I don't see anything in there. Is it somehow embedded in the Windows exe?

Walt - KZ1F

I assume it's firmware as I don't hear a disk spinning in the radio. From what I can tell, it is dropped onto your current drive when you install the latest ssdr. Since FRS isn't making that open source it is difficult to know precisely what happens when you depress 'Upgrade' but there is logic in flexlib to pump several file types into the radio. In the case of windows, it is buried under ProgramData, a hidden dir off of c:. I don't know if this is where they keep everything, just some things. This is why I said even if you run on Linux, or Android, or Mac or Raspberry Pi, you will need an image of Windows just to have a current SSDR and upgrade the radio. Allegedly, the upgraded radio will work with back leveled SSDR. Some of the upgrades to SSDR are bug fixes and seeing the new FlexLib code will allow you to see the fixes. For features though, you need more than the code, you need to see how / if it is implemented in the UI. So, yeah, you'll need to have a legacy SmartSDR hanging around. I say that, primarily, because I use Linux and Android. Once done with the portable GUI, my laptop capable of booting to Windows will boot there about once a year come TurboTax time, except for keeping up with FRS on features and bugs.

Walt - KZ1F

Doug, the radio reports the version number on discovery as well. This is how it is you see it on the discovery dialog when initially choosing a radio to use. The other side of that, should you have a current FirmwareRequiredVersion.? is this, effectively, header file lists the required version. An issue I ran into when first running my version of SSDR is the software immediately wanted to do a downgrade on the radio as the version of that file FRS ships is not the one they built the software with. Sooooo, you likely will hit that issue. So be sure to change the required_version UInt64 to what the radio actually is using, adjusting for the internal format issue.

Stu Phillips - K6TU

Doug,

Why are you trying to implement the firmware update process in your client?  I would hate to be the source of bricking someones radio due to an error in the update process.  At the very least, wouldn't the use of a third party updater either violate warranty or even violate FlexRadio's copyright on the binary being installed in the radio?

I think there are some things (like radio firmware upgrade) that should be left to the manufacturer and their discretion, procedures, rights etc.

From an API perspective, which I believe you and all others should confine themselves (as do I BTW), it has a version number that is part of the connection process.  In general, the API is NOT backward compatible - a radio with a down rev versions string on the API will not behave the same way as the latest version.

You have two choices - figure out how to manage down rev radios (which I have chosen to do in the Objective C interface library to a limited extent) or tell the user that an upgrade is necessary.

My observation is that most Flex 6000 users are comfortable with upgrading to the newest release of the radio firmware because of the strong QA job that FlexRadio Systems does in conjunction with its alpha software test group.  

So within a short period of time, a very high percentage of the installed base has moved to the newest release.

Stu K6TU

Stan VA7NF

Stu, perhaps you could expand on how you currently handle the rev versions string as there will be changes to both the .14 and .11 coming soon. (No I don't have any release schedules, just it will be coming).

Better now than when these apps break.

Walt - KZ1F

Doug, as I said previously, if the firmware versions do not match that will force the SSDR program into doing, or wanting to do, an up/down grade. I reported this as a bug, as FRS was not shipping the version of FirmwareRequiredVersion.cs that they use for the released software. Eric said they would do that going forward. So, where right now I ignore that difference, going forward I will honor it.

The min/max versions you will find in Radio.cs at line 229/230. You can see where Flexlib tests that in Radio::2212. If you are working with the core library Stu did they may not be there at all. As I said my core library (FlexLib facsimile)  is 100% compatible with the FRS FlexLib. Obviously Windows is unique with C: nomencature so mine uses a more OS independent solution for where files are stored and/or retrieved.
As I said, it may not make sense for someone running on Linux, Android, iPad, Mac, et al. to initiate a firmware upgrade. This is why it makes sense to hang onto a Windows image for just such occasions. Again, I do not know if in the Objective C version of Flexlib those facilities even exist. That would be a Stu question. But, to your initial question you will want to keep them in sync either in absolute terms or at least close. A quick email to steve@flexradio will resolve the backwards compatibility of radio code to control surface code. I would have to find where he said that, if I really must. It was either in an email to me or post to the community.

As an addendum to Stu's comment of only two choices, there is a third. Ensure the core library you use, be it Objective C or my portable library is current with the feature set of the FRS Flexlib. That means a fair amount of playing catchup on the part of another vendor's flexlib replacement.

Stu Phillips - K6TU

The parser in my Objective C code (equivalent to Flexlib) is designed to ignore keyword/value pairs that is doesn't understand and continue to work with what it does).

Flexlib for any particular release behaves the same way but SmartSDR (the client) checks to see whether the radio has the firmware load it requires.  So easier for FlexRadio to avoid this problem.

So generally, changes result from new functionality that has been added.

The API version number tells you whether a change has been made but some changes haven't rev'd the version number.  Its really not that big a deal to cope with.

Stu K6TU

Doug - K3TZR

Walt,

After thinking about it and talking with Stu I think firmware upgrades are best left to Flex-provided software. I don't want to brick anyone's radio and force the user to return it to Flex for service.

If we're lucky and there is a significant group of OS X client users in the future, perhaps we can ask Flex to take a little time out of their schedule to provide a standalone OS X based firmware loader.

Walt - KZ1F

I believe I've been saying that all along,perhaps a little differently, where it is not a question of if it can work or brick the radio, just there is something to be said for keeping the radio in sync with the mated version of SSDR. If you are using Stu's Objective C flexlib and it doesn't support uploading files to the radio, that, alone, pretty much ends the conversation.

I suspect everything that is in the FRS FlexLib is all that is necessary. As we don't have the code in SSDR to see what happens in the event "Update" is depressed and we don't have the code running in the radio to see what happens when it receives turf files. I actually have done this in software (vendor firmware upgrades) for commercial software and haven't lost a patient yet.

The danger is if FRS were to individually release the upgrade file for the radio then yes, they would potentially have a lot of people not knowing what they were doing break their radios. I do suspect a factory reset would reset the firmware back to V0.92 or however the radio shipped.

If I were to put money on it, they'd release a java based solution so all platforms (except for iPad) could upgrade the radio. Actually, that is not a slight against iPad, simply you don't want anything battery powered doing firmware upgrades. Even Apple warns the phone must be plugged in before upgrading it. I'd put even more money on they'd never do it at all...ever.

Lee - N2LEE

Doug I am very interested in your work on a Mac client. How can I keep in touch to discuss your efforts.

Travis Best

Doug, I am very interested in what your trying to do on the MAC and if your looking for anyone to test I am open to it

Doug - K3TZR

Lee & Travis,

I'll post updates here as things progress. This process is a long and tedious one, first you need the equivalent of Flex API to interface to the radio and then you need the actual Client to provide the UI (i.e. the replacement for SmartSDR).

There are a number of people in various stages of development on the Flex API part. At the same time I'm working on the UI part. When I have something to test I would be happy to share it and solicit comments.

Mike - ZL1MRC

Hello,
Please add me to the list of the beta tester.

Thanks
Mike

Michael Coslo

I'd also love to test it for you. Having to install and run Windows on my Mac reminded me of why I left. - 73 Mike N3LI -