New ongoing "Development" version has been created
Re: New ongoing "Development" version has been created
>>I've change the release on 19th January to a "Stable" release.
Is it possible there was an update to the release after I downloaded it? My Radio reports under firmware info:
OpenGD77
Built
13:17:08
Jan 10 2021
[ b7ed2e1 ]
But when I look at the Jan 19th release, today, at https://github.com/rogerclarkmelbourne/ ... 1.01.19.01, I see it is labeled: e3b7357
And, I don't know enough about git to know how to find the "build time" ...
Is it possible there was an update to the release after I downloaded it? My Radio reports under firmware info:
OpenGD77
Built
13:17:08
Jan 10 2021
[ b7ed2e1 ]
But when I look at the Jan 19th release, today, at https://github.com/rogerclarkmelbourne/ ... 1.01.19.01, I see it is labeled: e3b7357
And, I don't know enough about git to know how to find the "build time" ...
Re: New ongoing "Development" version has been created
The 19th Jan version was not changed.
I only changed its designation, on the server from where its downloaded, from Beta to Release.
We have not been adding any major new features for a long time, and the last few releases have mainly focused on fixing bugs.
I have not had any reports of serious problems with the 19th Jan version and hence it could therefore be re-labelled as a full / stable release.
There is nothing in the firmware build time or git revision related to build type, as that sort of information is not in the firmware.
In fact, there is nothing in my build process where I specify a Beta or Release type.
I just build the firmware, and it only becomes clear after weeks of initial testing, then weeks of user testing, whether its stable enough to be changed to a Stable release.
The firmware is incredibly complex. Literally tens of thousands of lines of code, and its not possible to foresee problems that may be caused, even by the most innocuous of changes.
And as the functionality is so huge and complex, with many people only using a small subset of the functionality, its not possible to to complete testing before the Beta is released, as it would take hundreds of hours of effort.
And even after the firmware is released as a Beta, it can take many weeks before bugs are spotted in the more obscure sections of the functionality.
I only changed its designation, on the server from where its downloaded, from Beta to Release.
We have not been adding any major new features for a long time, and the last few releases have mainly focused on fixing bugs.
I have not had any reports of serious problems with the 19th Jan version and hence it could therefore be re-labelled as a full / stable release.
There is nothing in the firmware build time or git revision related to build type, as that sort of information is not in the firmware.
In fact, there is nothing in my build process where I specify a Beta or Release type.
I just build the firmware, and it only becomes clear after weeks of initial testing, then weeks of user testing, whether its stable enough to be changed to a Stable release.
The firmware is incredibly complex. Literally tens of thousands of lines of code, and its not possible to foresee problems that may be caused, even by the most innocuous of changes.
And as the functionality is so huge and complex, with many people only using a small subset of the functionality, its not possible to to complete testing before the Beta is released, as it would take hundreds of hours of effort.
And even after the firmware is released as a Beta, it can take many weeks before bugs are spotted in the more obscure sections of the functionality.
Re: New ongoing "Development" version has been created
Very impressive change-list, thank you again.
However, one problem remains causing me to stuck with the last 2020 release. I've already commented it in reaction to OK1ICQ's post here: http://opengd77.com/viewtopic.php?f=7&t ... 084#p13084
Also VK7JS reported that in this thread few posts above.
The trx mode announcement before announcing the channel name stops me from using my ht effectively so I had to downgrade despite all the amazing stuff introduced this year.
Please, do you consult the major changes to the voice prompts with some users which are depending only on the VP feature (typically the blind and drivers), or do you just guess the best workflow on your own?
However, one problem remains causing me to stuck with the last 2020 release. I've already commented it in reaction to OK1ICQ's post here: http://opengd77.com/viewtopic.php?f=7&t ... 084#p13084
Also VK7JS reported that in this thread few posts above.
The trx mode announcement before announcing the channel name stops me from using my ht effectively so I had to downgrade despite all the amazing stuff introduced this year.
Please, do you consult the major changes to the voice prompts with some users which are depending only on the VP feature (typically the blind and drivers), or do you just guess the best workflow on your own?
Re: New ongoing "Development" version has been created
I appreciate ALL you and Roger are doing. And since people are whining, I just wanted to say so without complaining.
es vy 73 om de "baab" w9ya
es vy 73 om de "baab" w9ya
Re: New ongoing "Development" version has been created
User Guide has been updated with information about the current functionality of the Eco Levels
https://github.com/rogerclarkmelbourne/ ... #eco-level
And also the QuickKeys
https://github.com/rogerclarkmelbourne/ ... -quickkeys
Also.
I've found a bug with the DMR Tx frequency calibration control, which seems to affect the Baofeng DM1801, and may effect the Baofeng RD5R
https://github.com/rogerclarkmelbourne/ ... issues/902
I've investigated the problem for about 8 hours today, but I don't have a solution yet.
However, its unlikely to affect anyone, unless they have multiple radios that they want to use with the same hotspot, and the DM1801 need extra calibration to make the DMR Tx frequency match the DMR Tx frequencies of other radios.
And.
There appears to be some problem with the RD5R DMR transmit pulse envelope, at the beginning of the 30ms DMR Tx pulses.
I suspect this is why the RD5R seems to need more Tx power access repeaters than other radios, like the GD-77.
I don't think the Baofeng DM1801 has the same problem.
I think the problem is probably related to the RD5R being originally designed as a Tier 1 radio, and is not fully capable of modulating the PA on and off ever 30 milliseconds
Its possible that the official firmware does some trick, like leaving the PA enabled during the non-transmitted timeslot, or perhaps does not enable the receiver in the non-transmitted timeslot.
However, its going to take considerably more time for me to attempt to analyse what could be causing this problem.
https://github.com/rogerclarkmelbourne/ ... #eco-level
And also the QuickKeys
https://github.com/rogerclarkmelbourne/ ... -quickkeys
Also.
I've found a bug with the DMR Tx frequency calibration control, which seems to affect the Baofeng DM1801, and may effect the Baofeng RD5R
https://github.com/rogerclarkmelbourne/ ... issues/902
I've investigated the problem for about 8 hours today, but I don't have a solution yet.
However, its unlikely to affect anyone, unless they have multiple radios that they want to use with the same hotspot, and the DM1801 need extra calibration to make the DMR Tx frequency match the DMR Tx frequencies of other radios.
And.
There appears to be some problem with the RD5R DMR transmit pulse envelope, at the beginning of the 30ms DMR Tx pulses.
I suspect this is why the RD5R seems to need more Tx power access repeaters than other radios, like the GD-77.
I don't think the Baofeng DM1801 has the same problem.
I think the problem is probably related to the RD5R being originally designed as a Tier 1 radio, and is not fully capable of modulating the PA on and off ever 30 milliseconds
Its possible that the official firmware does some trick, like leaving the PA enabled during the non-transmitted timeslot, or perhaps does not enable the receiver in the non-transmitted timeslot.
However, its going to take considerably more time for me to attempt to analyse what could be causing this problem.
Re: New ongoing "Development" version has been created
The latest Beta version seems to be causing the CPS a problem on Windows 10.
I think its something to do with the USB communications speed being reduced, because of another bug fix in the Beta release. This is not related to the Eco Levels, the CPS may fail on W10 regardless of Eco Level.
I think its something to do with the USB communications speed being reduced, because of another bug fix in the Beta release. This is not related to the Eco Levels, the CPS may fail on W10 regardless of Eco Level.
Re: New ongoing "Development" version has been created
I have released a new version of the CPS which should work with the latest firmware, but currently I had to do a temporary work-around to fix problems on Windows 10, which has caused both reading and writing of the codeplug to be much slower.
See
https://github.com/rogerclarkmelbourne/ ... 1.02.15.01
I will need to rewrite large sections of the communications between the CPS to fully resolve this problem
This release also fixes a bug with the DMR Tx frequency on the Calibration screen
See
https://github.com/rogerclarkmelbourne/ ... 1.02.15.01
I will need to rewrite large sections of the communications between the CPS to fully resolve this problem
This release also fixes a bug with the DMR Tx frequency on the Calibration screen
Re: New ongoing "Development" version has been created
Do I really need that new version, if previous (2021.01.03.02) is working fine for me? I'm on Win 10 pro 20H2 build 19042.804.VK3KYY wrote: ↑Mon Feb 15, 2021 10:25 amI have released a new version of the CPS which should work with the latest firmware, but currently I had to do a temporary work-around to fix problems on Windows 10, which has caused both reading and writing of the codeplug to be much slower.
See
https://github.com/rogerclarkmelbourne/ ... 1.02.15.01
I will need to rewrite large sections of the communications between the CPS to fully resolve this problem
This release also fixes a bug with the DMR Tx frequency on the Calibration screen
New one (2021.02.15.01) is almost twice slower. Not that I really care if it takes 8 or 15 seconds.
Re: New ongoing "Development" version has been created
No. The fix was for some W10 machinesYT5HOK wrote: ↑Mon Feb 15, 2021 2:43 pmDo I really need that new version, if previous (2021.01.03.02) is working fine for me? I'm on Win 10 pro 20H2 build 19042.804.VK3KYY wrote: ↑Mon Feb 15, 2021 10:25 amI have released a new version of the CPS which should work with the latest firmware, but currently I had to do a temporary work-around to fix problems on Windows 10, which has caused both reading and writing of the codeplug to be much slower.
See
https://github.com/rogerclarkmelbourne/ ... 1.02.15.01
I will need to rewrite large sections of the communications between the CPS to fully resolve this problem
This release also fixes a bug with the DMR Tx frequency on the Calibration screen
New one (2021.02.15.01) is almost twice slower. Not that I really care if it takes 8 or 15 seconds.
If you don't have the problem you don't need it.
I will attempt to make a better fix which works with the latest Windows 10 but is not slooooow