9037Re: WSPR with Raspberry Pi
- Jun 30, 2012Purely 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.
--- In email@example.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.
> 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 firstname.lastname@example.org <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
> > >
- << Previous post in topic Next post in topic >>