[pskmail] Notes from the Zweibrücken meeting
- From: Pär Crusefalk <per@xxxxxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Thu, 25 Sep 2008 14:04:56 +0200
Hi,
I have not received any updates, apart from Thomas (thank you), on the
meeting notes from the participants so I figured I may as well post them
on the mailing list. I know there are lots of subjects discussed that
didn't make it into these notes but it was all I wrote down (note to
self and others: its good to elect a secretary at the beginning of the
meeting).
The attached odt file contains the notes. For those using pc's where you
are unable to read that format there is a badly formatted text version
here:
A few notes from the Zweibrücken meeting 20-Sep-08.
Present were:
Rein, PA0R
Roberto, IS0GRB
Pär, SM0RWO (”elected” secretary of the session)
Rolf, DL0IMA
Thomas, DJ4WL
Franz-Josef, DB3CF
Jörg, DL9YCS
Matters discussed:
Before taking notes (and being appointed secretary) Rolf and Thomas gave
a presentation about Intermar and their activities. They also described
the need for and use of a windows version of the client. A gui design
idea was presented and the aim of that was to create a client that would
run on windows and be custom made for sailing yachts. We had a rather
lenghty discussion about this windows client and neither yours truly or
Rein were very interested in taking on the job of forking and building a
client for windows only. Personally, your secretary here again, I would
rather see a platform independent client and I can have a look at that
(perhaps run by cygwin on windows). But, the gui design ideas that Rolf
and Thomas presented were very interesting and I can see why they would
want a windows version. We should definitely consider this and see what
can be done.
Beacon policy
There are now several servers with active beacons. If a client should
try to connect during the first five minutes of the hour then that
client will have a hard time, especially so on 30 mtrs (10.148) as there
are several servers transmitting beacons.
The meeting agreed that servers should only beacon once per frequency
and hour. There may be concerns for servers using several modes on the
same frequency, no decision was made on that.
Note from the secretary:
The beacon was added when there was just one server (sm0rwo) and one
client (pa0r). It was then a good way to let the client see that the
server was active and what exact frequency it was using. Now the traffic
intensity is much higher, with aprs beacons and message handling, with
more servers and clients so the need for the beacon is less obvious. The
total beacon amount should be in inverse proportion to the amount of
other traffic on the frequency.
QSY and common frequency on 30 meters
Rolf expressed that it would be good for a client to have a world wide
frequency for pskmail aprs. A sailing yacht crossing the atlantic was
mentioned, it would be good to have a common frequency so as not have to
hunt for servers on different frequencies there.
The meeting decided that we should move the current european common 30
meter frequency to 10.148 instead of 10.148,25 (center frequency). Also,
it was decided that the frequency should be used mainly for aprs/pskaprs
and connected sessions should be handled on other frequencies.
Connecting on the frequency should be fine however, the client should
then use the QSY command and move to the servers traffic channel. Or, if
the server is scanning, the client should connect when the server is on
the traffic channel.
Note on Dial frequency and center frequency
This is just a comment by your secretary, Pär. It was discussed wether
frequencies should be written as dial (vfo) or center frequencies. By
center frequency we mean the actual center frequency, that is dial fq
+/- the center audio fq being used. An example is 10.147 and USB
displayed on the rig, if we then use 1000 Hz as ”sweet spot”/center fq
then the actual transmission will take place on 10.148.
If we only write dial fq then two stations using different offsets
”sweet spot” will not be able to communicate. As pskmail limits the afc
search range and servers use narrow filters it is very important to know
where the actual traffic should be handled. That is why the wiki only
lists the center frequency for each server, they can then use whatever
sweet spot suits their equipment best (for instance I use 900 Hz and
receive in cw using bfo offset).
Development, client maintenance
Rein declared himself happy with the current status of the client. He
wanted to free himself of the maintenance workload and have time to
develop the next version of the on air protocol. He wanted someone to
step up and take over development, maintenance and support of the
client.
Pär Crusefalk, sm0rwo, voluntered to handle the client. (comment: I
don't know if we came to any decision here but I'm ready to handle this
(sm0rwo)).
FAQ and WIKI for the client needs to be updated, if you see questions
repeated over and over on the mailing list then they and their
respective answers should be added to the FAQ.
New modes, MFSK-64 and THOR-22
THOR22 is currently being tested on the 80 meter path between Australia
and New Zealand by John, VK2ETA. Patches has been submitted by John and
those have been worked in to the main development tree.
Of these perhaps Thor-22 is the most interesting, its supposedly
(secretary has not tested yet) about as fast as PSK-63 but very robust
and adapted to the QRN/M on 80 meters. MFSK-64 is 1 kHz wide and that in
itself is a problem.
New modem for pskmail
Franz Josef (DB3CF) has isolated the fldigi mdem and has a testable
version running with pskmail.
The idea is to fork the modem, make the modem as lean as possible and
integrate it into the pskmail client and server. The basic idea is to
migrate only the necessary controls into the GUI, and set most of them
via a modem config file in ~/.pskmail. This means that the modem can run
without X and can for instance be run as a daemon on a server. Franz has
implemented the current posix pskmail-fldigi interface but he has also
added an IP-based interface to this modem. Here a discussion started
about all the thing possible to do with a modem that does not need X and
can be connected using IP, that took a while (couldn't write it all
down). Franz demonstrated the modem and we all agreed that this is
looking like a very nice modem and that this is the way forward for the
project.
The status of the modem is now such that it can be used with the client
and the server but there are a few things left to do still.
Client projects
Integrating Sylpheed and pskmail client should be better documented, a
wiki page on that is needed.
Modem parameter window for Franz modem needs to be added (when fldigi
gui is removed).
Rig scheduler, move client to certain frequency at certain time and
duration (including mode).
List of servers should be updated in accordance to servers heard by the
client, this could be fetched from Robertos monitor as well.
Server projects
Roberto will add more agents to the server (for fetching stuff), how to
do that was discussed.
A streaming agent was discussed, that could be an agent with a buffer
that discards old data. The prime example is interfacing to a
dx-cluster, older data is not to be sent.
New protocol
Rein showed slides documenting the problems with the network
handling/traffic management using CSMA in todays system. He then showed
ways to improve the network using a DAMA-like network. This will reduce
the amount of collisions and also provide a way for the server to handle
multiple connects on the same frequency and at the same time (bandwidth
will be shared of course).
Rein is intending to start to implement this new protocol and that is
why he has expressed the wish to be relieved of the client management as
mentioned above.
Server forwarding
Roberto expressed the need for a server to be able to forward traffic
without the use of the internet. We discussed various solutions to this
and Rein mentioned a way to handle an incoming FBB telnet connect and
establish a forward path between two servers where the FBB protocol
would be used.
Developer resources
There were issues relating to developer resources and among these were
the repository. The entire, well almost anyway, history of the pskmail
source code is available through the subversion repository hosted by
Pär, that is available here:
http://www.crusefalk.se/pskmail/
Using a common repository is very beneficial when several programmers
are involved, through it we are able to look at when a certain feature
was implemented and by who. We can roll back to a certain version and so
on. Also, the repository handles simoultaneous work by several
programmers. The latest version is in the repository and we can submit
patches and work in the same file and at the same time. All can read
from the repository but you need a user and password to submit patches,
that can be requested from Pär.
Other related posts:
- » [pskmail] Notes from the Zweibrücken meeting
