Quantcast

Entirely digital exciter

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Entirely digital exciter

Gullik Webjorn
Hello,

I am planning to try out a completely digital exciter, using a dds to
generate a fo/n signal, replacing a crystal oscillator. This has a few
advantages, in that modulation can become "exact", and also that the TX
can be locked to GPS.

Generating the carrier at fo/n, many old "non-synthesized" repeater or
base trasmitters can be put into ham service, where they previously have
been regarded as boat anchors due to the disappearance of crystal
grinding shops.

Now for the things I want feedback on:

What interface should the exciter have that would allow best integration
with svxlink?

What format of digital audio should be used?

Since this  will be ALL digital, the transmit data stream ( from svxlink
to remotetrx ) will go straight to the exciter, assuming a computer
running remotetrx.

Things that come to mind is "16 bit signed", which will be scaled to the
fo/n, to produce a deviation that when multiplied to the output
frequency is "correct".

A sound format that directly comes to mind is G.711, codecs for this
will run on even the simples microcontroller, and it requires half the
bandwidth of 16 bit signed.

How do you feel about ASYNC / UART for carrying the voice? 115 kbit/sec
can transport a 64 kbit G.711 audio stream, and is a common interface on
most PC's maybe using a UART dongle....

A uart would also possibly interface  the GPS puck...for time
synch....and oscillator discipline...


Well let it rip....

SM6FBD



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Entirely digital exciter

Rob Janssen
Gullik Webjorn wrote:
> Hello,
>
> I am planning to try out a completely digital exciter, using a dds to
> generate a fo/n signal, replacing a crystal oscillator. This has a few
> advantages, in that modulation can become "exact", and also that the TX
> can be locked to GPS.

It is something I have been considering for our co-channel diversity repeater on 70cm.
However, it would be preferred in our case to generate the 70cm transmit frequency
directly (so n=1).
Our existing repeater has a PLL frequency generation board that outputs the modulated
70cm signal and that could be replaced bt such a new exciter, keeping the existing
power amplifier (and receiver).

> Now for the things I want feedback on:
>
> What interface should the exciter have that would allow best integration
> with svxlink?
>
> What format of digital audio should be used?
>
> Since this  will be ALL digital, the transmit data stream ( from svxlink
> to remotetrx ) will go straight to the exciter, assuming a computer
> running remotetrx.
>
> Things that come to mind is "16 bit signed", which will be scaled to the
> fo/n, to produce a deviation that when multiplied to the output
> frequency is "correct".
>
> A sound format that directly comes to mind is G.711, codecs for this
> will run on even the simples microcontroller, and it requires half the
> bandwidth of 16 bit signed.
>
> How do you feel about ASYNC / UART for carrying the voice? 115 kbit/sec
> can transport a 64 kbit G.711 audio stream, and is a common interface on
> most PC's maybe using a UART dongle....

I think the board should interface to the computer using a fast digital link like USB
that transports 16-bit signed audio at a high sample rate (48000 samples/s)
as that is the native format for svxlink.  A somewhat lower sampling rate like 12000
or 16000 samples/s would be adequate at this point.
The codec can remain part of svxlink, it will just expand the received audio to that format.
This equals 768000 bits/s plus framing and timing info overhead so it is not practical
to send it over RS232.   115200 bps would allow only about 5500 16-bit samples/s which
is not enough.  At least 230400 or better 460800 bps async would be required.
USB is easier, I think.  You can get one-chip implementations of the entire interface.
(which could still present itself to the computer as a serial port device)

>
> A uart would also possibly interface  the GPS puck...for time
> synch....and oscillator discipline...
>

The interface from the GPS to the board should be:
- 10 MHz reference frequency
- 1 PPS timing info

Of course, "absolute time" information is required as well, at least once after initialisation
of the board, but it can be sent from the computer (that is NTP-synced) over the digital link.
The board uses this info to coarsely set its internal clock, then locks to the 1 PPS for
accurate timing.

The serial info from the GPS is sent to the computer, to be processed by ntpd
(optionally via gpsd) for the same purpose, and also to provide information for the
monitoring to check if the GPS is still functional.  It is too cumbersome to feed this info
via an exciter board as well, and it does not require it anyway. This also means you do
not need to implement the various GPS serial protocols, gpsd is already doing that.

What I had in mind:

- a classic PLL to generate a high frequency clock from the 10 MHz reference.
   (like 1 - 1.2 GHz)
- a DDS to generate the output frequency from that
- a digital upsampler to convert the 48000 (or lower) audio into higher sampling rate to
   modulate the DDS without generating too many nearby spurs

There are some chips, mainly from Analog Devices, that could be suitable for the PLL
and DDS part (e.g. the AD9956 has both PLL and DDS, or more basic ones like the AD9912
have only the DDS and require a second chip for the PLL).
The digital upsampler and timing could be done in an FPGA.  But I have no experience
in programming an FPGA to do such complex things.  I understand that in such cases
often a simple CPU (e.g. ARM) is programmed into the FPGA to do the more complicated
slower tasks using firmware, and the fast tasks like upsampling the modulation or even
the DDS itself can be done by logic blocks programmed in the same FPGA.

Rob

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Loading...