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

WSPR with Raspberry Pi

Expand Messages
  • bob_g3wkw
    I have managed to send and receive, and upload spots using a Raspberry Pi with Debian Wheezy. Interested to hear from anyone else trying to use a RasPi with
    Message 1 of 14 , Jun 27, 2012
    • 0 Attachment
      I have managed to send and receive, and upload spots using a Raspberry Pi with Debian Wheezy. Interested to hear from anyone else trying to use a RasPi with WSJT modes as there are a good few issues which need tweaking. Decoding speed, reported spot time error are the main issue. I kept a log of issues tonight and added a couple of screen shots linked here if interested :
      http://homepage.ntlworld.com/re.thornton/G3WKW/files/WSPRTest20120627.pdf

      Joe already gave me some hints to get this far and I will make some changes and try again tomorrow. It will be nice to run 3.5 watts computing power instead of 500 during the summer if it ever arrives this year!


      Bob

      G3WKW
    • Randy Hall
      Outstanding. Keep us posted. I have a Pi sitting here. I haven t fired it up yet. Hope to see if someone can get FL DIGI running on it. Randy K7AGE
      Message 2 of 14 , Jun 28, 2012
      • 0 Attachment
        Outstanding.

        Keep us posted. I have a Pi sitting here. I haven't fired it up yet. Hope to see if someone can get FL DIGI running on it.

        Randy
        K7AGE

        On Wed, Jun 27, 2012 at 5:28 PM, bob_g3wkw <bob.thornton@...> wrote:
         

        I have managed to send and receive, and upload spots using a Raspberry Pi with Debian Wheezy. Interested to hear from anyone else trying to use a RasPi with WSJT modes as there are a good few issues which need tweaking. Decoding speed, reported spot time error are the main issue. I kept a log of issues tonight and added a couple of screen shots linked here if interested :
        http://homepage.ntlworld.com/re.thornton/G3WKW/files/WSPRTest20120627.pdf

        Joe already gave me some hints to get this far and I will make some changes and try again tomorrow. It will be nice to run 3.5 watts computing power instead of 500 during the summer if it ever arrives this year!

        Bob

        G3WKW


      • Michael O'Bannon
        A couple of weeks ago, I was able to install and run fldigi on the Raspberry Pi with limited functionality under Debian Squeeze. It produced short periods of
        Message 3 of 14 , Jun 28, 2012
        • 0 Attachment
          A couple of weeks ago, I was able to install and run fldigi on the Raspberry Pi with limited functionality under Debian Squeeze.  It produced short periods of audio output in transmit tests, but eventually ceased to transmit at all.  Some modes did not produce any output.  Audio was interrupted when the mouse was in use.  I assume some tuning needs to be done on the settings for alsa.

          I have no method of audio input, so no receive functions were tested.

          This limited test gave me some optimism that someone with greater understanding of the issues will be able to get fldigi fully functional on the RPi.

          Best regards,
          Michael  KD4SGN
          Outstanding.

          Keep us posted. I have a Pi sitting here. I haven't fired it up yet. Hope to see if someone can get FL DIGI running on it.

          Randy
          K7AGE


        • Michael O'Bannon
          Bob, Sounds like you are making good progress! Could you describe how you are getting audio into the Raspberry Pi? I d like to give it a go here, but I m not
          Message 4 of 14 , Jun 28, 2012
          • 0 Attachment
            Bob,

            Sounds like you are making good progress! Could you describe how you
            are getting audio into the Raspberry Pi? I'd like to give it a go
            here, but I'm not sure how to handle audio input.

            Thanks,
            Michael KD4SGN
            > I have managed to send and receive, and upload spots using a Raspberry Pi with Debian Wheezy. Interested to hear from anyone else trying to use a RasPi with WSJT modes as there are a good few issues which need tweaking. Decoding speed, reported spot time error are the main issue. I kept a log of issues tonight and added a couple of screen shots linked here if interested :
            > http://homepage.ntlworld.com/re.thornton/G3WKW/files/WSPRTest20120627.pdf
            >
            > Joe already gave me some hints to get this far and I will make some changes and try again tomorrow. It will be nice to run 3.5 watts computing power instead of 500 during the summer if it ever arrives this year!
            >
            >
            > Bob
            >
            > G3WKW
            >
            >
            >
            >
            > ------------------------------------
            >
            > To unsubscribe, send an email to:
            > wsjtgroup-unsubscribe@yahoogroups.com
            >
            > WSJTGroup HomePage http://www.ykc.com/wa5ufh/
            >
            >
            >
            >
            >
            > Yahoo! Groups Links
            >
            >
            >
            >
          • Kristoff Bonne
            Hi Bob, Again send to wrong address. Should have been send to the group. I run WSPR on my pandaboard without much of an issue. Of course, the pandaboard has
            Message 5 of 14 , Jun 29, 2012
            • 0 Attachment
              Hi Bob,



              Again send to wrong address. Should have been send to the group.



              I run WSPR on my pandaboard without much of an issue.
              Of course, the pandaboard has quite some more CPU power to burn then the Ras Pi. Calculation time at the end of every 2 minute cycle takes about 3 seconds on one core.

              I'm also experimenting with wsjt on the pandaboard. That is a much more mixed result overthere. Sometimes, calculation is done in just a few seconds (when no signal is present); sometimes -especially if there are two QSOs going on simultanous- can take around 15 to 20 seconds which make it


              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.

              Another trick is to use the optimalisation of gcc. When I compile my gmsk encoder on a mini2440 (ARM9), just using "-O3" on gcc makes the code run about 2.5 to 3 times faster). Especially for DSP routines (typically the "multiply-and-add" commands) gcc manages to really use the capabilities of the processor pretty well.
              As far as I see, both wspr and wsjt are written in fortran. I don't know how well gfortran does code-optimimalisation.

              It would perhaps be interesting to have a very good look at the compiling-process and check if nothing can be tweaked overthere.


              73
              Kristoff - ON1ARF


              On 28-06-12 02:28, bob_g3wkw wrote:
               

              I have managed to send and receive, and upload spots using a Raspberry Pi with Debian Wheezy. Interested to hear from anyone else trying to use a RasPi with WSJT modes as there are a good few issues which need tweaking. Decoding speed, reported spot time error are the main issue. I kept a log of issues tonight and added a couple of screen shots linked here if interested :
              http://homepage.ntlworld.com/re.thornton/G3WKW/files/WSPRTest20120627.pdf

              Joe already gave me some hints to get this far and I will make some changes and try again tomorrow. It will be nice to run 3.5 watts computing power instead of 500 during the summer if it ever arrives this year!

              Bob

              G3WKW



            • Joe Taylor
              Hi Kristoff and all, ... 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
              Message 6 of 14 , Jun 29, 2012
              • 0 Attachment
                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
              • Jeffrey E. Hundstad
                ... Hello, Agreed! gfortran actually uses the same back-end code optimizer that the the C compiler uses. GCC contains many front-ends, including Fortran, C,
                Message 7 of 14 , Jun 29, 2012
                • 0 Attachment
                  On 06/29/2012 11:06 AM, Joe Taylor wrote:
                  > The gfortran compiler optimizes at least as well as gcc.

                  Hello,

                  Agreed! gfortran actually uses the same back-end code optimizer that
                  the the C compiler uses. GCC contains many front-ends, including
                  Fortran, C, C++, Java, etc.

                  You can sometimes get some benefits by optimizing your binary/program
                  for your specific hardware. But the big bang for the buck ends up in
                  having the system libraries that are being used fully optimized,
                  sometimes by using specialized hardware. This is where the FFT happens
                  and that's where the time is spent.

                  --
                  Jeffrey WE0A
                • bob_g3wkw
                  The USB audio adaptor is one of the cheapest available on fleabay. I probably paid 2 pounds for a local sourced one but available at half that price from China
                  Message 8 of 14 , Jun 29, 2012
                  • 0 Attachment
                    The USB audio adaptor is one of the cheapest available on fleabay. I probably paid 2 pounds for a local sourced one but available at half that price from China if you are prepared to wait. I have used it extensively for JT65-HF with my main PC and find it performs as well as the PC internal sound card. But I do run it through a powered hub as I think the RasPi has those polyfuses to limit the current. I also had to isolate pin 4 on the USB lead from the hub to the pi as the hub was feeding power back (common to most cheap hubs I believe) and the pid went unstable (I just used a small piece of masking tape on the contact). I run the hub from a true DC (7Ah battery plus 5V reg) as the PSU I had caused visible 50Hz horizontals. I tried to run the pi from the same powered hub but it probably needs the power from 2 ports as it is again unstable unless it has its own PSU.

                    Bob
                    G3WKW

                    --- In wsjtgroup@yahoogroups.com, Michael O'Bannon <mob@...> wrote:
                    >
                    > Bob,
                    >
                    > Sounds like you are making good progress! Could you describe how you
                    > are getting audio into the Raspberry Pi? I'd like to give it a go
                    > here, but I'm not sure how to handle audio input.
                    >
                    > Thanks,
                    > Michael KD4SGN
                    > > I have managed to send and receive, and upload spots using a Raspberry Pi with Debian Wheezy. Interested to hear from anyone else trying to use a RasPi with WSJT modes as there are a good few issues which need tweaking. Decoding speed, reported spot time error are the main issue. I kept a log of issues tonight and added a couple of screen shots linked here if interested :
                    > > http://homepage.ntlworld.com/re.thornton/G3WKW/files/WSPRTest20120627.pdf
                    > >
                    > > Joe already gave me some hints to get this far and I will make some changes and try again tomorrow. It will be nice to run 3.5 watts computing power instead of 500 during the summer if it ever arrives this year!
                    > >
                    > >
                    > > Bob
                    > >
                    > > G3WKW
                    > >
                    > >
                    > >
                    > >
                    > > ------------------------------------
                    > >
                    > > To unsubscribe, send an email to:
                    > > wsjtgroup-unsubscribe@yahoogroups.com
                    > >
                    > > WSJTGroup HomePage http://www.ykc.com/wa5ufh/
                    > >
                    > >
                    > >
                    > >
                    > >
                    > > Yahoo! Groups Links
                    > >
                    > >
                    > >
                    > >
                    >
                  • bob_g3wkw
                    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
                    Message 9 of 14 , Jun 29, 2012
                    • 0 Attachment
                      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, 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 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
                      Message 10 of 14 , Jun 30, 2012
                      • 0 Attachment
                        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, 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 Jeffrey, ... Well, the proof of the pudding is in the eating. What I once did is use gcc to use the compile but do not assemble option and look at the
                        Message 11 of 14 , Jun 30, 2012
                        • 0 Attachment
                          HI Jeffrey,



                          On 29-06-12 19:02, Jeffrey E. Hundstad wrote:
                           

                          On 06/29/2012 11:06 AM, Joe Taylor wrote:
                          > The gfortran compiler optimizes at least as well as gcc.

                          Hello,

                          Agreed! gfortran actually uses the same back-end code optimizer that
                          the the C compiler uses. GCC contains many front-ends, including
                          Fortran, C, C++, Java, etc.

                          You can sometimes get some benefits by optimizing your binary/program
                          for your specific hardware. But the big bang for the buck ends up in
                          having the system libraries that are being used fully optimized,
                          sometimes by using specialized hardware. This is where the FFT happens
                          and that's where the time is spent.

                          Well, the proof of the pudding is in the eating.

                          What I once did is use gcc to use the "compile but do not assemble" option and look at the assembler-files it creates. Then you can see if it actually uses the DSP instruction-sets of the ARM11 or not.


                          If I understand Bob's message correctly, the Ras Pi needs more then one minute to process one minute of audio. My pandaboard does it in less then 3 seconds on one core, including the GUI. I don't think that just the difference in CPU can explain this 20-times time difference. There must be something else playing here.


                          Jeffrey WE0A

                          73
                          Kristoff - ON1ARF

                        • 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 12 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 13 of 14 , Jul 2, 2012
                            • 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 14 of 14 , Jul 12, 2012
                              • 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.