[Xastir] Xastir control API?

[Tom Russo]

On Wed, Aug 08, 2012 at 11:04:11AM -0600, we recorded a bogon-computron collision of the <esarfl at gmail.com> flavor, containing:
> On Wed, Aug 8, 2012 at 9:47 AM, David A. Ranch <xastir at trinnet.net> wrote:
> > Thoughts?   And yes, I realize I could do this just with the Linux "beacon"
> > command to send an APRS formatted UI string but it would be nice to have
> > Xastir running more often.
> >
> > --David
> 
> I think you're onto something here... run Xastir all the time, but
> disable beaconing. Use cron and "beacon" to beacon, or use the Xastir
> equivalent, xastir_udp_client http://www.xastir.org/wiki/Server_Port.
> With both of these options, you have to generate the packet string
> yourself, so maybe not exactly what you're looking for.

Sending posits through the server port *could* work, but it's dicey.

The server port is not meant to provide a network-to-rf feed.  You can
trick Xastir into transmitting date fed into the server port if you use the
same callsign/ssid as the Xastir program, but I'm not absolutely certain this
works for the station posit --- it certainly works for feeding objects into
the stream, but as I recall, it doesn't work for messages (due to the specifics 
of how object processing works).

A simple signal handler to cause an immediate beacon *would* be pretty
simple.  You'd have to make sure, though, that Xastir won't try to beacon
on its own schedule as well.  I don't think there's a way to tell Xastir 
"beacon only on request."   I think the only way to disable beaconing would
*also* cause Xastir not to beacon even if you set posit_next_time to zero (as 
I suggested the signal handler do).  It would also prohibit transmission of
station posits through the server port (assuming that even works).

The ideal solution to this would be to have Xastir use hamlib to do the QSY
itself.  That would require a new interface type to be created, which would
be a big deal (interface.c is already a complicated mess).   Or better, 
that existing interface types (serial TNC, KISS TNC, etc.) be controlled by a 
higher level of code that can, if configured, handle rig control before 
sending data to the interface.  'Course that would require someone to really
want this feature enough to implement it...

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236        http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
 one trick, rational thinking, but when you're good and crazy, oooh, oooh,
 oooh, the sky is the limit!"  --- The Tick