You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I don't know if it is an issue of the YSFReflector or if it is an issue of the BrandMeister YSFClient-connection to the reflectors but:
If you use actual version of YSFReflector (actual since about 2 weeks with blocking abilities built in by Jonathan) it is working perfectly from YSF to YSF. But if you have an interconnected Reflector that uses YSFClient-Connection from BrandMeister to get connected to a TG there traffic originated at YSF side will sound stretched and repeatingly on DMR... an effect we had on first attempts of the blocking list but removed them... It's only persistent with actual version.
So if someone also has this effects, please report them for further testing... I think there is something little odd in the code that the DMR-Bridges don't like so much.
Bad thing is that I can't test it myself because I only have one hotspot and when using it with YSF I only can check with blueDV and AMBE-Stick on DMR and then all sounds ok strangely.
73 de Kim
DG9VH
So I sadly can't reproduce this alone, that's the fact why I did not report it while I was testing the version two weeks ago...
Hope someone is responding to help us testing this :-)
The text was updated successfully, but these errors were encountered:
The network hasn't changed at all. Is it possible that someone is interpreting the sequence number incorrectly? The sequence number is a byte with the end of message bit being 0x01. The rest of the byte is used as the sequence number is the remaining seven bits. It was a silly design decision I know.
If you interpret the byte as a simple sequence number you will get 0, 2, ,4 , 6, etc. So your software would presumably fill in the gaps. So the byte needs to be shifted to the right one bit to get the sequence number and the byte ANDed with 0x01 to get the end of message indication.
That's my idea, too... the BrandMeister YSFClient is causing the problem here :-) will wait, what the BM-guys say... I asked in their telegram-support-group... but still no reply...
All good with the sequence numbers. From time to time Reflector creates at least the second connection context for the same srcip:srcport. Probably when reflector is behind the NAT.
Copy of my E-Mail to the Mailinglist:
Hi,
I don't know if it is an issue of the YSFReflector or if it is an issue of the BrandMeister YSFClient-connection to the reflectors but:
If you use actual version of YSFReflector (actual since about 2 weeks with blocking abilities built in by Jonathan) it is working perfectly from YSF to YSF. But if you have an interconnected Reflector that uses YSFClient-Connection from BrandMeister to get connected to a TG there traffic originated at YSF side will sound stretched and repeatingly on DMR... an effect we had on first attempts of the blocking list but removed them... It's only persistent with actual version.
So if someone also has this effects, please report them for further testing... I think there is something little odd in the code that the DMR-Bridges don't like so much.
Bad thing is that I can't test it myself because I only have one hotspot and when using it with YSF I only can check with blueDV and AMBE-Stick on DMR and then all sounds ok strangely.
73 de Kim
DG9VH
So I sadly can't reproduce this alone, that's the fact why I did not report it while I was testing the version two weeks ago...
Hope someone is responding to help us testing this :-)
The text was updated successfully, but these errors were encountered: