Others I have mentioned this before but I have been thinking about
this more recently:
You sent up your flmsg in the socket settings to send to a
fl-traffic ARQ address and Port instead of fldigi.
When you compose a flmsg message and press the auto-send button, it
sends it to fl-traffic instead of fldigi.
Also fl-traffic monitors incoming received messages.
Fl-traffic lists the messages for outbound in inbound separately.
From fl-traffic, you can send the outbound or forward the inbound to
send as well to any instance of fldigi you have set up by ip/port.
You can have multiple instances of fldigi set up by IP and/or port
so one per radio/band HF/VHF/UHF/ etc.
fl-traffic allows you to check off if the message has been forwarded
and a field for notes and to enter who you passed it to, etc.
fl-traffic has a running log of historical tasks you completed,
receiving of files, sending of files, etc.
I know this might add too much for the normal user to handle.
But imagine a large scale event with multiple messages that need to
be passed to multiple frequencies / nets.
Now imagine multiple flmsg message takers / fillers or even the
served agency themselves filling out the messages in flmsg.
They then press autosend and it goes into the fl-traffic queue.
A ham is running the fl-traffic "switchboard" and is the only one
that actually initiates the sending of the message as he/she is the
only licensed amateur radio operator.
Imagine if there was a two way interface to flmsg also so that same
"switchboard" operator could direct an incoming message to the
appropriate operators computer.
This could make things flow a lot easier and reduce manpower needed
to translate forms as the served agency is filling out flmsg forms
natively and receiving them the same way.
Now for someone to implement this in actual code - the hard part.
I am no C programmer, I can program in different dialects of BASIC
and have no time with my current work commitments.
Is anyone up to the challenge?
Posted by: Larry Levesque <ka1vgm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>