[pskmail] Re: xastir and jPSKmail-0.8.5, an unprecedented solution for HF aprs

  • From: "Rein Couperus" <rein@xxxxxxxxxxxx>
  • To: pskmail@xxxxxxxxxxxxx
  • Date: Wed, 29 Dec 2010 18:19:02 +0100 (CET)

Hi John,

I have been working on the client today, got the messaging 
mapclient->pskmail->server->xastir going.
The client is now sending an ack to the mapclient as soon as it sees a message,
so that the repeats are cancelled. Repeats have to be handled in the pskmail 
client,
as the timing between xastir and pskmail is completely different.
The client now sends 1 message to the nearest server, and those end up on 
the internet (I have another copy of xastir running here) and on findu.
I may implement a ;imited repeat queue at a later stage.

Next thing to tackle is the server, as the other way around 
(internet->pskmail->map client is 
not working at the moment. But I know what to do :)

More work is needed on the server, as the number of message/posit formats has 
increased exponentially.

To do this efficiently I will need a priority list, as to cover the complete 
functionality of xastir will take months.

What do you want xastir to do?
What should be implemented first?
(**These questions are for everybody**)

What is working so far:
* xastir displays HF beacons from servers and clients which it hears on HF
* xastir displays positions of stations via the ~GETNEAR command
* When the igate is running (at home) xastir displays positions coming through 
internet via PSKAPR
* The Igate sends positions it hears on HF to the internet
* Messages sent from xastir are sent on HF by the client and reach their 
destination either 
on HF via a server, or on the internet (xastir, UIview).

The route from internet through the server is a matter of changing the relevant 
APRS input filter, 
I will start on that tomorrow.


73,

Rein PA0R

BTW, xastir is quite picky abt the formats, so it needs lots of 
trial/error to find out... unless you want to study the source...


>Hi Rein,
>
>Thanks for your comments.
>
>One thing though. regarding the APRS messages that I can't get to work
>from either the client or Xastir.
>
>This is a new issue. I will do more test tomorrow and confirm.
>
>Regards,
>
>John
>
>
>On Wed, Dec 29, 2010 at 9:24 PM, Rein Couperus  wrote:
>> Comments below...
>>
>>>Hi Per and Rein,
>>>
>>>Great work. I tested this morning the latest client with TX capability
>>>from APRS and here are the results:
>>>
>>>1. The TX seems to be working fine. I noticed that the call sign of
>>>the APRS application is replaced by the call sign of the jPskmail
>>>preferences. Not a bug, but is that what we want? I haven't given much
>>>thoughts.
>>
>> This is what you want, transmit with the callsign of the pskmail client.
>>
>>>
>>>2. Messages and position beacons are transmitted fine by the client
>>>and trigger a QSL response from the server (latest version in Alpha
>>>directory from Rein)
>>>
>>>3. For some reason all APRS messages typed either in xastir or
>>>directly in the client don't get sent by the server to the APRS
>>>network but get acknowledged with a "QSL...".
>>>
>>
>> This is a format issue.... needs (lots of) work to be done on the server...
>>
>>>4. Different story for the xastir position beacons: if I leave the
>>>default for the station as "fixed station", I don't get position
>>>reports sent by the server to the APRS-IS network, but if I use
>>>"mobile station with local time" in the Xastir defaults then I get the
>>>position transmitted by the server but not the comments appended after
>>>the position.
>>>
>>
>> Also here, the server needs work... the pskmail server is a great filter...
>> Until now, only the client issue has been tackled.
>>
>>>I noticed that in the position block, the character before the
>>>position is an "!" (apostrophe) when the position is sent directly
>>>from the java client, but when sent from Xastir is an "=" or "@" from
>>>xastir depending on the type of station I select. This could be the
>>>issue. So I suspect the client side is ok, but the sever side does not
>>>recognise the data.
>>>
>>
>> See above...
>>
>>>5. The ~GETNEAR data now flows nicely even for these OZI stations down
>>>under! Thanks :)
>>>
>>>6. I have started testing the email download resume. I still get these
>>>extra carriage return when I stop and resume (under Windows for the
>>>moment, I will test the same files under Linux tomorrow).
>>>
>> I have only been able to test this with Linux... I put loads of time
>> into testing this.
>>
>>
>>>7. I realised that with the resume function in the server, there is no
>>>way of cancelling such an interrupted download.
>>>
>>>In the non-DTN system, I would simply abort and reconnect to stop a
>>>larger than expected or wrong download, but now I have no choice but
>>>to let it get through otherwise I can't download anything else.
>>>
>>>Should we ask the operator if he/she want the previously interrupted
>>>downloads when the server sends an FO block just after connect?
>>>
>>
>> That is the idea behind the ~FY and ~FN operands, to give the client a
>> choice based on certain criteria (which have not yet been defined).
>> Has not been implemented yet, unfortunately
>> a day has only 24 hours...
>>
>> 73,
>>
>> Rein PA0R
>>
>>>All the best,
>>>
>>>73's, John
>>>
>>>On Wed, Dec 29, 2010 at 4:49 AM, Pär Crusefalk  wrote:
>>>> Hi John,
>>>>
>>>> I just committed an updated socket interface that added the TX side from
>>>> the external aprs mapper. I tested using xastir and tried all the
>>>> general queries and positions etc. Its a transparent socket now so
>>>> whatever the mapper can push out there will be sent. Perhaps we should
>>>> add a setting that controls if the external mapper should be allowed to
>>>> transmit?
>>>>
>>>> 73 de Per, sm0rwo
>>>>
>>>
>>
>>
>

Other related posts:

  1. Home
  2. pskmail
  3. Archive
  4. 12-2010