Re: [wsjtgroup] Re: WSPR with Raspberry Pi
- Hi Bob,
On 01-07-12 00:33, bob_g3wkw wrote:
Purely from observing the processor load on transmission I would say the audio is already "compiled" once and stored as with my Pi there is no audio output for about 90 seconds on the FIRST transmission. As you can imagine at first there was much wiggling of connectors and checking of mixers as it apparently "doesn't work" but thereafter transmission is a very low load and no delays, hence my 50% ratio to allow the decoding process to complete. I was a bit surprised that it appears to settle at a 1:1 Tx/Rx with no apparent randomisation.
Your point 3) is I believe the problem area. The pi hardware http://elinux.org/RPi_Hardware is 256 megabytes of RAM and a 700MHz ARM11 processor. As you say the "Hard Drive" is an SD card and to add inasult to injury this is also being used as a Swap File (Virtual Memory). It is quite possible that a laptop hard drive might provide a faster swap file, certainly it would prolong the life of the SD card. That is on my list to try, being on the same hub as the audio might be an issue. But I have been looking through the code hoping to see where the 2 minute delay occurs and what I cannot see is the Date_Time.wav file that should be created for each 2 minute receive period. I figured that should be visible but have found no trace of it and am wondering if that is being created in ram disk somehow. There is clearly some conflict preventing 2 sequential reception periods on the pi and use of ram disk and lack of ram space would explain that.
But really this is just an exercise to see what it can do and I am pleased that it can do what it does. The 2 minute error can be patched quite easily, but it would be nice to identify the root cause because I am sure it has been seen before, I noticed spots of my signal being late once at least.
Concerning the "Date_Time.wav" file created ... well, .. "strace" is your friend.
If you do this "PATH=$PATH:. LD_LIBRARY_PATH=./ strace -f python -O wspr_nogui.py 2>straceout.txt", you will get a text-file containing all system-calls issued by wspr or its child-processes.
Based on that, it turns out that no wav-files are generated; so it must be that it actually kept in memory. (or, at least, that how it runs on my machine; perhaps there are options that can influence this behaviour).
There are a number of files that are modified every 2 minutes or on certain events:
[pid 22266] open("/home/kristoff/wspr/wspr/decoded.txt", O_RDWR|O_CREAT|O_LARGEFILE, 0666) = 4
[pid 22266] open("/home/kristoff/wspr/wspr/wspr.log", O_RDWR|O_CREAT|O_LARGEFILE, 0666) = 7
[pid 22260] open("/home/kristoff/wspr/wspr/audio_caps", O_RDWR|O_CREAT|O_LARGEFILE, 0666) = 8
[pid 22269] open("/home/kristoff/wspr/wspr/pixmap.dat", O_RDWR|O_CREAT|O_LARGEFILE, 0666) = 8
[pid 22270] open("/home/kristoff/wspr/wspr/ALL_WSPR.TXT", O_RDWR|O_CREAT|O_LARGEFILE, 0666) = 8
I think at least some of them could be moved to a ram-disk to reduce wear on the flash cards.
Now, I did take a look at the Makefile that is created by .configure on my pandaboard.
There seams to be two elements that are important:
FFLAGS = -g -O2 -fno-range-check -ffixed-line-length-none -Wall -Wno-character-truncation -Wno-conversion -Wtabs -fPIC
CFLAGS = -Wall -O0 -g -Wall -O0 -g
The flags for gcc and gfortran.
Now, for some reason, code optimisation for the C-compile has been disabled. I don't know why this is. But, in essence, this is probably not very critical -as far as I see- no DSP related code.
Now, what I propose it that you add this to two lines:
This tells the compiler to create code for the ARM1176JZF-S CPU.
ARM CPUs can have very different kinds of architecture, and -perhaps- this will give the cross-compiler more change to generate code especially for the architecture of the CPU in the pi.
Again, I don't know if this will help; but I get it will not hurt to try.
If you say that decoding the WSPR file takes more then 2 minutes on the Ras Pi (vs. less then 5 seconds on my pandaboard), I propose we focus on this. I have not yet worked in python or fortran, but I will try to isolate that particular piece of code and wrap some debugging code around it.
If we can find out why that particular piece of code is so slow, we can perhaps use that to fix the rest.
Kristoff - ON1ARF
Well here is a bit of an update on the Raspberry Pi and WSPR. The minor defect has been sorted correcting the timestamp for uploads. But the basic lack of processing power turned out to be down to the choice of linux implementation. I had used a Debian Wheezy build based on armel which does not use the Floating Point processor which is available on the board, instead emulating it in software. I rebuilt based on an armhf (hf standing for Hard Float) version of Wheezy and all is well. I doubt that I could have started from here in the first place as this build was VERY light and I had to apt-get things I would not have heard of had I not used the first more generous build, although it was too slow. Well Raspberry Pi is intended to be educational. Here is my latest updated diary and installation guide.