Will dual band radios ever be supported?

[cam-wil]

Will the dual band radios ever be supported by this project? Is it a technical reason why they aren't supported or just a decision to keep the project cleaner? I'd love an UV with these tools.

[travisgoodspeed]

Not by this project, but OpenGD77 does support dual band radios.

[rogerclarkmelbourne]

Some guys Italian guys are attempting to port the OpenGD77 codebase to the MD380, but AFIK progress is slow.

I bought a Retevis RT-3S aka MD-380UV, with the intention of porting to that radio, as the chipset is similar apart from the MCU, however, pressures of work etc, have forced me to shelf this idea for the medium to long term.

[tarxvftech]

https://github.com/OpenRTX/OpenRTX, for the from-scratch firmware project. https://github.com/KG5RKI/TyMD380Tools/tree/md2017/TyMD380tools (md2017 branch) for some possible dual-band support on a hard fork of this project.

[rogerclarkmelbourne]

Yep.

Same people. Just a different project name.

Look at the code you'll see some of it is directly copied and pasted from the OpenGD77 project.

The original comments I wrote are the fingerprints, as are simple things like the order in which functions are called, when there is not set order to call the functions.

[tarxvftech]

@rogerclarkmelbourne I figured the links would be handy for those unaware of the Italian guys and the existing KG5RKI MD-2017/MD-UV380 codebase. Thanks very much for sharing your work!

[rogerclarkmelbourne]

@tarxvftech

I don't know if they kept their OpenGD77 port to the MD30 or whether they deleted it when they changed the name of their project.

I had a quick look but I can't find it, so perhaps they deleted the repo and all the forks.

I did start porting the OpenGD77 to the MD/UV380 but I had to stop, because there is still a lot of development work to do on the OpenGD77, with some major functional blocks still to implement, and I don't have time to do both.

I'm currently working on the battery power saving functionality but its not easy a quick thing to do.

[tarxvftech]

My understanding is they wanted to start fresh to better decouple the rest of the code from the GD77-specifics, so that might explain the disappearing act.

[rogerclarkmelbourne]

Yes.

They I guess they didn't want any dependencies, apart from cutting and pasting from the current OpenGD77 codebase.

BTW. I hear they are now working with the M17 team to port their OpenRTX firmware to the Ailunce HD1 with some M17 compatibility

[d235j]

There are problems with the license in the OpenGD77 codebase (GPL does not allow adding any additional terms that create new restrictions — only certain additional terms such as warranty disclaimers or ones that provide additional permissions are allowed). Perhaps this is one motivation to not reuse OpenGD77.

That said, if they are copy-pasting code from OpenGD77 into OpenRTX, some more detail as to which code is being copy-pasted would be useful as GPL still requires the code to be correctly attributed. I would suggest opening an issue on their repo as well.

[rogerclarkmelbourne]

They already said they would now add some form of credits

And yes. The license was never valid in the first place, for a variety of reasons, including that additional clauses can't be added to the GPL license, but also because the binaries include blobs from Radioddity etc with no source to these, plus various other factors.

So as result the binary was never fully open source. 50% of the binary file size is closed source.

I presume that the OpenRTX will be fully open and not include any binary sections.

Kai's intention was clear that he wanted the additional clauses / limitations, in just the same way as MMDVMHost does it, but unfortunately he chose the incorrect license, as did MMDVMHost.

[d235j]

They already said they would now add some form of credits

OK — that's good to hear.

the binaries include blobs from Radioddity etc with no source to these, plus various other factors.

This can be a problem, depending on what happens with the blobs — if they are e.g. firmware that is loaded on peripherals, that might be okay (Linux does this); if it's linked with the main binary, then it's not. Additional exceptions might help, but it does get complicated — and everything relies on the rights to redistribute those blobs in the first place. Without such rights, one would need to have the end-user run a program that builds the firmware from object files compiled from the open source portions with the blobs sourced from the vendor.

Kai's intention was clear that he wanted the additional clauses / limitations, in just the same way as MMDVMHost does it, but unfortunately he chose the incorrect license, as did MMDVMHost.

Yeah... if he wanted to do this, following something similar to the old MAME license (the one that was phased out in the 2016 relicensing effort, which required a laborious process that involved contacting past contributors) would have been best... of course this would also mean no use of outside GPL code, and limitations on how LGPL code could be used.

Many of the files themselves have authorship information that indicates that others wrote the files and therefore probably would not fall under such terms anyway, but in general it's a big mess, especially for something as useful / widely used as MMDVM.

[rogerclarkmelbourne]

Yep. The license is a mess.