Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

INVALID CHANNEL is cryptic #509

Open
jmkristian opened this issue Jan 24, 2024 · 2 comments
Open

INVALID CHANNEL is cryptic #509

jmkristian opened this issue Jan 24, 2024 · 2 comments

Comments

@jmkristian
Copy link
Contributor

If I configure two devices, like this:

ADEVICE plughw:CARD=Digirig,DEV=0
ACHANNELS 1
ADEVICE1 plughw:CARD=DRA,DEV=0

... 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.

@wb2osz
Copy link
Owner

wb2osz commented Jan 26, 2024

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."

I believe this was implemented correctly.

Your analysis is welcome.

73,
John WB2OSZ

@jmkristian
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants