DCS not uploaded on anytone D878UV2

[red0queen]

Hi. When pushing a codeplug with analog channels and DCS code, the DCS code is'nt pushed on the radio. If i configure the DCS directly on the radio, qdmr is able to read them. Pushing the same codeplug will erase it on the radio. No problem with CTCSS.

Firmware 2.03

Thanks !

[jwjensen]

I reported #205, which was fixed here: https://github.com/hmatuschek/qdmr/commit/6c8fb1529fe78c62938d02b2d11be3325ae94495

Try building from source, or wait for the next release?

[red0queen]

ho, my bad, I haven't find this previous ticket. I will try with sources. Thanks you guy !

[hmatuschek]

However, this should be fixed in 0.10.2. Let me know if this is not the case.

[red0queen]

Ok, I reopen because my problem exist with 0.10.2 builded from sources, on Debian 11. Can I send you some logs or others info to help ?

[jwjensen]

Running 0.10.2 in debian (from testing, not built from source), I can do:

 [--] jensen@p15:~ 10:57:08
{1009} $ dmrconf -v
dmrconf 0.10.2

 [--] jensen@p15:~ 10:57:14
{1010} $ dmrconf read /tmp/d878uv.dfu
[================================================= ] 98%

 [--] jensen@p15:~ 10:57:20
{1011} $ dmrconf decode --yaml --radio=d878uv /tmp/d878uv.dfu | grep Tone
      rxTone: {dcs: 516}
      txTone: {dcs: 516}
      rxTone: {dcs: 413}
      txTone: {dcs: 413}
      rxTone: {dcs: 516}
      txTone: {dcs: 516}
      rxTone: {dcs: 413}
      txTone: {dcs: 413}

Can you run the same dmrconf commands, and see if it correctly parses the dcs codes?

(you will need to use --radio=d878uv2 I think)

[hmatuschek]

Yes, d878uv2 is AT-D878UVII, while d878uv is just the old AT-D878UV.

dmrconf --list-radios

Prints a detailed list of all supported radios.

[red0queen]

~$ dmrconf -v
dmrconf 0.10.2
~$ dmrconf read /tmp/d878uv.dfu
[================================================= ] 98%
~$ dmrconf decode --yaml --radio=d878uv2 /tmp/d878uv.dfu | grep Tone
      rxTone: {dcs: 754}
      txTone: {dcs: 754}
      rxTone: {dcs: 743}
      txTone: {dcs: 743}
      rxTone: {dcs: 734}
      txTone: {dcs: 734}
      rxTone: {ctcss: 67}
      txTone: {ctcss: 67}
      rxTone: {dcs: 723}
      txTone: {dcs: 723}
      rxTone: {dcs: 712}
      rxTone: {dcs: 703}
      txTone: {dcs: 703}
      rxTone: {ctcss: 88.5}
      txTone: {ctcss: 88.5}

Reading seems ok. Have you a way to instigate what's happening when pushing this conf on the radio ? (I actually using Anytone software for pushing this conf without loosing DCS)

[hmatuschek]

To test self-consistency you may try to encode the read codeplug and decode it again:

dmrconf encode --radio=d878uv2 mycodeplug.yaml mycodeplug.dfu
dmrconf deocde --radio=d878uv2 mycodeplug.dfu mycodeplug_test.yaml
diff mycodeplug.yaml mycodeplug_test.yaml

Alternatively write it to the radio and read it back. Please note, that not all settable DCS codes are implemented in qdmr. Only those 83 standardized ones (see https://en.wikipedia.org/wiki/Squelch#DCS).

The self-consistency will likely work as it works for me with 0.10.2. However, the current implementation relies on the FW version 2.01b. Maybe they have changed something from 2.01b to 2.03. I'll check.

[hmatuschek]

Just checked with CPS version 2.04 (matching FW version 2.04). There appears no change in how the CPS encodes these settings.

[red0queen]

The DCS I've choose are in the standardized list. If i push the codeplug and read it back, the DCS disappear.

Diff return that

6c6
<   micLevel: 1
---
>   micLevel: 0
59,60d58
<       rxTone: {dcs: 754}
<       txTone: {dcs: 754}
73,74d70
<       rxTone: {dcs: 743}
<       txTone: {dcs: 743}
87,88d82
<       rxTone: {dcs: 734}
<       txTone: {dcs: 734}
115,116d108
<       rxTone: {dcs: 723}
<       txTone: {dcs: 723}
129d120
<       rxTone: {dcs: 712}
142,143d132
<       rxTone: {dcs: 703}
<       txTone: {dcs: 703}

No problem when I do the same write and read back with CPS.

[hmatuschek]

Tested it with FW version 1.27 on a D878UV. I do not own a D878UVII, however, there appears to be no difference in this setting between these two devices. At least when comparing FW Versions 2.04 and 1.27.