Open hmatuschek opened 1 year ago
Note for later:
Multi DMR ID support: OpenGD77 supports multiple DMR ids. qdmr has general support for this feature, but not for OpenGD77. Reading a OpenGD77 device with multiple IDs (written by the Windows CPS) works fine, though, they are correctly written to the yaml file. Writing and re-reading just returns one ID. qdmr correctly complains before writing.
Maximum number of TGs (RXGroupList): "The maximum number of TG's in a TG-List is 32" (https://www.opengd77.com/viewtopic.php?t=2063 or https://www.opengd77.com/viewtopic.php?t=2541 for other sizes) Actually, qdmr 0.11.3 seems to not read the 32 entries from an RX list on my RD-5R running OpenGD77 - qdmr 0.8.1 is working correctly. Will try to determine why. Seems to only read about 15 oder 16. Is that somewhere in opengd77_limits.cc ? At " / Define limits for group lists. /"? But: is it writing more than it is reading? Is it a display issue? Strange. Have to confirm how many are written.
Does qDMR support STM32 radios? or only MK22 ones?
@luzemario : Are you asking specifically regarding radios running OpenGD77? There was some discussion here: #300 I have an RD-5R running OpenGD77 which is handled well by qdmr and is MK22-based, right?
Currently, qdmr supports for example an RT3S when running stock firmware. There seem to be differences between the implementations of OpenGD77 on the supported radio families, though. So current status is (again, from report at #300) that qdmr can not be used reliably for an RT3S or DM1701 when the radio is running OpenGD77.
To change that is the goal of the tasks in this issue. Did I understand your question correctly?
Yeah, I own a DM-1701 running OpenGD77. And yes, some fields are shown garbled after reading the radio. You are correct.
The DM-1701 has a STM32, that is slightly different from MK22.
Does anyone know, where I can get the source code of the latest OpenGD77 CPS and firmware? It is super weird to treat this open source firmware like any other shitty commercial one, needing to reverse engineer everything from scratch.
Maybe this can be useful:
https://www.opengd77.com/viewtopic.php?f=19&t=2742
The interface code has changed a bit since then, but not too often.
Thanks, that helps a lot.
I have a OpenGD77-ified MDUV380 that I would really like to use qdmr to program, since I think their CPS is really not the best... It seems like this project is close already. I have tested your recent work that it does correctly identify my radio and mark it as unsupported. If I use the existing OpenGD77 class anyways, it reads contacts and zones fine aside from some extra garbage entries, but contacts / TGs are not read at all. Writing to the radio makes no change after it completes, even though the radio shows all the right screens.
Is this something you expect to be working on in the coming months? If not, I may try to make the changes to support at least the new format/protocol, at least for my radio. But I do not want to duplicate any effort here.
OpenGD77 format is almost the same across different models, with slightly differences for MD9600 and other mobiles. Once it works with one of them, maybe will work for all with Opengd77 firmware installed.
Another OpenGD77 issue in https://github.com/hmatuschek/qdmr/issues/479
Maybe related to https://github.com/hmatuschek/qdmr/issues/475
This is a larger change. With the support of other radios, the OpenGD77 firmare changes the codeplug and callsign DB format. To this end, a detection of the firmware variant is needed and some device specific implementation of the codeplug/callsign DB. Hence the following sub-steps are needed. (Unifies issues #393, #300, #297, #239, #223)