Duane - N9DG wrote:
With the various talk and efforts toward multiple SDR-1000's
all being driven form a single machine I think that it would
be nice to be able to buy a simpler monoband board stack
version of the SDR-1000 (perhaps call it the SDR-1000MB??).
Essentially make a simpler board to put on the stack to
replace the BPF/PA and RFE boards. Or perhaps more accurately
combine the functionality of those two boards into one. This
single board however would not bandswitch for different bands
but instead would be set up with a single frequency range in
mind (or use plug-in filters perhaps). This new monoband
board would still provide low level TX out and RX gain just
like the BPF/PA & RFE boards do now.
I would envision such a configuration being somewhat popular
with VHF+ transverters users who want to have 4, 5, 6 or more
of them dedicated as drivers for their transverters. I would
think that such a SDR-1000MB configuration could be marketed
for something in the $400-500 region including a case. At
that cost the idea of dedicating a small fleet of these
SDR-1000MB's to transverter use would be very compelling and
down right competitive cost wise to those all bands in one
box radios. This especially true once you factor in how much
more capable this fleet of SDR-1000MB's and transverters
would be than the typical all bands in a box radios are
today.
W0VB is the expert here, but in my limited experience, two HF models
might suffice -- one for 20 meters and one for 10 meters. Add one more
for 2 meters, but we already have Down East Microwave's solution there.
Anyway, the transverters I know about start with one of those three
bands. Perhaps others are sometimes used, but I haven't seen it and
maybe it could be ignored in the interests of economy unless the HF band
choice is a "daughter card" that gets plugged into a common design.
Regardless, this is part of a theme I've been thinking about and would
wish to talk about at Dayton. I know others are doing the real work,
but it would seem to me that we would want to make sure the software
structure develops so we can drop in this idea, Phil's ideas, and other
radios to be designed later. I'm not sure where this all stands, but it
seems to me important to future hardware development of all kinds that
this be done right.
Hopefully, this is already taken care of.
For instance, my idea in the forum was for a very portable, digital
only, small radio. The idea would be, you'd take a small laptop (maybe
even one of the faster 386 style PDAs) and put a very small, digital
mode only radio on the other end of a USB cable. The emphasis would be
on small size (e.g. the size of my fist) and good QRP functionality.
Something you could imaginably backpack. It would have Phil's PIC chip
in it, or some modern 8048 derivative, so it would be a little more
functional than the base SDR of today and so could expect to use the
laptop and/or PDA's simpler sound card in what we have today as the
"second" such card. Very, very portable is the key.
This digital only solution could then be taken to the nearest big hill
and used to work QRP, as is often done with the K1. Imagine a
backpackable PSK31! And, then you switch to CW.
Another product idea would be to have an "add on" box that includes a
micro and an approved Flex sound card. This add on box would take over
the parallel port and the various stereo cables of today (that is, it
would plug into them). It would export a USB cable. This would allow
hardware dummies like me to not have to deal with the complexities of
the dual sound card. (It would all be hidden away by the one or two
official sound cards Flex would support and hide in my imaginary
product, taking whichever of the ones I selected). I'd just hook up the
USB cable and that's it.
It doesn't really matter of Flex ever does these things. What matters
is that whatever Flex decides to produce, we can reuse upwards of 80 to
90 per cent of the code, higher if possible, even if the underlying
radio is very different. E.g. has a PIC using a VXO or something
unexpected like that versus my box add on idea and yet it hooks up to
our CAT interfaces and our designed input / output streams so that the
GUI and filtering code doesn't care about the radical change in
underpinnings. And, too, if we want to leave the PIC kind of thing out
sometimes and have simple switches to toggle -- allow for that, too.
Somethings, like D/A bandwidth differences, couldn't be hidden. But,
the vast majority of it should be able to be completely covered up.
Even the D/A bandwidth could be fairly simple if we took it for granted
that there were ever only going to be a few sizes -- 44K and 192K are
already magic numbers. How many more would we need? How many future
hardware solutions couldn't be adapted to one number or the other? We
can cope regardless, but limiting the bleed through will only help.
If, that is, we structure the software so that we can plug-and-play any
of these product ideas, with or without Phil's micro in the mix, maybe
with or without Phil's D/A solution in the mix. I think it can be done,
but that will be something to test in Dayton. My basic idea would be
layers of this sort:
Network/GUI capable layer. The radio can be remoted and/or dealt with
via GUI. Third party programs (e.g contesting software) can be
surrounded with supplemental code (e.g. to control the UCB or simply
know about transverters downstream). Fully integrated consoles (that
know about everything, including amps, transverters, and send/receive
antenna combinations) could all be managed here.
Model Independent layer. For the PIC/micro driven hardware, this would
be the direct interface software (and CAT) would see. The radio is
basically akin to a printer still, albeit one more like a Postscript one
than an ordinary one. At this level, it is strictly a device, but it
looks the same no matter what's underneath it. Data streams (digital
and analog, prefiltered or not for digital) are all well-defined and
provided at this layer. It would also deal with the potential for
multiple threads/programs in the Network/GUI layer above to be
contacting it. This would allow fully integrated consoles and
"piecemeal" solutions where (e.g.) contesting code could be supplemented
a bit for UCB control and like items. It would "export" something that
looks a lot like today's SDR 1000 with CAT and also the UCB control
architecture.
Model Dependent layer. For radios with more simple underpinnings (no
micro), this is the interface that is defined. It is idiosyncratic and
the main item on the menu is control software that runs the switches and
turns on the blinkin' lights. On its "upper" end, it provides/links up
with the Model Independent layer. The main difference is, it resides in
the PC instead of on the other end of (usually) a USB cable. For
products that provided the micro, this is what would be embedded in its
firmware.
Larry WO0Z
