[hpsdr] Project proposal - Hermes

[Graham / KE9H]

All:

I would like to support Kevin's pursuit of Hermes as a derivative project.

It may or may not advance the technical state of the art on hardware.

There are a few things on Penny that can be improved and I have
already informed Kevin of my thoughts. [I also copied the list,
but my email was bounced back to me because the list was down.]

I think we are approaching the point where the effort can shift more
to the software side, and any platform that opens up and encourages
OPEN software development for the underlying HPSDR architecture is a
positive from my viewpoint.

So far, software has been the long pole in the tent, and that pole
has been supported by Bill, KD5TFD almost singlehandedly for
PowerSDR extension, debug and modification to support the
HPSDR hardware set [Thank you, Bill].

I also thank the few people that have written the FPGA Verilog code.
And this story is getting much better by the generous contribution
by Kirk, KD7IRS by teaching, recording and psoting over a dozen classes
on Verilog programming, and functional content and flow of the
Merc/Penny/Ozy FPGA code.  [Thank you, Kirk] 
And Kirk has also rewritten a lot of the code, in a
progressive effort to clean up issues in the FPGA and Bus areas.

The three projects that I have worked on, really have not advanced
the state of the art as much as they have enabled the core HPSDR
cards to become usable in a more complete system application.

I think Kevin's Hermes proposal falls in this category.  It removes
a whole bunch of things that were put into Mercury, Penny, and
Ozy, just in case, for development testing, or experimental purposes
that sometimes didn't work out, or future universality, or ... .

Hermes could be a major cost and size reduction for the system level
platform of an SDR HF/transverter transceiver. Which also has value.

Filling out the system level hardware, either as I have helped do, or
in a more compact bus-less form factor will provide a reasonably
common and attractive platform for software development.

Once we get the hardware systems limitations out of the way,
I think more of the software types that perhaps don't have the
hardware development skills will come and play with us.

After all, this is a software defined radio, and it is time to
enable and encourage and feed the software development.

I will know I am right when I see the first proposal for a
software-only HPSDR project.  Perhaps a remote base
HPSDR, or a multi-user shared base HPSDR, or a software-only
addition converting HPSDR to test equipment apart from
PowerSDR or what ever smarter and younger people than me
can think of.

--- Graham / KE9H

==


Kevin Wheatley wrote:
> ***** High Performance Software Defined Radio Discussion List *****
>
>
> On 15 Apr 2009, at 14:52, Philip Covington wrote:
>
>> On Sun, Apr 12, 2009 at 12:35 PM, Kevin Wheatley 
>> <m0khz at tiscali.co.uk> wrote:
>>> ***** High Performance Software Defined Radio Discussion List *****
>>>
>>>
>>>
>>> Following the outstanding success of Mercury and Penelope, and while 
>>> investigating the verilog code for both, I had the insane idea of 
>>> merging the verilog code of Mercury and Penelope into a single fpga! 
>>> I played around with this idea for a while and the more I thought 
>>> about it the more I liked the idea.
>>> So here is the proposal, to develop a single board HPSDR based on 
>>> the hardware of Mercury and Penelope and a single large fpga.
>>> This board would have PC connectivity by USB. I’m planning to 
>>> squeeze this all onto Euro Card sized PCB (100 x 160 mm), and if I 
>>> utilize both sides I might even have room for a Pennywhistle type 
>>> PA  :).
>>> Basic specs so far (nothing cast in stone)
>>> Fpga EP3C25Q240C (I think this is the largest without BGA pin out)
>>> Mercury receive chain
>>> Penelope transmit chain
>>> USB2 to PC data transfer
>>> Pennywhistle PA (if there’s room)
>>> 10Mhz on board with ext an option
>>> Alex filter switching header
>>> 13.5V supply
>>> I’ll post a provisional block diagram on the Wiki this week, and 
>>> lastly, why the name?
>>> Following the tradition of the HPSDR naming convention, I thought 
>>> Hermes was appropriate as he was known for his invention and theft!
>>> All comments welcome.
>>> Kevin – M0KHZ
>>
>> While interesting, this proposal does not fit in with the rest of the
>> HPSDR projects.  It does nothing to advance HPSDR because it is a
>> rehashing of boards that have already been produced.  The idea behind
>> HPSDR was to break the projects up into modules that could work on a
>> common bus (ATLAS).  By breaking it up into modules, multiple people
>> could work toward a common goal.  There is also a (project leaderless)
>> proposal for an Ethernet based OZYII board now - how does that jive
>> with your stand alone board proposal?
>>
>
> I agree this proposal doesn't align with the mission statement of the 
> group, however I gain my best learning from doing, and each time I 
> tackle a project I learn different skills (isn't this what Amateur 
> radio is all about). As I state above, the idea was born from 
> investigating the verilog code and postulating a different 
> architecture. Hence the project proposal. OzyII has nothing to do with 
> Hermes.
>
>> The other issue is that this will necessarily require different
>> firmware, software, and FPGA HDL than the individual modules it
>> combines.  What about those who have invested in Atlas, OZY, Mercury,
>> Penelope, etc..?   Will development be slowed or stopped for those
>> people if favor of the this new board that combines all the work of
>> these individual projects into one?
>>
>> Phil N8VB
>
> I agree, different fpga firmware will be required, but having followed 
> Kirks fantastic coarse, with very my limited skills (but growing), I 
> think I've half a chance of hacking something that may work, once 
> again learning by doing and having some hardware here that needs new 
> firmware is a great incentive :) I'm not sure about the firmware for 
> the USB interface (haven't thought this through), but as I understand 
> the code, the C&C encoder / decoder is the key? I can't respond 
> regarding future developments on the existing boards, but I think Kirk 
> has provided one clear view - development won't slow down or stop.
>
> I must point one that I am one who has invested in a full suite of 
> HPSDR boards, and are used daily as my main rig, these will not be 
> made redundant, if / when Hermes become a reality, that's the great 
> benefit of mix and match with the Atlas back plane.
>
> 73's
> Kevin - M0KHZ
>
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at hpsdr.org
> Subscription help: http://lists.hpsdr.org/listinfo.cgi/hpsdr-hpsdr.org
> HPSDR web page: http://hpsdr.org
> Archives: http://lists.hpsdr.org/pipermail/hpsdr-hpsdr.org/
>


 1239820588.0