EMB Field

Discussions related to the firmware code development
Post Reply
JP7NJT
Posts: 32
Joined: Wed Oct 18, 2023 12:44 pm

EMB Field

Post by JP7NJT » Wed Oct 23, 2024 7:53 pm

Hi,

I have RX errors on dsd-fme for each superframe emitted by OpenGd77.
After research, it seems that Opengd77 does not update the EMB field with the CC and parity of the whole field.

Would it be possible to add the management of this field in TX ? Or is it too complicated?
SLOT 1 TGT=1 SRC=1 FLCO=0x00 FID=0x00 SVC=0x00 Group Call
DMR PDU Payload [00][00][00][00][00][01][00][00][01] SB: 00000000000 - 000;
SLOT 1 SB/RC (FEC ERR) E:9; I:BC3D2E01 D:000;
emb-field.png
emb-field.png (22.59 KiB) Viewed 319 times

VK3KYY
Posts: 8195
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: EMB Field

Post by VK3KYY » Thu Oct 24, 2024 1:13 am

JP7NJT wrote:
Wed Oct 23, 2024 7:53 pm
Would it be possible to add the management of this field in TX ? Or is it too complicated?
We have no knowledge of this level of the DMR protocol. The firmware simply mimics what the official firmware does, which was implemented by capturing SPI bus transfers from the MCU to the C6000 when the GD77 was running the official firmware. However its possible that something was omitted.

Try looking in the C6000 datasheet to find out whether its actually possible to control this part of the transmission

downloads/datasheets/C6000

also look in the application/hardware/HR-C6000.c source code, specifically the interaction with

Code: Select all

SPI0WritePageRegByteArray(0x02, 0x00, (uint8_t*)deferredUpdateBuffer, LC_DATA_LENGTH); // put LC into hardware

Code: Select all

SPI1WritePageRegByteArray(0x03, 0x00, (uint8_t*)(deferredUpdateBuffer + LC_DATA_LENGTH), AMBE_AUDIO_LENGTH); // send the audio bytes to the hardware

i.e The voice frame data is sent to register 0x02 on SPI bus 0

This is 27 bytes of which half is sent before the "Embedded signalling" and half is sent after the signalling
The C6000 splits the entire voice data frame into the 2 sections.

IIRC SPI0 register 0x02 configures the contents of the "Embedded signalling" e.g. the Voice LC frame,

However the data that is required by the C6000 does not include anything for the lower level of the protocol in your diagram labelled "EMB"

Perhaps you can understand the C6000 data sheet in regard to whether the C6000 generates this or whether there is an interface register to this.
You could also try sending 1 extra bytes in the LC data to register 0x02 to see if this perhaps changes the "EMB" byte value that is transmitted.

JP7NJT
Posts: 32
Joined: Wed Oct 18, 2023 12:44 pm

Re: EMB Field

Post by JP7NJT » Thu Oct 24, 2024 7:53 pm

Thanks for your answer.

I have another question: in the hotspot.c file the DMR protocol is really detailed but what is it for?
Does the data come from the radio receiving and is sent to the Raspberry Pi via USB?
Does the data come from the Raspberry Pi via USB and is sent as a transmission to the radio?
Does it work differently?

User avatar
F1RMB
Posts: 2878
Joined: Sat Nov 16, 2019 5:42 am
Location: Grenoble, France

Re: EMB Field

Post by F1RMB » Thu Oct 24, 2024 10:35 pm

JP7NJT wrote:
Thu Oct 24, 2024 7:53 pm
Thanks for your answer.

I have another question: in the hotspot.c file the DMR protocol is really detailed but what is it for?
Does the data come from the radio receiving and is sent to the Raspberry Pi via USB?
Does the data come from the Raspberry Pi via USB and is sent as a transmission to the radio?
Does it work differently?
I think you answered your own question at the same time...

VK3KYY
Posts: 8195
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: EMB Field

Post by VK3KYY » Thu Oct 24, 2024 10:39 pm

JP7NJT wrote:
Thu Oct 24, 2024 7:53 pm
Thanks for your answer.

I have another question: in the hotspot.c file the DMR protocol is really detailed but what is it for?
Does the data come from the radio receiving and is sent to the Raspberry Pi via USB?
Does the data come from the Raspberry Pi via USB and is sent as a transmission to the radio?
Does it work differently?
Normal MMDVM_HS Hotspots are dumb, they just send the raw 4FSK bitstream via serial to MMDVMHost

OpenGD77 does not have access to the raw bitstream inside the C6000 chip, so it has to construct a MMDVMHost compatible 4FSK bitstream from the higher level data that is available from the C6000, i.e contruct the DMR frame bitstream from the AMBE audio and LC data.
This process also has to happen in reverse, the MMDVMHost bitstream has to be processed to the AMBE audio and LC data to send to the C6000

All this code is based on publically available code e.g. from MMDVMHost and MMDVM_HS and other places, but to avoid licensing issue was rewritten and optimised for OpenGD77. We do not have any detailed knowledge of exactly how this bitsteam < --- > AMBE + LC translation works.

Post Reply