OpenGD77

G4EML wrote: ↑

Tue Jan 07, 2020 9:34 pm

Thanks for the reports. I think this may be a good as we can get it at the moment.
Receiving the other timeslot for a short time is possibly a side effect of the improved timeslot detection we are now using. It now spends more time checking the received timeslot signal is valid. This may make it a little slower to lock onto the correct timeslot but it should also mean that it detects the timeslot more reliably. As you say this will normally only happen on first receiving the signal such as when you change channel. There is a 50/50 chance of being on the wrong timeslot initially. It may be possible to mute the receiver during this time but that may then give the impression of being slow to receive.

that's fine for me, it's absolutely not a problem

Hi guys,
yesterday afternoon during 2 qso on 2 different repeaters this thing happened again (with the latest firmware released on 21-02-2020).
the radio transmit on the wrong time slot. This had not happened for a long time.
I realized it because at a certain point, at the end of my transmission I saw the carrier in rx but I no longer heard the audio. Changing the timeslot from 2 to 1 I received my correspondent in qso.
this time, however, I was in a base station with an external antenna and the repeaters arrived with a strong signal and vice versa I arrived on the repeaters with -87 dbm. With a very stable signal.
Obviously it doesn't always happen, but occasionally it still does.
73 de IU4LEG

GUYs, SOME TIMES HAPPEN AGAIN, ESPECIALLY IN MOBILE.....

try Using and old version, and let us know the last version which does not have the problem

ok, i will try

Hi to all guys,

i have the latest firmware, and occasionally my radio change the TS for 1 to 2 or viceversa.
other OM in the world with this boring problem?
I attach a screen of the dash board:

Av salut


Samuele

I can confirm it, I was in qso with Samuele.
It didn't happen to me because I temporarily reinstalled the original firmware to do some tests.
it actually happens often, and I don't know which previous firmware version i can try to test which one didn't have this problem.

I've just noticed this is happening on my radio as well.

I think perhaps one of the changes for the CC filter removal has changed something which has broken the TS locking.

I won't know when this problem started, as I only just noticed it today, and it will take me some time to try some previous versions to confirm which version does not have this problem.

I have modified the firmware to hopefully reduce this bug.

Please see my post

viewtopic.php?f=13&t=737

and try the new version.

Looking at how this could happen, the only condition I could see, was when there is a weak signal and the radio is receiving multiple incorrect TimeCode values from the C6000 chip.

If the firmware had more than 3 invalid TimeCodes in a row, it assumed that the radio must have the Timeslots transposed, so the firmware locks onto the last of the last received TimeCode.

If you happen to transmit just after the TimeCode has been changed, its possible that the radio just received 4 noisy frames that happened to appear as
TS 1, TS 2, TS 1, TS 2.

But could all have been wrong. The changes of this are only 1 in 16 ( 2 x 2 x 2 x 2) , so this could happen relatively frequently on very noisy signals .

So I've added another check that after the radio changes synchronization, that the radio can't immediately transmit, and it needs to receive another 5 frames that are in lock, before TS is allowed.

For very weak and noisy signals, this will prevent transmission for 150mS (5 x 30ms), which will hardly be noticeable, but normally on strong signals the radio will be "in lock" and there should be no extra delay.

ok Thank you Roger,
We will try this version. We let you know
73