Simultaneous transmission on both time slots.

[IU4LEG]

Hi guys.

@Colin

Many thanks for the the trouble you took in order to do your investigations and considerations you have exposed, you are really very kind!
I will try to contact the Sysops by submitting the matter.
I have no experience with that kind of thing, but if I understood correctly it would be a matter of trying to update the repeater's firmware, which, however, I do not know if it is easy or hard to do.
I guess that the update is doable, but I am not sure that the upgrade firmware is free and I guess that the repeater too will have to be reprogrammed.
I will try to write to Sysop about all this things.
Of course I will try to test the thing with other repeaters especially BrandMeister, but also of other kinds.
It is still weird, as with the factory firmware from Radioddity I have never found it and in any case I have never seen the problem even by other users who use different models of DMR terminal and also of other brands.
Also the lack in bilateral communication between GD-77s with stock firmware from Radioddity and the Open one while transiting through the repeater, in example by engaging the TG9 (LOCAL) or TACs, could be consequent of the obsolete firmware of the Motorola DR3000 repeater, even if it is a mystery why in the same scenario with the factory firmware from Radioddity the two GD-77s talk each other without problems and the Motorola DR3000's firmware is always the same, even if obsolete.
A thought of mine is that since the problem is there and it is real, it means that potentially in a totally unconscious way any DMR user could create problems to the network, even considering the large amount of repeaters whose firmware may not be updated and therefore obsolete.
Thanks Colin!

@Fabio

Thanks my namesake!
What you wrote relieves me, so I am not the only one who noticed the thing.
Do you remember ever seeing the problem even while using the stock firmware from Radioddity?
The answer could be useful to know, as I believe that, beyond the fact that it would be better the repeater's firmware was always updated in the limit of the possible, it could be interesting to understand what in the factory firmware from Radioddity prevents the onset of the problem regardless of the firmware revision running on the repeater.
My personal opinion.
Thanks Fabio!

73 best regards de Fabio IZ2EIB

Hi Fabio,
No, with the original firmware it never happened. Or at least I never noticed the problem.
Samuele IZ4RCU had the same problem a few days ago, and he too has the firmware opengd77 updated to the latest version. We were talking on a repeater on tg9 ts2 and occasionally I didn't listen to him anymore. I saw the carrier, and if I moved on the TS1 I could listen to it. After a while I no longer listened to him on Ts1 because he returned to tx on TS2. The repeater in this case was the IR6UDA of the DMR-ITALIA network. I do not know if it is a Motorola or something else, because it is not indicated on the dashboard of that network.
greetings from IU4LEG.

[VK3KYY]

Colin

Originally in Tx we set it to receive on the alternate TS, but there seemed to be audio problems on Tx with Motorola repeaters if we did this, so I changed it simply to not do anything on the alternate TS.

The code could be changed so that it would receive on the alternate TS, and we could see if that made any difference .

I have no idea why the Tx audio suffered a sort if fading effect when Rx was enabled on the alternate TS, but just for testing this problem it’s worth trying that.

The code is in the TimeSlot Interrupt as part of the switch statement.

Btw. I wonder if this issue is just in Tx Wakeup of also after Wakeup, or whether if the Tx doesn’t need to send the Wakeup whether that makes any difference


Cheers

Roger

[IZ2EIB]

@Fabio

Thanks for your kind reply!
So now I am no longer alone, at least three users have noticed the problem: me IZ2EIB, you IU4LEG and the third IZ4RCU.

@Roger

Thanks for your tireless work on the project.
I see you already have some ideas in mind.
Thank you very much Roger!


73 best regards de Fabio IZ2EIB

[VK3KYY]

Guys

Can you try this version.

The radio is configured to Rx during the alternate TS, during Tx, i.e the PA will be turned off and the antenna switch will be changed and the Rx preamp will be enabled.

It has audio drop-out problems on Tx when I use it with a Motorola DR3000 repeaters, which is why I don't normally operate the firmware in this way, but it should definitely not be transmitting on both TS.

[EA5SW]

I have been able to reproduce this problem with my gd77 in a dual hotspot but it only does so when starting for the first time the GD77 and changing from the tg that is stored to a different one.

Tomorrow I test this version.

[DL4LEX]

The switching between RX snd TX is each done in an interrupt.
These interrupts are triggered some nanoseconds before the 30ms timeslot ends. If during transmitting the firmware switches the unused timeslot to RX this switching could happen too early, garbling the end of the actual frame.

If this happens it should be visible on the scope.
@Colin, could you repeat your measurement with this version?

Maybe the DR3000 repeaters are a bit more picky than other repeaters.

This could also be a reason for the voice cut offs if optimization is turned on.

There is a register in the HR-C6000 to set the time between triggering the interrupts and the end of a timeslot.

[VK3KYY]

Alex

The master version code does not switch to Rx between Tx, it just configures the C6000 to neither transmit or receive.

Initially the code in state TX_1 set the C6000 to receive on the next TS, but this causes some strange fading effect on the DR3000 and other repeaters, but it works fine with simplex and duplex hotspots.

I asked Colin about whether the other radios e.g. Motorola receive on the alternate TS when transmitting, but he didn't think that they did this.


The problem of the Tx audio fading in and out when Rx is enabled during Tx is strange. The signal does not always cut out completely, sometimes the audio seems to slowly get worse and then a few seconds later it starts to work again, during the transmission.

This would suggest a timing problem where perhaps the audio data is not ready to be sent, perhaps because the additional processing required to handle the other interrupts during Tx, which may not occur when Rx is not enabled on the alternate TS during Tx

[G4EML]

I haven’t experienced the fading audio problem but if it behaves as you say then it would point to a timing drift problem. Repeaters tend to have a window in which they will receive a signal. If the timing drifts outside this they don’t receive correctly. From memory the MMDVM systems have a much larger window than the commercial repeaters. This sounds like it is better but a signal that is significantly out of sync will cause problems to the other timeslot.

I will repeat my timing test later today.


As for receiving in the unused timeslot. Some radios do this but they are only looking for the reverse channel data which is a very short burst in the centre of the timeslot. They don’t try to receive the whole frame. Reverse channel signalling can be used to interrupt a transmission and force the radio to go back to receive. Motorolas do this but I don’t think any Chinese radios do.

[VK3KYY]

Hi Colin

Look at the TX_1 state in the Timeslot ISR, there is a line commented out, which would enable the Rx i.e if you comment out the other line.


https://github.com/rogerclarkmelbourne/ ... #L925-L926


The build I uploaded has that change, but I tested and on DR3000 the audio gets a strange semi random fading effect.

I presume that by enabling the Rx on the alternate TS the C6000 must be generating more interrupts and perhaps the time in the SYS ISR etc is taking too long and this is then delaying the Timeslot interrupt.

BTW. Its not super high resolution, but the PIT timer counter variable is a reasonable way of getting an idea of when each ISR is called.

However the only way to really know when stuff is actually getting transmitted is to use a scope etc on the data lines or looking at the RF

[G4EML]

Roger,
I can confirm that if you enable Rx in the unused timeslot the Tx audio suffers from occasional dropouts.
Looking on the scope it is not affecting the Slot timing so the timeslot interrupt looks OK.
The problem is most likely some sort of buffer overflow or underflow that is messing up the voice coding.

Colin.