Wait for clear channel (not busy) when using VARA

[bseidenberg]

Currently, Pat only implements the busy check for ARDOP. Do the same for VARA. The actual busy/not busy logic is already implemented in Pat-Vara/vara.go in handleCmd().

[bseidenberg]

Note: I currently only have remote access to radios to test this, which makes generating the right RF rather difficult. But, it seems straight forward enough given the code.

[bseidenberg]

Updated

[martinhpedersen]

This must also be changed. Passing adTNC here is only correct for ARDOP. We will need to pass a reference to the appropriate TNC connection, which depend on the URL scheme.

[bseidenberg]

Ah, I got it. Sorry, i thought "adTNC" was the current one, I see now where the symbols come from.
Sorry, I'm still struggling with idiomatic Go, especially the typing system. (This is the only go code base I've touched).

And yes, to your earlier question, the VARA modem code does implement the Busy() method.

Will send try 3.

[martinhpedersen]

Looks promising 👍

The only thing remaining is to test this over some time, and under different conditions. Since we don't provide a method for overriding the "wait busy" state, we depend heavily on a good busy detector.

Do you have any chance of testing this soon, or organize some testing one way or another?

Thanks!

[bseidenberg]

Thanks Martin! I'm away from my radios, but hopefully will be back to them in a few more weeks. Benjamin

…

On 2/14/23 01:34, Martin Hebnes Pedersen wrote: ***@***.**** commented on this pull request. Looks promising 👍 The only thing remaining is to test this over some time, and under different conditions. Since we don't provide a method for overriding the "wait busy" state, we depend heavily on a good busy detector. Do you have any chance of testing this soon, or organize some testing one way or another? Thanks! — Reply to this email directly, view it on GitHub <#387 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADDPQUAIZS3JHA4RU24NX2TWXM7RTANCNFSM6AAAAAATO7AUEE>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[martinhpedersen]

@bseidenberg - Did you get a change to test these changes as we discussed? 🙂

[bseidenberg]

Thanks for the reminder! I decided to look at this today, and it segfaults on a nil pointer exception in transport.go... but I can't figure out how it's different from the ARDOP version. I need to brush up on my go pointer passing as I debug...stay tuned.

…

On 4/16/23 04:55, Martin Hebnes Pedersen wrote: @bseidenberg <https://github.com/bseidenberg> - Did you get a change to test these changes as we discussed? 🙂 — Reply to this email directly, view it on GitHub <#387 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADDPQUH3UFJ7FPYEQUQFJZ3XBPMZ5ANCNFSM6AAAAAATO7AUEE>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[bseidenberg]

OK, I think I understand what's going on...I think. All the other initModem/initTNC() functions are argument-less and directly manipulate the various variables in connect.go for their modems. However initVaraModem() takes a pointer to the modem. That pointer is passed by value as vModem. The vModem local is updated inside initVaraModem() to point to the new modem, but because it's passed by value, the outer "global" of varaHFModem/varaFMModem isn't updated. So, those are always nil, and my code blows up when it tries to dereference them later.

This seems like a bug with the call structure of connect.go, and it being inconsistent... thoughts?

[martinhpedersen]

I had a quick look, and I think I've spotted the bug 🙂

The problem is not in your code. The problem is initVaraModem(vModem *vara.Modem, scheme string, conf cfg.VaraConfig). It takes a pointer to vara.Modem, expecting to be able to reassign it. It needs to take a pointer to pointer in order to reassign it like that.

So the global vars varaHFModem and varaFMModem is never really assigned and is therefore nil when passed to busyWait(). That's probably a bug from the original author that has been this way since VARA support was first introduced.

I can create a branch to fix this, but I don't have the setup to test. Maybe you could help me with that? What we need to confirm is that the fix does not break teardown on subsequent VARA sessions. E.g. make one connection, wait a bit (without stopping Pat) and then do another connection.

[bseidenberg]

Yep, happy to test, just shoot me the branch. By the way, if you're on any realtime chat service (IRC?), that'd be great for real-time discussion. Feel free to ping me out of band.

(Edit: Also: Glad we agree on the bug :) )