Loading ...
Sorry, an error occurred while loading the content.

Re: WSPR with Raspberry Pi

Expand Messages
  • bob_g3wkw
    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
    Message 1 of 14 , Jun 30, 2012
    • 0 Attachment
      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.

      Bob

      G3WKW

      --- In wsjtgroup@yahoogroups.com, Kristoff Bonne <kristoff@...> wrote:
      >
      > Hi All,
      >
      >
      > Three remarks:
      > 1/ One way you can deal with time-constrains on linux is to make code
      > based on kernel-generated interrupts. It's part of the real-time
      > extensions of linux.
      > I use this in my programs:
      > - attach a certain function to an interrupt
      > - tell the kernel to generate that interrupt
      > In an audio related piece of code, the function is simply "grab a piece
      > of pre-created audio from the buffer and send it of to ALSA" or "grab
      > audio from alsa, put it on a queue".
      > That way, no matter how busy your system is doing other things, the
      > audio code will always be executed in time.
      >
      > I don't know if python has functions for this, but what we can do is
      > split of the time-sensitive code (like audio) from the other functions
      > (decoding, graphs ...) into two seperate programs. Have the audio-code
      > just run and create audio-files every minute; then have a background
      > process in python grab these files and process them.
      >
      > The main disadvantage of this system is that -as it uses a linux RT
      > extension- it will only work on linux.
      >
      >
      > 2/ for transmitting, isn't that the same audio every time. Can't we just
      > precalculate that and drop it in a file?
      >
      >
      > 3/ Concerning files, I noticed wsjt also creates some files every minute.
      > Rememember that a lot of the ARM devices are based on flash-cards an
      > writing a lot of them can be an issue. Especially if you overwrite the
      > same file every time, this can result in wear on always the same sectors
      > on the disk.
      > I know there are now more advanced filesystems that can deal with this,
      > but perhaps it would not be a bad idea to all the user to specify a
      > directory where to store local files. That way, she can point it to
      > -say- a RAM-disk.
      >
      >
      >
      > 73
      > Kristoff - ON1ARF
      >
      >
      >
      >
      > On 29-06-12 22:55, bob_g3wkw wrote:
      > >
      > > I just had a very quick try to run with nogui. Lot's of error messages
      > > about not finding the audio devices even though the GUI wersion works
      > > and retains device settings. Currently I am finding the only way to
      > > work is with 50% ratio so that the decoder works while it is in Tx
      > > mode. It takes about 30 seconds to display the waterfall, and about 90
      > > seconds to decode callsigns. The time is then displayed 2 minutes
      > > late. Another issue is that the first transmission does not send a
      > > tone for about 90 seconds, the processor fully loaded. But it is fine
      > > after that so not a major problem but first reaction is that "it
      > > doesn't work".
      > >
      > > Bob
      > > G3WKW
      > >
      > > --- In wsjtgroup@yahoogroups.com <mailto:wsjtgroup%40yahoogroups.com>,
      > > Joe Taylor <joe@> wrote:
      > > >
      > > > Hi Kristoff and all,
      > > >
      > > > ON1ARF wrote:
      > > > > Perhaps, one thing that might help for WSPR would be to design a
      > > > > stripped down version without any GUI. This would reduce the
      > > overhead of
      > > > > that (also concerning memory foodprint). I think WSPR as an
      > > application
      > > > > that can turned into a GUI-less application, if it is combined with a
      > > > > web frontend.
      > > >
      > > > The original WSPR had no GUI. There's also a present version that has
      > > > no GUI. If you know what you're doing -- for example, I'm assuming you
      > > > can compile the program -- on a development system you can start the
      > > GUI
      > > > version with
      > > >
      > > > $ python wspr.py
      > > >
      > > > and the non-GUI version with
      > > >
      > > > $ python wspr_nogui.py
      > > >
      > > > > As far as I see, both wspr and wsjt are written in fortran. I
      > > don't know
      > > > > how well gfortran does code-optimimalisation.
      > > >
      > > > The gfortran compiler optimizes at least as well as gcc.
      > > >
      > > > -- Joe, K1JT
      > > >
      > >
      > >
      >
    • Kristoff Bonne
      Hi Bob, ... I did a bit of research on this this weekend. Concerning the Date_Time.wav file created ... well, .. strace is your friend. If you do this
      Message 2 of 14 , Jul 2 5:12 AM
      • 0 Attachment
        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.

        I did a bit of research on this this weekend.

        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:
        "-mcpu=arm1176jzf-s"
        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.


        Bob
        G3WKW

        73
        Kristoff - ON1ARF
      • bob_g3wkw
        Success! 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
        Message 3 of 14 , Jul 12 12:13 PM
        • 0 Attachment
          Success!
          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.

          http://homepage.ntlworld.com/re.thornton/G3WKW/files/WSPR_RasPi_Setup2.html

          Bob
          G3WKW
        Your message has been successfully submitted and would be delivered to recipients shortly.