OpenGD77 Tier 2 Alpha 2 is available for download

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

The latest version of the OpenGD77 firmware can now be downloaded from this link

https://github.com/rogerclarkmelbourne/OpenGD77/raw/Tier2/firmware_binaries/daily_builds/OpenGD77_Tier2_Alpha_2.sgl

Edit. 1st November

I found a crash bug in the original Tier 2 Alpha 2 in the Zone list menu

I’ve now updated Alpha 2 version to fix the bug, but I am sure that I will probably need to release more bug fixes to the Alpha 2 so I have created a new version “Tier2 latest”, which I will update whenever I make any progress with the Tier 2 development

https://github.com/rogerclarkmelbourne/OpenGD77/raw/Tier2/firmware_binaries/daily_builds/OpenGD77_Tier2_latest.sgl

 

For those interested in the technical details. The RF chip (AT1846S) and the EEPROM use the same I2C connections to the CPU / MCU, which means I have to be carefull that different parts of the firmware don’t try to access the EEPROM and the AT1846 at the same time.

This is especially problematic, because of the DMR timing requirements a lot of the control of the AT1846 has to be done in an Interrupt Service Routine, which has very high priority and can interrupt during an EEPROM transfer, hence causing the I2C bus to effectively hang. I’ve noticed in these circumstances that a soft reboot, does not resolve the problem and the only way to clear the bus conflict is to turn the radio off and one again.

Its easy to spot when this problem has occurred, because when the firmware tries to read the EEPROM, it can’t so it has to go back to using hard coded defaults for the frequency and the display back light intensity etc.  So you’ll see 430.0000 displayed on the VFO and the backlight will be at 100% intensity.

 

In this case the problem was not being caused by an ISR, but was because the firmware uses a Realtime Operating System (RTOS), where the main task which includes the User Interface and menus etc, runs as a separate task to the DMR/FM RF control task.

