Update 4th Feb

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

Re: Update 4th Feb

Post by VK3KYY » Thu Feb 06, 2020 9:36 am

DL2MF wrote:
Thu Feb 06, 2020 9:14 am
VK3KYY wrote:
Thu Feb 06, 2020 12:45 am
...
I did consider changing things, so that if the operator kept pressing Function + Right arrow , perhaps 5 times when the power was already 5W, that it would then set to 5W++. i.e like an Easter egg function, (but a documented one)
Suggest, when in 5W mode -> Function + Long keypress Right arrow

73 Mike
Yes. That's a possibility.

On 70cm even providing max drive to the PA only outputs around 5.5W, and I suspect that as the battery goes flat, even with max PA drive the output would not be 5W

On 2m however the output is substantially above 5W.

The other possibility is to only enable it for DMR which is only 50% duty cycle, so heat dissipation would not be a problem.

However I don't know whether the harmonic distortion increases considerably if the PA drive is set to its maximum.

iz1dsj
Posts: 2
Joined: Thu Feb 06, 2020 11:19 am

Re: Update 4th Feb

Post by iz1dsj » Thu Feb 06, 2020 11:25 am

Hello,
I have the radio on, receiving on TS2, I hear once in a while short bursts of conversations being held on TS1, lasting a tenth of a second more or less.
Regards,
IZ1DSJ/N1DSJ Jack

ea3ihi
Posts: 87
Joined: Fri Jan 10, 2020 9:28 pm
Location: Barcelona, Spain

Re: Update 4th Feb

Post by ea3ihi » Thu Feb 06, 2020 12:23 pm

Hello,
I have the radio on, receiving on TS2, I hear once in a while short bursts of conversations being held on TS1, lasting a tenth of a second more or less.
Same here, I was actually going to document it as a bug.

I suspect that due to bit errors that sometimes might affect the TS field, some frames are in the wrong TS. This means that if you are listening to TS2 sometimes you receive audio frames from TS1....but if you are in TS1 when this happens, probably it means that you loose some audio frames (that are treated as if they were for TS2).

This can be better experienced when one TS is silent and there is traffic in the other TS.

There are some bit recovery functions that are applied to every dmr frame but probably not all errors are recoverable. I will investigate if something can be done, maybe keep track of wht TS was being used for centain DMR stream ID (each time you use the PTT a new stream id is created and used during the whole transmission)

David

User avatar
EB3AM
Posts: 204
Joined: Fri Jan 24, 2020 1:40 pm
Location: Catalonia, not Spain
Contact:

Re: Update 4th Feb

Post by EB3AM » Thu Feb 06, 2020 4:57 pm

ea3ihi wrote:
Thu Feb 06, 2020 12:23 pm
Hello,
I have the radio on, receiving on TS2, I hear once in a while short bursts of conversations being held on TS1, lasting a tenth of a second more or less.
Same here, I was actually going to document it as a bug.

I suspect that due to bit errors that sometimes might affect the TS field, some frames are in the wrong TS. This means that if you are listening to TS2 sometimes you receive audio frames from TS1....but if you are in TS1 when this happens, probably it means that you loose some audio frames (that are treated as if they were for TS2).

This can be better experienced when one TS is silent and there is traffic in the other TS.

There are some bit recovery functions that are applied to every dmr frame but probably not all errors are recoverable. I will investigate if something can be done, maybe keep track of wht TS was being used for centain DMR stream ID (each time you use the PTT a new stream id is created and used during the whole transmission)

David
Yes I see this, yesterday night, mix of two slots at same time. Filter TS active.

G4EML
Posts: 919
Joined: Sat Nov 16, 2019 10:01 am

Re: Update 4th Feb

Post by G4EML » Thu Feb 06, 2020 6:44 pm

The timeslot bit is received from the repeater and is compared with the radios local timeslot counter. There is a deliberate delay before the radio will re-synchronise it’s local counter with the repeater. This is because the received timeslot bit is prone to errors and can be received incorrectly. Without the delay the radio could randomly change timeslot. The radio has to see a constant difference before it decides to re-sync.
Once synchronised, providing the repeater continues to transmit, the timeslot should not get out of sync.

You are therefore most likely to hear the wrong timeslot when first selecting a channel that is already active. In that case the radio initially starts with a random timeslot value which may be incorrect. It will then take a fraction of a second before it validates the received timeslot bit and changes to the correct one.
This could probably be improved by muting the receiver for a short while when first selecting a channel until the timeslot has been confirmed. I don’t think this is currently being done.

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

Re: Update 4th Feb

Post by VK3KYY » Thu Feb 06, 2020 10:04 pm

Colin

As the timeCode variable is an int, and we only need to store 0, or 1 in it.

We could set it to -1 when the channel is changed and at the end of reception etc.

Then change the synchronisation code, so that it immediately re-syncs

e.g.
in the HRC6000TimeslotInterruptHandler(void) function

Code: Select all

// Force re-sync is timecode is currently undefined 
	if (slot_state == DMR_STATE_REPEATER_WAKE_4 ||  timeCode == -1)			//if we are waking up the repeater
	{
		timeCode=receivedTimeCode;							//use the received TC directly from the CACH
	}
	else
	{
	....
	}
BTW.

I've had strange things happen if I make the volatile static variables in a global.

It seems to be safer to make an accessor function.

I can give this a try if you like

F6GVE
Posts: 84
Joined: Sat Nov 16, 2019 8:52 am

Re: Update 4th Feb

Post by F6GVE » Thu Feb 06, 2020 11:03 pm

I found something wrong with this firmware + calibration in the CPS

I wanted to calibrate the 1W and 5W UHF. Everything is OK from 400 to 435 MHz but from 440 to 475 MHz the setting is ineffective, no matter the value that is set. it concerns both low power and high power

I downgraded to a previous version (Jan 28 2020 17:28:45 d37986c) and everything worked as expected

I upgraded and downgraded twice to be sure

73
Luc

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

Re: Update 4th Feb

Post by VK3KYY » Thu Feb 06, 2020 11:22 pm

F6GVE wrote:
Thu Feb 06, 2020 11:03 pm
I found something wrong with this firmware + calibration in the CPS

I wanted to calibrate the 1W and 5W UHF. Everything is OK from 400 to 435 MHz but from 440 to 475 MHz the setting is ineffective, no matter the value that is set. it concerns both low power and high power

I downgraded to a previous version (Jan 28 2020 17:28:45 d37986c) and everything worked as expected

I upgraded and downgraded twice to be sure

73
Luc
OK.

Thats strange

I'll double check.

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

Re: Update 4th Feb

Post by VK3KYY » Thu Feb 06, 2020 11:25 pm

ah.

Yes.

My mistake

VHF has 8 calibration regions and UHF has 16. I got the 2 mixed up, which prevented the UHF calibration working in the upper half of the calibration regions.

G4EML
Posts: 919
Joined: Sat Nov 16, 2019 10:01 am

Re: Update 4th Feb

Post by G4EML » Fri Feb 07, 2020 10:50 am

Hi Roger,

I don’t have the time to do any firmware changes at the moment.
Forcing a re-sync on channel change should work although there is a small risk that it might re-introduce the problem of transmitting on the wrong timeslot.

Colin.

Post Reply