[Fixed] Occasional transmission on the wrong TimeSlot

IZ2EIB
Posts: 161
Joined: Sat Nov 30, 2019 12:55 pm

Re: Occasional transmission on the wrong TimeSlot

Post by IZ2EIB » Tue Dec 31, 2019 2:46 pm

Hi guys.
I am sorry for the mess in my replies resulting by the split of the original thread.
Please, apologize me.
m1dyp wrote:
Tue Dec 31, 2019 12:51 am

hi, if i had read this correctly

does this show a fault with gd77 factory firmware from Radioddity, if you have to enable promiscuous mode ?

or am i totally wrong and just making thing worse :mrgreen:
Hello Ken.
I was probabily foggy in describing the facts, however no, no new bugs for the factory firmware from Radioddity, rather a new oddity for the Open one that seems to be able to route communications on the repeater in an unintelligible way for others DMR terminals.
I did some tests with the new test firmware released by Roger,
31122019_fw.png
31122019_fw.png (2.55 KiB) Viewed 4000 times
finding the same oddity of which I wrote in my previous post.
31122019.jpg
31122019.jpg (107.63 KiB) Viewed 4000 times
Now the time slot is honored, for what I can deduce from the BrandMeister dashboard, but for a reason that I can not understand by transmitting with the GD-77 on which the new Open test firmware is runnig, then with the other one GD-77 on which there is the stock firmware from Radioddity it is not possible to listen to anything, not even intercept the DMR id, to do it with the GD-77 running the factory firmware from Radioddity it is need to enable the promiscuous mode.
Instead transmitting with the GD-77 on which the stock firmware from Radioddity runs, the GD-77 with the new Open test firmware listen perfectly and without problems, therefore practically with these latest two Open test firmwares the communications are not bilateral but rather one sided, although there seems to be no logical reason for this behavior.
TG and time slot were the same for both GD-77s, either because I saw it on the BrandMesister dashboard, and because in the end I disconnected the TG91 invoking the TG4000 from the GD-77 with the stock firmware from Radioddity and the communication has stopped as it was logical to expect and this shows that the GD-77 on which the factory firmware from Radioddirty runs is correctly configured both as a TG, as a time slot, and as for any other its setting.
I want to point out that anyway from my side I do not see any evidence that there is any occasional transmission on the wrong time slot.
Based on what the BrandMeister dashboard show at me, now time slot is always honored correctly and it does not change, not even occasionally.
The only clue that makes me suspect a problem is the non-bilateral nature of communications, where the GD-77 with the new Open test firmware is not listened to by the other one on which the factory firmware from Radioddity runs if not by enabling the promiscuos mode, while instead by transmitting with the latter transceiver with the stock firmware from Radioddity the first with the Open test one has no problem decoding the DMR traffic.
Evaluating the facts, as the TG is surely the same for both the transceivers, what comes to my mind is that the two GD-77s are broadcasting on two different time slots, but the thing is not occasional, here it is persistent, as I can not in no way to listen to myself while using the GD-77 with the factory firmware from Radioddity, which beyond its any bugs, is to be considered as a reference to evaluate the other transceiver on which the new test Open firmware is running.

VK3KYY wrote:
Tue Dec 31, 2019 9:11 am
Can you also try this version

