[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: Mon, 30 Mar 2009 10:01:46 +1100
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:
