[pskmail] Re: Aw: (Long) Report of "extensive" use of PSKmail while crossing the Pacific Ocean
- From: Christian Wagner <wagnerschristian@xxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Mon, 9 Jul 2012 19:44:50 -0500
Hi All,
Thanks for the warm welcome back to the list...
BTW, I uploaded the NOT error corrected version of the mail- I had a couple of
weeks to write that damn thing and now that...AAARGGG.
Anyways, you seemed to get what I wanted to say just fine despite my numerous
spelling errors and half finished sentences.
Here are some thought on your replies:
The multiple mail download works allready. That's good news. My ribs will thank
you...(get pushed against the navigation table with every wave...).
Multiple upload is most welcome too since you usually want to send all your
mails in the outbox any way. I totally agree that the more automation, the more
people tend to go with a certain "fire and forget" attitude, but if it shows
over time that people tend to interfere with existing QSOs, you can always
remove the feature.
I'd like to clarify the multiple header download on my part a bit:
Often with bad connection after you request a header download (QTC) - the
server does not deliver right away and you get the usual back and forth chatter
just as if the connection is idle. Then, after a minute or two you get nervous
and press qtc again. As it turns out, the server understood the first request
just fine and delivers the headers now two times. The same happens with a mail
download sometimes. Of course you allways can do a "stop transaction" request
to stop the server from sending stuff a second time, but I also found that the
"stop transaction" sometimes takes as much time as downloading a small amount
of data, so you just go with it. But there could be something on the server
side that prevents the delivery of the same data twice. A criteria for this
could be same data request right after each other or within the same session
etc.
Coordinates:
Is anybody actually using decimals (dd,dd) with Lat/Long data? I only saw it
displayed where the Position is not required to be human readable (like a web
browser address on the openstreetmap site etc.). Just forget the decimal stuff
and make everything in the client in the degree/minutes format (dd mm,mm) this
is much easier to work with (as a user).
All the gpses on all the boats I know of, display the Pos. in that format -
nobody uses dd,dd.
Another thing- I downloaded the serverlist a couple of time during the passage
to try some new servers. What would be really helpful is a rough position of
the servers- I think an accuracy next to the nearest full degree would be
enough- that is about +/- 30 Miles near the equator- good enough for knowing if
the server is 500 or 2500 miles away. I know, in Europe the callsign is a good
indicator of the servers location, but an actual position helps a lot to
discriminate between a west and an east coast server in the US.
Also I found, after coming back ashore, the server list looks quite different
from what I downloaded about two weeks ago. In the hf aquired list I never saw
KB2PNM for instance, although he was almost always "on air". Also, it seems
that there is a new australian server.
It could be that all that just has changed between the last two to three weeks-
can anybody comment on that?
I just learned from the mailinglist that jPSKmail 2.xx works with OpenJDK now.
That's good news- I will happily switch to 2.xx if that is the case now, just
to get rid of fldigi. Is it really useable with OpenJDK? Any comments on that?
BTW, compressed data delivery should be made the default as it really speeds up
things- more time for others to use the frequency.
Cheers, Christian
Other related posts:
