Re: [wsjt-devel] WSPR crashes, error starting rx thread

2014-12-22 Thread Alan VK2ZIW
Hi Greg and all, WSPR stops. The error message Error starting rx thread comes from startrx.f90 line 34. I added an immediate 'try again'. We still get to the "stop" in startrx.f90. spawning new thread: Resource temporarily unavailable  Error starting 1st rx thread  11 spa

Re: [wsjt-devel] WSPR crashes, error starting rx thread

2014-12-21 Thread ki7mt
Hi Alan, Your package situation is not resolved, not by any stretch of the imagination, but if you want to consider it good that's your call. I would take Joe's advice ( given 2 maybe even 3 times now ), run WSPR0, see it if fails, cut the problem in half, or start isolating possibilities. You c

Re: [wsjt-devel] WSPR crashes, error starting rx thread

2014-12-21 Thread Alan VK2ZIW
Hi Greg and all, Can we please focus on the "crash " problem? WSPR runs perfectly fine for 10+ hours then crashes: spawning new thread: Resource temporarily unavailable Error starting rx thread     11 The "pillow" issue is resolved. Just do:

Re: [wsjt-devel] WSPR crashes, error starting rx thread

2014-12-20 Thread Joe Taylor
Hi Alan, VK2ZIW wrote: > ... > In the end, we all need a Low Power, Low Price way to run WSPR or WSJT. > That is repeatable and reliable. Several questions seem relevant to me: Who are "we all" (the many potential users) you are thinking of? What do they want to do, or would you like them to be

Re: [wsjt-devel] WSPR crashes, error starting rx thread

2014-12-20 Thread ki7mt
HI All, Apologies for not being very clear here. The packages you need, for the distribution you have (Debian based Wheezy) do no exist in the Debian WHeezy repositories for Python3. Python3 Imaging Library (python3-pil or python3-pillow): * Wheezy = No * Jessie and Sid = yes Python3 Imaging,

Re: [wsjt-devel] WSPR crashes, error starting rx thread

2014-12-20 Thread Alan VK2ZIW
Thanks Greg, On my home Banana Pi there is no 'funny business' all the build info is in a previous email. Just "apt-get " then "pip-3.2 install -I pillow==2.5.3" What you see is out of the Debian 'sources' deb http://ftp.de.debian.org/debian/ wheezy main non-free contrib deb-src http://ftp.de.d

Re: [wsjt-devel] WSPR crashes, error starting rx thread

2014-12-20 Thread ki7mt
Hi Alan, I kind of figured something was not right. Ok, well, that's goods news and bad. The good news, f2py3's path looks ok from what I can tell. F2PY3 is being picked up in the Makefile, unless you manually edited it, as is Python3. That's about all the good news. * Pip - your pip is for py2

Re: [wsjt-devel] WSPR crashes, error starting rx thread

2014-12-20 Thread Alan VK2ZIW
Hi Greg, You are on the wrong box. "club.bmarc.org" is a Banana Pi at the BMARC clubhouse. Bananian 3.0 loaded in late September 2014. cat /etc/debian_version => 7.4 My box, here at home is at "www.unixservice.com.au". To get to my Banana Pi, login as "wsjtdev", then you get redirected to 192.168

Re: [wsjt-devel] WSPR crashes, error starting rx thread

2014-12-19 Thread ki7mt
Hi Alan, I did a few more checks on your python3-numpy setup. That portion looks correct ( when using /usr/bin/f2py3.2 ). Specifying it's location with ./autogen .. .. .. should work: Additional Info: command: /usr/bin/f2py3.2 --help-link f2py_info: FOUND: sources = ['/usr/lib

Re: [wsjt-devel] WSPR crashes, error starting rx thread

2014-12-19 Thread ki7mt
Hi Alan, After a bit of poking around, I'm surprised you got as far as you did. >From the looks of things, I may be logged into the wrong box or something. Here is what I found thus far: * I could nto find a WSPR install directory /downloads/hamradio, they were all listed as wsjt. 4336 was the l

Re: [wsjt-devel] WSPR crashes, error starting rx thread

2014-12-19 Thread Alan VK2ZIW
Hi Joe and all, WSPR on ARM (Bananian 2013-12-02) crashed after 15 hours. Banana Pi Build notes: Wrote SD card, did: bananian-update bananian-config set root password etc.. Wanted GUI: apt-get install task-lxde-desktop Reboot, GUI came up. vi /etc/login.defs set UMASK 002 Add group tims, user

Re: [wsjt-devel] WSPR crashes, error starting rx thread

2014-12-19 Thread KI7MT
Hi Alan, I'm not sure where FD 21 puts f2py, but Wheezy add it's to: /usr/bin/f2py3.2 Armel: https://packages.debian.org/wheezy/armel/python3-numpy/filelist Armhf: https://packages.debian.org/wheezy/armhf/python3-numpy/filelist I added a couple ac_arg_with statements to configure.ac. I can't lo

Re: [wsjt-devel] WSPR crashes, error starting rx thread

2014-12-19 Thread Alan VK2ZIW
Hi Joe and all, Now running Bananian (wheezy) and apart from no "f2py3" which I copied from Fedora 21, "autogen.sh" didn't pickup the "no f2py3". WSPR SVN 4795 "top" PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 12854 alanb 20 0 264m 90m 8212 S 4.0 10.4

Re: [wsjt-devel] WSPR crashes, error starting rx thread

2014-12-18 Thread Joe Taylor
Alan -- For several years already the SVN repository has included two lightweight WSPR tools: wspr0.exe wspr_nogui.py If running on minimal hardware is a high-priority goal for you (or for your balloonists, or ???) have you considered either of these? These programs have not received mu

Re: [wsjt-devel] WSPR crashes, error starting rx thread

2014-12-18 Thread Alan VK2ZIW
Yes Joe, We'll let you know what we find. And yes, I'm using ARMv7 hardware, because size of equipment and power are VERY important. How many hams in India could afford to run a 100W PC 24x7 for WSPR? That's $300 per year here in Australia. Can yo

Re: [wsjt-devel] WSPR crashes, error starting rx thread

2014-12-17 Thread Joe Taylor
Hi Alan, On 12/17/2014 6:19 PM, Alan VK2ZIW wrote: > WSPR is not much use if it only runs 10 or 11 hours. Many people run production releases of WSPR for many weeks, or even longer, without problems. It appears that you're running an executable you compiled yourself, using various tools and pa

[wsjt-devel] WSPR crashes, error starting rx thread

2014-12-17 Thread Alan VK2ZIW
Hi all, WSPR is not much use if it only runs 10 or 11 hours. When I looked at "top" at 18:10 (see below) there was no sign of problems.  So, fiddling with compiler flags has made little or no difference. Has anybody seen this before? Alan VK2ZIW On Wed, 17 Dec 2014 17:23:53 +