Data Link Layer and Call Control Layer

[JP7NJT]

Hello all,

I'd like to use opengd77 as a Wireshark scanner.
Do you know in which part of the source code I can get a TX buffer and an RX buffer that contains the entire Data Link Layer (Layer2) and another that contains the entire Call Control Layer (Layer 3) for each frame or superframe ?

[G4EML]

The HRC6000 chip handles most of the DMR protocol. The raw data is not used by the firmware, so the buffers you refer to are not currently available.
Most of the parameters are available by reading the chip registers but It is not clear from the limited documentation of the chip if the raw data is available. All of the interaction with the chip is in HRC6000.c

Colin G4EML

[JP7NJT]

All of the interaction with the chip is in HRC6000.c

Thank you for this information. I've tried the DEBUG_printf command and it works in some places in the code but not in other places. When it's not working, it doesn't display some of the information it should.

Do you know what can cause this?

Example with the HRC6000.c code

I've changed the COM port to 115200 and putty too.

static void hrc6000HandleLCData(void)
{

USB_DEBUG_printf("LC:");
for (int i=0;i<DMR_FRAME_BUFFER_SIZE;i++) USB_DEBUG_printf("%X",DMR_frame_buffer[ i ]);
USB_DEBUG_printf("\r\n");

uint8_t LCBuf[LC_DATA_LENGTH];
bool lcResult = (SPI0ReadPage

In putty there is only the first debug_print that shows :

LC:LC:LC:LC:LC:LC:LC:LC:LC:LC:LC:LC:LC:LC:LC:LC:LC:LC:LC:LC:LC:LC:LC:LC:

[G4EML]

The code for the debug print is very simple and was only intended to be used for occasional short messages. There is no buffering of the print data so you must allow time for each message to be sent. In your example you would need to build your own buffer using sprintf and then send the whole buffer at once. I am also not sure if there is a limit to the size of the buffer. If you really need it you could always improve the behaviour of the code yourself, it is in USB.c.

Colin.

[JP7NJT]

Thanks for your explanation.

Regarding the sound in FM mode, I assume that it is processed directly by the HRC6000 and that there is no way to record the sound emitted and received in FM mode?

[G4EML]

The FM audio is processed by different chips in the different radios. However in all cases it remains in the analogue domain and is never digitised, so it can't be recorded.

Colin.

[OK2MOP]

Actually RT3s with stock "recording" firmware was able to record the FM audio and store it encoded by AMBE in flash, as well as the DMR calls, so some way how to do this has to exist. I was wondering earlier if this was a way how to get the APRS RX, but it would probably not work on other radios.

[G4EML]

Are you certain about that? I was under the impression the recoding feature only worked on DMR, I have never tried it though. That is also what the Retevis manual says and it makes sense from what we know about the chips.

Colin G4EML

[OK2MOP]

Hello,
I managed to get now to the secondary QTH, have taken my father's RT3s which is still on stock firmware - the recording firmware S018.009 - and recording of incomming analog audio works, but the quality after AMBE conversion is quite bad, recording of outgoing audio is OK, and recordings can be shown only after switching to digital channel. I will test with another radio with newer firmware, maybe it is disabled there.

73, OK2MOP

EDIT: So S019.013 firmware on MD-UV390 from TYT which arrived 5 weeks ago behaves the same way.

[G4EML]

OK, Thanks for the update. In that case it sounds like they may be using an undocumented feature of the HRC6000 to do that. The documentation we have does not mention the ability to route the FM audio to the AMBE encoder. Not surprising, as there are a lot of undocumented, or poorly documented features.

73
Colin.