OpenGD77 Tier2 Alpha 2 now being tested

posted in: DMR, GD-77, Ham radio | 19

Over the last few weeks, the Alpha 2 has had a number of bugs which only seem to affect some people, and its been difficult to track them down.

One problem in particular, was that Jon G4TSN was unable to access his local VHF repeater, but was able to access UHF repeaters. The problem also was only manifest when using a Channel and not if the same repeater was setup on the VFO.

After a lot of experimentation, I found that in the VHF channel, the radio was receiving OK but did not appear to be transmitting, despite the red LED being illuminated.ย  However I attached a power meter to my radio and found that it was actually transmitting, but not on the correct frequency.

Adding some debugging to the code I found that the transmit frequency had been subtly changed somehow between when the Channel was selected and when the radio actually transmitted, and that the frequency was not completely random.ย  But that some of the digits of the frequency (binary digits) had been increased by 1.

An equivalent in decimal, was that the radio changed frequency from 145.725Mhz to 145.826Mhz – but since the numbers are stored in binary the actual frequency seemed to change in a very strange way.

To track the problem down, I had to resort to using hardware watchpoints, in the hardware debugger I have attached to one of my GD-77s, to monitor the memory location that stores the Tx frequency, and I eventually found that the master screen update function was modifying the memory used to store the Tx freq, but this didn’t happen for all channels.

To cut a long story short, the culprit was the code which displays the TG, and Channel name and the Zone name. However when the PTT is pressed, these bits of text have to be moved down the screen to make space for the Talk Timer digits, and the screen is only tall enough to display the TG and Channel name but not the Zone name.

However the code was still attempting to display the Zone name even though the position of the text was below the bottom of the screen, this caused the memory after the screen buffer to be modified my merging with the pixels of the Zone name text characters.

The final solution to the problem was easy. Just don’t display the Zone during Tx ! However finding the cause of the problem took many hours ๐Ÿ™

This bug could have been causing other problems as potentially around 10 other settings could have been corrupted depending on the Zone name text.

ย 

Also, as part of the search for cause of this problem, I have been trying to determine whether the binary code of the AMBE codec, accesses any memory which is also being used by the OpenGD77 firmware, however I have not managed to find this out yet.

Looking at Kai’s code, it wasn’t immediately clear how the memory used by the AMBE codec was being allocated, but after more research and sending an email to Kai, I found that Kai has allocated the entire lower 64k bank of RAM in the MK22 CPU to the AMBE codec.

However doing some tests where i filled the lower 64k RAM with a known pattern (0x55 hexidecimal), and then using the radio for about an hour, before dumping the memory to a file. I discovered that the AMBE coded is only using approximately 8kb of memory in the middle of the lower 64k RAM bank, and the rest is actually available for the OpenGD77 firmware if needed. However I’d need to modify the linker files in order to access this memory, and currently there is around 16k free in the upper 64K, and hence no pressing need to make this change.

What I still don’t know is whether the AMBE codec, may be using some of the upper 64k bank of RAM, and the easiest way to do this is to stop the OpenGD77 firmware using blocks of the upper 64k of RAM and fill them with 0x55 or some other test value and see if they get used.

ย 

Anyway, at the moment, because the firmware seems relatively stable, the likelihood is that the AMBE codec only uses some of the lower 64k, and its going to be a while before I can find time to continue this academic investigation.

I think I am now close to having a stable version of the OpenGD77 Tier 2 Alpha 2 that I can release publicly.

19 Responses

  1. ken
    |

    looking good, thank you

  2. Jeffrey
    |

    Thanks for your hard work and effort!

  3. Tom Nash
    |

    Thank you for your involvement

  4. Alec-N1AJW
    |

    could this be why on phase one I cant get the GD-77 to work on VHF. It just locks up. UHF is fine. I couldnt find anyone who tested VHF. Alec N1AJW

  5. taesik shin
    |

    ๊ฐ์‚ฌํ•ฉ๋‹ˆ๋‹ค. ๊ทธ ๋…ธ๋ ฅ์ด ํ—›๋˜์ง€ ์•Š์„ ๊ฒƒ์ž…๋‹ˆ๋‹ค. ํ•œ๊ตญ์—์„œ๋„ ์‘์›ํ•ฉ๋‹ˆ๋‹ค. HL3BAT

    Translates to


    Thank you. That effort will not be in vain. We support in Korea.”

  6. Roger Clark
    |

    Alpha 1 seemed to have some problems on VHF with the memory overwrite issue.

    I’ll email you a Alpha 2 version

  7. Ray C
    |

    Awesome news, I can’t wait to test it.

  8. Roger Clark
    |

    Ray

    I’ll email you a link to the private download.

  9. Jon
    |

    Sounds great looking forward to testing!

  10. Jon Moran
    |

    Sounds great looking forward to testing!

  11. Peki
    |

    Hi Roger, link to download alpha 2 test, Sounds great looking forward to testing!

  12. Peki
    |

    Hi Roger, link to download alpha 2 test

  13. Peki
    |

    great looking forward to testing!

  14. Alec-N1AJW
    |

    thank you. Ill look forward to a copy Alec N1AJW

  15. Roger Clark
    |

    While the Alpha 2 is out with the testers, I have noticed some less than optimal functionality which I want to fix before I do another general release.

    For example I found that the VFO screen is actually redrawing 1000 times per second, even when nothing is changing on the screen. As this will be wasting valuable CPU power that is needed for the AMBE audio decode etc, I have fixed this problem.

    I am also adding a signal strength bar graph onto both the VFO and Channel screen, which is proving to be very handy. However, I have not managed to get it to work with simplex DRM signals from another DRM radio. In theory I should be able to synchronise the RSSI sampling to the incoming DMR signal, but in practice if I sample when I receive a TimeSlot Interrupt from the C6000 the AT1846 RF chip reports no signal at all.

    So itโ€™s going to take some more work to get this feature fully working.

    I have also noticed when changing channel / frequency between groups of repeaters transmitting the same signal, that the TG and ID are not redisplaying. I think this is because the TG and ID display system is setup to not do unnecessary updates when nothing changes, however in this case the TG and ID do need to be redisplayed even though they have not changed.

    And I still have the problem of your own ID displaying due to the digital echo of your own signal returning from the repeater , up to a second after you release the PTT.

    However I will probably release the Alpha 2 or Alpha 3, in the next week or two, even if it has some of these niggles, as itโ€™s still far better than the Alpha 1.

  16. DO9EA
    |

    Amazing work, really great !
    Question: In analog mode, the radio lacks the 1750 tone of EU repeater.
    The solution is not: GD-77 analog mode, press PTT button + โ†button.
    Any hints ?
    Thanks for your great work for OpenGD77 !

  17. Roger Clark
    |

    G4TSN also mentioned to me that the 1750 tone burst is still used on some repeaters in the UK.

    I think it should be possible to configure the RF chip (AT1846) to generate a 1750Hz tone, using its CTCSS generation system, as any tone can be generated.

    However I don’t know how this is configured in the CPS.

    Is there a way to do this in the official CPS and official firmware ?

  18. Mimmo
    |

    Hello to all
    have any of you done tests in C4FM?
    personally I did several tests, but it doesn’t work!
    it would be interesting to be able to use it also in C4FM
    some idea?
    regards

  19. Roger Clark
    |

    The HR-C6000 DSP chip used in the GD-77 only appears to support DMR.

    There is no direct access to either the digital audio samples from the RF chip (AT-1846S) or the 4FSK decoder part of the HR-C6000.

    Hence no other modes apart from DMR and FM are possible.

Leave a Reply