[hpsdr] Sasquatch II

[Lyle Johnson]

>>> On the other hand, I like embedded DSP, and I hate to see
>>> the HPSDR project become PC-dependent.
>> Why not?
>>
>> By going for an embedded DSP you'd just be reproducing
> existing Japanese radios but with better hardware. Isn't
>  it about time that we shed the past and move onto more
> advanced user interfaces? The developments of DttSP and
> the VR kernel promise to revolutionise amateur radio.

No argument.

I prefer to use an embedded DSP simply because I prefer to use an 
embedded DSP.  This is merely my perspective.

The whole premise of Sasquatch is to be PC independent.  It is not a 
requirement.  You can hook up the various modules and use Ozy and tie it 
to your PC already.

And you can already get a really small motherboard and embed a PC into a 
box along with HPSDR modules and have a standalone solution.

I prefer to not have a PC embedded in the radio, and enjoy working with 
embedded DSP.  I accept the limitations - and challenges - that brings.

Hence Sasquatch.

> If they are talking about the "Beagle Board".  It is a PC.  Or at
> least it can do all the PC things you have listed.
> 
> If I had a say in the design, I'd press for design that integrated a
> true DSP chip with a small general purpose processor both on the card.
>  The general purpose processor would run Linux or Unix and do all the
> above "PC stuff" (GUI, VR kernel,...) The chip could be an ARM, SPARC
> or a "soft CPU" burned into an FPGA.  The DSP would have to have a
> free toolchain.  It would be more then really cool if the tool chain
> could run on the general purpose processor makeing a self contained
> system.

What you are describing is a TI OMAP processor.

The Beagleboard is based on the OMAP3530.  The new one is the OMAPL137. 
  There are trade offs between them, depending on what you wish to 
accomplish.

Sasquatch was originally a spin-off into HPSDR but was in reality a test 
bed for some AMSAT work.  But various factors suggest that AMSAT has no 
need of this, so it is now a question of whether there is sufficient 
interest to move forward, and if so, what the best path is.

The way I read things, the development path for Sasquatch may be:

1) Port dttsp to the Beagleboard.

2) Interface the Beagleboard to ATLAS via OZY (USB).

3) Create a small carrier board (Son of Sasquatch) for the Beagleboard 
to allow its GPIO to interface to ATLAS.  This is very dependent on 
there being sufficient bandwidth, etc., for the FPGAs downstream to be 
loaded and interfaced (Penelope, Mercury, Phoenix/Janus).

4) Evaluate creating an OMAPL137-based board with the bus bandwidth for 
ATLAS, etc.  If this looks like a reasonable thing to do then...

5) Port dttsp to the OMAPL137.

6) Create the hardware OMAPL137 board (Sasquatch II).

?

73,

Lyle KK7P

 1228934899.0