New ongoing "Development" version has been created

Locked
IU8OGE
Posts: 65
Joined: Tue Sep 29, 2020 3:35 pm

Re: 10/25 pre-release issue

Post by IU8OGE » Sun Oct 25, 2020 10:59 pm

VK3KYY wrote:
Sun Oct 25, 2020 10:42 pm

So, as you can see, nothing is ever as simple as it looks!
you completly right

W1CY
Posts: 76
Joined: Sun Jan 12, 2020 6:57 pm

Re: 10/25 pre-release issue

Post by W1CY » Mon Oct 26, 2020 2:30 am

VK3KYY wrote:
Sun Oct 25, 2020 10:42 pm
W1CY wrote:
Sun Oct 25, 2020 7:41 pm
Second time was a charm... I tried it again today, but instead of using the standalone firmware loader I used the new 10/24 CPS. It worked fine and the radio is operational. Not sure whether it was a coincidence or whether using the CPS loader made a difference or not. The bottom line is that everything is working now. Thanks again for your support.

FYI.

Its a long boring story about the change to the release method and the CPS, but just to explain in more detail

Originally the CPS and the Standalone downloader, "Screen scrape" the Github Releases page, searching for specific things on the web page, specifically a version code that looks like a release , e.g. R2020.10.10 or a development release e.g. D2020.09.27

However to support displaying a list, using screen scraping was no longer practical.

So my first attempt at building a list of releases, was by using the RSS feed available on Github, and I spend several hours battling with this data format, only to discover that it didn't actually contain the release version (aka release_tag) . This was an arrrghh moment, as I'd just wasted over 3 hours on this.

I then found Github also has an API download , which does contain this data

https://api.github.com/repos/rogerclark ... 7/releases

So I had to then rewrite all my code to use this data forum instead. Probably around 2 hours work.
Just to complicate matters, I then found that the Micosoft built in data parser for the API data format (called JSON), is not compatible with Linux , so the Standalone installer could not be used on Linux...

Yet another aarggghh moment.

Luckily, I found a third party plugin (DLL), that could parse JSON format, and was also compatible with the build process that Daniel F1RMB uses to make the Linux version of the standalone firmware loader.


But, here's the kicker as they say...

When I looked at the list of release names using the new loader in the CPS I noticed that the older releases didn't have proper names and I'd simply put the release version in the Release Title.

But when I corrected this on Github by editing the title on the old releases. Github decided that these old releases now needed to be displayed above the newer releases, on the Releases web page, which the Standalone Loader still uses.

IMHO, this is a bug on Github, as editing some text about a release should not make it the latest release.

I partially fixed this, by re-editing the newer releases to change the title to include the year "2020" but I think somehow the old Firmware loader is still incorrectly detecting some old releases as if they are new releases :-(



So, as you can see, nothing is ever as simple as it looks!
WOW, more than I imagined. Thanks for your great work in enhancing and maintaining this FW.

VK3KYY
Posts: 7478
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: New ongoing "Development" version has been created

Post by VK3KYY » Mon Oct 26, 2020 5:57 am

Yet another development version update with more bug fixes.

https://github.com/rogerclarkmelbourne/ ... 2020.10.26


Changes since last development release

* Removed 220 Mhz frequency range from band limits when using the CPS setting. (Bug fix, as the range should not have been included)
* Change to All Channels zone after codeplug is uploaded by the CPS, to overcome problems where the current Zone or Current Channel has been deleted from the codeplug in the CPS.
* Fix All Channels name displaying only displaying 15 instead of 16 characters.
* Add system to cache the channels allocation data table.
* Other bug fixes to prevent crashes if the codeplug contains invalid data
* Other code cleaning.

Thanks to Daniel F1RMB for all his work with this update.


This update is available via the updated CPS

User avatar
f6fzo
Posts: 72
Joined: Sat Jan 04, 2020 7:28 am

Re: New ongoing "Development" version has been created

Post by f6fzo » Mon Oct 26, 2020 6:28 am

ok et merci :D

User avatar
Ik0nwg
Posts: 242
Joined: Sat Nov 16, 2019 7:23 am
Location: JN61VG
Contact:

Re: New ongoing "Development" version has been created

Post by Ik0nwg » Mon Oct 26, 2020 10:05 am

VK3KYY wrote:
Mon Oct 26, 2020 5:57 am
Yet another development version update with more bug fixes.

https://github.com/rogerclarkmelbourne/ ... 2020.10.26


Changes since last development release

* Removed 220 Mhz frequency range from band limits when using the CPS setting. (Bug fix, as the range should not have been included)
* Change to All Channels zone after codeplug is uploaded by the CPS, to overcome problems where the current Zone or Current Channel has been deleted from the codeplug in the CPS.
* Fix All Channels name displaying only displaying 15 instead of 16 characters.
* Add system to cache the channels allocation data table.
* Other bug fixes to prevent crashes if the codeplug contains invalid data
* Other code cleaning.

Thanks to Daniel F1RMB for all his work with this update.


This update is available via the updated CPS
CPS and firmware from October 26th installed .... everything seems to work correctly .... At this point Roger only needs that this radio can make coffee !!! Of course, thanks to all the team you are fantastic !!!
ciao Roger

VK3KYY
Posts: 7478
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: New ongoing "Development" version has been created

Post by VK3KYY » Mon Oct 26, 2020 10:15 am

Hi Sal

Daniel is investigating a possible problem with this when there are a lot of channels.

I have not noticed this bug, but if you have any problems, please reload the version from yesterday

User avatar
Ik0nwg
Posts: 242
Joined: Sat Nov 16, 2019 7:23 am
Location: JN61VG
Contact:

Re: New ongoing "Development" version has been created

Post by Ik0nwg » Mon Oct 26, 2020 10:23 am

VK3KYY wrote:
Mon Oct 26, 2020 10:15 am
Hi Sal

Daniel is investigating a possible problem with this when there are a lot of channels.

I have not noticed this bug, but if you have any problems, please reload the version from yesterday
227 channels stored in my radio .... everything seems to work correctly ... if you tell me what is the bug to check I will do some targeted tests ...

VK3KYY
Posts: 7478
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: New ongoing "Development" version has been created

Post by VK3KYY » Mon Oct 26, 2020 10:41 am

Hi Sal

I will do some more testing, I think perhaps there is some processing of Zone number inside the firmware, and I need to contact Colin G4EML to ask some questions about the zones.

VK3KYY
Posts: 7478
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: New ongoing "Development" version has been created

Post by VK3KYY » Mon Oct 26, 2020 10:52 am

Hi Sal

Actually, perhaps you can test making some new channels from the VFO.

I did some tests and it worked OK for me.

FYI.

The official codeplug format is very fragmented.

Channels 1 to 128 are stored in the EEPROM, but channels 129 - 1024 are stored in Flash memory.
We think this is because the codeplug format comes from some much older radios which only had 128 memories and only the EEPROM for data storage.

Also, the CPS does not compact the channels data. So when you delete a channel it does not move all the channels down to fill that space, it just has an empty / unused channel.


So in the firmware when using VFO -> New Channel, it will use the first available unused channel location, (the same as the CPS)

If the channel number is 1 to 128 this is in the EEPROM, but if the new channel is in number 129 - 1024 it is stored in the Flash memory.


So if you make some new channels in different zones, perhaps you can check this works OK for different zones and also for channels below 128 and also channels above number 128

Thanks

Roger

User avatar
Ik0nwg
Posts: 242
Joined: Sat Nov 16, 2019 7:23 am
Location: JN61VG
Contact:

Re: New ongoing "Development" version has been created

Post by Ik0nwg » Mon Oct 26, 2020 1:03 pm

VK3KYY wrote:
Mon Oct 26, 2020 10:52 am
Hi Sal

Actually, perhaps you can test making some new channels from the VFO.

I did some tests and it worked OK for me.

FYI.

The official codeplug format is very fragmented.

Channels 1 to 128 are stored in the EEPROM, but channels 129 - 1024 are stored in Flash memory.
We think this is because the codeplug format comes from some much older radios which only had 128 memories and only the EEPROM for data storage.

Also, the CPS does not compact the channels data. So when you delete a channel it does not move all the channels down to fill that space, it just has an empty / unused channel.


So in the firmware when using VFO -> New Channel, it will use the first available unused channel location, (the same as the CPS)

If the channel number is 1 to 128 this is in the EEPROM, but if the new channel is in number 129 - 1024 it is stored in the Flash memory.


So if you make some new channels in different zones, perhaps you can check this works OK for different zones and also for channels below 128 and also channels above number 128

Thanks

Roger
I entered about 30 new channels from the radio (mixed analog / digital) in various areas ..... the numbering he gave to the new memories were both under the number 128 and above ...... I read the radio with CPS .... I reloaded the codeplug just saved with the new memories .... I did some scanning tests in the various areas ..... I deleted all the new memories from the CPS and I sent everything back to 77 .. .... I HAVE NOT DETECTED ANY PROBLEM
Grazie Roger

Locked