Update 7th Feb
Re: Update 7th Feb
No success with that. Still does it.
Re: Update 7th Feb
I'll toy with it a bit more tomorrow and over some of the weekend and see what I observe from general use. But with the weak signal trick or antenna reconnecting, it produces the same results. Interesting, but not a big deal. As for me, it is now bed time. Thanks for jumping in!
Re: Update 7th Feb
Just let the GD-77 scan with TS2.
Done this with mixed analog and digital (Brandneister), TS1 bursts can be heard all time with good repeater siganls
Re: Update 7th Feb
I've not been able to test this as there has been virtually no traffic at all today on the local DMR MARC repeater network.DF9HJ wrote: ↑Fri Feb 07, 2020 7:34 am
Just let the GD-77 scan with TS2.
Done this with mixed analog and digital (Brandneister), TS1 bursts can be heard all time with good repeater siganls
I do have a duplex Hotspot as well, so if the issue can be replicated simply by scanning, I"ll give that a try.
I'm a bit surprised that this is happening during scanning, but I may have made things worse with my last change.
Re: Update 7th Feb
You know that it is a long time since I sometimes relate about the RX "noise/cratch/disruption/corruption" (don't know how to name it) that frequently occurs in RX when listening to DMR with my GD77's.
This happened first with the first attempt to separate the two timeslots. The first hotpost Tier 1 firmware had not this particular issue.
Today the issue is still here, no matter filtering or not the TG.
Even if this issue happens randomly, I wanted to add (but I didn't want to insist too much as few people seems to be concerned) that a way to reveal this issue is to listen to weak DMR signals, but not stable DMR signals. When moving my GD77 in order to be just sensitive enough, the BF doesn't switch on/off clearly as it should but there are many cratch/artefacts/noise instead.
I dont speak about the normal behavior when receiving a weak signal. This is an extra noise.
In fact it is almost impossible to properly listen in mobile situation if the S/N is not high.
I have sometimes the same issue when the scanning stops on a DMR signal, or when switching from VFO to MR if the frequency is different.
I sometimes have this mix of timeslots as related.
I could initialy think that the PLL fails to properly lock for some reason, or the clock is not correctly set.
I spent days in adjusting the clock, to test every improvement of the firmware (buffering, etc.) but the issue is still here.
Thanks a lot for the new improvements of this firmware, and thanks to Daniel too. I can't wait to try it.
But today I wont be that much available for intensive testing
73
Luc
This happened first with the first attempt to separate the two timeslots. The first hotpost Tier 1 firmware had not this particular issue.
Today the issue is still here, no matter filtering or not the TG.
Even if this issue happens randomly, I wanted to add (but I didn't want to insist too much as few people seems to be concerned) that a way to reveal this issue is to listen to weak DMR signals, but not stable DMR signals. When moving my GD77 in order to be just sensitive enough, the BF doesn't switch on/off clearly as it should but there are many cratch/artefacts/noise instead.
I dont speak about the normal behavior when receiving a weak signal. This is an extra noise.
In fact it is almost impossible to properly listen in mobile situation if the S/N is not high.
I have sometimes the same issue when the scanning stops on a DMR signal, or when switching from VFO to MR if the frequency is different.
I sometimes have this mix of timeslots as related.
I could initialy think that the PLL fails to properly lock for some reason, or the clock is not correctly set.
I spent days in adjusting the clock, to test every improvement of the firmware (buffering, etc.) but the issue is still here.
Thanks a lot for the new improvements of this firmware, and thanks to Daniel too. I can't wait to try it.
But today I wont be that much available for intensive testing
73
Luc
Re: Update 7th Feb
I can't replicate the bug of briefly hearing the other TS when the scan stops.
Does this problem only occur if both TS1 and TS2 are in use. There was a QSO on TS2 on one repeater, so I set my radio to TS1 and scanned, and I did not get any audio when the scan stopped on the repeater which had traffic on TS2.
In fact there were several repeaters all on the same TG transmitting the same QSO on TS2, and the scan paused on all of them several times, but I didnt hear any TS2 audio.
Does this problem only occur if both TS1 and TS2 are in use. There was a QSO on TS2 on one repeater, so I set my radio to TS1 and scanned, and I did not get any audio when the scan stopped on the repeater which had traffic on TS2.
In fact there were several repeaters all on the same TG transmitting the same QSO on TS2, and the scan paused on all of them several times, but I didnt hear any TS2 audio.
Re: Update 7th Feb
It happens also if you change the frequency manually, which scanning does itself.VK3KYY wrote: ↑Fri Feb 07, 2020 7:41 amI've not been able to test this as there has been virtually no traffic at all today on the local DMR MARC repeater network.
I do have a duplex Hotspot as well, so if the issue can be replicated simply by scanning, I"ll give that a try.
I'm a bit surprised that this is happening during scanning, but I may have made things worse with my last change.
I've two local repeaters, both Brandmeister, if scan comes across with paused scan, both have the burst and sometimes the TG and ID are displayed.
Holding the GD-77 on the repeater QRG (stop scanning) than no burst, no display.
BTW. I've noticed the burst on older releases as well, It began, if I remeber well, around when you implemented the DMR frame buffering
Re: Update 7th Feb
My local repeater is out of order at the moment, so unfortunately I cannot check if this occurs too when both TS1 and TS2 are in use. I can only test this on next week.VK3KYY wrote: ↑Fri Feb 07, 2020 10:34 amI can't replicate the bug of briefly hearing the other TS when the scan stops.
Does this problem only occur if both TS1 and TS2 are in use. There was a QSO on TS2 on one repeater, so I set my radio to TS1 and scanned, and I did not get any audio when the scan stopped on the repeater which had traffic on TS2.
In fact there were several repeaters all on the same TG transmitting the same QSO on TS2, and the scan paused on all of them several times, but I didnt hear any TS2 audio.
Otherwise my GD77's does the same as you described when everything is allright.
I dont know why sometimes I can ear one TS on both TS1 and TS2 (of course when filtering TS). I didn't try yet to investigate about that
Edit: I badly red, sorry.
"Does this problem only occur if both TS1 and TS2 are in use" No. And I don't know if this also happens when both TS are in use
Re: Update 7th Feb
I believe I have also noticed it when both time slots are active and timeslot filtering is on.F6GVE wrote: ↑Fri Feb 07, 2020 4:32 pmMy local repeater is out of order at the moment, so unfortunately I cannot check if this occurs too when both TS1 and TS2 are in use. I can only test this on next week.VK3KYY wrote: ↑Fri Feb 07, 2020 10:34 amI can't replicate the bug of briefly hearing the other TS when the scan stops.
Does this problem only occur if both TS1 and TS2 are in use. There was a QSO on TS2 on one repeater, so I set my radio to TS1 and scanned, and I did not get any audio when the scan stopped on the repeater which had traffic on TS2.
In fact there were several repeaters all on the same TG transmitting the same QSO on TS2, and the scan paused on all of them several times, but I didnt hear any TS2 audio.
Otherwise my GD77's does the same as you described when everything is allright.
I dont know why sometimes I can ear one TS on both TS1 and TS2 (of course when filtering TS). I didn't try yet to investigate about that
Edit: I badly red, sorry.
"Does this problem only occur if both TS1 and TS2 are in use" No. And I don't know if this also happens when both TS are in use