This may be better, but it may also make things worse ;-)
Hello Roger, thank for your tireless work.
As for the previous release of the Open test firmware OpenGD77_201912302100-Fix-for-end-of-tx.sgl, also this latest one OpenGD77-201912311749.sgl fix the simultaneous transmission on both time slots, but from what I have written above, sadly it does not seem to improve the situation, also in consideration of what IU4LEG relates with his testimony (https://www.opengd77.com/viewtopic.php?f=11&t=400).

One thing that I have forgotten to report, although actually it has nothing to do with the matter being discussed here, is that as far as I am concerned with these last two Open test firmware (and I guess with the current official releases), the alias' management has improved a lot.
Thanks Roger!




Hello Colin, thank you very much for your investigations!
G4EML wrote:
Tue Dec 31, 2019 11:31 am
This should really be moved to a new thread because the original problem of simultaneous transmission on both timeslots has been fixed.

The problem with occasionally transmitting on the wrong timeslot is a different one.
I agree, since as far as I have been able to see directly, time slots are now correctly honored.
I repeat that from my side I do not see any evidence that there is any occasional transmission on the wrong time slot.
Based on what the BrandMeister dashboard show at me, now time slot is always honored correctly and it does not change, not even occasionally.
I can still be wrong, though.
Thanks!

G4EML wrote:
Tue Dec 31, 2019 11:31 am
IZ2EIB,
It sounds like your problem talking between two radios is down to the behaviour of the factory firmware. The factory firmware has a bug where it will only receive if the talkgroup is included in a RX group. You must have a RX group setup on every channel even if you only want to use one talkgroup. This is different from most DMR radios which will normally always receive the talkgroup you are transmitting.
Colin, I agree the original firmware from Radioddity has the bug you wrote, however in this case it does not seem to me to be the only culprit because:

I have a RX group setup on every channel (just double checked), but with Roger's CPS Community Edition I remember writing and using without problem codeplugs on which Rx Group list was set to None instead of linked to some TGs, because CPS Community Edition allows the DMR channels to work, even when the Rx Group list is set to None, or if the Transmit “Contact” TG is not in the Rx Group (https://www.rogerclark.net/gd-77-firmwa ... -rx-group/).

Using the stock firmware from Radioddity on both GD-77s that I have the problem there is not neither between them, nor from and to any other DMR terminal of any brand and type I have been able to hear, even considering that in all the time from which I have the GD-77 it never happened to me to come across this same situation and this regardless of whether Rx Group list is set to None or different or else whether the Transmit “Contact” TG is or not in the Rx Group while I am using Roger's CPS Community Edition.
In no case I have had problems while RX/TX or decoding DMR, as well as no one has reproached them of any kind to me.
Then, of course everything can be and in any case I am the least suitable person to discuss these matters, the only little thing I can do is explain what is evidenced by my tests.
Beyond bugs in the factory firmware from Radioddity I am pretty sure that it is possible to fix everything even with the Open firmware, since the GD-77's hardware is always the same, so if it is possible for the stock firmware from Radioddity, it is surely so also with the Open one.
Anyway, of course, from my side no problem at all to split the things using separate threads.
Thanks!

Happy new year to everybody and thank you all for your great deal of patience!
(@Roger, here I still have about 7 and a half hours to go until the new year arrives.)

73 best regards de Fabio IZ2EIB

User avatar
IU4LEG
Posts: 191
Joined: Wed Nov 20, 2019 12:49 pm

Re: Occasional transmission on the wrong TimeSlot

Post by IU4LEG » Tue Dec 31, 2019 3:11 pm

VK3KYY wrote:
Tue Dec 31, 2019 1:31 pm
IU4LEG wrote:
Tue Dec 31, 2019 12:27 pm
Ok sorry Roger. also delete my post that I just created
No worries

Happy New Year... Its now 00:31 local time on 1st Jan 2020 for me. Time for bed.
it's true! happy New Year to you too! we are still in 2019 here :-)

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

Re: Occasional transmission on the wrong TimeSlot

Post by m1dyp » Tue Dec 31, 2019 3:23 pm

wish i was near a repeater to help, but alas only hot spot here, hope it gets sorted

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

Re: Occasional transmission on the wrong TimeSlot

Post by VK3KYY » Tue Dec 31, 2019 9:41 pm

I've been discussing this with Colin via email, and the problem seems to be that when the signal gets weak that the "TimeCode" aka TimeSlot number that the C6000 reports to the firmware, (by reading register 0x52 in the C6000), is not always correct, and if the PTT is pressed when this value is incorrect, the radio will transmit on the wrong timeslot.

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

Re: Occasional transmission on the wrong TimeSlot

Post by VK3KYY » Tue Dec 31, 2019 9:43 pm

VK3KYY wrote:
Tue Dec 31, 2019 9:41 pm
I've been discussing this with Colin via email, and the problem seems to be that when the signal gets weak that the "TimeCode" aka TimeSlot number that the C6000 reports to the firmware, (by reading register 0x52 in the C6000), is not always correct, and if the PTT is pressed when this value is incorrect, the radio will transmit on the wrong timeslot.
I can now reproduce the problem fairly reliably by using the magnetic mount antenna I use on the car, put on the ground outside my shack.

If I choose a repeater that has a very weak signal e.g. around S3 or less, I get the problem about 1 in every 5 transmissions to the repeater

Colin has sent me a possible fix for this, which I'm now looking at, and I have some ideas myself about possible solutions, which are similar to Colin's solution

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

Re: Occasional transmission on the wrong TimeSlot

Post by VK3KYY » Tue Dec 31, 2019 10:13 pm

Well, my idea on how to fix this didn't work very well, so I've attached a version that uses Colin's fix.

I think this version will fix the problem, because I can replicate the problem by using a small antenna and this version always transmits on the correct TS

PS. Its the first version for 2020 ! at exactly 9:00 local time.
Attachments

[The extension sgl has been deactivated and can no longer be displayed.]


User avatar
IU4LEG
Posts: 191
Joined: Wed Nov 20, 2019 12:49 pm

Re: Occasional transmission on the wrong TimeSlot

Post by IU4LEG » Wed Jan 01, 2020 7:03 am

Good morning and happy new year,
Today I will try this version.
Thank you very much

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

Re: Occasional transmission on the wrong TimeSlot

Post by VK3KYY » Wed Jan 01, 2020 7:28 am

I have dissassembled a GD-77 today and carefully soldered very very small wires into the PCB, so that I can monitor the data between the C6000 IC and the CPU MCU.

I'm already seeing some interesting data, which will hopefully make even more improvements to the DMR functioning, after we have understood what the data means.

User avatar
IU4LEG
Posts: 191
Joined: Wed Nov 20, 2019 12:49 pm

Re: Occasional transmission on the wrong TimeSlot

Post by IU4LEG » Wed Jan 01, 2020 8:34 am

good job Roger,
I have installed the OpenGD77-202001010900.sgl version but I have not tried it yet. I'm waiting for Samuele to do a long qso by monitoring the dashboard. During the day we do the tests. ;-)

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

Re: Occasional transmission on the wrong TimeSlot

Post by VK3KYY » Wed Jan 01, 2020 8:58 am

OK

I have now collected some interesting data between the MK22 MCU and the C6000 DMR chip.

It will help us improve the operation.

Post Reply