[hpsdr] Hgx2

[Georg Prinz]

Joe, Ken and All,

DttSP is the main code for PowerSDR. So far as I know it supports up to
4 receivers and the receiver number is a parameter. Based on this
information this would mean that no changes on the mercury board would
be necessary. The communication is done through OZY.

Further more the DttSP receiver (PowerSDR) is split into three parts:
pre-processing common to all parts, demodulator and a post-processing
part. 

Because I am not familiar so far with the detailled source code I have
to assume:

Taking into account the upper structure for a dual configuration
application in our sense (Phase diversity) we would need an addition to
the pre-processing part.

The application I have in my mind is, to eliminate the phase-lines in a
cross-yagi configuration. 

As I understood Joe, for his application it is the same topic, but
without the demodulation part.

The output signals of mercury are the real and imaginary part of the
received spectrum.

Using two receivers, we need to add the two outputs as vectors. This
means adding the two real parts and the two imaginary parts together.
Maybe a normalization will be necessary to stay within the applicable
magnitude range.

This combined signal can be passed to the pre-processing section of
DttSP. 

The post-processing section (GUI) needs some addition to show the phase
of the two antennas.

For Joe, the magnitude seems to be enough and has to be calculated
separatedly. I can imagine that he needs a different post-processing
module without demodulation of the signal. 

Please consider my text as a first step to get ideas what we want and
how it could be implemented.

Vy 73,
Georg, dl2kp




On Sa, 2009-02-28 at 18:54 -0700, Joe Martin K5SO wrote:
> ***** High Performance Software Defined Radio Discussion List *****
> 
> Ken and All,
> 
> As it happens, polarization diversity is exactly my particular  
> interest in using dual synchronized Mercury boards with both operating  
> at the same frequency but with a bandwidth greater than 250 KHz  
> preferably and each connected to a different polarization port on the  
> antenna system!  Sorry, I don't follow the Linux reflector postings  
> and so I don't know what you mean by the "M application" at all.   
> Maybe it's exactly what I'm needing?
> 
> My thinking on the dual-Mercury-boards issue to date has been to learn  
> how to code the FPGAs in both Mercury boards in order to extract the  
> instantaneous (simultaneous) voltages at the two Mercury rf input  
> jacks (one input for each orthogonal polarization port on the  
> antenna), to square those voltage values, and then to add them  
> together to form a single-output "power" level in order to achieve  
> about a 3dB improvement in S/N over a single-polarity rf signal.
> 
> As I want to use this for pulsar star work I personally do not need  
> the overhead of any communication demodulation schemes (e.g., to  
> produce CW, SSB, FM, AM, etc signals) in the PC program.  I was  
> thinking that the Ozy USB interface to the PC would be the appropriate  
> path to take the power-level data into the PC for processing.  I'm not  
> following you on how one might eliminate the Ozy interface function  
> with the PC.  Certainly one could simply the PowerSDR program on the  
> PC substantially but it seems to me that Ozy will still be a necessary  
> component(?).  However, I'm certainly interested in knowing if there  
> are other ways of collecting and processing such data.
> 
> For the present, I fully intend to re-write a version of the PowerSDR  
> code to support the signal processing functionality that I described  
> above so dealing with a PowerSDR-like program is not a terrible show  
> stopper as I see it.
> 
> I'm sure others have very different reasons for wanting dual Mercury  
> boards running though.  We can all benefit from exploring/discussing   
> the various possible methods of doing it, I think.
> 
> Joe K5SO
> 
> 
> On Feb 28, 2009, at 5:48 PM, Ken wrote:
> 
> > Joe - I am also interested  In the dual (synchronized) Mercury board  
> > receiver (perhaps you have been watching the Linrad reflector).
> >
> >
> >
> > M application is polarization diversity for EME reception.
> >
> >
> >
> > Anyway, it would seem there are likely to be a number of ways to  
> > attack this, it would be interesting to see discussion on the topic.
> >
> >
> >
> > For a simple single-frequency application (center frequency of the  
> > pass band would be fixed) one could modify the FPGA program so that  
> > OZY and PowerSDR are not needed. This would greatly reduce the  
> > programming effort to get some proof of concept going.
> >
> >
> >
> > 73
> >
> >
> >
> > Ken
> >
> >
> >
> 
> _______________________________________________
> 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/