General Specifications
Name of Radio:
1. Purpose:
We need a name for our new baby. What's in a name you say? Well for one
thing I think it gives the project a focus for talking and some form of
identity. OK so we don't have a lot more to go on at the moment but
ideas, but that does not matter. We need a name so people start to use
it, especially when talking about it on air or in the local club.
2. Format:
Do we want simply an acronym, or a number (DSP2K) or do we want a name.
3. Suggestions:
Alpha
DSP2K
DSP-Alpha
SDR-Alpha
DS-Alpha
SD-Alpha
I'm giving some thought to a project name. Maybe it is time that Amsat
spun off a sub-area for Advanced / Blue-Sky / Live-In-Hope projects.
Something like Amsat Advanced Projects. You know the stuff, possible
missions to Mars, Lunar probe etc etc. The stuff that maybe causes
controversy with the pure traditionalists but people like talking about
anyway (personally I think the envelope needs pushing, the current old
modes are getting boring). Project Blue-Sky anyone? or Dark Skies,
Clear Sky...
Goals:
1. Open Platform:
The open source model has a lot to offer such a project, and the use of
open source software (and "open hardware", which may one day be also
commercially produced) could enable amateurs to take a lead in this area.
This project should be a "GNU-like" project so having a "near-complete"
system the "bit-hunting" hams could easily write their own software, and
exchange firmware.
And here's where the Linux/OSS people come in. The software could be
developed in a similar fashion to how Linux development has proceeded
for the last 9 years. GNU licensing could be either utilized directly,
or an adaptation of the idea could be more suited to our needs.
The concept of an 'open source' approach for hardware is kind of
interesting. I'm trying to figure out, though, some of the issues for
doing this. Like is there a good free or cheap program that we could
use for designing circuits. That is so one person could layout the
circuit and another could add in a few parts or do a few tweaks and
repost it. Are there any options here that don't cost lots of money?
That is so everyone involved could look at the work or submit changes.
The hardware and software would be of open design. Experimenters could
build software or hardware as desired. Kits could be made available,
and perhaps even a commercial manufacturer may make a version. We need
to think about licensing our design to ensure that it stays open and
available.
The source code for all radio software will be available and hardware
will use off the shelf components. Development tools should be freely
available or available at minimal costs so that experimentation is
encouraged.
We should use what is available off the shelf :
* RX and TX kits from Down East Microwave
* Low cost DSP starter kits from TI or Analog Devices
* Readily available filters used in volume applications for
availability
* PC architecture in the form of an embedded controller running Linux
I can envisage the day where the hardware becomes commercially
produced, with the software available pre-loaded, or many exciting new
functions, written by hams and other coders, down-loadable off the
Internet.
2. Modular Design:
This box should be designed to use plug in (internal) modules.
A motherboard with plugable DSP, CPU and RF modules would facilitate
high flexibility and ability to change to future technology since we
know that parts are getting obsolete in shorter and shorter cycles.
Pluggability and modularity should be designed in from start. This will
facilitate replacement of obsolete CPU and DSP parts. Companies
withdraw even relatively common and simple components such as SAWF and
helical filters at short notice. Also, highly complex components such as
DSP, DDS, Digital Preprocessors etc continually get upgraded.
Allow for replacement of major sections via plug in modules. The
intent of this item is to allow for improvement in the radio as new
hardware becomes available, or existing hardware is no longer
manufactured without requiring the complete reconstruction of the
radio.
The DSP power today in a single chip is a factor of 50 or so better than
we had just 6 years ago. And you can count on another x4 to x8
improvement by the end of next year. As a matter of fact the
specification should allow plug in replacement of newer faster larger
and cheaper chips.
An open design where you can plug in different type of stuff. If you
want some more RF modules, plug them in. If one wants an Ethernet
interface instead of USB just plug the right card in, or both.
Flexibility and extensibility are key.
Minimizing the function of a single plug in card also allows for easy
upgrades and changes.
The key would be to thoroughly define the interfaces between the RF and
the IF section as well as the interface between the IF and the User
Interface section. This would give a lot of flexibility to each
designer to work on an RF or an User Interface section.
An open architecture concept.
The interface structure should not limit future enhancements.
A system with some kind of bus that permits the use of different RF
modules, DSP modules (one or more at a time) and interface modules, as
well as modules for doing things with the data received, like putting it
on Internet... The idea of the PC where you can plug in any cards and
change almost anything attracts me much.
Also, a standard for internal interfacing (the bus) needs to be
specified, so modules can be easily developed by interested parties.
A modular approach lends itself to easy construction and implementation
by the end users in stages (i.e. use a hybrid analog/digital setup with
the help of existing gear, while building the last modules).
The humble PC provides a good example of what can be done with a modular
system. A similar (but lower noise!) bus structure should be considered
for the SDR.
The TX, RX, DSP and control modules are all independent. It is possible
to have multiple units covering a single band, multiple bands or any
combination of these. The number of TX/RX channels possible is
effectively dictated by the DSP power.
As messy as it sounds, I think on the analog side we might be better
off using a rats nest of 50 ohm coax cables with RCA jacks on each end.
Rather than trying to do a buss. At least with coax it's easier to
understand what's going on. I'm scarred of sticking RF analog signals on
a card edge.
Application:
a. Purpose:
A framework that would allow virtually any application on virtually
any band.
Suitable for communications via amateur satellites and SAREX/ISS.
The original intent was to build a satellite radio, but perhaps a
general use platform makes more sense. If we build for the more
complex applications, the less complex should be inherent.
A high-end HF radio.
To use the P3D Digital stuff right, I think it'd be nice to have a
comparable system here on the planet surface. That is with a
ADC/DDC/DSP receiver and the like.
The DSP-10 project addresses analog satellites and so do products
from Kenwood, Icom and Yaesu. It seems to me that the main purpose of
this project is to build a radio that is capable of operation with
high-speed digital satellites.
b. Modes:
All modulation and demodulation is done via DSP.
The radio shall be compatible with existing analog modulation (AM,
FM, SSB).
The radio shall support the modulation and demodulation of existing
digital modes ( 2-FSK, 2-PSK).
The radio shall be compatible with upcoming high speed digital mode
(up to 170 kbps ?).
The radio shall support full duplex.
I believe that this radio will be able to support both good analog
and digital modes. It would be a shame to limit the capabilities to
only a limited set of modes. The beauty of the DSP concept with the
currently available very high performance chips is that the the radio
capabilities and limitations are completely software defined and are
reprogrammable. Quite likely you can download your radio and I can
download mine and we will both be happy with the same hardware.
I'm wondering if it's a good idea to include analog mode support with
this radio. After all, most of us already have analog radios, and
the transverters needed for this project will also work fine with
existing radios. Unless the analog support comes free, or almost
free, it might be a good idea to simply concentrate on digital
capabilities, as that's something that's mostly unavailable in
commercial (ham) radios.
I presume that the modes choices will include SSB, FM, CW as well as
the digital modes and sat. specific capabilities. I want to use
this for a high end HF radio also. Infinite control over bandwidths
and even split filters is feasible.
The hardware is capable of supporting all modes of current and
planned satellites. Here is a list of modes that I know of on
amateur satellites:
SSB voice, 300-3000 Hz AF bandwidth
NBFM voice, 5 kHz deviation, 300-3000 Hz AF bandwidth
1200 BPS AFSK over NBFM (modulator only)
1200 BPS PSK (demodulator only)
9600 BPS CPFSK, 3.3 kHz deviation, 16 kHz IF bandwidth
38.4 KBPS CPFSK, 13 kHz deviation, 64 kHz IF bandwidth
76.8 KBPS CPFSK, 26 kHz deviation, 128 kHz IF bandwidth
153.6 KBPS CPFSK, 53 kHz deviation, 256 kHz IF bandwidth
153.6 KBPS PSK
256 KBPS PSK (AO-40 RUDAK)
2.048 MBPS QPSK (SSTL minisats and enhanced microsats like UO-36)
I think the first mode would be CW with adaptive or infinite
filters. Burst reception and transmission would be very interesting.
The second could be USB and LSB (or both simultaneously) Control the
filters and bandwidths independent of mode selection is needed. The
auto notch filters existing in many audio dsp filters are essential
for comfortable HF work to delete the tuner-uppers in pile-ups.
The PSK modes with maximum DSP optimization would be high on my
list. I would expect that the Satellite modes optimization with
doppler detection and correction would be a most interesting project.
PSK31 The Doppler problem, even with the LEOs, ought to be
solvable. Digipan already can chase a signal that drifts.
It has always been attractive to me to have a portable means of
accessing the long distance fun of Ham radio. With use of "low
speed" data, such as PSK31, many more QSOs can be supported at much
lower ERP and much less bandwidth- just look at how well it is
working on HF with first generation equipment and software. For
modes, I'd like to see (as I'd use): CW, FM, USB/LSB/ISB, 400 bps PSK
(for telemetry), 1200 bps PSK and AFSK, 9600 bps FSK, high speed
packet (at least up to the 150-300 kbps mark), hooks for future
digital audio modes. Might as well put the DSP to good use. :-)
Some of the sound card based modes (PSK-31, MFSK-16, SSTV, etc) are
desirable, but not essential (since the PC can still be used to
generate these in SSB mode).
From my point of view, the absolute minimum functionality necessary
is the ability to receive 70cm band 1200 and 9600 bps data (or maybe
to start with, just audio?).
Purely dependant on driver software. 256 point QAM wouldn't be that
difficult.
Megabit+ data rates should be possible, if not with the current DSP
then certainly with multiple or faster units.
c. Features:
Clock should be considered. An awful lot of clocks on the ground,
why not sync up repeatedly to a known source via a small receiver
on HF......?
Configurations:
a. Computer Controlled.
The radio shall be controlled from a PC.
The whole idea of software defined radios is rather neat, and suits
my style of operation (fewer and more flexible boxes - the logical
extension of my computer based digital modes).
b. Self Contained.
A portable SDR HF rig that could support PSK31 and any of the other
sound card digital modes.
One compact box that could be used for teaching computer science at
schools, access e-mail, listen to SWL programs, work the ISS, other
satellites, HF digital modes, SSB contest.
Think about going to the park with this box, hook up a antenna,
battery and push the button and you are ready to go. Could make for
some great portable operation.
I think it is very important to consider making provisions right
from the start for the SDR radio to be self supporting. What I mean
is I think it should have a built in PC for control or at least some
type of disconnect header or connector so a built in PC could be
added. Maybe a striped down embedded PC for control that would use a
regular PC for initial set up and software up dates.
I agree with that the radio should be self containing. In my opinion,
Linux running on a small low cost embedded PC module is an ideal
platform. Nowadays it is very popular to use embedded PCs instead
of microcontrollers since the cost has come down dramatically, and
the software development tools are much better.
I'm all for a self contained radio. A PC interface is a must for
upgrading/loading new software, computer control (for satellite use,
etc), and for the flexibility of utilizing the PC's greater
memory/storage capacity for features such as extended memories and
"cloning". However, I feel the radio needs to be able to stand on
its own. Not everyone wants to have to turn on the PC with the
radio. Others (and I could myself in this group) would want to take
it on field trips, where running a PC isn't convenient, not to
mention emergency use.
If a self contained radio is desired, a powerful main CPU could do
some interesting things besides the user interface, such as
satellite tracking and display, antenna control, doppler correction,
logging, remote control, etc.
c. Remote Controlled.
A club owned remote SDR station that members could access using a
dialup account.
How about putting the DSP/SDR radio inside of a weather proof box and
installing it on the antenna!
The radio could be remote controlled over the Internet. A virtual
private network could be established between the operator and the
radio.
For analog modes the audio would be encoded/decoded in the sound
card of the computer and carried by the Internet or dial-up
connection to the radio.
User Interface:
A simple terminal interface would enable control from Psions, Palms,
Windows CE devices, VAXs, PCs, ...
The radio interface should not limit the type of computer used for
control. PC's, MAC's, Windows, Linux, etc. should all work if software
is available on the particular platform.
All control functions are software controllable. Even the power switch.
In my opinion, I very much like the idea of the interface to the radio
being a web browser. This allows ANY PC that can run a web browser to
control the radio, no special drivers to write, no proprietary
interfaces. Web browsers are available to run on all models of
computers and some even for DOS.
I love the idea of Netscape as some level of control.
The X window system may or may not be desired for the DSP/SDR project
but I believe it's is interesting to think about the possibilities.
X-Term. Interesting idea. The control processor could also run as an
http server and allow a web browser to control the radio.
I also do not like mouse turned knobs. Click on the spectrogram or the
lineal level meter is better.
I like the digipan type display and tuning method. The latest psk 31
cores (AE4JY) incorporated in DX4WIN allows decoding 2 simultaneous
stations within the band pass of the receiver.
Wouldn't it be cool to have the radio sample the beacon signal strength
and dynamically adjust your uplink so that your downlink was at the
same level? All this while you listen to your own signal on the
downlink.
Even if we don't have the power to show all of the passband, being able
to represent it on screen and then point and click on a linear scale is
a good thing.
Accepting Kenwood, Icom, and Yaesu commands to allow the use
of your favorite logging software.
Computer Interface:
I'd suggest multiple PC interfaces, they being USB/Firewire and serial.
The USB option is the more modern, and offers the potential for
offloading some processing to a host PC (e.g. using the radio as a DSP
modem only, and interpreting the data in the PC, for some modes).
Serial offers compatibility with more devices, including older PCs
(there's a lot of those in ham shacks) and dumb terminals/portable
devices. Down the track, other hardware developers may design other
interfaces, such as infra red, as need/interest arises.
While Ethernet would be the best interface, we may have to consider a
secondary interface such as InfraRed and/or PPP over a serial link. Many
of the new processors designed for "IP appliances" have these features
already. Think of how easy and convenient it would be if every piece of
equipment in your shack had a standard Ethernet port and all you had to
do was point your browser at the piece of equipment you wanted to
control.
Something I'm curious about is how many of the new computers don't have
a serial port? My IBM Aptiva has both. Also - is there a USB to serial
adaptor available that would allow somebody with a USB only computer to
use the backwards compatible serial port?
Power Requirements:
12 volt power source requirement.
Minimal current for portable operation.
Cost:
I think for a project of this nature, outright cost has to be of only a
secondary concern. So long as the cost doesn't go absolutely loopy the
primary motivator should be performance. Evaluation kits do tend to be
disproportionately expensive in comparison to component price. For many
of the important ICs, the cost is less than $30, with seemingly exotic
chips such as the DDS down below $10 (depending on specific type).
I'm not really too obsessed about the cost of these chips. We should
just go for it, imo. Really, the effort of building this thing, I
think, is going to exceed the cost of the parts. I guess that the the
state of the art chips would be around $300 for the main bits. I've
been getting the DDC's as free samples. Though they don't seem to give
out the ADC's. There are other problems. Does anyone know someone that
can make 4 layer PC boards relatively cheaply, in small quantities?
And, the other problem is that going to the better chips makes the
design trickier. This 'clock jitter' problem -- and just more bits
flying around faster and transmission line stuff. So, it's a
possibility, that even if we go for the newest stuff, we may not get all
the dynamic range that we're paying for.
If I go the the store and buy a satellite radio (IC-821, IC-910, FT-847,
TS-2000, etc.) and the data modems (PacComm, Symek IFD), I would have a
competent satellite station. However, I would be limited by the features
of the units I purchased. If we have an open hardware/software radio,
that could do all that the commercial equipment could do, plus new modes
and features continuously developed by hams around the world, I would
expect the price to be comparable to the performance and features. Even
though I would have to build it from a kit, the labour is a labour of
love and really doesn't count.
III. RF Section:
Each band requires only a relatively small amount of custom RF hardware. The front end is a simple low-loss trap to reject local transmit signals and nearby strong signals. As this is to be a specialist satellite RX, I suggest that it be a fairly narrow passband, centred on the satellite sub-band, and at the expense of the rest of the band. The reference design in design note AN-502 only has one (relatively low gain) element before the mixer, and I see no need to change this. This keeps internally generated noise to a minimum. For instances when the RX is used in a simplex mode, a "transmit" input is provided to disable the RF input via a PN diode. The dynamic range of the DSP system is quite capable of detecting a faint satellite signal, when a loud RF source is relatively nearby, so long as the RF parts do not saturate.
We should use what is available off the shelf: RX and TX kits from Down East Microwave
As messy as it sounds, I think on the analog side we might be better off using a rats nest of 50 ohm coax cables with RCA jacks on each end. Rather than trying to do a buss. At least with coax it's easier to understand what's going on. I'm scarred of sticking RF analog signals on a card edge.
Imo, the IF filters and the ADC should be close together. Just cuz' any noise that comes in after the IF filters is going to go right into the receiver. I guess we'd be okay sticking the various receiver front ends/mixers on separate cards, with RCA jacks and coax connecting them together. Maybe how it works is that you stick your receivers for 450Mhz/2Ghz/10Ghz up on your roof in little waterproof boxes. And then run 70Mhz down to the receiver using cheap coax.
The remote front end idea has merit, will certainly have advantages for those seeking the best performance, bung it in a box up the mast, and no need for a separate preamp. :-)
Optional computer controlled IF matrix switch to select different RF sections. Make it just like switching bands on an HF transceiver.
Should be pretty much a conventional RF strip, though would have to cope with the demands of many diverse modes (both analog and digital). Which suggests using a popular IF band for the SDR. The logical choices are 28 MHz and 144 MHz. I'd go for 28 - 32 MHz myself, as a minimum IF range, which is directly compatible with many VHF and UHF transverters. A wider range may be of advantage for people intending to move up to the microwave bands (e.g. P3D Mode L/S, or L/X, S/X, etc).
I like your specs, but I would like to see the following change: Instead of an IF frequency of28 to 32 MHz or 144 to 148 MHz., I would like to see BOTH IFs available. Most 1296 and higher transverters use 144 MHz. for an IF, while the common IF for 50, 144, and 432 is 28 MHz.
Dual IFs would permit the use of common VHF/UHF/Microwave transverters, and also make full duplex operation much easier. People who do not need both IFs could just eliminate the second IF freq., and add it latter on if their needs change.
This is a spec I really struggle with. Your right about the transverters on the market. Virtually all that I have seen are 28 or 144 MHz IF. With AO-40 now in orbit and looking like it will be in operation, I expect we will also see transverters with IFs of 430 MHz. The commercial satellite rigs all seem to have 144 and 430 as the two most common bands.
If we use 28 MHz, a transverter can be used to get to 144 MHz. A 28 MHz IF for both input and output would seem to offer the most flexibility.
An IF of 70 MHz has been suggested as better for A/D conversions. This adds to the project as RF modules need to be built. I would prefer to use as much already available components as possible. I think that a project of this magnitude already has enough work.
The other thing I worry about is interference from the output to the input. While an inverting transponder and doppler may help separate the signals for satellite operation, some people are interested in using the radio for weak signal or EME work. If the same band is used for both input and output, are we asking for problems or increasing the complexity of filtering and shielding. This may even be a factor in harmonically related bands.
I am really not sure what the best answer is. Perhaps 28 MHz for transmit, produced directly by the D/A converter and 144 MHz for receive, converted to an IF of 70 MHz, which is then fed to the A/D converter. Or is it worth the effort to use non-standard IF's and build the RF sections?
Well, the problem is we can't make filters as good as we can buy. And, the ones we buy are only going to be at certain frequencies. Take a look at this list, for example.... http://www.sawtek.com/products/comfqiniit.htm And, these parts are expensive, though I have seen them available in small quantities. Anyway, I think the effort of putting another stage if you really want to work with existing transverters, isn't as difficult as trying to find filters at oddball frequencies.
Use of exactly the same IF frequency must be avoided for full duplex operation. However, I have used a 144-148 MHz IF for both transmit and receive with no problems as the actual uplink and downlink frequencies in those bands end up being a few hundred kHz apart. Use of a 144-148 MHz IF for a 435-438 MHz uplink creates problems with the third harmonic of the IF which can only be solved by using a high-level (17 dBm LO) mixer with low level (-3 dBm) IF input. This is why all commercial 70 cm transverters use a 28-31 or 27-30 MHz IF.
IV. IF Section:
The receive IF oscillator only need to be a relatively simple design, as frequency shifting, fine tuning etc *could* be done in the DSP preprocessor, with a fixed frequency oscillator being theoretically possible. As a "nice to have" though (and given the big payoff in increased flexibility and low cost) a Direct Digital Synthesis (DDS) oscillator is used here, and is broadly the same for each band the RX is designed for, with slightly different programming and a different RF multiplier chain. A typical DDS has a resolution of better than 0.01Hz. The DDS is set by the main CPU.
I would like to see quite a high IF frequency, the AD6600 ADC is capable of handling input signals up to 500MHz (effectively the second IF is here, with the actual sample rate dictating the IF frequency). For RX frequencies other than 2M, 140MHz is not out of the way. The actual IF frequency is dictated by the availability of SAW filters as much as anything. The rest of the IF strip consists of a series of fixed-gain amplifiers, SAW filters and a variable gain amplifier driven by the AGC (optional). I have also included the ADC and DSP preprocessor in this section of the diagram to allow multi-band simultaneous reception. If this is not required, a single unit (AD6600, AD6620)could be employed, with a switched IF source. The ADC "digital IF" output should be approximately 20MHz, enabling a Nyquist bandwidth limit of around 10MHz.
Imo, the IF filters and the ADC should be close together. Just cuz' any noise that comes in after the IF filters is going to go right into the receiver. I guess we'd be okay sticking the various receiver front ends/mixers on separate cards, with RCA jacks and coax connecting them together. Maybe how it works is that you stick your receivers for 450Mhz/2Ghz/10Ghz up on your roof in little waterproof boxes. And then run 70Mhz down to the receiver using cheap coax.
Do you intend to find a way to direct digitize the 28 or 144 MHz IF. I do not think the current state of the art allows this with the dynamic range desired. So consideration must be given to the base band frequency for the A/D operation. The second or final IF. Are under sampling techniques to be used?
One saw quite a lot of studies that turned around a processor audio, used in last IF of weak value. I think that at the present hour it is necessary to use all IF possibilities of the DSP's, either to bring up the Sigma-delta in IF on 455khz or 100 khz, either to bring up some A/D's converters directly in 28-30 Mhz. All it is possible while using some Analog-Devices products, or Intersil, or Maxim. One must be able to have IF bandwidths commutables on the narrow values for the analogic, where on the larger values for the numeric transmissions.
If this is to be used as a high-end HF radio, then it will have to deal with a number of narrow-band signals with widely differing signal levels. The radio should then have a number of analog filters preceeding the ADC to minimize the number of signals to be handled by the ADC. Existing DSP HF radios have a 8-15 kHz bandwidth roofing filter at the first IF for this purpose. For satellite operation, IF filter bandwidths up to 2 MHz may be required.
The type of analog filter technology becomes becomes a limiting factor. LC filters can handle a very wide range of signal levels with little distortion. Crystal filters create in-band intermodulation products that are only about 68 dB down (and almost completely independent of signal level) so you don't want too many signals appearing within their passband. Does anyone know what the IMD characteristics of SAW filters are?
Frequency domain spurious responses, such as bulk modes and plate modes, are also present in SAW devices. There are simple techniques which SAW manufacturers can use to suppress these effects more than 60 dB below the desired output signal and these phenomena are rarely a limitation. However, there are several spurious frequency modes that you will find as you approach twice the center frequency. These spurious effects can be suppressed by impedance matching and generally systems have other "roofing" filters or reduced gain in the far frequency regions to negate their effects. Similarly, third harmonic responses are often present but seldom important, except when the SAW designer chooses to use those responses to achieve higher frequencies or improvements in other parameters. Then the spurious signals to avoid are below your passband frequencies and are managed in a similar fashion.
I looked at the Sawtek website a while ago. The bulk mode and plate mode are the modes that occur in regular crystal filters which are Bulk Acoustic Wave (BAW) devices. BAWs propagate pressure waves through the crystal. The Surface Acoustic Wave filters propagate waves on the surface of the crystal so the BAW mode is to be avoided as it causes spurious responses at frequencies removed from the intended filter passband. However, the intermodulation distortion (IMD) is created when signals within the intended filter passband mix together and create new signals at intermediate frequencies between the original signals. In BAW filters they are created by imperfections in the crystal structure. I haven't seen anything published on this aspect of SAW filters. It would be nice if they have less IMD.
The responses referred to (such as bulk and plate modes) are "linear" responses, not intermod products. Bulk mode refers to vibrations in the block of substrate (usually quartz or lithium niobate), as opposed to the desired surface vibrations. Anyway, it is intermod products that concern us. These can be especially bad when two strong signals are near an edge of the passband and generate an IM product inside the passband. In recent years SAW filter vendors have (a) become aware that this is a problem, and (b) improved their manufacturing processes to deal with the problem. They often will accept a spec on intermod performance. This also can happen in crystal filters, by the way.
In an analog radio the IMD is of little consequence as the passband is narrow and there are few signals in the passband. If we use a wide analog filter and try to do most of the filtering in the DSP we may find extraneous interfering signals generated by this IMD.
I have made a lot of SAW filter intermod measurements over the years. The technology has improved greatly in this regard. I have seen 3rd-order intercepts of +50 dBm or better, and reasonably well-behaved (i.e. distortion drops about 3 dB per dB of input). Vendors such as Sawtek have been willing to accept specs of at least +40 dBm 3rd-order intercept on at least some of their saw filters.
The Drake R8 receiver uses some interesting technology...it is a HF radio with a 45 MHz first IF and a 50 KHz second IF....they use an image reject mixer....IF filtering at 50 KHz is done with 9 or 10 millihenry pot core coils and shunt and coupling caps are switched in for various bandwidths....it takes lot's of juice to get distortion from a pot core...in the DSP form...the image reject mixer is replaced with the standard I and Q channels brought out independantly and then they can be filtered with the pot cores etc and fed into the A/D for processing....
Kachina uses more or less the same approach: 75MHz 1st IF and 40KHz 2nd + IF amp/agc then DSP. The filters are xtal type, 20KHz wide. Any other filter bw are done at DSP level.
The receiver should have various analogue bandwidth to reduce the problem of dynamic range of the A/D converter. The IF that is digitized should be as large as possible to cope with future high data rates. An IF of about 10 MHz should be o.k.. If the analogue bandwidth can coarsely be adapted to the wanted signal then fast A/D converters of less resolution can be considered.
Dynamic range is important. Here, our major problems are pagers on 148 MHz (up to 1kW EIRP), which cause all but the best commercial spec receivers to fall over in a mess of burps and farts. Even in the satellite band, the resulting intermods can be severe enough to impact reception in Mode T and B. Mode J has its own peculiar requirements, as the Rx is very close to the 3rd harmonic of the Tx frequency.
Achieving enough dynamic range also requires a clean LO. The LO phase noise floor needs to be less than -154 dBc to achieve the blocking dynamic range goal above. For SSB signals from P3D the close-in phase noise requirements are modest. 40 dB attenuation of adjacent signals translates to -74 dBc/Hz of phase noise at a 5 kHz offset. If the receiver is to be used for terrestrial SSB weak signal work add at least 40 dB. Adjacent channel rejection for 9600 bps FSK links should be 60 dB. This requires less than -103 dBc/Hz phase noise at a 25 kHz offset. The wideband spur level at the DDS output is around -50 dBc so it needs to be heavily filtered. If the level of multiplication is low and the loop bandwidth narrow, a single loop PLL will suffice (see March/April 2000 QEX).
Maybe to stimulate a little discussion, here's a naive receiver proposal --
that is without any real study of how good this is or how much any of this
costs.
1. DEM receiver boards. (144Mhz -> 28Mhz)
2. LC bandpass -
3. AD8343? Mixer + 42Mhz 28Mhz --> 70Mhz
3a. ??? LO (70-28Mhz)=42Mhz
4. Sawtek 851541 (20db insertion loss? Bleah.) 250Khz at 70Mhz
5. AD6630? Gain. (Picked randomly cuz' that's what's in the Analog
doc.)
6. Sawtek 851541 Again.
7. AD6600 (Which I believe has it's own mixer to go down to 10Mhz or
so.)
8. AD6620
9 DSP5636 Dev system of some kind.
40db bandwidth on the 851541 is 890Khz. So I believe this would reject at 80db down at 450Khz away from the center frequency. They have a number, 60db for 'ultimate' rejection, so I think this would be 120db down for stuff that's way out of band. Assuming there aren't any loud local stations near the P3D downlink, and maybe assuming a gain antenna, I think this might be enough. Hmm? Maybe use the 851539 128khz filters would work for a 100khz channel for digital.
Would we need an analog AGC stage? It looks like the AD6600 has 30db of AGC already in there.
V. A/D Section:
The A/D and DSP should have certain minimum resolution and capability. The A/D should be on the order of 20 bits or better resolution and linearity in order to improve on analog equipment. 24 bit resolution is a goal and should be included in the plan even if not economic and practical this year. I know that processing tricks can improve the apparent a/d capability but do not quit at 16 to 18 bits.
No mention is made of dynamic range requirements for the receiver. I looked over an NTIA spectrum survey for the LA area and it shows -27 dBm (S9 + 66 dB) peak signal levels on the amateur 70 cm band. If the receiver has a 1 dB noise figure, this is 120 dB above the noise floor in a 2 kHz bandwidth so the blocking dynamic range should be at least 120 dB. The receiver should also have at least a 90 dB two-tone dynamic range to prevent IMD from strong signals from polluting weak satellite signals. This translates to an IP3 of -12 dBm at the antenna. The amateur 13 cm and 3 cm bands are easier to handle with -75 dBm (S9 + 18 dB) and -73 dBm (S9 + 20 dB) peak signal levels. We will have more interference in the future. LA county plans to use 2400-2485 MHz for TV links using 20W transmitters flying aboard police helicopters.
I have thought through the dynamic range needs for the A/D converter and do believe that the need for 20 to 24 bit resolution and dynamic range at the Nyquist data rates will be confirmed by others.
I have wondered if a fast 8 bit A to D converter with accuracy at the bit edge points trimmed or perhaps calibrated to 24 bits does not do almost as well in the presence of random noise as a true 24 bits spread over the same dynamic range. This comment may be technically unsupportable but may lead to an interesting and useful discussion.
The Data bandwidth for the system is an essential specification. If you used the higher IF, perhaps up to video bandwidth would be useful. Perhaps not practical quite yet. Of course bandwidths would be set by the DSP algorithms. I do no know the modes that will be most favored for this system. The front end just needs to be linear, have high dynamic range, low phase noise and essentially just keep out of the way of the IF DSP system.
Existing 20 and 24 bit ADCs are limited to a 100 KSPS sample rate. This would limit the radio to 9600 BPS data if the IF is digitized directly or 38.4 KBPS if there the ADC processes the output of an FM discriminator. Since we want to demodulate using DSP the ADC sample rate will have to accommodate the IF filtering and demodulation process. For 256 KBPS PSK the I and Q channels must each be sampled at at least twice the data rate for a total of 1.024 MBPS. The fastest 16 bit ADC is the AD9260 which samples at 2.5 MSPS and has a maximum input frequency of 1 MHz. For 2.048 MBPS QPSK (1.024 M symbols/sec.) the sampling rate must be at least 4.096 MSPS. This limits us to 14-bit ADCs like the THS1408 (8 MSPS/140 MHz max.) or AD6644 (65 MSPS/250 MHz max).
The required precision of the DSP arithmetic depends on how where IF filtering and AGC is implemented. If the IF filtering is narrow enough to select a single satellite's signal (the entire passband in the case of an analog transponder) before the ADC and the signal level at the ADC is held constant via analog AGC, the dynamic range at the ADC is minimized and a 16-bit DSP is adequate. If this filtering is to be done by the DSP the arithmetic precision needs to be adequate to discern a weak signal in the presence of one or more strong signals in the IF passband. The dynamic range is limited by the ADC which generates intermodulation products when there is more than one frequency in the passband. IMD in inexpensive ADCs will be about -70 dBc. An expensive ADC will have IMD that is -90 dBc. The second limiting factor is how the arithmetic round-off error affects the ultimate rejection of the digital filters. The filters need to be better than the ADC but not by much. 20-bits of resolution is required for FIR filters to achieve 90 dB attenuation. A 24-bit fixed point ALU or a floating point ALU with a 24-bit mantissa would achieve this goal with a 20 dB margin. 24 fixed point is sufficient in this application as none of the inputs or outputs has more than 20 bits of precision. The only use that I have seen for more precision in DSP is for the implementation of IIR filters and these are inappropriate for data as they produce a group delay that varies with frequency.
Unless the signal level to the ADC is maintained at a high level, the A/D conversion and DSP will need to be in separate modules to prevent noise from the DSP and especially from I/O ports from polluting the IF. For example, a AD6644 ADC has a 5 dBm (1.1 Vpp at 50 ohms) maximum input level and a wideband noise floor 74 dB below that. Using a DSP to filter the signal to a SSB bandwidth, adds 44 dB of processing gain so the MDS is -113 dBm (0.5 uV). The ADC needs to be well shielded from noise sources.
Yeah, it'd be pretty scary to stick a soldering iron to one of these guys. Heh. The AD6644 is just an ADC. It needs the ad6624, before the DSP. I believe it's as good as you can get right now. They say it allows 25Mhz of spectrum to be digitally processed. I think this would be your receiver for CW or HDTV, basically. Maybe you receive 10mbps Ethernet through this sucker. (Though I think someone else pointed out that the speed of the DSP becomes an issue -- with a very lucid description of the problem.)
If the ADC is preceeded by a SAW filter that eliminates signals outside the satellite passband (250 kHz for P3D analog and digital transponders and 16 or 64 kHz for 9.6 and 38.4 kbps FSK) then its specifications are not critical other than having ample headroom (at least 20 dB) to compensate for imperfect AGC. The AD6600 would work well in this case.
If a wider band is to be digitized then the IMD level in the ADC must be as good as the dynamic range of the receiver. The AD6644 would be better at -90 dBc IMD typical. Undersampling also degrades IMD and SNR for the ADC. The last IF frequency should be in the HF range to allow oversampling. Going to a last (analog) IF below 1 MHz would allow use of 16-bit ADCs like the AD9260 which are even more linear with a typical IMD of -97 dBc and don't need a digital down converter chip to reduce the sampling rate to something that the DSP can handle.
The AD6600 combination would probably provide a better dynamic range than the 6644. It has on-chip gain ranging when combined with 6620. The use of digitally controlled pre-amps would help overcome the shortcomings of the ADC.
I've put a day's work into the sort of the plan I outlined before. That is a receiver with a 70Mhz IF, 250khz filter, and AD6600/AD6620. These are cheaper, maybe half the price of the 6644/6624. Mainly I'm just farting around with circuitmaker, naming all the pins, and doing all the easy stuff. I'd put some stuff on my website, except I haven't figured out how to export to a gif or jpg yet. The AD6620 needs some digital parts to program the chip and reset it and do all that, which I still have to figure out. I'm not even sure how far I'll get with this, but for me it's more fun to just dive into these things. And, maybe it would make sense, to start again with the 6644/6624 at a later point. Humph.
For the AD6620, the computer controller will need a parallel port to set the registers. Their eval board uses a PC printer port, and maybe that's an easy way to go. This is in addition to being able to talk to and program the DSP. The DSP will need to read in I and Q over a serial port. I'm not what kind of data format the various DDC's spit out, so it's possible, that whatever DSP code we write to work with one chip set would have to be changed to work with another DDC.
Actually, so far the hardware side of this doesn't look that complicated, but programming the coefficients might need some Ph.D. level brains. And, there are subtleties, in terms of how much ADC/DDC/DSP muscle do we really need to do any new mode that people might cook up. The manuals show these schemes where they cascade DDC after DDC to do more advanced stuff, but I'm not sure under what circumstances exactly this is needed. Btw, I don't see why these kinds chips couldn't do frequency hopping. Hmm.
I understand that the parallel interface to the AD6620 evaluation board has some electrical problems. May pay to check on this.
You may like to look at Intersil chips also http://www.intersil.com. Burr-Brown were releasing the ADS852 (14 bit 65MHz ADC) which claimed a better dynamic range than the AD6644 but no sign of it as yet. These chips are used in the digital IF's of mobile phones. As such they may prove "hard to get". I understand that the phone makers take just about all production.
I assume this DSP radio is to be an IF DSP. The fast AtoD for RF DSP may not be possible now for good performance at a good price.
VI. D/A Section:
Each TX RF block is similar in design, with a generic (SSB capable) PA block and standard filters. Provision is made for power level control by the main CPU. It is driven by a Direct Digital Synthesis unit such as the AD9852, which is capable of extremely precise amplitude, frequency and phase modulation, giving scope for some very exotic modes, and capable of a 300MHz internal clock rate, which gives an output signal to around 100MHz without any external multiplication. The data pump for this could be either the main control CPU (for relatively simple modes) or the DSP block, if dynamically shaped pulses are required. There is no reason why the TX (or RX) should not be Spread-Spectrum capable.
The D/A conversion does not need to be nearly as good as the A/D conversion. 16 bits is probably very good. We do not have the dynamic range requirement that the receiver does. This one needs more consideration.
The transmitter DDS needs to be implemented with an IF filter following the DDS. Although the spur level of -80 dBc for the AD9852 is OK within the satellite band (the P3D maximum analog transponder SNR is 30 dB) the spurs radiated in the weak signal portion of the band may cause problems for terrestrial weak signal operators.
The TX DDS is capable of generating any combination of AM, FM, and phase modulation. Whether it is capable of SSB or suppressed carrier depends on the design of the RX exciter unit. It is capable of generating shaped pulse waveforms for low-bandwidth operations.
VII. DSP Section:
1. Digital Signal Processors:
Initially designed for only one processor/RAM/ROM, many DSPs are
multi-processor capable. It would be a good idea to retain this ability
in the design, to allow for potential processor intensive future modes
(Digital TV for example). Equally, it is possible to feed a DSP with
multiple sources. Obviously different DSP designs have different
capabilities in these areas, which should be investigated. No thought
has thus far been given as to detailed architecture or specification.
Using Analogue Devices RF components does not necessarily imply using
their DSP.
If the receiver is to demodulate 153.6 kbps PSK or FSK the DSP will have
to be powerful enough to implement the required demodulation and
filtering. This requires processing at least 614.4 KSPS on the I and Q
channels with at least 25-tap FIR filters for predetection and
post-detection filtering and at least one division per sample to perform
FM demodulation for Pacsat downlinks. The 30 MIPS available in low-cost
16-bit DSP chips isn't enough to accomplish the task and 32-bit DSPs are
too expensive. The Motorola DSP5636x series seems to be the most
cost-effective and allows building on the amateur software base that was
developed for the previous generation DSP56002 (PSK31, SSB, 9.6/38.4
kbps FSK and other modes). It can implement FIR filters with 150 taps
processed per microsecond, do 6 million divisions per second and is
relatively inexpensive. It is also available in TQFP packages so it can
be hand-soldered if you are careful.
It has been given out of desires to use some Sharcs ADSP21065 to order
the system, it seems that it is at the present hour the best compromise
possible price/quality.
The DSP should be at least 64 bit mantissa plus floating point. Let us
not get hung up on optimizing into fixed point or other older DSP
technology. The newer stuff from TI and others is faster, lower power,
less external hardware and way cheaper than that available only a year
ago. The floating point algorithms are also easier to write than the
older optimized fixed point limitations. I hope that comment is not
controversial. Perhaps ease is dependent on the experience level of the
designer. We certainly are not much constrained by computing power now,
although getting high enough resolution analog to digital data fast
enough remains a limitation.
MBPS QPSK would require a very fast DSP or specialized DSP hardware like
the Intersil HSP50214/HSP50210 chipset.
The processor power should be as large as possible. You will never have
enough. It will be the bottle neck of the design. It is easy to record
all RTTY- transmissions on one amateur band at the same time or to
monitor many PSK-31 signals using a single older DSP, but only one
Pactor-2 reception requires the full power of a modern DSP in order to
do the Viterby decoding of the deep space code. We should consider to
have the possibility to plug in a second one. Also a powerful FPGA
should be discussed as a possibility to relocate special tasks to a
micro- programmed hardware.
I do not agree with the necessity of a 64 bit processor. I programmed
a lot of communication algorithms, and I definitely never ran into a
problem with the 24/48 bits fixed point of the DSP56k (but 16/32 bits
are not appropriate).
And, the other problem is that going to the better chips makes the
design trickier. This 'clock jitter' problem -- and just more bits
flying around faster and transmission line stuff. So, it's a
possibility, that even if we go for the newest stuff, we may not get all
the dynamic range that we're paying for.
As for DSP part, what about Texas Instruments DSPs. They have some very
powerful (and complex!) chips in the TMS320C6000 series that are used
for xDSL modems, I think...
2. DSP Development Tools:
I'm slightly concerned about the cost for development tools. That is
compilers and assemblers and stuff. Is there like a GNU C or assembler
for DSP's or anything cheap? Would people who want to code need to
buy their development system? How do the Analog/Motorola/TI DSP chips
compare from this perspective?
It looks like there's a smattering of free compilers and assemblers for
various chips. And these guys have what looks like a Gnu based
compiler for C3 and C4. http://www.elec.canterbury.ac.nz/c4x/
The only free development software that I have seen for a modern DSP
what is available from Motorola for the Motorola DSP56xxx series. The
Gnu software for the TI DSP doesn't cover the 320C6xxx series which is
the current generation of product from TI. I believe that the Analog
Devices development software requires purchase of an EZ-Kit at $100 for
16-bit fixed point and $300 for floating point.
I see no problem with running the DSP tools on an NT box that is totally
separate from the radio. The idea behind Linux is to use it as the
embedded operating system and not necessarily the development system.
Linux is able to emulate both DOS and Windows. Actually most of the
DSP56K work that is done in the ham community today is compiled on the
DOS cmd line.
The programming and debugging tools should have some weight at the
decision.
VIII. Radio Bus:
This design is based on a "black box" without any front panel controls as such. However, should it be desirable to produce a stand-alone design, the main processor has plenty of power to drive a colour LCD, rotational encoders, keypads etc. At the moment packaging isn't a consideration. I am loathe to use an open backplane given that the high frequency nature of the digital stuff. There is, however, a common bus to allow the Main CPU and DSP to share resources, and to allow multiple DSPs, but this is not essential. It would be possible to replace the control CPU by integrating the DSP and digital sections on a PCI card, but this would of course limit portability and make hardware debugging a nightmare. The architecture is not limited to 1 RX and 1 TX.
If we map the DSP board on a simple ISA bus interface the firmware can be upgraded from the Linux embedded control system. My idea is that the whole DSP board is mounted as a Mezzanine module with a simple bus interface and DSP specific interfaces. This will allow total flexibility and future upgrades!
Don't limit the device to ISA-only. I have already encountered this with L.L. Grace and their Kansas City Tracker. Granted, it's a wonderful device, but I have requested information on a PCI interface and they said they have no plans to engineer one. In this day and age, if you limit yourself to just one technology or the other, you may shut the door on some who may be really interested.
We have now seen ISA come and go and PCI may also not stand the test of time. It all depends on how much influence Bill Gates has over future standards.
This can be a good idea, but implementing a PCI design is not trivial. Also the form factor of a half or full length PCI card is not particularly suitable for a portable system. If we need a bus interface I would propose PC/104 (that is ISA in a different form factor).
If necessary, maybe the digital part of the system (digital RX, DSP) could be built onto a PCI card, with the analogue parts in an external case. I'm certain the AD6620 can spit out either analogue or digital data (see the data sheets). Equally, the Analog Devices DSP (and others) can read either format.
If you look at the control of the ADC, DDC, DSP they probably all need to be hooked up to the cpu in some way. I think is It is much better to define a layered structure with standardized bus interfaced on the bottom layer. If you look at products on the market today, you will find that many professional products are built this way. The reason why is that everybody wants to have flexibility and not having to start all over or add a temporary rats nest solution if one component becomes obsolete or if you want to add one more module.
It is a fair question to ask if USB could be used for module interconnects as well. Perhaps the newer high speed USB presently being introduced would be fast enough to achieve the reduction of parallel interfaces to the simple serial shared bus.
IX. AF Section:
Optional audio input and output. Input levels at standard microphone and line levels. Output levels at standard line, headphone and speaker levels. The optional audio encoder/decoder to encode audio to PCM stream or decode PCM stream to audio. Without this option, the audio would be encoded/decoded in the sound card of the computer.
I feel there is room for both on board DAC and PC based decoding. On board DACs are useful where the rig needs to run relatively independent of a PC - a standard audio chain can be used to drive a loudspeaker. Digital I/O adds flexibility for those who integrate their PC with their radio.
For regular SSB, CW, FM and AM work is should have normal speaker , key and mic functionality.
X. Control Processor:
1. Requirements:
For the AD6620, the computer controller will need a parallel port to set
the registers. Their eval board uses a PC printer port, and maybe
that's an easy way to go. This is in addition to being able to talk to
and program the DSP. The DSP will need to read in I and Q over a serial
port.
Would highly recommend the software be fully replaceable via upload of a
new improved software system, with a default version onboard, and
hardboots run of the firmware. This would give the safety of defaulting
to the blast off firmware, but allow as needed uploads of improved
filters, software mode support, et all. Has manageable risk, but
extreme flexibility.
The choice of the booting hardware is a good question. ROM, Flash RAM,
Disk on a Chip, etc? I think this may also tie in with with the need
for a control processor. Or does it?
I would guess at ROM for the boot (Hard ROM, not eprom), and fall back
mode, and then a RAM loadable running section. Fall back mode, also
low power would be the if something happens mode, and in many years
time, the probable mode it would operate in as the system fails.
For PR purposes, a portion of the software could be uploaded by any ham,
staying resident for say 20 minutes, then reverting to default. This
would allow a large range of experimentation on DSP filter design,
allowing many to upload filter designs, and test the designs against
actual operation. PR from the standpoint, that digital modes, if
relaying, could append a small trailer, like, "SAT XYZ - filters by
KF8JW - Program by VE7CLA - 0014Z", for example.
I second the notion that the firmware should be field upgradable.
Regarding the choice of boot hardware, I wanted to comment that since
the radio will in some way be connected to a computer, the original
"blast off" firmware could reside on the computers hard drive,
downloadable when the user/experimenter wants to revert back to it. The
embedded DSP system would then only need some mechanism (perhaps as
simple as a push button on the circuit board) to invoke the download
algorithm. (I thinking here that the firmware experimenter has managed
to really hose up the on-board firmware and needs to get back to
something that works). This would eliminate the need to keep the
original firmware on board somewhere.
2. No Control Processor:
The control processor can and should be outside the DSP radio,
interfacing via the USB, IRDA, or Ethernet. The optional control panel
should use this single interface as well. The dsp radio should not
include a significant control processor except to the extent needed to
run local switching functions and handle the interfaces and define the
interface protocol. The control program should run in the external
processor, control panel or pc.
The idea of the control processor is one I wrestle with. Having one adds
to the complexity, and as you mention could also be a hindrance with
the DSP compilers. Perhaps a separate developer's interface to the DSP
might be an option.
The DSP-10 project addresses analog satellites and so do products from
Kenwood, Icom and Yaesu. It seems to me that the main purpose of this
project is to build a radio that is capable of operation with high-speed
digital satellites. If this is true, then most users will have a very
powerful control processor with an existing development environment in
the form of a PC running Windows or Linux. I don't think that we want to
replicate that environment as it complicates development and adds
considerable cost but no benefit for most users.
3. Minimal Control Processor:
The standard control processor should be limited to interfacing the DSP
to the PC. All it needs to do is transfer data to and from the DSP and
facilitate the use of the JTAG port on the DSP for debugging. This can
be done with a few KB of code on a single chip MCU and no operating
system. In fact, the host interface port on most DSPs could hook
directly to a parallel printer port with the addition of a few buffers.
The operating system that is most important is the one that runs on the
DSP. A simple monitor program, like LEONID (developed by Finnish hams)
may be all that is required in the DSP. Drivers then need to be
developed for Linux and Windows that support the existing development
environments on PCs and Macs.
The reason I included a separate control CPU in my design was to
off-load the non real-time tasks from the DSP. Tasks like communicating
with the host PC via RS232/USB/IEE1394, setting up the various digital
chips, packet reassembly, accurate carrier frequency tracking and
basically anything thats isn't directly DSP related. I think that having
the ability to run X-Windows, a web server (to generate html pages) and
so on is introducing massive complexity and could more easily be
relegated to the host controller. An html or X-Windows interface would
limit any external communications to machines that have the appropriate
interfaces.
I agree, there's a lot to be gained by putting a fair amount of
"intelligence" on board. Still, for 99% of the control functions
required, the processing power of the controller would not need to be
too great.
I'm not sure why a powerful "main" CPU is needed. It may not have that
much work to do. A better approach may be a small housekeeping processor
to control the DSP during booting and debugging. The PC connected to the
DSP can handle non-DSP tasks like error correction and data formatting.
4. Full Featured Control Processor:
a. Processor:
An Intel CPU would be the obvious answer, given the availability of
compilers etc, but I lean towards a cleaner, more open design such
as the Motorola 680x0 and similar, with linear address space and a
clean architecture. Open source cross-compilers are freely available
for these. I do not envisage an Operating System as complex as Linux,
although it remains a possibility. I am aiming for a ROM capacity of
around 1 MB and RAM of 8MB or so. This seems small in modern
(Microsoft Windows) terms, but at this level is pretty large. It is
desirable to use DMA channels to move data around.
If we use device drivers - we have a layer model. It will be very
easy to change processor and processor hw. architecture in the future.
Control processor to control radio operation, and interface to user.
This serves two purposes, first to offload all control functions
from the DSPs, and second to abstract the control functions. The
control processor is to be capable of executing the 386 instruction
set.
A control processor could provide a stable layer of abstraction,
allowing the use of different DSP chips, and minimizing the code
needing to be rewritten if the DSP was changed. It could also provide
a great platform for experimentation. For example, the radio could
be remote controlled over the Internet. A virtual private network
could be established between the operator and the radio using
software that already exists. In this case a front panel would not be
needed. No need to write code to implement IPsec on the DSP. Or how
about the radio tracking the sats and doing doppler correction on
it's own. Or how about accepting Kenwood, Icom, and Yaesu commands to
allow the use of your favorite logging software. In a stand alone
configuration, how about automatic logging, or displaying satellite
coverage maps.
The control unit could control many modes, and modules.
The '386 control processor running Linux that is embedded in the
radio should be an option that goes with the control panel rather
than a required feature.
There are several manufacturers that make silicon disks with no
moving parts that look just like an IDE drive to the system
controller. The problem is right the high cost of flash. You could
also use lap top hard drives, since the can take a lot of punishment
and are cheaper. Of course, power considerations need to be done.
If a self contained radio is desired, a powerful main CPU could do
some interesting things besides the user interface, such as satellite
tracking and display, antenna control, doppler correction, logging,
remote control, etc.
The PC/104 platform may be a very good option here. It is somewhat
standardized in size, shape and function, and it is available from
several manufacturers.
Info on the PC/104 platform can be found at www.pc104.org
b. Operating System:
An embedded version of Linux is to be the operating system.
I love the idea of Linux as the OS.
I also agree that embedded LINUX or a real time derivative, such as
QNX, is the way to go.
Linux provides an open environment with free development
tools that could generate some interesting applications.
The operating system should not be processor specific. It should be
transparent to 386 or better. While Linux may be the best available
choice perhaps the interfaces to the operating system can be defined
so that the specific operating system can change with time. Also
keep in mind that we need to be able to handle the DSP compilers
available from the major DSP manufacturers (TI, AD, Mot). Will Linux
support them without requiring new Linux specific implementations?
The only problem is for those people that would want to run their
PC-based operation on MS-Windows, but perhaps this can be accommodated
on this platform as well....
I think there's a bit of confusion here. The use of Linux is not for
the "end user apps", but as the embedded OS that the inboard control
processor would run on. There's no reason why the radio can't be
interfaced by any means compatible with existing Windows based apps.
Most users wouldn't even notice the Linux OS inside the rig, it'd
just be another device to hook up to the PC, and use like any other
computer controlled rig/TNC/whatever the device will look like
today. :)
You still can operate the radio via your preferred interface. The
Linux OS in the radio is not even talking to a VGA display to save
cost. We could install a tiny web server on the Linux system
controlling the radio. You could then control the radio from your
favorite web browser running on your Windows machine. If we were to
run Windows on the radio, we would have a cost problem since MS is
sensitive about licensing.
I actually meant that the Linux embedded computer should be part of
the DSP radio. Then you could attach it to a number of different
computer systems. You could also do software upgrades via serial,
Ethernet, USB etc.
With the structure below you can add as many units as you want, you
can do Linux standard system calls to talk to your devices, you can
run statistics thru the Linux stats, you can easily port your code to
other platforms as NT, 2000, 98, QNX etc, and you can easily have
several developers working on a project in parallel. It is also much
easier to make a network enabled device.
Graphical or text based user interface
##################################################################
Control software
##################################################################
Linux kernel
##################################################################
ADC - DDC - DSP device drivers
##################################################################
ADC - DDC - DSP ISA bus decoders (simple one chip ISA decoders !)
##################################################################
ADC # DDC # DSP # hardware
##################################################################
Analog interfaces
##################################################################
It is possible to purchase X86 (AMD SC410 based) computers that cost
as little as 100 GBP + that can run Linux in a stripped
configuration. We are probably looking at a relatively powerful
computer to do what you describe above. A typical microcontroller
would probably need external RAM and FLASH. If we do some cost
comparison, I that think we will find that the cost of a uC system
compared to a stripped down X86 system with Linux is not that much
different. With Linux we get really good software development tools
for free. Also the modularity is built in. Implementing e.g. USB on
a uC is not a trivial task. On Linux somebody else has done it for
us, and the source code is available to modify if needed.
Depends what features you want to be able to incorporate in the long
term. I suspect the main OS (which controls the UI) will be one of
those beasts that evolves as people get into programming the system.
Having a bit of "spare capacity" here allows software experimenters
to let their imagination roam free.
The fact that it runs a Linux kernel would give you support for both
modes of operation (PC-based or self-contained) with the same
software (or maybe a stripped version of the software for the
self-contained option).
A job for the software people :o) Talking of which, I think an
embedded PC type controller running Linux might be overkill. For all
that it is a respected OS, it is complex and restricts the number of
available developers. A more minimal custom OS with a restricted
number of library modules would reduce development complexity. It
would need to be capable of real time operation and fast
communication with the DSP units and TX/RX modules.
In my opinion, Linux running on a small low cost embedded PC module
is an ideal platform. Nowadays it is very popular to use embedded
PCs instead of microcontrollers since the cost has come down
dramatically, and the software development tools are much better.
The performance is also much higher with this approach.
Linux can easily be adapted to run from 2MB of flash and some MBs of
RAM. With special tweaking of the kernel, libraries and other files,
these figures can be reduced considerably. Linux is free, open
source and has a very good TCP/IP stack built in. It can boot and
display to a serial LCD module, and simple matrix keypads can be used
for the user interface.
The use of Linux enables several developers to work on this thru CVS
version control system. Drivers can be written for our hardware so we
are processor independent. A perfect fit for the HAM community.
XI. Computer Physical Interface:
1. Serial (RS-232, EIA-232, etc):
Standard speeds supported to at least 115,200 bps. DB-9 connector.
Most PCs now support 230.4 KBPS and this will be valuable to support
153.6 KBPS PSK/FSK demodulators.
For me, serial is the best. USB will rely on me doing a major Win2k
upgrade. However, that is highly likely by the time the project comes to
fruition, so it may be a moot point in real terms.
I hope the DSP-RADIO only needs a serial port.
Something I'm curious about is how many of the new computers don't have
a serial port? My IBM Aptiva has both. Also - is there a USB to serial
adaptor available that would allow somebody with a USB only computer to
use the backwards compatible serial port?
I have USB to serial converters that I use all the time.
The user interface should be a serial port or USB port.
There is no problem to install an USB to serial adapter on PCs that
have only USB. These are readily available from a number of sources.
The prices has come down considerably.
In the spirit of "you have to start somewhere" I'd go with a serial
port. You could then run it in RS-232 brain-damage mode and talk to it
with a terminal program. You could also run PPP over it and do IP stuff.
A simple serial interface will be required for access by older systems,
dumb terminals or some portable devices. Sure, use USB when it's
available on the host system, but the simpler serial interface is still
more "universal".
Someone raised the idea of USB interface. I'm in two minds about this.
USB offers some nice features, and is going to be around a while, but
there are still a lot of legacy systems in ham shacks all over the
place. Perhaps USB for full functionality (including high speed data
from the radio), but a cut down serial interface available for basic
command/control and low speed data?
Anything with an RS-232, or USB/Firewire link. Bearing in mind that
RS-232 can only handle 115kbit/s at most, and handheld devices are
generally restricted to 9.6kbit/s, transmission of audio sampled from a
source other than the optional internal ADC would require a relatively
fast source. Making RS-232 the only digital connection would compromise
maximum data rates.
2. Universal Serial Bus (USB):
I agree that USB looks like the way to go for the external interfaces.
I have been a heavy user of multiple serial and parallel ports. I
reluctantly started using USB and find that the world is becoming
simpler. The interface is not as transparent as the old serial ports
that I understand, but I now think that it is the way to go for
interfaces.
Perhaps the newer high speed USB presently being introduced would be
fast enough to achieve the reduction of parallel interfaces to the
simple serial shared bus.
I would estimate that a USB or Firewire connection would be noisy as
well.
The user interface should be a serial port or USB port.
Microchip recently introduced a family of two one-time programmable
(OTP) devices supporting the USB 1.1 low-speed interface. The
PIC16C745 and PIC16C765 8-bit microcontrollers feature a software
detachment mechanism that allows the peripheral to remove itself from
the system without removing the cable.
Sure, use USB when it's available on the host system, but the simpler
serial interface is still more "universal".
Someone raised the idea of USB interface. I'm in two minds about this.
USB offers some nice features, and is going to be around a while, but
there are still a lot of legacy systems in ham shacks all over the
place. Perhaps USB for full functionality (including high speed data
from the radio), but a cut down serial interface available for basic
command/control and low speed data?
USB is the best way to connect to the PC as it is readily available at
little or no cost.
It is also easy to daisy-chain up to 256 USB devices which can be
plugged while powered up. USB will undergo changes soon as speeds
increase and the USB and Firewire standards come closer together.
The USB/Firewire concept is a good idea. I guess we will see more ham
radio equipment with USB in future.
I like USB. The kachina and Pegasus use serial ports. The serial ports
are not as fast as USB and USB can be expanded.
I would weigh in for USB control. Very powerful. Currently in vogue.
3. Firewire (IEEE1394):
I would estimate that a USB or Firewire connection would be noisy as
well.
My techish son suggests Firewire, about which I know very little except
it's suppose to be really fast.
USB will undergo changes soon as speeds increase and the USB and
Firewire standards come closer together.
The USB/Firewire concept is a good idea. I guess we will see more ham
radio equipment with USB in future.
4. Ethernet:
Auto sensing 10 or 100 BaseT.
A good low cost network interface like Ethernet all sorts of things
could become possible.
Ethernet will give a networking possibility that can support Voice over
IP functionality over UDP connections. This can be routed much easier
than USB traffic.
I'm partial to the Ethernet interface as it allows easier remote
connectivity.
While Ethernet would be the best interface, we may have to consider a
secondary interface such as InfraRed and/or PPP over a serial link. Many
of the new processors designed for "IP appliances" have these features
already. Think of how easy and convenient it would be if every piece of
equipment in your shack had a standard Ethernet port and all you had to
do was point your browser at the piece of equipment you wanted to
control.
The data output could be thru an Ethernet connector if we need to
assign an IP address.
An Ethernet interface (10 or 100 Mb) would, I suspect, be electrically
noisy. All those nice square waves.
5. Infra-Red (IR):
6. Parallel port:
The host interface port on most DSPs could hook directly to a parallel
printer port with the addition of a few buffers.
7. Interface Modules:
I/O Module: This is the "catch all" bit. It includes the audio DAC
(more than one is possible, enabling multi-channel audio) and ADC (for
that funny old mode called "voice"). This section also encompasses
external communications via RS232 (for initial testing and debugging)
and a faster system such as IEE1394 "FireWire" or USB. RS232 is simply
not fast enough for advanced communications. Data is fed to these via
the DMA channels. This section would also take care of any panel
controls (LCD, keypads, rotary encoders etc).
Perhaps build in serial and the rest as add in cards.
Why not use plug in modules to provide the computer interface. This way
it would be up to the individual to choose the interface desired. Why
not even allow two or more interfaces to be installed.
I'd suggest multiple PC interfaces, they being USB/Firewire and serial.
The USB option is the more modern, and offers the potential for
offloading some processing to a host PC (e.g. using the radio as a DSP
modem only, and interpreting the data in the PC, for some modes).
Serial offers compatibility with more devices, including older PCs
(there's a lot of those in ham shacks) and dumb terminals/portable
devices. Down the track, other hardware developers may design other
interfaces, such as infra red, as need/interest arises.
XII. Interface Points:
The key would be to thoroughly define the interfaces between the RF and the IF section as well as the interface between the IF and the User Interface section. This would give a lot of flexibility to each designer to work on an RF or an User Interface section.
Use Kenwood, Icom, or Yaesu commands to allow the use of existing software.
XIII. Front Panel:
Optional front panel with display and control knobs and buttons. Use a standard VGA LCD, optically encoded knobs and momentary contact buttons. All controls to be software definable.
What about looking into making a kit for a complete compact integrated box that would use a laptop screen, or maybe one of the smaller word processor screens, a open OS like Linux that could be use as a development platform for SDR and one of the nice full spaced compact key boards.
XIV. Miscellaneous Hardware:
The power supply should be a non-switching / linear supply, to reduce potential interference.
The DDS, ADC and DAC need precise, low-jitter clock sources. Facility for a GPS-derived signal source is desirable.
A control board to control rotators, polarization switching, preamp and power amp switching.
XV. Hardware Construction
I strongly believe that a box like above could be put together using many off the shelf laptop parts to keep the cost down. The main problem as I see it is buying the parts in bulk. I belive TAPR might be in a very good position to help with the kit supply. They have a long history of making all sorts of kits and by providing a central source for the kit parts TAPR could really help make my dream come true.
This kit would also make a great project for science class in schools Etc.
Did we get it all!
There you have it!
73 Simon GM4PLM