[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 

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: