Update 16th Feb

[ea3ihi]

With the latest version there is an audio quality drop in my gd77, it sounds like metallic and with some noise.

David

[EB3AM]

This bug is still active when I am moving and when the RX level is weak
Here I was in my elevator

https://youtu.be/VaxplJBmL44

This is not new with this release but something is new, it happens that the loudspeaker keeps off though it should not. In this case I have to switch off then on the GD77

73
Luc

Same here!
yes, the same thing happens to me, with the car, and outside antenna. In areas where the signal is S9 or higher, if the signal drops fast, the radio cuts off constantly.
I want to see if the official firmware does the same ... I'll try to compare what happens.

I have found that if you turn off the TG filter the audio stays much better, without so many cuts and without pixelation. On the move, with the car, I was able to travel about 10km without practically modulation cuts. With the TG filter on, the same route, no conversations can be heard.

[EB3AM]

I have found that if you turn off the TG filter the audio stays much better, without so many cuts and without pixelation. On the move, with the car, I was able to travel about 10km without practically modulation cuts. With the TG filter on, the same route, no conversations can be heard.

Thinking a bit, and without having much idea of how the DMR chip is programmed and working, it could be possible to extend the life of the slot selection by a few seconds so that the radio sends the audio to the slot it has seen, even if you lost the signal for a few moments. This could improve reception with fluctuating signals, such as on the move.

[VK3KYY]

We have no idea of the DMR chip either.

The only data for the chip is virtually useless. Its just an overview of how to use the chip, with no specific details of how to program it.

Its impossible to get the full data sheet because the manufacturer does not publish it.

Probably, the firmware for all radios which use this chip e.g in radios by TYT / Radioddity, Baofeng etc, is all written by the company who make the chip, so they don't need to write a data sheet.

[EB3AM]

Hi Roger, Sorry for not spelling correctly in English.
What I mean is, I don't know how the firmware is programmed, or how the dmr chip delivers the data.

The idea is that the filter you are using in the firmware that decides which slot to deliver to the speaker, could be programmed to keep the Slot open for a few seconds if the signal goes down. So if it's a momentary drop, the firmware won't have to rediscover the slot, and it'll save time, which translates to better RX audio.
I hope you understand better.

73, Jordi

[VK3KYY]

Hi Roger, Sorry for not spelling correctly in English.
What I mean is, I don't know how the firmware is programmed, or how the dmr chip delivers the data.

The idea is that the filter you are using in the firmware that decides which slot to deliver to the speaker, could be programmed to keep the Slot open for a few seconds if the signal goes down. So if it's a momentary drop, the firmware won't have to rediscover the slot, and it'll save time, which translates to better RX audio.
I hope you understand better.

73, Jordi

We have no control of what the DMR chip does.

It receives raw audio from the RF chip, with no squelch no filtering at all.

The DMR chip outputs 27 bytes of audio for each 30mS that it decides is a valid signal

In this case the DMR chip has not output any data.

[EB3AM]

I insist ... The chip gives us raw data, ok. Or nothing.

I think it can be improved.

Current Flowchart (as I understand it):

valid Raw data ---> filter slot ---> if slot ok then ---> Audio
every 30ms this happens. and if there is no data for a few mili seconds, we have to synchronize the slot again.

My flowchart:
valid raw data ---> fliter slot ---> if slot ok then ---> SAVE Slot ID, then audio
Every 30ms this happens, but if for a few ms there is no data, when retrieving raw valid data, we know which slot we are listening to, because we saved it before. No need to rediscover the slot ID.

I noticed that if the firmware does not filter slot (orange button, filter: none), the RX audio is much more stable under low signal conditions.

73, Jordi

[VK3KYY]

I think these problems are caused because of some differences in configuration of the RF chip and also some unknown filtering / set-up parameters in the C6000

Its possible that there is clipping in the RF chip, on very strong signals, and the official firmware may have a way to decrease the sensitivity of the RF chip, however there is also no public documentation on the RF chip (AT1846S) either.
We have some confidential data sheets for the RF chip which escaped onto the internet, but its not complete.

If you want to read the datasheets see

https://github.com/rogerclarkmelbourne/ ... ata_sheets


The only original data sheet for the C6000 DMR chip is

https://github.com/rogerclarkmelbourne/ ... inese.docx

Its in chinese.

Andrea Contini translated some of it into English, and I made some edits

https://github.com/rogerclarkmelbourne/ ... K3KYY.docx

However, there is no information on filter settings at all

[kd2lh]

I'm continuing to have problems with this version (as the last version) in hotspot mode on my RpiZeroW.

The firmware version is [ 69d1313 ].

This one is dumping out of conversations that are incoming from Brandmeister. Here's a livelog:

M: 2020-02-17 23:23:51.579 DMR Slot 2, received network end of voice transmission from N1FTE to TG 31371, 2.2 seconds, 0% packet loss, BER: 0.0%
M: 2020-02-17 23:23:55.610 DMR Slot 2, received network voice header from N1FTE to TG 31371
M: 2020-02-17 23:23:56.247 DMR Talker Alias (Data Format 1, Received 6/11 char): 'N1FTE '
M: 2020-02-17 23:23:56.247 DMR Slot 2, Embedded Talker Alias Header
M: 2020-02-17 23:23:56.247 0000: 04 00 56 4E 31 46 54 45 20 *..VN1FTE *
M: 2020-02-17 23:23:56.932 DMR Talker Alias (Data Format 1, Received 11/11 char): 'N1FTE Keith'
M: 2020-02-17 23:23:56.932 DMR Slot 2, Embedded Talker Alias Block 1
M: 2020-02-17 23:23:56.932 0000: 05 00 4B 65 69 74 68 00 00 *..Keith..*
M: 2020-02-17 23:23:57.531 DMR Slot 2, received network end of voice transmission from N1FTE to TG 31371, 2.1 seconds, 2% packet loss, BER: 0.0%
M: 2020-02-17 23:24:05.682 DMR Slot 2, received network voice header from N1FTE to TG 31371
M: 2020-02-17 23:24:05.931 DMR Talker Alias (Data Format 1, Received 6/11 char): 'N1FTE '
M: 2020-02-17 23:24:05.932 DMR Slot 2, Embedded Talker Alias Header
M: 2020-02-17 23:24:05.932 0000: 04 00 56 4E 31 46 54 45 20 *..VN1FTE *
M: 2020-02-17 23:24:06.655 DMR Talker Alias (Data Format 1, Received 11/11 char): 'N1FTE Keith'
M: 2020-02-17 23:24:06.655 DMR Slot 2, Embedded Talker Alias Block 1
M: 2020-02-17 23:24:06.655 0000: 05 00 4B 65 69 74 68 00 00 *..Keith..*

At this point, the PiStar desktop showed the station in red "TX" and the GD77 dumped out of HotSpot mode and back into normal radio mode. "TRX" shows a red "TX DMR Slot 2".

The last stable functioning version was 2/10, which I'm reloading. [a0f4440].

[VK3KYY]

I insist ... The chip gives us raw data, ok. Or nothing.

I think it can be improved.

Current Flowchart (as I understand it):

valid Raw data ---> filter slot ---> if slot ok then ---> Audio
every 30ms this happens. and if there is no data for a few mili seconds, we have to synchronize the slot again.

My flowchart:
valid raw data ---> fliter slot ---> if slot ok then ---> SAVE Slot ID, then audio
Every 30ms this happens, but if for a few ms there is no data, when retrieving raw valid data, we know which slot we are listening to, because we saved it before. No need to rediscover the slot ID.

I noticed that if the firmware does not filter slot (orange button, filter: none), the RX audio is much more stable under low signal conditions.

73, Jordi

Originally the radio firmware did this

valid Raw data ---> filter slot ---> if slot ok then ---> Audio

However, with weak signals this part

if slot ok


Does not work.

Because the slot is often not detected correctly.

The "TimeCode" from the DMR should be 1 2 1 2 1 2 1 2 1 2 etc

But on weak signals its often

1 2 2 1 2 1 1 1 2 1 2 2 etc (totally random)

When the radio first receives the signal (start of reception), the internal timecode is set to the received timecode.

Rf = 1 Radio = 1

So in the example above

RF 1 2 2 1 2 1 1 1 2 1 2 2
Radio 1 2 1 2 1 2 1 2 1 2 1 2
Match Y Y N N N Y N N N Y

If there are 3 failures to match, the firmware sets its own internal timecode to the RF timecode - however the RF timecode may not be correct at this time.


There is probably a way to improve this, and also the official firmware reads an undocumented register 0x57 which appears to contain a version of the timecode which is not exactly locked to the RF signal timecode.


The data sheet says register 0x52 contains the timecode (and other data) but does not have any information on the purpose of register 0x57

I looked in the decompilation for the official firmware but I can't find any code that accesses register 0x57 . There must be some code which does this, but I could not find it.