PTB integration (new PACTOR mode) - #529
Conversation
|
Thanks for this PR 😊 Haven't found time to review yet, but hopefully next week. Thank you! |
| // Network address of the PTB data socket (e.g. localhost:8301). | ||
| // If empty, defaults to command port + 1. | ||
| DataAddr string `json:"data_addr,omitempty"` |
There was a problem hiding this comment.
Do you imagine we'll ever need to set this explicitly? Maybe we can omit it, and re-consider on user requests? I usually lean towards making the API surface as small as possible 😊
| ardop: ARDOP TNC | ||
| pactor: SCS PTC modems | ||
| pactor: SCS PTC modems (legacy driver) | ||
| ptb: PTB (PACTOR-TCP-Bridge) - modern PACTOR driver |
There was a problem hiding this comment.
I'd like to discuss merging ptb into the existing pactor scheme. Ideally we should have one transport per mode, and which "driver" to use should be configurable by the user. This way, connect URIs such as pactor:///HB9AK?freq=10144.4 can work regardless of the driver.
Depending on whether we want to fully deprecate ptc-go, I think we have two options:
Transport agent
We've done this for the ax25 scheme, with the concept of a "transport engine". Depending on the selected engine, the dial/listen/init picks a code path.
For ax25 I took it one step further, having ax25 serve as an alias for ax25+linux://, ax25+agwpe://, ax25+seria-tnc://. This was done in case anyone wanted to use more than one at a time. They are implemented as distinct transport schemes, and ax25:// is resolved using this function:
Lines 450 to 461 in 2e6a8d1
We could do the same here, by having pactor:// resolve to either pactor+ptb:// or pactor+serial://.
Addr vs Path fields
Another approach could be to stick withpactor:// and the config struct Pactor alone, and switch on whether the (deprecated)cfg.Pactor.Path is set. We should at the same time remove the default /dev/ttyUSB0 value of Path of course, so new users won't get the deprecated driver by default.
type Pactor struct {
// Network address of the PTB command socket (e.g. localhost:8300).
Addr string `json:"addr"` // NOTE: This one should probably have a default value
// (optional) Reference name to the Hamlib rig to control frequency and ptt.
Rig string `json:"rig"`
// Enable PTT control through the rig.
PTTControl bool `json:"ptt_ctrl"`
// Deprecated fields (using omitempty so they won't appear in new config files)
Path string `json:"path,omitempty"`
Baudrate int `json:"baudrate,omitempty"`
InitScript string `json:"custom_init_script,omitempty"`
}
func (p Pactor) IsLegacy() bool { return p.Path != "" && p.Addr == "" }If we truly want to deprecate ptc-go, I think this may be the cleanest way to do it. Once ptc-go is fully obsolete we can remove the code and are left with the intuitively named pactor:// and cfg.Pactor.
Which to pick really depends on whether we want to keep ptc-go alive for years to come, or want users to migrate now. I guess that's up to you to decide, if you want to maintain both ptc-go and ptb 😊
|
I've fixed the build failure @ develop. A rebase of your branch should resolve the build check. |
66ea02d to
b913187
Compare
|
Thanks for the review Martin, I addressed both items, implemented Connection tests succeeded: and 73s, Torsten |
2 participants
Transport for the PACTOR-TCP-bridge. See PTB git page for details. Enables listen mode on PACTOR.