[pskmail] Re: To do and wish list for the java client + feedback on V0.3.3

  • From: John Douyere <vk2eta@xxxxxxxxx>
  • To: pskmail@xxxxxxxxxxxxx
  • Date: Tue, 31 Mar 2009 16:25:23 +1100


Thanks for your reply.

1. I will try to document what fldigi is sending when setting modes from the
Java client. Please note that was under WinXP so may not be visible under

2. For the automode I had a look around the fldigi documentation and code
and this is what I think could be of value:

A. Setting modem RSID on and off: There is an xmlrpc server built into
Fldigi which provides the main.rsid and main.rx methods which seem to be
setting the rsid receive on or off. I don't know if there is a method to set
and read the mode and to set or reset the transmission of rsid. Maybe these
methods can be built into the ARQ side of the conversation rather than using
a separate connection to the xmlrpc server if it makes sense.

Only issue I can see is backwards compatibility since the enabling of rsid
would prevent reception of any frame until a positive rsid is received. But
since the s/n ratio needed for detection is between -18 and 16dB, it is par
with the best modes we use for Pskmail and therefore should not result in
more difficult link-ups. On the contrary it would elimitate the issue of
mode selection within a certain minute of the scanning sequence and allow
the best choice for the conditions and purpose (connected or unproto modes).

B. The sequence I would propose is the following:

B1. Server side: have the RX rsid switched on while listening (no session in
progress). The RX rsid will go off automatically on receipt of a valid ID
then the mode will be set accordingly by fldigi and normal squelch will

On the TX side, keep rsid on until first reply from client (i.e send connect
ack and initial status message with rsid). Then switch rsid off as it saves
about 3 seconds per frame until disconnection or request for a mode change.

When a mode change is requested (using the current method (~SPEEDxxx!),
acknowledge the request, then change mode and set TX rsid on until receipt
of an ack from the client. Then switch TX rsid off.

Unproto modes (i.e. beacon) always set TX rsid on.

B2. On the client side: RX rsid on when not connected so it can receive
beacons and TTY connect requests in any mode. On connect set TX rsid on,
until it receives a connect ack from the server. Then switch TX and RX rsid
off for the duration of the session. If a mode change is requested, wait for
receipt of acknowledgment of our request from server, then switch RX rsid on
until next server frame is received.

For unproto modes, always set TX rsid on at the client side.

This simplifies the on-the-fly change of mode and allows to start with a
secure mode (i.e. MFSK16 or Thor11 for example and work the way up to faster
speeds seamlessly).

I believe this would allow for more robust modes to be used for server
beaconning and APRS reporting (with the mode information included in the
beacon text for information to the clients), while not compromising high
speed connects when conditions permit.

In fact the next (easy?) step could be server or client initiated automatic
modes/speed adjustments based on the error rate since only reducing block
size produces a rapidly diminishing return (due to the fixed overheads of
headers and footers). This could be a good "selling point" I suggest.

The new protocol (no client polls) certainly allows for a much simpler
implementation of variable mode/speed QSOs.

Best regards,

John (VK2ETA)

On Mon, Mar 30, 2009 at 10:53 PM, Pär Crusefalk <per@xxxxxxxxxxxx> wrote:

> Hi John,
> Thanks for your input, its appreciated!
> Regarding the issues:
> 1. Probably, it just sends the command now, I have not seen fldigi
> misunderstand that and send it but its possible. It should be made
> better anyhow.
> 2. Ah, thats not covered at all. Needs work,
> 3. Yes, correct. I have seen that too, should be on a server list of
> things to do.
> And regarding the list:
> A. One way to do that would be to diff the system time to the gps time
> and apply the diff whenever using the clock. We could hide the time in a
> class and apply methods for that. Ultimately we could use GPS time and
> update the system clock. But that requires that the user is allowed to
> update the time, I don't know what group you have to be a member of the
> get that access.
> B.
> 1. Auto mode. Interesting. We send XML formatted commands to fldigi now
> and it would be possible for fldigi to return stuff the same way.
> 2. Yes, address book would be good. Adding that.
> 3. Yes, agree
> 4. Yes
> 5. Yes, an ack is always nice ("at least they know I am sinking...").
> Thanks John!
> 73 de Per, sm0rwo
> mån 2009-03-30 klockan 10:01 +1100 skrev John Douyere:
> > Hi Rein and Per,
> >
> > First some feedback after using the java client 0.3.3 (under windows)
> > this week end (went camping about 150Km from home and could not do
> > nothing..hihi). This is really coming out as a fine solution. At the
> > risk of repeating myself here, but really, the change in protocol is a
> > winner and opens more options (more down this email).
> >
> > Some issues first:
> >
> > 1. When setting a new mode from the java client, fldigi transmits the
> > command over the air. I haven't looked at the text sent but it happens
> > every time. This could be a duplicate with Rein's bug list below.
> >
> > 2. I suspect the code is not implemented yet, so fldigi changes the
> > mode but no request to change is sent to the server. Just a comment on
> > "on-the"fly" changes of mode: in my opinion, the logic of the code as
> > in the Perl version was good with two steps: request at the first
> > selection, then change the local fldigi when selected a second time.
> >
> > 3. On the server side I noticed that if a request arrives late in a
> > minute cycle (scanning server obviously) and the server does not reply
> > within that minute, the scanning logic will come into action before
> > the reply and the reply will be done on the new frequency/mode
> > combination.
> >
> > Now on the comments to Rein's wish list (and more):
> >
> > A. Clock from GPS: a good feature in my mind. rather than changing the
> > system clock, use the gps time in the client only and display an icon
> > or text identifying the source of the clock in the client display. If
> > the gps was to be stopped, use the system clock corrected in + or - by
> > the last measured time difference (in the current session) between gps
> > and system.
> >
> > B. On the rest I would vote for in order of interest to me:
> >
> >      1. Addition to your list: auto mode (explanation below)
> >      2. Addition to your list: a simple address book (or integrated
> >         with a standard one)
> >      3. Speed in other units of measure (for land bound ppl like me)
> >      4. Compass
> >      5. Clients receiving emergency info should react (not sure
> >         how...display, sound, I am not sure about the value of sending
> >         an ack)
> >
> > Regarding the auto mode:
> >
> > This is the result of testing I did this weekend where I set the
> > server using different modes (MFSK and PSK at various speeds).
> >
> > I realised that it could be possible to have the server react to a
> > client's Reed Solomon id which would be transmitted only at connect
> > requests and at mode changes. That way all scanning servers can listen
> > on a default mode (e.g. PSK250 for speed), but can change to any mode
> > at the reception of a connect. If we can read the RSID received in
> > fldigi from the server, then we can adjust the timing correspondingly.
> > The advantage of this is that we can then select the mode most
> > appropriate for the conditions at the time.
> >
> > Since the client does not poll anymore, there are no tricky issues of
> > timing between the client and server which were a real issue in the
> > past.
> >
> > When a request for change is made from the client while connected (by
> > sending a new RSID until acked), the server can then send the next one
> > or two polls with an RSID then switch the id sending off. This will
> > then automatically set the client to the right mode without having to
> > manually select the mode a send time in the client. The client stops
> > sending RSIDs when the mode received is the same as the mode sent.
> >
> > I am not sure if controlling and reading the results of the RSID is
> > possible from the client or server at present but I don't feel it
> > would be difficult to implement in fldigi.
> >
> > Hope this helps.
> >
> > Please keep up the great work.
> >
> > 73, John (VK2ETA)
> >
> >
> >
> > On Mon, Mar 30, 2009 at 3:21 AM, Pär Crusefalk <per@xxxxxxxxxxxx>
> > wrote:
> >         Hi,
> >
> >         Just came back from a weekend in Latvia (Riga). Had no
> >         internet during
> >         the stay and I had decided to relax and not do anything. Well,
> >         I kept to
> >         that "do nothing" idea for a while but in the end I started to
> >         write a
> >         to do list and expanded that into a wish list for future work
> >         on
> >         jpskmail. I have discussed this with Rein and he added a few
> >         things so
> >         its now a big list of things to do.
> >
> >         Anyway, I am posting this to get your ideas about what is
> >         important,
> >         what is not and if you feel stuff has been left out etc.
> >         Feedback
> >         welcome :-)
> >
> >         To do and wish list for the client:
> >
> >         * Bugs
> >         - APRS-icon starts wrong, should be shown with image
> >          (i.e ship, house etc).
> >         - Modem mode setting, better state machine and handling
> >
> >         * GPS and position related
> >         - Position entry in degrees, degrees&minutes and locator
> >         selectable
> >                - Masked edit field to help with format
> >         - Presentation of speed in km/h, knots and mph (more?)
> >         - Graphical course presentation (emulated compass)
> >         - Maybe make it possible to update system clock from gps time
> >         (permission trouble here)
> >
> >         * Miscellaneous
> >         - Emergency mode, client sends emergency messages
> >                - Client receiving these should react somehow
> >         - Compressed messages, add support like linux client
> >         - Statistics for received info (heard list)
> >         - Tooltips for all fields in the options window
> >         - compressed file upload to server (emcomm)
> >         - TTY (keyboard-to-keyboard) mode
> >
> >         * Code related
> >         - Automated gui regression test procedure,
> >          perhaps using http://abbot.sourceforge.net/doc/overview.shtml
> >         - Create UML from reverse engineering, use that to clean up
> >                - Clear out unused classes and methods
> >         - Javadoc, explanations about every method
> >         - serialport and nmeaparser classes better split to enable
> >         support for
> >         other hardware
> >                - Integrate weather station
> >         - Less static declared classes
> >         - Main loop should be removed and replaced by timer events
> >         - Support for other modems, such as hardware based. Not a
> >         priority now.
> >         - New email window to be expanded with recipients, bcc etc.
> >         - Received messages, bulletins, to be completely viewable by
> >         doubleclicking to open in own window
> >         - pushmail, mostly a server issue but client needs stuff too
> >         - Support for some kind of messenger, jabber, possible?
> >
> >         * Map, new tab
> >         - Extend tab idea and include a mapping component, for
> >         instance using
> >         JXMapViewer with local map data
> >         - Present received geographical data (positions etc) on map
> >         tab
> >         - Heading and distance to other stations (ships for instance)
> >         - Present emergency messages and show heading, distance with
> >         some
> >         priority
> >         - Right click on presented unit to get info, send message etc.
> >         - Make it possible to send pointers to stuff, like "dangerous
> >         rock here"
> >         with an icon
> >         - Send areas, lines, bearings etc.
> >
> >         * Completely wild idea...
> >         - Make it a C3 system
> >                - Control of more sensors
> >                - Lots of map functions, predicitions (loads of work
> >         here)
> >         - include IMO "On scene commander" support for rescue ops.
> >         - And more stuff I do not dare to even write...;-)
> >
> >         73 de Per, sm0rwo
> >
> >
> >
> >

Other related posts: