[pskmail] Re: Puppy Linux V4 / Pskmail V1.0 on Asus eee laptop
- From: "John Douyere" <vk2eta@xxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Mon, 15 Sep 2008 19:18:32 +1000
Rein,
It's us who have to thank you for the work on this program.
I have been through he arq.pm program and have seen the timeouts set
according to the mode, including the ones for others i.e. non psk63,125 or
250. I need to find a way of tracing the code as I can't recognise the
timeouts values. I tried to increase these values by a factor of 3 to make
sure I would recognise them, but it didn't affect the issue I mentioned
before.
Is there a way of stepping through the code or putting watchpoints (like the
good old C debuggers I used to use..hihi)? Alternatively I will put a few
print statements to stdout and launch it from the console.
73s, John
On 9/15/08, Rein Couperus <rein@xxxxxxxxxxxx> wrote:
>
> Tnx for the valuable info John...
>
> looks like we have to experiment with Thor next summer season (very little
> static here at the moment,
> 5 Watts is enough to work at least 2 of the servers...)
> As soon as I have time I will have a look at the timing for slower modes.
> There is a separate set
> of parameters for PSK63 and PSK125. Parameters for DOMINOEX have to be
> changed. We could start
> with taking the ones for PSK63 as a reference. Look in arq.pm and grep for
> PSK63 :)
>
> 73,
>
> Rein PA0R
>
> > -----Ursprüngliche Nachricht-----
> > Von: "John Douyere" <vk2eta@xxxxxxxxx>
> > Gesendet: 15.09.08 08:34:48
> > An: pskmail@xxxxxxxxxxxxx
> > Betreff: [pskmail] Puppy Linux V4 / Pskmail V1.0 on Asus eee laptop
>
>
> >
> > I have upgraded my eee 701 to the latest version of Pskmail live CD.
> > First let me say that the program is evolving quite well with some
> > very interesting features (E.g Telnet and nearby APRS stations).
> >
> > The upgrade was easy with the copy of the new file to the memory
> > card that I boot from. I had to delete of course the save sessions
> > from the old version 301. Not sure if I had to do this or not, but I
> > did it just in case. So that I started from a fresh new system.
> >
> > Two issues I discovered:
> >
> > 1. The internal sound card would work on capture (Rx) but not
> > playback (Tx). Run alsaconf a few times but no difference. Then I
> > remembered I had to change a line in /etc/modprobe.conf when I
> > installed puppy v301 and applied the same change. This fixed the
> > issue.
> > See the following link if you have the same issue: http://www.murga-
> > linux.com/puppy/viewtopic.php?t=24608
> >
> >
> > 2. With both the internal sound card and a usb sound card (Signalink
> > USB), I had deep and rapid fade in the sound every 2.5 second or so
> > at a very regular intervals when transmitting. I first tried a few
> > sample rates for the sound card, no impact. I checked the CPU usage:
> > 40 to 60% idle, so should not be the issue. I then realised that when
> > the Pskmail client didn't run, the sound output from Fldigi would be
> > fine.
> >
> > Finally isolated the issue to be with gpsd. I commented out the line
> > that launches gpsd when starting Pskmail and the sound was fine.
> > Maybe because it was trying to access /dev/ttyUSB0 and I don't have a
> > gps on that port (mine is via bluetooth). I will check later on what
> > happens when I try to make it connect to the right port.
> >
> > Hope this helps.
> >
> > One issue that is still remaining: when I connect using a slower mode
> > like DominoEx22, the server and client keep talking over each other.
> > This results in the client not waiting long enough before sending a
> > new connect request which every time doubles up with the server's
> > acknowledgment.
> >
> > The FEC option in the new Fldigi 3.02 makes this mode (or it's "
> > cousin" Thor22) very interesting for the summer months in the low
> > bands here. I had some very reliable QSOs with ZL1ANY (about 3000KMs)
> > using Thor22, including a successful Flarq file transfer which
> > indicates that it is well suited for these ARQ modes. Its effective
> > speed is equivalent to psk63, but is much more resilient to static
> > crashes and QRM.
> >
> > One think I noticed when using these modes instead of psk: the Fldigi
> > squelch bar only raises to about 1/3 of the way at best in my system,
> > so the threshold needs to be adjusted down. Otherwise it misses the
> > start or all of the text. On the positive side, I noted that the FEC
> > option also gives time to the decoder to synchronize properly and
> > makes it much more reliable than the previous non-FEC DominoEx mode
> > for that application. I will continue testing when I have sorted the
> > timing issue in Pskmail, but it looks very promising for marginal or
> > noisy (crashes) conditions in light of the tests we did with Flarq.
> >
> > John (VK2ETA)
> >
> >
>
> --
> http://pa0r.blogspirit.com
>
>
Other related posts:
