[pskmail] Re: Good Conditions

  • From: Bernard Dekok <kc9sgv@xxxxxxxxx>
  • To: pskmail@xxxxxxxxxxxxx
  • Date: Wed, 11 Jan 2012 07:11:51 -0600

Thanks John,

All good points.

I was thinking about this a bit and I will try the following as a PSKmail
manual technique:

For my current setup with PSKmail 1.5 software and an older rig using
manual tuning to .1 KC -
I will set my FlDigi search range to 30 Hz.
I will use your mode table as suggested.
I will then first send a ping on one of the Thor modes.
When the beacon comes back, I will then manually tune dead center onto it
by looking at the waterfall.
After that I will hit the connect button (assuming of course that my
tranmitter transmits dead set on the receiver frequency. No RIT issues
etc.)

Or maybe I should start with MFSK32 or MFSK16.
I will see and report what seems to work better.

Hopefully this technique will give older rigs a new life as a PSKmail
client or even a future fixed frequency PSKmail server....

73,
Bernard
KC9SGV

On Tue, Jan 10, 2012 at 10:34 PM, John Douyere <vk2eta@xxxxxxxxx> wrote:

> Bernard,
>
> Interesting point about the search range.
>
> In version 2 where the modem is integrated in the application we will
> be able to apply better logic to the frequency alignments since the
> RSIDs exchanged allow a very precise re-aligment of the TX and RX
> frequency independent of transceivers and sound cards frequency errors
> (and the combination thereof).
>
> In the mean time, the modes that allow for the best auto-alignment are
> the THOR modes with a minimum of 100Hz either side without an issue.
>
> Then the fast PSK modes (PSK250/250R and 500/500R) but not so much
> PSK125/125R and very little for PSK63.
>
> MFSK32 is average (from memory about 36Hz each side) but not MFSK16
> (18Hz each side only).
>
> So if you are concerned about frequency mis-alignments I would choose
> the following mode list: PSK250, PSK250R, MFSK32, THOR22, THOR11, or
> worst case scenario, drop MFSK32 from that list.
>
> Increasing the search range of the PSK modes in the Fldigi preferences
> is a double edge sword with the current AFC logic. It can do more harm
> than good by "jumping around" and in my experience is better left at
> 30 to 40Hz max.
>
> Hope this helps,
>
> 73, John
>
> On Wed, Jan 11, 2012 at 4:10 AM, Bernard Dekok <kc9sgv@xxxxxxxxx> wrote:
> > Thanks Rein, Robert and Roger,
> >
> > I think my search range was set too low.
> > I use a Signalink USB and an old Icom 735 which works fine for Winmor
> with a
> > 100 Hz search parameter.
> > Maybe I should set my PSKMail search range up to 100 hz as well.
> > The old IC 735 is only tunable to .1 KC
> > Furthermore, I set the Signalink USB TX and RX audio control pots to the
> > Winmor values, with the Delay (DLY) pot to almost minimum, anti
> clockwise.
> >
> > I will test some more when I am off from work this weekend.
> > Please keep up the good work.
> >
> > 73,
> > Bernard
> > KC9SGV
> >
> >
> > On Tue, Jan 10, 2012 at 10:44 AM, G6CKR <radio@xxxxxxxxxxxxxxx> wrote:
> >>
> >> Sound card calibration and frequency accuracy is more important on some
> >> modes both of which may explain the lack of connect at the slower modes.
> >> 73 Roger G6CKR
> >> On 10/01/12 15:49, Rein Couperus wrote:
> >> > What we see a lot is multipath during mid-day, giving rithmic, deep
> QSB
> >> > up to 80 dB down.
> >> > The server will downgrade the link until it reaches the lowest
> requested
> >> > mode,
> >> > and also reduces the block length.
> >> > If that does not work the server sends 2 disconnects and stops the
> >> > session...
> >> > The number of polls is configurable on the server, we use a number of
> 10
> >> > to
> >> > let the session survive a pactor or ALE QRM session starting on top
> of a
> >> > running connection.
> >> >
> >> > The client can decide which modes to use for the session. We added the
> >> > MFSK and THOR
> >> > modes for multipath and NVIS conditions.
> >> > It pays to use different mode tables for different conditions.
> >> > Slow modes are not always the right answer, I use MFSK16 as the
> slowest
> >> > mode,
> >> > and I often use THOR22 to connect....
> >> >
> >> > The 14 MHz frequency is pretty stable during the time 10 MHz cannot be
> >> > used...
> >> > That is why we introduced scanning in 2006...
> >> > Don't forget to pick the right time and the right frequency, we did
> not
> >> > yet implement
> >> > the cognitive radio stuff....
> >> >
> >> > I use 5 Watts to connect SM0RWO on 10 MHz, and it works most of the
> >> > time.
> >> >
> >> > Rein PA0R
> >> >
> >> >
> >> >
> >> >
> >> >     Hi Robert,
> >> >
> >> >     What you describe on the PSKMail connection, is what I have
> >> >     expierenced many times with your server and also with the AB9FT
> >> > server.
> >> >
> >> >     I have on many occasions seen a gradual deterioration of the link.
> >> >     It goes asymmetric with the server still in a faster mode, and my
> >> >     client stuck in one of the lower speed modes, to the point that
> >> >     everything just freezes up there.
> >> >     Seems like this is part of the problem with PSKMail.
> >> >     There seems to be no automatic disconnect signal like with Winmor,
> >> >     when conditions deteriorate to the point of oblivion. (I think
> >> >     Winmor sends a double disconnect signal and an  ID.)
> >> >     So the connection on PSKMail just deteriorates, then hangs there
> in
> >> >     silence, waiting for who knows what.
> >> >     I think this could also be partly due to the peculiarity of the
> 30 M
> >> >     band.
> >> >     It behave much differently from say the 20M and 40M bands,
> >> >     I can say this from observation and experience as an HF band Ham
> for
> >> >     the past 30 years.
> >> >     The 30 band will presently suddenly cut off completely, then come
> on
> >> >     again 30 minutes later.
> >> >     In the US at least, the 20M and 40 M bands are very predictable
> most
> >> >     of the time, with good propagation during all of the morning, and
> >> >     then again later in the afternoon and
> >> >     evening.
> >> >
> >> >     Just my observation with some good time on playing with PSKMail
> 1.5
> >> >     and the KB2PNM
> >> >     and AB9FT servers from Chicago. (I have not had any response from
> >> >     the other servers after multiple pinging during the past few
> days.)
> >> >
> >> >     73,
> >> >     Bernard
> >> >     KC9SGV / ZS4BDK
> >> >     Chicago
> >> >
> >> >
> >> >
> >> >     On Tue, Jan 10, 2012 at 6:11 AM, Robert Krasowski
> >> >     <rkrasowski@xxxxxxxxx <mailto:rkrasowski@xxxxxxxxx>> wrote:
> >> >
> >> >         We had some problems yesterday with PSKmail, first we talk on
> >> >         SSB for 45 min, conditions were great. But later when we
> switch
> >> >         into PSKmail I was able to hear them great, but for some
> reason
> >> >         Client didi not responded into server response. I could't do
> >> >         anything about it since they did not hear me. But during the
> >> >         night they were able to exchange some emails so must
> recognized
> >> >         and fix the problem. Will know today what was the issue.
> >> >         Darrel, they are in the middle of Atlantic, not in Poland , so
> >> >         not that far but still quite good.
> >> >         Best regards toi all
> >> >         Robert
> >> >         KB2PNM
> >> >
> >> >         --- On *Mon, 1/9/12, John Douyere /<vk2eta@xxxxxxxxx
> >> >         <mailto:vk2eta@xxxxxxxxx>>/* wrote:
> >> >
> >> >
> >> >             From: John Douyere <vk2eta@xxxxxxxxx
> >> > <mailto:vk2eta@xxxxxxxxx>>
> >> >             Subject: [pskmail] Re: Good Conditions
> >> >             To: pskmail@xxxxxxxxxxxxx <mailto:pskmail@xxxxxxxxxxxxx>
> >> >             Date: Monday, January 9, 2012, 10:34 PM
> >> >
> >> >
> >> >             Hi Darrel,
> >> >
> >> >             Yes, nice log.
> >> >
> >> >             I noticed the failed attempts at connections to Robert's
> >> >             server (KB2PNM).
> >> >
> >> >             Robert,
> >> >
> >> >             It looks like the client does not hear the server's
> connect
> >> >             acknowledgement (since the connect is received and acted
> >> >             upon AND the
> >> >             client's status reply required to confirm the connection
> is
> >> >             much more
> >> >             likely to success than a long connect frame).
> >> >
> >> >             I would recommend SQ2OAZ tries to connect with something
> >> >             like THOR22
> >> >             or MFSK16, and let the server adjust the speed up if
> >> > possible.
> >> >
> >> >             But of course how to let him know if he does not connect
> to
> >> >             his email
> >> >             (APRS messages maybe?).
> >> >
> >> >             Regards,
> >> >
> >> >             John
> >> >
> >> >
> >> >             On Tue, Jan 10, 2012 at 1:13 PM,  <ve7cus@xxxxxxx
> >> >             <http://mc/compose?to=ve7cus@xxxxxxx>> wrote:
> >> >             > I had an interesting capture on my station on the west
> >> >             coast of N.A. this afternoon.
> >> >             >
> >> >             > Darrel, VE7CUS
> >> >             >
> >> >             > 16:01:21 <SOH>00uSQ2OAZ:6 (93u8'c  Y 83C1<EOT>
> >> >             > 16:02:54 <SOH>1!kKB2PNM:24 SQ2OAZ:1024 57CAF<SOH>
> >> >             > 16:02:54 SQ2OAZ<>KB2PNM: <SOH>7!s   16BB<EOT>
> >> >             > 16:03:17 SQ2OAZ<>KB2PNM: <SOH>1!kKB2PNM:24 SQ2OAZ:1024
> >> >             57CAF<SOH>
> >> >             > 16:03:19 SQ2OAZ<>KB2PNM: <SOH>7!s   16BB<EOT>
> >> >             > 16:07:01 <SOH>1"kKB2PNM:24 SQ2OAZ:1024 53750<SOH>
> >> >             > 16:07:04 SQ2OAZ<>KB2PNM: <SOH>7"s   16FF<EOT>
> >> >             > 16:16:14 <SOH>1$kKB2PNM:24 SQ2OAZ:1024 5A0AE<SOH>
> >> >             > 16:16:15 SQ2OAZ<>KB2PNM: <SOH>7$s   1677<EOT>
> >> >             > 16:17:24 SQ2OAZ<>KB2PNM: <SOH>1$kKB2PNM:24 SQ2OAZ:1024
> >> >             5A0AE<SOH>
> >> >             > 16:17:25 SQ2OAZ<>KB2PNM: <SOH>7$s   1677<EOT>
> >> >             > 16:18:29 <SOH>00uAB9FT:71 73 4E93<EOT>
> >> >             > From AB9FT: 73%
> >> >             > 16:19:08 <SOH>00uSQ2OAZ:7 B685<EOT>
> >> >             > =4904.13N/12305.39WMXASTIR-Linux
> >> >             > 16:20:10 <SOH>00uSQ2OAZ:7 B685<EOT>
> >> >             > 16:23:19 <SOH>1%kKB2PNM:24 SQ2OAZ:1024 559FA<SOH>
> >> >             > 16:23:20 SQ2OAZ<>KB2PNM: <SOH>7%s   D64A<EOT>
> >> >             > 16:23:39 SQ2OAZ<>KB2PNM: <SOH>1%kKB2PNM:24 SQ2OAZ:1024
> >> >             559FA<SOH>
> >> >             > 16:23:40 SQ2OAZ<>KB2PNM: <SOH>7%s   D64A<EOT>
> >> >             > 16:26:07 <SOH>00uSQ2OAZ:6 I7@=9Xm4'Y D0E8<EOT>
> >> >             > 16:32:12 <SOH>10cSQ2OAZ:1024 KB2PNM:24 885b4321AA0F<EOT>
> >> >             > 16:33:06 SQ2OAZ<>KB2PNM: <SOH>1!kKB2PNM:24 SQ2OAZ:1024
> >> >             57CAF<SOH>
> >> >             > 16:33:06 SQ2OAZ<>KB2PNM: <SOH>7!s   16BB<EOT>
> >> >             > 16:33:31 SQ2OAZ<>KB2PNM: <SOH>1!kKB2PNM:24 SQ2OAZ:1024
> >> >             57CAF<SOH>
> >> >             > 16:33:32 SQ2OAZ<>KB2PNM: <SOH>7!s   16BB<EOT>
> >> >             > 16:33:51 SQ2OAZ<>KB2PNM: <SOH>1!kKB2PNM:24 SQ2OAZ:1024
> >> >             57CAF<SOH>
> >> >             > 16:33:52 SQ2OAZ<>KB2PNM: <SOH>7!s   16BB<EOT>
> >> >             > 16:38:01 <SOH>00uSQ2OAZ:7 B685<EOT>
> >> >             > 16:38:08 <SOH>00uAB9FT:71 77 8E91<EOT>
> >> >             > From AB9FT: 77%
> >> >             > 16:38:33 <SOH>00uSQ2OAZ:7 B685<EOT>
> >> >             > 16:39:22 <SOH>10cSQ2OAZ:1024 KB2PNM:24 885b4321AA0F<EOT>
> >> >             > 16:40:47 SQ2OAZ<>KB2PNM: <SOH>7"s   16FF<EOT>
> >> >             > 16:41:33 SQ2OAZ<>KB2PNM: <SOH>1"kKB2PNM:24 SQ2OAZ:1024
> >> >             53750<SOH>
> >> >             > 16:41:33 SQ2OAZ<>KB2PNM: <SOH>7"s   16FF<EOT>
> >> >             > 16:42:18 SQ2OAZ<>KB2PNM: <SOH>1"kKB2PNM:24 SQ2OAZ:1024
> >> >             53750<SOH>
> >> >             > 16:42:19 SQ2OAZ<>KB2PNM: <SOH>7"s   16FF<EOT>
> >> >             > 16:46:01 <SOH>00uSQ2OAZ:6 I7>69Z4.(Y 35AA<EOT>
> >> >             >
> >> >             >
> >> >
> >> >
> >> >
> >>
> >>
> >
>
>

Other related posts: