Hello all!
I'm a software engineer/architect that is very new to DMR (and ham radio in practice if I'm being honest). Just picked up a GD-77 and almost immediately updated the firmware to OpenGD77. Thusfar this is way better than the stock firmware! Thank you all.
73,
Keith
K4ITH
Greetings!!
Re: Greetings!!
Welcome Keith.
The firmware is better in a lot of functionality, however because of the complete lack of good documentation on the hardware, there are still a number of problems which we have not been entirely able to resolve.
Also, there are some large blocks of functionality which are yet to be written.
SMS, and battery economy modes.
I know one developer is working on his own and has had some success with sending and receiving some SMS, however I don't have his code at the moment and may never receive it.
I doubt if personally I'll ever have time to write the SMS functionality as its an complex and non-documented protocol, and every manufacturer e.g. Motorola, Hytera etc have their own implementation of this.
The DMR spec only defines how to send and receive raw data packets and not the higher levels of the hierarchy or data encoding etc
The Brandmeister network can handle multiple SMS data types, but their software is totally closed source with no documentation
Hence getting SMS to work is non trivial
Battery usage on the open firmware is higher than the official firmware, as we don't have any economy functionality.
So the radio will take around 80mA all the time.
I've started to try to understand how the official firmware operates its power saving, as the average current used when not actively receiving, by the official firmware, is just a few milliamps.
Given that the receiver chip takes 30mA on its own, and the DMR chip also takes a significant amount of current, possibly 10 to 20mA, the official firmware must be turning off both the receiver and the DMR chip, as well as suspending the CPU, for some periods of time, to achieve an average current drain of 5mA or less.
However, it takes the receiver chip and the DMR chip significant amounts of time to wake after being in their low power states, e.g. 20mS or more, before the receiver RSSI can be sampled etc
Hence its likely to be a complex process to attempt to achieve the ultra low power usage that the official firmware is capable of.
However I am now investigating this.
Dual Watch on the Channel screen is not currently implemented, but would probably be not hard to implement.
Channel priority when scanning is not implemented, but could be done, albeit is more difficult than it sounds.
PS.
Because of people and companies not adhering to the non-commercial requirement of the license, as written into the ReadMe.
The developers have stopped releasing source code for the Beta versions.
I know several people who decided just to work on their own version because of this and may never publish the code to their own version.
The code that is in Github, is for the last full release version.
When the firmware is fully finished and is finally stable the source code will be probably be released.
However that portion of new code will probably be under a stronger license, in an attempt to prevent commercialization of the firmware.
The firmware is better in a lot of functionality, however because of the complete lack of good documentation on the hardware, there are still a number of problems which we have not been entirely able to resolve.
Also, there are some large blocks of functionality which are yet to be written.
SMS, and battery economy modes.
I know one developer is working on his own and has had some success with sending and receiving some SMS, however I don't have his code at the moment and may never receive it.
I doubt if personally I'll ever have time to write the SMS functionality as its an complex and non-documented protocol, and every manufacturer e.g. Motorola, Hytera etc have their own implementation of this.
The DMR spec only defines how to send and receive raw data packets and not the higher levels of the hierarchy or data encoding etc
The Brandmeister network can handle multiple SMS data types, but their software is totally closed source with no documentation
Hence getting SMS to work is non trivial
Battery usage on the open firmware is higher than the official firmware, as we don't have any economy functionality.
So the radio will take around 80mA all the time.
I've started to try to understand how the official firmware operates its power saving, as the average current used when not actively receiving, by the official firmware, is just a few milliamps.
Given that the receiver chip takes 30mA on its own, and the DMR chip also takes a significant amount of current, possibly 10 to 20mA, the official firmware must be turning off both the receiver and the DMR chip, as well as suspending the CPU, for some periods of time, to achieve an average current drain of 5mA or less.
However, it takes the receiver chip and the DMR chip significant amounts of time to wake after being in their low power states, e.g. 20mS or more, before the receiver RSSI can be sampled etc
Hence its likely to be a complex process to attempt to achieve the ultra low power usage that the official firmware is capable of.
However I am now investigating this.
Dual Watch on the Channel screen is not currently implemented, but would probably be not hard to implement.
Channel priority when scanning is not implemented, but could be done, albeit is more difficult than it sounds.
PS.
Because of people and companies not adhering to the non-commercial requirement of the license, as written into the ReadMe.
The developers have stopped releasing source code for the Beta versions.
I know several people who decided just to work on their own version because of this and may never publish the code to their own version.
The code that is in Github, is for the last full release version.
When the firmware is fully finished and is finally stable the source code will be probably be released.
However that portion of new code will probably be under a stronger license, in an attempt to prevent commercialization of the firmware.