QDMR 0.10.2 - Option "TS-override" not correct working

[thunderstar5000]

trafficstars

Hello again,

Device: GD-77 Firmware: Opengd77 QDMR: 0.10.2

I discovered, that the option "OpenGD77 - TS-override" is not respected by QDMR. Although it can be set, when "extensions" is activated, but when the codeplug is written back to the radio, the TS of the contact is set to "none".

Tried several times without success.

Did I miss something or is it a bug?

Best regards

Hans

[hmatuschek]

Thanks for filing the bug. I'll have a look at it. Which version of OpenGD77 are you using?

[hmatuschek]

The issue appears to be in line

https://github.com/hmatuschek/qdmr/blob/6fb0b23124461d088ca68793d12973f41c209227/lib/opengd77_extension.hh#L84

This is an odd mistake or the codeplug format has changed from 2021.08 to 2022.02. This means that with the later, the meaning of time-slot override None and TS1 is swapped. If you set it qdmr to "None", TS1 will be set, and if you set it "TS1" it will be disabled. TS2 should work as expected. Could you check if this is the case. If so it is an easy fix.

[thunderstar5000]

My firmware is the latest version by writing this mail. You are correct, the codeplug has changed since 2021.08, as with the new firmware a new OpenGD77CPS was released. I will recheck it and tell the result in my next mail. In the meantime, just for info, and as we talked, that there is a new firmware and CPS, I discovered another thing yesterday, which might also related to the new firmware. When creating the codeplug and adding all fields with its name (TG, Channel whatever) with OpenGD77CPS, and then load it up to the GD77, then download it again back to the PC with OpenGD77CPS, everything is fine = check ok.

But, when I load the same codeplug up to the GD77 with OpenGD77CPS, then download it with QDMR, and then reupload it back to the GD77 with QDMR and at last download this back to the PC with OpenGD77CPS, then some entries are missing = check not ok.

This is really strange! I could not discover any misbehaviour of the transceiver, but by editing the codeplug with OpenGD77CP, I discovered this.

If interested, I can make a screenshot or create a CSV-file. As I said, the transceiver do not misbehave, but some entries are missing (like TG-99, there is no more RxG "TG-99"). I thought, you might be interested in this. As it is no bug at all, take it as an info.

In the afternoon, I will recheck ass I promised, and tell you the results.

Best regards

Hans

[hmatuschek]

If there are some group lists missing, this is definitely a bug. Could you open a separate issue for that one? If there is nothing secret in the codeplug, could you also attach the binary codeplug generated by the OpenGD77CPS as well as a memory dump of the radio after the OpenGD77CPS has written it as well as after QDMR has rewritten the codeplug? A memory dump of the radio can be obtained using the dmrconf tool (command line tool for QDMR) with

dmrconf read codeplug.dfu

So:

• upload correct codeplug with OpenGD77CPS
• read using dmrconf read orig.dfu
• read and write with QDMR
• read using dmrconf read modified.dfu

This will likely help to find the issue.

[hmatuschek]

Any news on this issue, does the master branch work for you?

[thunderstar5000]

Hi Hannes, I will recheck this issue in the next days. At the moment I am busy with an examination I am in, but next week I will have more time.

Please be patient, I will call back as soon as I got new informations.

Thanks for recall!

Best 73 de Hans

P.S. The other issue, you noticed me too, I will also reply to next week.

Am Thu, 04 Aug 2022 03:12:15 -0700, Hannes Matuschek @.***> schrieb:    

Any news on this issue, does the master branch work for you?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[thunderstar5000]

Am Donnerstag, 4. August 2022, 12:12:15 CEST schrieb Hannes Matuschek: Hi Hannes,

nope, my last report was against 0.10.2, so there is no change.

Have a nice day!

Best

Hans, DL4OCJ

Any news on this issue, does the master branch work for you?

[hmatuschek]

Ok, can reproduce it, even when decoding a codeplug encoded using dmrconf. This should be fixed soon.

[hmatuschek]

There is still an issue.

[hmatuschek]

The version in master can reliably set the time-slot override for the contacts. However, the encoding is wrong, at least for the latest release I've found (2022-02-28, 0118581D). There it appears that None = 0x01, TS1⁼0x00, TS2 = 0x02. I'll encode this time-slot override for the 0.10.3 release. Is there a newer firmware release, does it change the encoding?

You can check it by hand using the command line tool. First, edit the setting in the radio. Then download the binary codeplug

drmconfig read codeplug.dfu

Then inspect the codeplug using

dmrconfig info codeplug.dfu | less

The contacts are stored in flash memory starting at address 87620h. Each contact entry takes 18h bytes. The time-slot override is the last byte. For example

876b0  42 6c 6e 2f 42 72 62 ff  ff ff ff ff ff ff ff ff  |Bln/Brb.........|
876c0  00 00 26 21 00 00 00 02  53 61 2f 54 68 ff ff ff  |..&!....Sa/Th...|

The "Bln/Brb" contact overrides the time-slot with TS2.

[hmatuschek]

Any news on that? Does it work now?

[thunderstar5000]

Am Sonntag, 25. September 2022, 23:07:02 CEST schrieb Hannes Matuschek:

Any news on that? Does it work now?

Hi Hannes,

thanks for your question.

Yes, as far as I can see, everything is working fine now. Or better say: i could not find any issues so far.

Looks like everything is working fine.

My version: 0.10.3, built for Debian-stable, 64-bit and same system on another computer but 32-bit.

Hint: For Debian systems I set the path to the binary to /usr, and not (as in the documentation) to /usr/local/.

(This is prepared, if one day a debian package is in the repo. Binaries in debian are below /usr). For Ubuntu /usr/local is correct.

I still did not try, sending a codeplug from 32-bit to the GD-77. You might remeber, there was an issue withe the frequencies (i.e. when the frequency was 438,670 it was shown as 438,699). We talked aboit it, believe it is a floating point error. However, please do NOT care about it, because I might be the only one in Europe, maybe the world, still using 32-bit system with linux. 32-bit is dead!

Hope this helps a little bit, and thanks for the great work.

Best regards and 73s

de Hans, DL4OCJ

P.S. I can even not understand, how one single person can code such a big and complex program on his own! Highly admirable!!!

[hmatuschek]

Ok, thanks for the info. So I can close this issue now. Concerning your question: I have a 1h commuting trip every day to work and back. Over the time, this accumulates to some significant amount of spare time for such projects.