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

KVASD_95 for ARM linux

Expand Messages
  • Kristoff Bonne
    Hi, I m currently experimenting with wsjt on a pandaboard running ubuntu/ARM. When enabling deep decode , I get an error on the console saying KVASD_95 not
    Message 1 of 3 , Jun 25, 2012
    • 0 Attachment
      Hi,

      I'm currently experimenting with wsjt on a pandaboard running ubuntu/ARM.


      When enabling "deep decode", I get an error on the console saying
      "KVASD_95 not found" (quit normal as the libraries provided as i386).

      Is there any way to provide an ARM version of these applications? I
      don't know who has the source-code for these, but it would be nice if
      somebody would cross-compile them for the ARM platform.
      This application could then run other ARM based systems too (e.g. like
      the Ras Pi). :-)



      73
      Kristoff - ON1ARF
    • Joe Taylor
      Hi Kristoff, ... As you probably know, KVASD is a soft-decision decoder for the Reed Solomon (63,12) code using six-bit symbols. It uses a petented algorithm
      Message 2 of 3 , Jun 25, 2012
      • 0 Attachment
        Hi Kristoff,


        ON1ARF wrote:

        > I'm currently experimenting with wsjt on a pandaboard running ubuntu/ARM.
        >
        >
        > When enabling "deep decode", I get an error on the console saying
        > "KVASD_95 not found" (quit normal as the libraries provided as i386).
        >
        > Is there any way to provide an ARM version of these applications? I
        > don't know who has the source-code for these, but it would be nice if
        > somebody would cross-compile them for the ARM platform.
        > This application could then run other ARM based systems too (e.g. like
        > the Ras Pi). :-)

        As you probably know, KVASD is a soft-decision decoder for the Reed
        Solomon (63,12) code using six-bit symbols. It uses a petented
        algorithm (see the note at bottom of this WSJT web page
        http://www.physics.princeton.edu/pulsar/K1JT/devel.html).

        In principle there's no reason it could not be compiled for the ARM
        processor. Evidently there is not much demand; I have never before seen
        such a request. I do not have an ARM-based machine on which to do the
        compile. It's not clear that the Raspberry Pi has enough "horsepower"
        to make it a useful platform for the JT65 mode.

        -- 73, Joe, K1JT
      • Kristoff Bonne
        Hi, Forgot to put the list in cc: 2nd try. :-) 73 Kristoff - ON1ARF ... Subject: Re: [wsjtgroup] KVASD_95 for ARM linux Date: Tue, 26 Jun 2012 08:26:52 +0200
        Message 3 of 3 , Jun 26, 2012
        • 0 Attachment
          Hi,


          Forgot to put the list in cc:
          2nd try. :-)



          73
          Kristoff - ON1ARF


          -------- Original Message --------
          Subject:Re: [wsjtgroup] KVASD_95 for ARM linux
          Date:Tue, 26 Jun 2012 08:26:52 +0200
          From:Kristoff Bonne <kristoff@...>
          To:Joe Taylor <joe@...>


          Hi Joe,



          On 25-06-12 21:48, Joe Taylor wrote:
           

          Hi Kristoff,

          ON1ARF wrote:

          > I'm currently experimenting with wsjt on a pandaboard running ubuntu/ARM.
          >
          >
          > When enabling "deep decode", I get an error on the console saying
          > "KVASD_95 not found" (quit normal as the libraries provided as i386).
          >
          > Is there any way to provide an ARM version of these applications? I
          > don't know who has the source-code for these, but it would be nice if
          > somebody would cross-compile them for the ARM platform.
          > This application could then run other ARM based systems too (e.g. like
          > the Ras Pi). :-)

          As you probably know, KVASD is a soft-decision decoder for the Reed
          Solomon (63,12) code using six-bit symbols. It uses a petented
          algorithm (see the note at bottom of this WSJT web page
          http://www.physics.princeton.edu/pulsar/K1JT/devel.html).

          Yes, I was aware of that. (hence the "I don't know who has the source-code" remark) :-)

          There are three options:
          - set up a ARM cross development enviroment on a i386 box
          - set up a ARM emulator on i386
          - Or else, I can provide you with an account on my pandaboard.

          I already run WSPR on the pandaboard withouy any issues.


          In principle there's no reason it could not be compiled for the ARM
          processor. Evidently there is not much demand; I have never before seen
          such a request.

          I have a small project to see what kind of ham-related project you can all run on these kind of boards.

          Two years ago, when I started this, there where only the "plug-computers" (like the sheeva-plug or guruplug), but now we have a whole range of options: high-end high-power boards like the pandaboard and the pandaboard, over the low-power (< 1W) board like the friendlyarm mini2440, boards dedicated for I/O like the beaglebone to "as cheap as possible" Ras Pi.

          The new "Universal Digital Radio" John K9VE is working on is nothing else but an ARM board with a radio wrapped around it.


          I now run WSPR on my pandaboard. The gmskmodem developement I do is on one of the boards I have, including real-time codec2 encoding/decoding on the pandaboard.



          I do not have an ARM-based machine on which to do the
          compile. It's not clear that the Raspberry Pi has enough "horsepower"
          to make it a useful platform for the JT65 mode.

          The ARM1176JZF-S does have a vector FPU and additional DSP core, so I think it mainly depends on the quality of the gcc optimalisation code for this processor.

          But it also depends on what you want to do.

          One thing I think of is -concidering the small size and power of Raspberry Pi- a platform for a JT65 monitoring device. Connect it to a HF receiver somewhere and let it continuesly monitor the JT65 frequencies and upload the spots to the net. It can use up to a whole minute to decode the audio.

          No need for a GUI for that, so less code. Cheaper then a PC, less power-consumpting that a PC and no fans that make noise.


          -- 73, Joe, K1JT

          73
          Kristoff - ON1ARF



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