The RSSI sampling is handled by the DMR / FM RF task, but the Zone list menu is handled by the main / UI task, and the EEPROM access to read the Zone names was being interrupted by the DMR / FM task, as it has higher task priority (because its more time critical than the main / UI task.

 

I had a couple of options to fix this, either move the RSSI sampling to the main task, or mark the code block in the DMR / FM RF task as “Critical”, so that task switching could not occur when it was sampling.

Because RSSI is a RF related element, I decided it made more sense to leave the RSSI sampling code as part of the DMR / FM task, and to add the code to prevent task switching.

The EEPROM reading and Writing code, already has the code to prevent task switching, so the bug was most likely that the EEPROM read was initiated whilst the RSSI was being read from the AT1846. Either way, the result was the EEPROM could not be read and the final result was the I2C bus locking up.

 

In addition, I also found a bug in some new code which I added to do partial updates to the display. And the RSSI bar graph was not always getting updated. So I’ve changed the code back to doing a full screen redraw each time the bar is updated.
In the longer term I need to work out why the partial display update didn’t work correctly. But because the firmware was working prior to this update, I’ve simply put it back to the way it was before.

 

And…

I made one other small enhancement. The feature to temporarily change the radio’s DMR ID has been changed, so that pressing Function + Green key, after entering the new DMR ID, writes the ID to the codeplug, so that even if the radio is power cycled the new ID will be retained.
I did this because I needed it for testing, as I could not be bothered to keep loading different codeplugs with different ID’s in them.

Also this means that its now possible to get a brand new GD-77, install the OpenGD77 firmware, and to operate the radio using the VFO without needing to use the CPS to set the DMR ID or a channel etc.

This version is still far from perfect, hence I’m not renaming it as a Beta version, but it is better than the original Alpha version.

 

Known bugs and other comments

  1. Hotspot mode has not been integrated into this version yet as its not stable enough.
  2. Your own ID / Callsign will be displayed when using repeaters which have a digital echo.
    I will need to put some sort of masking to prevent the radio from displaying its own ID / TG if its an echo after releasing the PTT when using a repeater.
  3. The firmware crashes occasionally
  4. The firmware can be made to crash by doing things like changing the channel over and over again in quick succession or switching between modes over and over again , quickly
  5. Sometimes the display briefly shows TG 0, or potentially an old ID rather than the current ID, when changing channels or Timeslots.
  6. The display occasionally has come pixels in the wrong place, but it normally immediately redraws and the pixels are removed.

 

New features in this version

 

  1. In Rx when the received signal Rx group does not match the Tx TG the Talk Group is shown in inverse video.
    This is to alert the operator that they will not be transmitting back to the other station on the same TG as the other station is transmitting on.To switch to the TG being used by the other station: Press the Function (blue) key while the TG is being shown in inverse video and the Tx TG will be changed to match the Rx TG.
  2. Signal strength bar graph is now shown on the Channel and VFO screens.
    This is not highly accurate and as intended as a guide to the signal strength. If you need a dbM measurement of the signal use the RSSI screen, but even then each GD-77 has slightly different Rx sensitivity so the dBm value is not guaranteed to be that accurate.
  3. TimeSlot filtering works a lot better than in the previous version.
  4. ID and TG number display should only be for the currently selected TimeSlot.
  5. The Orange button now accesses a context sensitive menu on the Channel and VFO screen.
    Currently this only has a few functions.
    On the VFO screen, the VFO freqs can be changes e.g. Tx / Rx swapped, or both frequencies set to the Rx frequency.
    On the Channel screen there is only one function, which copies the Channel data to the VFO

 

 

 

54 Responses

  1. Rick
    |

    I’m leaving for vacation today. So won’t be able to try out drawing any “signal strength” and “battery” icons in above bitmap software (like in the UTF-8 fonts) before two weeks. Maybe someone else is ready.

  2. Roger Clark
    |

    Adding the VFO B should not be too hard. But I think that the middle of the top of the screen, will need to show the name of the VFO. I think it probably isn’t necessary to show the word Channel or CH in the middle of the header row for the Channel screen as it’s immediately visually obvious it’s the channel screen.

    I keep a copy of both the current channel data and the VFO data in memory, and I can make the VFO channel data struct into an array of structs. ( length 2 ).

    And store a new variable to store whether the current VFO is A or B.

    I don’t currently write the changes to the VFO back to the codeplug, I store the VFO data as part of the non-volatile settings , which are saved in the EEPROM when the radio is turned off.

    But I could easily change this to use the codeplug for storage, because I think the VFOs are stored in the EEPROM section.

    I don’t normally write to the Flash, because of its wear limits, and also because you have to read , erase and then rewrite the flash memory in 4K pages, even if you only change a few bytes.

    The only time I potentially change the Flash is when the operator presses Function + Green in the channel screen to permanently save a change to the channel, and the Channel number is > 128 and hence is stored in Flash ( because of the legacy Codeplug structure )

  3. Roger Clark
    |

    I think I need to add a screen to allow users to calibrate their individual radios for both power and RSSI.

    The RSSI calculation is an average from 3 different radios, all of which had different sensitivity.

    Also the RSSI calculation is different on 2m to 70cm. So I would need to include calibration entry on a per band basis. i.e. VHF, and UHF, and potentially in the future on the 220 MHz band that the RF chip also supports

    On the RSSI screen, in the top right corner there is a number.

    This is the raw RSSI value that I get from the AT1846S RF chip.

    The calculation I use for dBm is

    // Use fixed point maths to scale the RSSI value to dBm, based on data from VK4JWT and VK7ZJA
    dBm = -151 + trxRxSignal;// Note no the RSSI value on UHF does not need to be scaled like it does on VHF
    }
    else
    {
    // VHF
    // Use fixed point maths to scale the RSSI value to dBm, based on data from VK4JWT and VK7ZJA
    dBm = -164 + ((trxRxSignal * 32) / 27);

    So there is both an offset and a scale factor.
    The scale was done using integer maths but in hindsight, it would be better to use floating point , as the CPU has single precision floating point as part of its instruction set

    The S meter bar graph is a bit of a hack. I just put spaces between the text so that it lined up approximately with the length of the bar graph.

  4. Roger Clark
    |

    FYI,

    VK4APF has the same problem with the audio breakup and the LED going out etc etc.

    If I can’t replicate your bug on any of my 5 GD-77, I will ask Robert VK4APF if he is willing to swap radios with me, and I will need to post him by radio and he will need to post his radio to me.

    However my guess at the moment is that the problem is possibly an Rx calibration issue, and I will ask Robert VK4APF to backup his radio and send me the files, so I can compare whether any of the factory calibration data has values which are a lot different to my radios, but similar to your calibration values.

    Kai wrote the code which handles putting the calibration data into the hardware, so I do not know if he applied any Rx calibration, e.f. Perhaps some AF level control of the 4FSK audio signal from the AT1846 into the C6000 DMR DSP chip

Leave a Reply