[pskmail] Re: Java client on Linux and Windows

  • From: Per Crusefalk <per@xxxxxxxxxxxx>
  • To: pskmail@xxxxxxxxxxxxx
  • Date: Fri, 13 Mar 2009 15:52:09 +0100

Hi John,

Thank you for your comments, very interesting and I'll try to comment a
few things.

2. GPS
I can certainly include a way to alter the units used for the gps
presentation. I'll put them within preferences. I'll also look into what
can be done about presenting the heading. Do you like the "compass"
emulation that is in the perl client?

3. findu
I don't know if I missed that when I made it or if its removed by
accident or if Rein has a better plan there (he worked with the server
update just now). I'll check that.

Regarding the thor mode and that bug I have not experienced that, quite
possibly because I only do psk250. I'll leave that one for Rein :-)

Thanks for the suggestions, I'll keep them in mind now that I'm working
with the client. 

While on the subject, Rein and I have been discussing position formats
used. Position is now in degrees within preferences, that was selected
as gpsd delivers data in decimal format. But, now that we don't use gpsd
(with the java client) we could change that. NMEA delivers its positions
just like aprs wants them: in degrees and minutes. So now I convert the
nmea to decimal format and that is then converted back to degrees and
minutes for aprs (double conversion which may cause a slight rounding
error). So, I'd like to change and use degrees and minutes everywhere.
This could be slightly odd if you've used the perl client and you are
used to the decimal format... Comments welcome.

73 de Per, sm0rwo




73 de Per, sm0rwo


fre 2009-03-13 klockan 17:32 +1100 skrev John Douyere:
> Per, Rein,
> 
> I have tried the Java client V0.21 on both WinXP SP3 and Linux
> (Mandriva Linux 2007 as per the older live CD).
> 
> They both work well. Certainly the new protocol is much more reliable.
> Today I did some tests with Steve (VK2ZSZ) at a distance of 225KM on
> 40M and the transfers over PSK125 was smooth despite a number of
> packet losses. There was of course no overlap as per the old protocol
> where I would see a lot of lost time with overlapping packet and
> re-synchronization between the server and client. So a great
> improvement really.
> 
> I didn't notice any bugs, so just a couple of comments:
> 
> 1. Since the client is always manned I really like the connect
> principle at the moment where the connects requests are generated
> manually instead of automatically at set intervals. The human ear
> and/or fldigi waterfall are much better instruments to decide if a
> connect request needs to be sent again or not. I am not sure how to
> reconcile that with the Mail/scanning option, maybe by sending only
> the first connect and letting the operator do the repeats if
> necessary.
> 
> 2. Although I haven't tried the gps input on this version, one comment
> on the old one if it's used as a starting point: regarding the display
> of the gps supplied information in headings and speed, is it possible
> to have an option for KM/h and Mile/H as well, and maybe change the
> heading display to the 8 or 16 directions (e.g E-NE for 22.5 deg
> heading) or a rotating compass? This is for the land restricted, great
> central desert thrill seeking Hams among us.
> 
> 3. In the mail details (for a server update) there is currently no
> password for position report via a findu email. Not sure if this is
> permanent or not. Personally I only do position reports in the unproto
> mode so it would not be a big issue for me if not implemented.
> 
> One question though: on this new client what is the usage and impact
> of the DCD number? Is that seconds delay after last character received
> before transmitting?
> 
> Server side: One issue that I noticed with my home server in the past
> and have reproduced on Steve's server today (with both the old client
> and the new one): when we use the THOR mode, the server will sometimes
> just ignore any block received by Fldigi although the block is formed
> properly. When this occurs, the server will then ignore any new block
> received in any mode and needs a restart. We never see that with the
> PSK modes. This could be due to the encapsulation of the pskmail block
> with the <stx> and <eot>: is the <stx> creating an issue with the
> beginning of the block or are the two side by side <eot> at teh end
> basically interpreted as an empty block? 
> 
> Although I am happy to do some debugging I am not sure where to look
> for in the server code: rflinkserver.pl or arq.pm?
> 
> Great job on the java client, please keep it up.
> 
> 73s, John (VK2ETA)
>  
> 
> On Fri, Mar 13, 2009 at 1:51 PM, Fred Reiselt <freiselt@xxxxxxxxxxxxx>
> wrote:
>         Here's some pretty good PSKmail DX through my server:
>         
>         Position of C56DL --- 25.7 miles southwest of THIES, SENEGAL
>         --- Report received 1 hours 58 minutes 22 seconds ago
>         Raw packet: C56DL>PSKAPR,TCPIP*,qAS,WB5CON:!
>         1426.23N/01700.98WY-Sunjet Gambia-
>         
>         Cool!
>         
>         Fred - WB5CON
>         
> 


Other related posts: