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

  • From: Pär Crusefalk <per@xxxxxxxxxxxx>
  • To: pskmail@xxxxxxxxxxxxx
  • Date: Mon, 30 Mar 2009 13:53:52 +0200

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: