Update 7th Feb

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

Update 7th Feb

Post by VK3KYY » Fri Feb 07, 2020 12:58 am

I've uploaded a new version

https://github.com/rogerclarkmelbourne/ ... latest.sgl

Changes in this version are
  • Many fixes to Hotspot mode problems, from Daniel
  • DMR options that control how where the Callsign and name data comes from, have been moved to the Display Options screen, as the main Options screen was getting very full and the Display options screen seems the more logical place for these settings. From me.
  • A new Display option has been added, to control whether the Callsign and name is show on 1 or 2 lines. The default is now for the Callsign and name to just be displayed on the middle line of the display. These changes are thanks to Daniel.
  • Fixes to UHF power calibration settings. From me
  • I've also added a possibly fix for the bug reported where bursts of audio from the incorrect TS could be heard, probably when changing channel or frequency
  • The 5W++ power setting has been temporarily removed, until some consensus is achieved about whether it can be included perhaps by some special keypress.
  • Last heard screen. Blue button (SK2), now displays the TG and time, instead of SK1. I changed this to allow for future uses of SK1, where hopefully the button will be user configurable in the CPS
Notes
This version has not been extensively tested, but seems to be stable.

User avatar
W1AEX
Posts: 126
Joined: Sat Nov 16, 2019 9:00 pm
Location: Connecticut, USA
Contact:

Re: Update 7th Feb

Post by W1AEX » Fri Feb 07, 2020 1:17 am

Roger,

I loaded this on my two GD77 radios and it's running fine on both. Good idea moving the Cc, DB, TA setting to Display Options. I would vote to forget the 5++ watt setting but that's just me being conservative and also wondering about signal purity.

Looks like a fine release.

73, Rob W1AEX

NA7Q
Posts: 151
Joined: Wed Jan 01, 2020 3:41 pm

Re: Update 7th Feb

Post by NA7Q » Fri Feb 07, 2020 1:32 am

I have tested the incorrect timeslot heard bug, and it is still be present for me. You beat me to the UHF calibration fix. I had spotted that last night.
Thanks for this! So far, everything seems stable using my build on this new code.
VK3KYY wrote:
Fri Feb 07, 2020 12:58 am
I've uploaded a new version

https://github.com/rogerclarkmelbourne/ ... latest.sgl

Changes in this version are
  • Many fixes to Hotspot mode problems, from Daniel
  • DMR options that control how where the Callsign and name data comes from, have been moved to the Display Options screen, as the main Options screen was getting very full and the Display options screen seems the more logical place for these settings. From me.
  • A new Display option has been added, to control whether the Callsign and name is show on 1 or 2 lines. The default is now for the Callsign and name to just be displayed on the middle line of the display. These changes are thanks to Daniel.
  • Fixes to UHF power calibration settings. From me
  • I've also added a possibly fix for the bug reported where bursts of audio from the incorrect TS could be heard, probably when changing channel or frequency
  • The 5W++ power setting has been temporarily removed, until some consensus is achieved about whether it can be included perhaps by some special keypress.
Notes
This version has not been extensively tested, but seems to be stable.

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

Re: Update 7th Feb

Post by VK3KYY » Fri Feb 07, 2020 1:46 am

NA7Q wrote:
Fri Feb 07, 2020 1:32 am
I have tested the incorrect timeslot heard bug, and it is still be present for me. You beat me to the UHF calibration fix. I had spotted that last night.
OK.

I we probably need a more complex solution, or possibly need to reset the timecode variable in some other places in the code.


What's a good way to reproduce the problem ?

User avatar
m1dyp
Posts: 601
Joined: Sat Nov 16, 2019 8:03 am
Location: Hertfordshire, U.K.
Contact:

Re: Update 7th Feb

Post by m1dyp » Fri Feb 07, 2020 1:47 am

many thanks to all

edit: I like the split option......all on one line looks good

NA7Q
Posts: 151
Joined: Wed Jan 01, 2020 3:41 pm

Re: Update 7th Feb

Post by NA7Q » Fri Feb 07, 2020 2:14 am

VK3KYY wrote:
Fri Feb 07, 2020 1:46 am
NA7Q wrote:
Fri Feb 07, 2020 1:32 am
I have tested the incorrect timeslot heard bug, and it is still be present for me. You beat me to the UHF calibration fix. I had spotted that last night.
OK.

I we probably need a more complex solution, or possibly need to reset the timecode variable in some other places in the code.


What's a good way to reproduce the problem ?
I reproduce it by weak signal or the other method I'll mention. If I am on the opposing timeslot, I can tilt the radio horizontally to lose the signal, when I go back vertically, the signal comes back, and you hear the incorrect timeslot. For me this is as simple as being indoors and moving around as well.
Interestingly enough, I do not hear it if I disconnect the antenna and reconnect just a single time. It will only seems to happen If I quickly disconnect and reconnect the antenna a few times a second, acting like that weak signal flicker we see on the LED when on the fringe of receiving.

I use a BNC adapter and BNC antenna for quick and easy disconnecting. So try to disconnect and reconnect at a quick rate of a few times a second, and you should easily reproduce it.

I do see it in other ways, but this is the easiest way to reproduce it.

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

Re: Update 7th Feb

Post by VK3KYY » Fri Feb 07, 2020 2:26 am

NA7Q wrote:
Fri Feb 07, 2020 2:14 am

I reproduce it by weak signal or the other method I'll mention. If I am on the opposing timeslot, I can tilt the radio horizontally to lose the signal, when I go back vertically, the signal comes back, and you hear the incorrect timeslot. For me this is as simple as being indoors and moving around as well.
Interestingly enough, I do not hear it if I disconnect the antenna and reconnect just a single time. It will only seems to happen If I quickly disconnect and reconnect the antenna a few times a second, acting like that weak signal flicker we see on the LED when on the fringe of receiving.

I use a BNC adapter and BNC antenna for quick and easy disconnecting. So try to disconnect and reconnect at a quick rate of a few times a second, and you should easily reproduce it.

I do see it in other ways, but this is the easiest way to reproduce it.
OK.

Did you try doing the same thing using the official firmware or other radios ?

The problem is that on weak signals the TimeCode value (TS number) get corrupted, hence we can't simply rely on the TimeCode value in the DMR signal, and instead we keep track of the TS as it normally alternates between TS1 and TS2.

If we get several missmatches in a row between our internal TimeCode and the one in the DMR signal, then we re-sync.

In your case its loosing sync and we only resync if the signal is out of sync for more than 3 DMR frames.

We can't mute the audio when it potentially goes out of sync, as that would cause dropouts on weak signals.

NA7Q
Posts: 151
Joined: Wed Jan 01, 2020 3:41 pm

Re: Update 7th Feb

Post by NA7Q » Fri Feb 07, 2020 2:47 am

VK3KYY wrote:
Fri Feb 07, 2020 2:26 am
NA7Q wrote:
Fri Feb 07, 2020 2:14 am

I reproduce it by weak signal or the other method I'll mention. If I am on the opposing timeslot, I can tilt the radio horizontally to lose the signal, when I go back vertically, the signal comes back, and you hear the incorrect timeslot. For me this is as simple as being indoors and moving around as well.
Interestingly enough, I do not hear it if I disconnect the antenna and reconnect just a single time. It will only seems to happen If I quickly disconnect and reconnect the antenna a few times a second, acting like that weak signal flicker we see on the LED when on the fringe of receiving.

I use a BNC adapter and BNC antenna for quick and easy disconnecting. So try to disconnect and reconnect at a quick rate of a few times a second, and you should easily reproduce it.

I do see it in other ways, but this is the easiest way to reproduce it.
OK.

Did you try doing the same thing using the official firmware or other radios ?

The problem is that on weak signals the TimeCode value (TS number) get corrupted, hence we can't simply rely on the TimeCode value in the DMR signal, and instead we keep track of the TS as it normally alternates between TS1 and TS2.

If we get several missmatches in a row between our internal TimeCode and the one in the DMR signal, then we re-sync.

In your case its loosing sync and we only resync if the signal is out of sync for more than 3 DMR frames.

We can't mute the audio when it potentially goes out of sync, as that would cause dropouts on weak signals.
I have tested using the official firmware, and it does not do this, as one would expect. On either of my two radios. It is in fact exclusive of OpenGD77.
The test is being done listening to my VHF repeater. It happens when mobile also, but less noticeable as I'm usually within a strong coverage area if I use it mobile. So I suppose this has me wondering what could be done to resolve this.
Last edited by NA7Q on Fri Feb 07, 2020 2:57 am, edited 1 time in total.

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

Re: Update 7th Feb

Post by VK3KYY » Fri Feb 07, 2020 2:56 am

OK

Its a bit difficult to work out whats going on.

It sounds like the TimeSlot interrupt must have stop triggering, otherwise we'd still be in sync, as the radio keeps relatively good sync even with no Rx, i.e during Tx the radio relies on its own internal synchronisation to keep on the correct TS, as its not receiving while its transmitting.

AFIK. the TimeSlot interrupt normally keeps going unless we deliberately reset the DMR system, i.e when we think the signal has completely ended.

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

Re: Update 7th Feb

Post by VK3KYY » Fri Feb 07, 2020 3:01 am

@NA7Q

You could try setting timeCode to -1 in here

Code: Select all

void init_digital_DMR_RX(void)
{
	write_SPI_page_reg_byte_SPI0(0x04, 0x40, 0xC3);  //Enable DMR Tx, DMR Rx, Passive Timing, Normal mode
	write_SPI_page_reg_byte_SPI0(0x04, 0x41, 0x20);  //Set Sync Fail Bit (Reset?))
	write_SPI_page_reg_byte_SPI0(0x04, 0x41, 0x00);  //Reset
	write_SPI_page_reg_byte_SPI0(0x04, 0x41, 0x20);  //Set Sync Fail Bit (Reset?)
	write_SPI_page_reg_byte_SPI0(0x04, 0x41, 0x50);  //Receive during next Timeslot
}
e.g.

Code: Select all

void init_digital_DMR_RX(void)
{
	write_SPI_page_reg_byte_SPI0(0x04, 0x40, 0xC3);  //Enable DMR Tx, DMR Rx, Passive Timing, Normal mode
	write_SPI_page_reg_byte_SPI0(0x04, 0x41, 0x20);  //Set Sync Fail Bit (Reset?))
	write_SPI_page_reg_byte_SPI0(0x04, 0x41, 0x00);  //Reset
	write_SPI_page_reg_byte_SPI0(0x04, 0x41, 0x20);  //Set Sync Fail Bit (Reset?)
	write_SPI_page_reg_byte_SPI0(0x04, 0x41, 0x50);  //Receive during next Timeslot
	
	timeCode = -1;// Clear current timecode synchronisation
}

Post Reply