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
There is an issue with the fact that if there are queued packets in an module at the end of a transmission, the transmitting client will get back a short sequence of its own Dv packets.
This is not a major issue, but it has some side effects:
In DCS, since each packet carries complete header info, it will match the users own info which may show up on the transceiver screen.
In Dextra mode, since the last few frames don't have header infosm it will put a blak message on screen. This is most disturbing e.g. on the UP4DAR, where it will erase the screen at the end of an incoming transmission.
The text was updated successfully, but these errors were encountered:
Hi, yes we know about this issue, and we had a look at your patch.
Well in fact, your patch works, but would put a second mechanism to the existing, which will be double employment.
We are going to extend the existing function already in place to avoid this behavior.
Thank you for you work.
73, Luc
Let's say it is more a "proof of concept".
Any other solution which prevents this behavior would be ok.
I will close the issue since it is acknowledged.
There is an issue with the fact that if there are queued packets in an module at the end of a transmission, the transmitting client will get back a short sequence of its own Dv packets.
This is not a major issue, but it has some side effects:
In DCS, since each packet carries complete header info, it will match the users own info which may show up on the transceiver screen.
In Dextra mode, since the last few frames don't have header infosm it will put a blak message on screen. This is most disturbing e.g. on the UP4DAR, where it will erase the screen at the end of an incoming transmission.
The text was updated successfully, but these errors were encountered: