[pskmail] Re: vhf/uhf relays

  • From: Rein Couperus PA0R <rein@xxxxxxxxxxxx>
  • To: pskmail@xxxxxxxxxxxxx
  • Date: Wed, 30 Jun 2010 10:12:49 +0200

One more issue to take into account is that the software strucure of 
client and server has been optimized for these 'narrow bandwidt/low-speed' 

My feeling is that the modem interface in the client software is at its upper 
limit for speed.
Faster modems will not increase the speed any more.

If you are thinking about 9600 Bd, it may be better to think about forking a 
special pskmail application for high speed / wide band width.
Also, we would need a different modem, as fldigi does not include higher spee 
That would also imply changing the timing scheme in the server.
I dislike mixing the narrow/wide band (we have seen the pactor3 catastrophe...).

The addition of a special mode table for high speed is fairly trivial otherwise 
(we already 
have two separate tables...)


Rein PA0R

BTW, the VHF/UHF relays thing is just a list of EU relay frequencies based on 
your actual APRS position...


On Wed, 30 Jun 2010 17:00:12 +1000
John Douyere <vk2eta@xxxxxxxxx> wrote:

> Hi Brett,
> Please refer to my comments in your email below.
> Best 73s, John
> On Wed, Jun 30, 2010 at 3:27 PM,  <pskmail@xxxxxxxxx> wrote:
> > On 30/Jun/2010 00:32 Steven Heimann <steven@xxxxxxxxxxx> wrote ..
> >> Hi John
> >>
> >> It would be nice if the modes used by PSKMail were configurable rather
> >> than being hard coded in.  In cases like this where FM will be used the
> >> server could limit the modes to ones useful for FM.  Also, as the
> >> channel bandwidth is fixed modes wider the 500Hz could be selected which
> >> could increase speed.
> >>
> >> Just a thought.
> I think there are two parts to your question:
> A. As mentioned in my email to Steven, I struggle with the benefits on
> HF, but again I may be missing something.
> B. For FM applications there would be a case for a separate list of
> modes, which again could be hard coded if we take the simple coding
> route.
> Alternatively, as you mentioned, we could limit the current list to
> the appropriate modes for that application, but in reality the system
> should be quite capable of adjusting itself as it continuously
> measured the signal quality both ways and makes decisions to change
> modes based on this.
> I haven't performed new tests using FM since we developed the
> adaptative mode feature, so if you were to do some tests we would be
> glad to hear back from you. With particular interest in the way the
> mode adaptation works in that case.
> >>
> >> Regards
> >> Steven
> >
> > Greeting-
> >
> > Is there no way to tell the server to use a wider bandwidth & higher speed 
> > mode?
> As mentioned above and in previous email the issue I have is that
> there are no higher speed mode available at present in Fldigi that we
> don't already use.
> For information, we tried PSK1000 but the results were not conclusive.
> > I would think one could get an easy 9600 baud in a standard FM channel.
> This would be an issue of mode available in Fldigi rather than Pskmail per 
> say.
> The issue that become apparent quickly when pushing the speed envelop
> towards the theoretical limit is that while if is possible to have a
> lab version of a protocol working at higher throughput that what we
> have now, the issue is when you get in the field, the hardware
> variations (PC sound card, radio, interfaces) is so large that it is
> easy to end up with a system that is not reliable and therefore does
> not get used or distracts from the objective.
> For example getting 9600 bauds on an FM channel required very good TX
> deviation accuracy and from what I have read is not a plug and play
> exercise.
> The other example was the PSK1000 test we did.
> In the current mode list we use you can have uncalibrated sound cards
> (off by thousands of PPMs) with non linear interfaces and far from
> linear rigs (in terms of frequency response) and still get through.
> So like life, this is full of compromises. But again we are open to new ideas.
> >
> > 73
> >
> > -Brett
> > wa3yre
> >
> >

Rein Couperus PA0R <rein@xxxxxxxxxxxx>

Other related posts: