[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 21:51:14 +1000
Rein,
I did that. Thanks. It got me to a band-aid solution: in rflinkclient.pl I
increased the sleep instruction at line 202 from 4 to 14.
I get good connections with Thor22, but not with DominoEx22 for some reason
as the control characters (<SOH>, <SOT>) seem to be removed when I use FEC,
and when I don't, it misses the beginning of the packets as it used to in my
earlier tests. So in my tests Thor22 produces much cleaner exchanges.
Only issue with this quick fix of course is that all modes are slowed down
at connect time. Tomorrow I will dig further to find where I can set a
variable timeout for the connect phase.
73s, John
On Mon, Sep 15, 2008 at 7:27 PM, Rein Couperus <rein@xxxxxxxxxxxx> wrote:
> What I do for debugging is:
> * do a 'touch debug' in ~/.pskmail to switch STDOUT back on ( you can
> ignore the GTK warnings...)
> * insert `echo "$var" >> debug.txt` statements into the code and do a 'tail
> -f debug.txt'
>
> Rein
>
> > -----Ursprüngliche Nachricht-----
> > Von: "John Douyere" <vk2eta@xxxxxxxxx>
> > Gesendet: 15.09.08 11:18:51
> > An: pskmail@xxxxxxxxxxxxx
> > Betreff: [pskmail] Re: Puppy Linux V4 / Pskmail V1.0 on Asus eee laptop
>
>
> >
> > 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
> >
> >
> >
> >
>
> --
> http://pa0r.blogspirit.com
>
>
Other related posts:
