[hpsdr] HPSDR and Beamforming

[Murray Lang]

Thanks Phil

I am looking at using GNU Radio (software) for experimentation. I've 
recently got myself another oldish PC to run Linux for that purpose. Not 
sure what the device driver situation is but if everything was straight 
forward it would be boring I suppose.

While I've got you, can you see any showstoppers in the idea of an external 
phase shifting unit based on the LTC2208? I am imagining a scenario where 
the LTC2208 samples a signal from any old ham rig under the control of an 
FPGA. The FPGA transfers the data to a circular buffer in DDR RAM, waits 
some programmable period, then reads the data and sends it to a DAC. I 
suppose the FPGA speed and amount of RAM required would limit operation to 
HF. It wouldn't matter about the overall processing delay because all of 
the units would be the same. However the resolution of the system would be 
limited by the time taken to write then read the RAM. The units would 
obviously be synchronised to the same clock and I imagine a gyro input 
would be useful to correct for vehicle or vessel rotation. I reckon such a 
unit would sell like hotcakes.

Murray
VK6HL

At 09:06 AM 14/09/2006, pvharman at arach.net.au wrote:
>Murray,
>
>This is  something we have discussed in relation to the HPSDR project. The
>Janus sound card Beta has the capability to be phase locked to an external
>reference. You could also use multiple Janus cards on the Atlas bus all phase
>locked together.
>
>Alternatively you could use one ADC running at say 192kHz and multiplex two
>96kHz I/Q streams over the USB. It may be easier to make a special purpose
>board (after all that is what the HPSDR project is all about) that has n ADCs
>all passed over the one USB interface.
>
>As a starting point you could take say two SoftRocks and feed them both from
>the same local oscillator and feed the I/Q outputs to inputs 1 & 2 and 3 & 4
>of a D44 sound card. Since the inputs all run off the same clock you 
>should be
>able to trim any static phase error out in software.
>
>A modified version of PowerSDR would be required but to a hardware guy 
>like me
>that is  just  "simply a matter of software" :)
>
>
>73's Phil....VK6APH
>
>
>
>
>
>Quoting Murray Lang <murray.lang at metoceanengineers.com>:
>
> > ***** High Performance Software Defined Radio Discussion List *****
> >
> > Hi Jeff
> >
> > I don't think you're clicking "Reply All" because hpsdr at hpsdr.org is not
> > appearing in your headers. I suspect I'm the only one receiving your posts.
> > More comments below.
> >
> > At 04:10 AM 14/09/2006, jeff millar wrote:
> > >>Now I'm wondering about synchronisation of sound cards if phase
> > >>adjustments are performed by PC software and there is a separate sound
> > >>card for each Tx/Rx. I suspect that they would have jitter relative to
> > >>each other due to task switching in the device drivers and to their own
> > >>clocks being unsynchronised. I suppose you would have to go for a
> > >>professional sound card with more inputs/outputs (at least 4 stereo
> > >>channels in each direction?). Maybe this is a candidate for an HPSDR
> > board.
> > >>
> > >Hmmm...As the frequency drops from RF to IF to Audio, the amount of 
> jitter
> > >tolerance goes up (as a percentage of the frequency).
> >
> > But this contradicts what has been said earlier about the phase shift at
> > I/Q scaling proportionately to RF.
> >
> > >Assume each audio A/D channel can DMA a continuous stream into into
> > >memory. Now we have to assume that each audio A/D runs from the same 
> clock
> > >reference. I don't know how the HPSDR project arranges that across audio
> > cards.
> >
> > This basically proscribes using multiple sound cards unless they have
> > external clock inputs (which I'm not aware that any do). Even if they 
> could
> > be synchronised, I'm not convinced that the data sent to them would be
> > synchronised unless maybe a single device driver drove all of them. Sounds
> > way too messy.
> >
> > Perhaps it would be better if all the audio channels were delivered by 
> USB.
> > I think this is relevant to the HPSDR project because any audio data 
> packet
> > format will need to be designed to allow for more than two channels.
> >
> > Murray
> > VK6HL
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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/
> >



 1158200180.0