[hpsdr] ADC for VSWR Measurement

Phil Harman phil at pharman.org
Fri Aug 29 04:54:35 PDT 2008


Hi  Gerd,

In response to your questions.

>SWR measurement needs 2 analog signals: FWD and REV. Are there ideas for
>the
>remaining 2 inputs on Penelope?

Just spares for some undefined future use.

>why do we not have the ADC for VSWR measurement on Mercury since the analog
>signal from Alex is going into Mercury?

Because Penelope is an exciter and Mercury a receiver.  Running a single 
ribbon cable
from Mercury to Alex seemed like a good idea since these will most likely be
used together. The connection between Mercury and Alex has changed since you 
made
your board.

>The cable which is needed to feed
>analog signals to Penelope is non standard: 4 pins on Mercury and either
>25pins on a DSUB (outside the housing) or an 8 pole header which is not
>very
>well accessible. And cables between cards seem to be in contradiction to
>the
>Bus architecture.

The bus was intended to take digital signals that would be shared between
boards.
We could have used the bus for FWD and REF but decided not to - one of the
problems of 'design by committee' I guess

>Maybe I write the code for SWR measurement. If so I would like to know your
>preferences on which pin(s) on Atlas you would connect the digital output
>of
>the ADC and which dataformat you would choose. Output is on one line, clock
>CBCLK is already available on the Atlas-Bus.

I would not do it the conventional way for the following reason.  The ALC
forPenelope is measured and used within the FPGA. This overcomes the delays
associated with

- measure forward power
- send output of ADC over USB
- read in PowerSDR and determine if within desired setting
- if not calculate new gain
- send over USB to  Ozy
- send over Command and Control on Atlas bus to Penelope
- correct I and Q gain in Penelope FPGA

by this time the output power has overshot!

instead we

- measure forward power
- read output of ADC in FGPA and compare against desired setting
- apply correction to I and Q gain

this is really fast and is the main reason that we can't over drive Penelope

I suggest you do the following

- feed the FWD and REF signals from your PA to two spare inputs on the ADC
on Penelope
- Calculate FWD and REF power and SWR in the FPGA
- use these values to operate your PA safely
- send the results of these calculations to PowerSDR over the USB where they
can be displayed

That way you will find you can read the instantaneous value of the SWR
whilst modulating and not just whilst in TUNE which is what happens at the 
moment.

>Furthermore the Ozy firmware has to be changed/completed and we need to
>define how the "analog" signals should be implemented in the USB protocol.

Correct - the USB protocol is in SVN and is still only a suggestion - feel
free to propose how this should be done. The  Ozy code will never be done 
because we intend
it to be an experimental/flexible platform and it will continue to evolve to 
support
what people are experimenting with.

>Are there suggestions?

No - have a go!

>Who has done the coding for the FX2 so far?

Phil, N8VB and Bill KD5TFD - I don't think you need to change the FX2 code.
Just add to the USB protocol and make the necessary changes to PowerSDR,
Ozy and Janus FPGA code.

>PWM_out from Penelope: what is it provided for?

There are three of these.  We have an idea for building a Class E PA. In
which case we expect to need to have a different phase relationship between 
the phase
modulated RF drive signal and the modulating envelelope. We may want a 
multiple stage
Class E PA with each stage having a different phase relationship. The 
PWM_out is
intended to be used to provide the modulation envelope for each stage - or 
for
something completely different.

These are provided for future fun and experiments.

>Have not yet found a connection for an ATU? (ATU_CTL and ATU_FB)?

Or the antenna rotator controller, or the phased array switching, or the
diversity antenna control, or the four square controller, or the.....

There's no reason connection for an ATU or any of the
other bits could not be implemented if someone wants to take them on.


73's Phil....VK6APH

P.S. HPSDR is not a closed source, black box - everything you have suggested
can be done along with many more exciting things. Play, experiment, learn 
and
share your fun and frustrations with the rest of the group.



 1220010875.0


More information about the Hpsdr mailing list