Closed maurizioandreotti closed 1 year ago
This looks like another case where the driver XON/XOFF handling may not be working 100%.
The 0.3 version XON/XOFF is guaranteed to drop characters There may be something we do not know about some Radios that does not work with the driver XON/XOFF handling.
iz2fow version corrections: my d-rats 0.3.9 Python 2.7.9 GTK 2.24.10 PyGTK 2.24.0 LibXML using 0.4 KB
Just noticed from this bug report, that D-Rats was operating in Linux XANY mode, which requires that the device sending XOFF to send additional XOFFs codes if needed.
If the radio is not sending the additional XOFF codes, then this can result in data loss on transmission.
The PR-268 reverts to the previous behavior, except that incoming characters that show up instead of XON/XOFF are no longer discarded.
Today some 2hour TR/RX tests - reporting here some outcomes and console logs to support troubleshooting.
All the stations below were in same locations for both the tests scenarios with the configuration usually adopted for D-rats 0.3.x As all three stations were able to receive clear audio between them and all radios were showing callnames at RX time at all times the expectation was that each station was able to receive all chats when other stations were transmitting. (i.e. everybody able to hear anybody at anytime).
Setup:
Scenario A - setup and results
Scenario B - setup and results station FOW: 0.3.10 with ID5100 --can receive D-Rats chat from both BDZ and FOW station BDZ: 0.4.1dev18 with ID51 -- can receive D-Rats chat from both LXI and FOW station LXI: 0.4.1dev18 with IC2820 -- can not receive D-Rats chat from other (but can transmit) (reverting to 0.3.10 the chat was receivable)
Log from BDZ:
LOG from LXI: