DMR code opimitisation

[VK3KYY]

I had a report about one of the previous versions that there were more DMR Rx audio corruptions, most noticeably at the end of overs.

One thing I changed in last weeks "Latest" version, was to re-enabled compiler optimisation on the main DMR processing file fw_HR-C6000.c

The compiler is the part of development system, which converts the C code into the machine code instructions used by the CPU.
And the Optimisation setting controls how intelligent the compiler is, at converting from C to machine code instructions.

Without optimisation, the compiler does a 1 to 1 conversion and does not look for redundant code or ways to speed things up or make things smaller.
However normally developers use the "Small" optimisation setting, which attempts to make the machine code as as small as possible without compromising speed, and normally the "Small" setting produces almost the fastest code execution with the minimum ROM file size.

However, when debugging, often Optimisation has to be disabled, because it makes the code hard to debug, because the machine code inside the CPU is not a direct 1 to 1 copy of the C code.

In this case, I left the optimisation set to "Off", in a version a few weeks ago, and only noticed last week that this was the case.
So I changed the DMR code optimistion setting back to what it should be, but this may have actually caused the DMR system to not operate as well, if there are timing issues.

Anyway...

To see if anyone notices any difference, I've re-compiled the last "Latest release" (14th December) , with compiler optimisation enabled again.
So I'd be interested if anyone can really notice any difference.


Ideally compiler optimisation should be enabled, and if things don't work correctly with optimisation enabled, it means there are bugs in the code which need to be fixed.

[W1AEX]

I picked up a second GD77 last week Roger so I installed firmware without optimization in one and firmware with optimization in the other. I let them run simultaneously and noted that they both exhibited audio corruption at different times while monitoring the same DMR activity. I made a tally while engaged in a private call and during a 10 minute stretch these were the results:

audio corruption tally:

optimization enabled: 6 audio breakups
optimization disabled: 3 audio breakups

Of course a 10 minute stretch is a sample that is way too small so I'll let both radios run simultaneously throughout the day and take note of which has less audio corruption.

73, Rob W1AEX

[EA5SW]

For me also is worse.. Without optimization works best in my hotspots simplex and duplex.

[DG3GSP]

I tried the new firmware: It seems that the optimized Firmware had more dropauts - but without a second radio it´s very difficult to compare

[m1dyp]

testing now

[VK3KYY]

Thanks

I was intending to re-enable the optimisation, but it looks like I will need to do some more side by side testing with one radios using optimised DMR and the other running unoptimised

[W1AEX]

Roger,

I had a chance to do some extended listening with both of my GD77's and the radio with optimization toggled OFF was far less susceptible to audio disruption and corruption compared to the radio with optimization toggled ON. It wasn't even close. So.. at least with my two radios it's clear that optimization is not the best scenario.

Rob W1AEX

[VK3KYY]

Roger,

I had a chance to do some extended listening with both of my GD77's and the radio with optimization toggled OFF was far less susceptible to audio disruption and corruption compared to the radio with optimization toggled ON. It wasn't even close. So.. at least with my two radios it's clear that optimization is not the best scenario.

Rob W1AEX

Rob. Can you switch which radio the firmwares are loaded onto and give it another try.

Its possible it doesn't effect all radios.

[W1AEX]

Roger,

Yes, already done as I wanted to confirm that it's the optimization setting and not something with the radio hardware. I'll post again when I have enough data to see if the dropouts follow the firmware.

73, Rob W1AEX

[VK3KYY]

Thanks Rob

There is definitely a bug in the DMR code, associated with the timing of when the current Timeslot number is read from the DMR chip.

The code is currently reading it in 2 places, but it should only need to be read once.

When I change the code to only read it on one place, everything goes wrong. Either the radio goes on the wrong TS or I don't get any audio.

So I'm going to have to work out whats going on, as this is likely to be causing a lot of small problems.