[Xastir] Messaging

[Curt, WE7U]

On Thu, 30 Dec 2004, Curt, WE7U wrote:

> On Thu, 30 Dec 2004, Tom Robson, ve7did wrote:
>
> > In case I missed it...Love that messaging  sequence you fixed.  Now you can
> > really tell what is happening without the pop up annoyances.....
> >
> > A good example is I received a message from a station and I responded using
> > the reverse path.  I didn't work after about 4 retries, so I changed the path
> > to one I know works and got an ack on first transmission.
>
> Well, since you're playing with that can you test a few messaging
> things on RF for me?  I'm currently down, but might be up again
> tonight if all goes well.
>
> *) Start sending a message to a station you know is not present.  A
> good choice might be your own call but an unused SSID.  Use the
> default paths you have set in your Interface->Properties.  In other
> words don't set a custom path in the Send Message dialog.  After a
> transmission or two, put a custom path into the dialog and see if
> the transmitted packets change to that new path.  Any time you
> change that path, the next transmit for that QSO should change to
> correspond.
>
> *) Delayed Ack Path:  We now send delayed ack's at t+30, t+60, and
> t+120 seconds after we send our first ack, if the remote station is
> sending duplicate messages to us.  The path used by any of these
> ack's remaining in the queue should get changed to whatever is in
> the Path: box in the Send Message dialog.  They should get changed
> at the point the dialog is closed or the Send Now! button is
> pressed.
>
> I'd have to check whether the delayed ack path gets changed just
> before transmit if the Send Message dialog is still up.  It may not.
> That may be a loophole that I still need to close.

Not a problem.  It should update the delayed ack paths within a
second or so of the path getting changed in the dialog.  I can see a
potential conflict here if you're in the middle of changing the path
when the delayed ack is scheduled to go out, you may get an
incorrect path in that case, but the next ack will be fine.  I
suspect this will happen so seldom that it's not worth putting
coding time in to fix it.

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto:    A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"