Probable bug in OpenGD77

[SA0BUX]

Also tried the other way around ( Radio 2 to 1 ) and got more differences

decode:F8 01 A9 97 8C F5
decode:F8 01 A9 9F 8C F3
decode:F8 01 A9 97 CC E0
decode:F8 01 A9 9F 8C F1
decode:F8 01 A9 9F 8C E0
decode:F8 01 A9 9D 8C E0
decode:F8 0D DC 9D 8C E0
decode:F8 01 A9 97 8C F5
decode:F8 01 A9 9F 8C E0
decode:F8 09 24 97 8C E0
decode:F8 01 A9 9F 8C F1
decode:F8 01 A9 9D 8C E0
decode:F8 01 A9 9F 8C D5
decode:F8 01 A9 9F 8C E0
decode:F8 01 A9 97 8C F5
decode:F8 01 A9 9F 8C E0
decode:F8 01 A9 97 8C E0
decode:F8 01 A9 9F 8C E5
decode:F8 01 A9 9D CC E0
decode:F8 01 A9 9F 8C D5
decode:F8 01 A9 9F CC E0
decode:F8 01 A9 97 8C F5
decode:F8 01 A9 9F 8C E0

[JP7NJT]

thanks for your tests SA0BUX.

[SA0BUX]

thanks for your tests SA0BUX.

If you make a compile for MD-9600 V2 , I can test that radio too.

[G4EML]

The MD9600 is the only other radio worth testing as it uses a different way of feeding the HRC-6000.

All of the supported handhelds use demodulated Audio to feed the HRC6000 and this could introduce errors. I would expect all of the handhelds to perform the same.

The MD9600 feeds 455KHz IF to the HRC6000. So the HRC-6000 is doing the FM demodulation internally. In theory that should be more accurate.

The MD380 also uses IF feed into the HRC5000 so comparison should really be done against the MD9600.

My suspicion is that the errors are being caused by the HRC-6000 AF receive circuitry and not by the firmware. The reason you are mainly seeing errors in the second half of the AMBE frame is because the AMBE protocol only applies Forward Error Correction to the first half of the frame. The second half is not error corrected and so will directly reflect the true BER of the receive process.

There may still be some adjustment of the parameters that will improve the reception but this will involve some trial and error to find. The AF decoding mode of the HRC-6000 is something that seems to have no documentation at all !

Of course the errors may be inherent to the HRC-6000 when operated with Audio input in which case there may not be much that can be done.


Colin G4EML

[JP7NJT]

thanks for your tests SA0BUX.

If you make a compile for MD-9600 V2 , I can test that radio too.

Unfortunately I hadn't downloaded the old source code from March 2023 for the MD9600 and the new source code from December 2023 no longer works with the command usb_debug_printf display.

If anyone has the old source code for the MD9600 and can publish it here, then I could compile for the MD9600.

[JP7NJT]

Several checks to be done...

[JP7NJT]

My suspicion is that the errors are being caused by the HRC-6000 AF receive circuitry and not by the firmware. The reason you are mainly seeing errors in the second half of the AMBE frame is because the AMBE protocol only applies Forward Error Correction to the first half of the frame. The second half is not error corrected and so will directly reflect the true BER of the receive process.

Yes, at the very beginning of this topic, I hypothesized that it could come from the code concerning the AMBE codec or the FEC code of the MD9600.
But it's impossible that this is the case with the compiled firmware that I have made you test. So it's not the fact that the FEC corrects the errors of the first 3 bytes.

I explain why:

On the first page I posted another test, it's the DMR buffer [DMR_frame_buffer] which contains the data received BEFORE deinterleaving and BEFORE GOLAY 24 and 23 corrections.

It is observed that there are also errors in the reception of the silence frame (not deinterleaved and not corrected by the FEC). And these errors seem to be in the same places.

I could be wrong but I have the impression that if it was a problem caused by the HRC-6000 AF receive circuitry, errors should be randomly distributed in the DMR buffer and then, yes, we could say that the first 3 bytes are corrected by the FEC.

But this is not the case, the errors are always pretty much in the same places before the FEC correction.

000000000001000001102DADB9E881526173002A6CF9E881526173
000000000001000001102DADB9E881526173002A6F39F881526173
000000000001000001102DADB9E881526173002A6BFDEC81527173
000000000001000001102DADB9E881526173002A6F39F881526173
000000000001000001102DADB9E881526173002A6EB1E881526173
000000000001000001102DADB9E88152617B002A7EF9E881526173
000000000001000001102DADF9F881526173002A6EB1E881526173
000000000001000001102DADB9E881526173002A6CF9E881526173
000000000001000001102DADB9E881526173002A6F39F881526173
000000000001000001102DADB9E881526173002A6EF1E881526173
000000000001000001102DADB9E88152617B002A7AF9E881526173
000000000001000001102DADB9E881526173002A6AF9EC81526173
000000000001000001102DADB9E88152617B002A6BB9E881527173
000000000001000001102DADB9E881526173002A6EB1E881526173
000000000001000001102DADB9E881526173002A6CF9E881526173
000000000001000001102DADB9E881526173002A6F39F881526173
000000000001000001102DADB9E881526173002A6EF1E881526173
000000000001000001102DADB9E88152617B002A7AF9E881527173
000000000001000001102DADB9E881526173002A6F39F881527173

