Integrate with github.com/n8jja/Pat-Vara

[xylo04]

I would also like to add bandwidth as a transport URL parameter, but that's a bigger change, and not strictly required right now.

[martinhpedersen]

I would also like to add bandwidth as a transport URL parameter, but that's a bigger change, and not strictly required right now.

I believe this could be implemented in the VARA modem's DialURL function directly? It has access to the full URL, including the query parameters 🙂

[martinhpedersen]

This is very exciting 👍

I'm not seing any modem teardown in func cleanup(). The tcp connection to the modem should be closed there, for proper app termination.

And shouldn't the vara package distinguish between modem.Close() and conn.Close()? 🤔 It looks like both the modem connection and the dialed vara connection are represented by the same type (the modem-struct). That's a bit odd IMHO. Wouldn't it be better to let DialURL return a separate type implementing the just the Conn interface?

[xylo04]

I would also like to add bandwidth as a transport URL parameter, but that's a bigger change, and not strictly required right now.

I believe this could be implemented in the VARA modem's DialURL function directly? It has access to the full URL, including the query parameters 🙂

That's where I'd like to pipe it down, and I already look for the bw query param in the transport code. However, actually putting that into the UI feels like a separate task, especially since other transports might also benefit.

I'm not seing any modem teardown in func cleanup(). The tcp connection to the modem should be closed there, for proper app termination.

Missed that, I'll add it! Also, I wasn't aware it was necessary because the TCP connection was being dropped after VARA disconnect, but it's possible that was a bug on my part. Should the TCP connection stay open after VARA disconnect?

And shouldn't the vara package distinguish between modem.Close() and conn.Close()? 🤔 It looks like both the modem connection and the dialed vara connection are represented by the same type (the modem-struct). That's a bit odd IMHO. Wouldn't it be better to let DialURL return a separate type implementing the just the Conn interface?

I can keep Close for aborting the RF connection and expose a new CloseModem for closing the TCP connection, does that sound right?

But that brings up a tangential point I was confused about. Since golang interfaces are duck-typed, and since net.Listener.Close and net.Conn.Close have the same signature, those two must be the same method, right? I guess that's appropriate in this case?

[xylo04]

I can keep Close for aborting the RF connection and expose a new CloseModem for closing the TCP connection, does that sound right?

But that brings up a tangential point I was confused about. Since golang interfaces are duck-typed, and since net.Listener.Close and net.Conn.Close have the same signature, those two must be the same method, right? I guess that's appropriate in this case?

The ARDOP and WINMOR stubs both expose Disconnect for RF and Close for Pat's connection to the TNC. Those get used in abortActiveConnection. The PACTOR stub doesn't expose a similar method, but I think it'd be useful to do that for VARA since we're still in early stages. I'll send a PR to add that to http://github.com/n8jja/Pat-Vara.

[xylo04]

Wouldn't it be better to let DialURL return a separate type implementing the just the Conn interface?

I think I'm starting to grok what you mean here. Maybe NewModem() should only initialize the cmdConn, and then DialURL can initialized dataConn and return that to the client code instead of implementing net.Conn itself. That way, if a client takes the return from DialURL and calls Close on that, they're only closing dataConn, not the modem. I'll start to rework the transport that way.

[xylo04]

I'm proposing changes to the VARA stub API in n8jja/Pat-Vara#10.

I tried separating Disconnect for just RF and Close for RF and TCP, but it turns out the VARA program doesn't tolerate that well (doesn't seem to like rapid TCP disconnect and reconnect), so I'm sticking with the one modem.Close method.

However, the change does separate out modem.Close from conn.Close as you suggested.

[martinhpedersen]

I tried separating Disconnect for just RF and Close for RF and TCP, but it turns out the VARA program doesn't tolerate that well (doesn't seem to like rapid TCP disconnect and reconnect), so I'm sticking with the one modem.Close method.

For WINMOR and ARDOP, both data and control sockets are held open even when the modem is idle. Maybe that's what VARA expects as well? Have you looked at the raw tcp frames between VARA and e.g. Winlink Express to see how they've implemented it?

It sounds strange to me that you would need to tear down the modem connection in between sessions. How would that work for incoming p2p connections?

Another concern is the inherit buffering in modems like these. For ARDOP it is very important not to disconnect the data and ctrl sockets until the buffer has been flushed and the modem confirms the disconnect and reaches idle state. If not, the last frames may be lost at either end. Have you investigated this with regards to VARA?

[martinhpedersen]

@xylo04 - What's the status on this? Are you awaiting my review and merge?

[xylo04]

@martinhpedersen no, I'm not waiting for review at this point. I'm trying to dig deeper with the TCP connection state as you suggested. To do that, I'm trying to set up both sides of a VARA-FM connection to test more reliably, and that has taken me off on a tangent of setting up my own RMS.

If it helps, we can change this PR to draft for now and I'll mark it active again later.

[martinhpedersen]

... and that has taken me off on a tangent of setting up my own RMS.

Been there 😆 👍

Thanks for taking the time. My experience is that these transport drivers requires a lot of testing.

I've ordered a RPi 4B in case I have some spare time to do some field testing 🙂 I would also love to see the Listener-interface be implemented. Hopefully I will have time to have a go at it within the next couple of months, if you don't beat me to it 😉

Converting to draft 👍

[gh42lb]

Aloha Chris,                   Just a quick note to give you some feedback on the Pata Vara build. I used this extensively on a Raspberry Pi 4b for the April 16th ARES Comex here in Hawaii. I used Vara exclusively for connecting to the HF gateways (Kenwood radio + Signalink + Diamond trap vertical). Connection was from Big Island to Kauai about 500 miles or so running barefoot only. We had very poor HF propagation on the day only 40M was working to some degree and that was marginal however using digital..the Pat Winlink + Vara performed brilliantly. I could see the Vara modem dynamically changing throughput rates based on the ACK codes going back and forward and even though the signal coming back to my station was in the noise my station had no trouble picking this out and sending back an ACK code. Its pretty impressive what you can do with a pi4b+pat Vara. I also was able to use P2P ardop and that also worked great from the pi. You had mentioned that you may be included the P2P vara listener in your check-in. Let me know if you have anything ready to test...so far so good...its performing great! 73 LB WH6GGO Message ID: ***@***.***>

[martinhpedersen]

I have nothing to add here, except a big thank you for all the hours spent adding support for this mode 😄❤️

Still waiting on my RPi 4 which I ordered many months ago, so I haven't been able to test it myself yet.. but looking forward to it 🙂