[hpsdr] Hermes Interest

[Abhi Arunoday]

Hi Jeremy,

I put in the "Caveat"  as I do understand that this would be NO trivial
exercise :),

There would have to be a single 122.88Mhz master clock and a  10Mhz
reference source driving both the cards (adding a jumper wire with 122.88Mhz
@ 1.5v PP is not a good idea if you have Penelane/lope anywhere near it),
there is also the issue of correctly correlating the data from the two
boards as you have already pointed out, in fact the thought of adding a
second ADC on Hermes did accur to me when I was working on the PCB but trust
me looking at the component density and crosstalk issues I immediately
discarded the notion,

The idea of adding even one more resistor to the Hermes board for some
reason does not seem to be very entertaining thought for some weird reason
:)

Regards,

Abhi

On Sunday, August 7, 2011, Jeremy McDermond <mcdermj at xenotropic.com> wrote:
> On Aug 7, 2011, at 2:28 AM, Abhi Arunoday wrote:
>
>> ***** High Performance Software Defined Radio Discussion List *****
>>
>> Hello,
>>
>> I agree completely with Jeremy, however, while a single Hermes Card may
not be able to do Diversity reception, i'm sure multiple boards can be run
together to allow this feature.
>>
>> The only Caveat is the higher cost and development of appropriate FPGA
and PC code.
>
> We've had some discussions on this before and it seemed rather impractical
to do so.  First, the clocks would have to be synchronized on both boards
such that they're completely in phase.  See the discussion earlier this week
on why merely phase locking clocks to the master 10MHz clock on Atlas based
systems doesn't work so well for diversity.
>
> Second, you would have to find some way to present that data to the
computer in a way that it can determine the proper time relationships
between the samples.  You could "slave" one Hermes to another in some way,
but you'd need an appropriate connector to do so.  I'm not sure there is
such a connection.  Even if there were, you're getting in the realm of "why"
since you're approaching the complexity of an Atlas system anyhow.  It would
make much more sense in this case to develop some sort of daughter card with
just the ADC on board.
>
> You could also try to use the Ethernet connections for both of them, but
this has also been discussed before.  You would have to have ultra-accurate
timestamps on the data to be able to correlate them correctly.  You can't be
guaranteed of timely delivery of the ethernet packets (or even that they'll
be delivered at all) so you may have to buffer samples coming from both
boards significantly.  There's also the questions of where you would get the
ultra-accurate timestamp from, and whether those timestamps are going to be
accurate enough to capture differences in phase relationships of a 50MHz
signal.
>
> The Atlas systems accomplish this by the controller card (Metis or
Ozy/Magister) correlating the data from the different Mercuries and
interleaving them in the packets to the computer.  We then know that
adjacent samples were taken at the same time.  Again, this could be done if
you had a "master" FPGA that did all the communication with the network, but
then again, this starts to look a whole lot like an Atlas system without a
backplane.
>
> All in all it seems like a *LOT* of hacking to come up with a system that
we have working relatively well on Atlas.  Hermes was really designed to be
simple and self contained, and therefore had compromises to make it so.
 Maybe it makes sense at some point in time to come up with a "Diversity
Hermes" that has two ADCs on board.  You need some more entertainment on how
to cram more components on the board, right? :)  Either that, or the idea of
a daughter card with an extra ADC is interesting.  Being the software guy,
I'm not sure how hard it would be to do something like that and keep all of
the data lines properly shielded and such.
>
>> regards,
>>
>> Abhi
>
> --
> Jeremy McDermond (NH6Z)
> Xenotropic Systems
> mcdermj at xenotropic.com
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20110807/45f1538c/attachment-0004.htm>