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
... the second AGW port is described to AGW clients as INVALID CHANNEL. An AGW 'X' request to this port elicits this response: {port:1, dataKind:"X", callFrom:"W6JMK", data:"00"}
Which suggests that Direwolf rejected the call sign. Direwolf's log output is not much more informative: ERROR - Request to transmit on invalid radio channel 1.
I would prefer that invalid channels are not visible to AGW clients, or at least the log message says something about this port relating to the right channel of the first device (not a channel of the second device).
I used Direwolf built from source tag 1.7 commit de293a1 on Ubuntu 22.04.3 on an x86_64 laptop.
The text was updated successfully, but these errors were encountered:
After fix for issue 510, the AGW 'G' command (get port info) response provides only valid channels.
If they are not in the list of valid channels, I would expect client apps not to try to access them.
Let's look at the code and see what it does when 'X' (register callsign) is used on an invalid channel.
First direwolf should print "AGW protocol error. Register callsign for invalid channel ...".
After the response header, there should be a single byte with 1=success or 0=failure.
Note that this is a single byte binary number, not an ASCII character.
The protocol spec states,
"The data frame is 1 byte long and contains the value 1 if the registrations is succesfull or 0 in failure.
1 is not ASCII value. This byte value is either 1 or 0."
Thank you for fixing issue 510. That prevents this situation from arising to begin with.
I agree, the only way to report the problem to the AGW client is to send a failure code in the 'X' response. But the log message could be more informative than "Register callsign for invalid channel ...". Why is the channel invalid? Does the problem lie within Direwolf, or in the AGW client? What might the user do to solve the problem? I've figured it out by now, but someone new to the problem would be puzzled.
If I configure two devices, like this:
... the second AGW port is described to AGW clients as INVALID CHANNEL. An AGW 'X' request to this port elicits this response:
{port:1, dataKind:"X", callFrom:"W6JMK", data:"00"}
Which suggests that Direwolf rejected the call sign. Direwolf's log output is not much more informative:
ERROR - Request to transmit on invalid radio channel 1.
I would prefer that invalid channels are not visible to AGW clients, or at least the log message says something about this port relating to the right channel of the first device (not a channel of the second device).
I used Direwolf built from source tag 1.7 commit de293a1 on Ubuntu 22.04.3 on an x86_64 laptop.
The text was updated successfully, but these errors were encountered: