[pskmail] Re: [pskmail] RE: [pskmail] Notes from the Zweibrücken meeting
- From: "John Douyere" <vk2eta@xxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Thu, 13 Nov 2008 22:08:20 +1100
Hi All,
Reviewing the notes, I noticed the comment about the new modes. MFSK64 was
tested here to allow another dimension to the modes available and that was a
higher data speed than psk250.
In practical terms, the wide bandwidth I agree is an issue as a) it goes
against the initial objectives of Pskmail of narrow bandwidth and b) it
prevents the used of a narrow filter that is useful for the performance of
the server. On the other hand I can use Thor22 with a 500Hz filter quite
successfully.
So in summary, since I am the one who made the original proposal for Thor22
and Mfsk64 to be integrated in the code, i would recommend that we remove
Mfsk64.
Comments welcomed.
I am happy to take the latest clients and servers codes and perform the
change if agreed.
73s, John (VK2ETA)
On Thu, Nov 13, 2008 at 9:06 PM, Sven <sven98de@xxxxxxxx> wrote:
> Hi all,
> DAMA could provide a solution to collisions, but I
> don't see how DAMA
> would work on HF, because to keep control, routes must
> be stable, and HF isn't.
>
> 73
> Sven
>
>
> --- Pär Crusefalk <per@xxxxxxxxxxxx> schrieb:
>
> > 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
> === message truncated ===
>
>
>
>
>
>
Other related posts:
- » [pskmail] Re: [pskmail] RE: [pskmail] Notes from the Zweibrücken meeting - John Douyere