Of course the errors may be inherent to the HRC-6000 when operated with Audio input in which case there may not be much that can be done.

I misunderstood your answer, you say that the audio input (microphone?) can produce errors? But I don't use the audio input in my test firmware.

I explain the process:

The codec_interface.c transmit mode does this:

soundRetrieveBuffer();// gets currentWaveBuffer pointer used as input r2 to the encoder

ENCODE INTO AMBE the WAV from soundRetrieveBuffer()->49 bits into bitbuffer_encode[49]
ADD FEC ->72 bits into bitbuffer_encode[72]
SEND bitbuffer_encode[72]

I do my tests like this:

soundRetrieveBuffer();// gets currentWaveBuffer pointer used as input r2 to the encoder

ENCODE INTO AMBE the WAV from soundRetrieveBuffer()->49 bits into bitbuffer_encode[49]
REPLACE data in bitbuffer_encode[49] with silence_frame[49]={1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,1,1,0,1,0,1,0,0,1,1,0,0,1,1,1,1,1,1,0,0,0,1,1,0,0,1,1,1,0,0,0,0,0,0};
ADD FEC ->72 bits into bitbuffer_encode[72]
SEND bitbuffer_encode[72]

So the audio input doesn't intervene, even if there are errors in the audio in bitbuffer_encode[49], as I completely replace the bitbuffer_encode[49] data with the data of a silence frame, it's as if the audio input doesn't exist, whether it contains errors or not.

[G4EML]

The AF input I am taking about is nothing to do with the microphone. I am talking about the receive signal chain.

The RF signal comes into the antenna, is demodulated to baseband AF by the AT1846 receiver chip and this AF is fed into the HRC6000 which then has to decode the 4FSK data from the AF input. This process is sub optimal and has a potential for error as the HRC6000 has no control over the quality or distortion of the signal. In fact it is not mentioned at all in the limited datasheet.

An alternative, and the datasheet defined method, is to use the HRC6000 with IF input. This is done in the MD9600. The RF signal comes into the antenna, is frequency converted to an IF of 455 KHz and this is fed to the HRC6000. It does not get demodulated to AF outside the chip. The HRC 6000 then does it's own demodulation and decode internally. This is a more accurate process and likely to result in fewer errors.

At the moment we don't know if this is the problem, it is just a hypothesis.

Colin G4EML

[G4EML]

I have just repeated the test on an MD9600 radio. I can confirm that the problem is not present on that radio type.

I made several 10 second transmissions from the test MDUV380 and did not log any bad AMBE Silence frames on the MD9600 used for receive.

The code handling the AMBE transfers is the same for both radio types. The only difference is the input signal interface method used for the HRC6000.

I think this is a good pointer to the problem being in the AF interface between the AT1846S and the HRC6000.

It remains to be seen if this can be improved.

Colin G4EML

[G4EML]

A possible fix......

It looks like the AF level from the AT1846S to the HRC6000 is very critical. Reducing the level seems to fix the problem for me.
I note from the software comment that we did have some problems with this level early in the project but probably didn't spend a lot of time investigating.

Please try changing this...

in the file 'application/source/hardware/AT1846S.c'
Change the last entry in the AT1846DMRSettings[] array from {0x44, 0x07, 0xFF} to {0x44, 0x07, 0xCF}

Code: Select all

const uint8_t AT1846DMRSettings[][AT1846_BYTES_PER_COMMAND] = {
		{0x40, 0x00, 0x31}, // UNDOCUMENTED. THIS IS THE MAGIC REGISTER WHICH ALLOWS LOW FREQ AUDIO BY SETTING THE LS BIT
		{0x15, 0x11, 0x00}, // IF tuning bits (12:9)
		{0x32, 0x44, 0x95}, // agc target power
		{0x3A, 0x00, 0xC3}, // modu_det_sel (SQ setting). Tx No mic input, as the DMR signal directly modulates the master reference oscillator
		{0x3C, 0x1B, 0x34}, // Pk_det_th (SQ setting)
		{0x3F, 0x29, 0xD1}, // Rssi3_th (SQ setting)
		{0x41, 0x41, 0x22}, // Digital voice gain, (bits 6:0) however default value is supposed to be 0x4006 hence some bits are being set outside the documented range
		{0x42, 0x10, 0x52}, // RDA1846 lists this as Vox Shut threshold
		{0x43, 0x01, 0x00}, // FM deviation
		{0x48, 0x19, 0xB1}, // noise1_th (SQ setting)
		{0x58, 0x9C, 0xDD}, // Disable all filters in DMR mode
		{0x44, 0x07, 0xCF}, // set internal volume to 100% (doesn't seem to decode correctly at lower levels on this radio)
};

This reduces the analogue gain of the AT1846S when in DMR mode.
This setting seems to be very critical. Hopefully it will be the same for all radios but this might need to be tested.

Colin G4EML