<br>

<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Date: Sat, 13 May 2006 08:40:30 -0400<br>From: "Philip Covington" <<a href="mailto:p.covington@gmail.com">

p.covington@gmail.com</a>><br>Subject: Re: [hpsdr] What can we do with 2 cards<br>To: Alex <<a href="mailto:harvilchuck@yahoo.com">harvilchuck@yahoo.com</a>><br>Cc: HPSDR List <<a href="mailto:hpsdr@hpsdr.org">

hpsdr@hpsdr.org</a>><br>Message-ID:<br>        <<a href="mailto:32aa05ee0605130540s3c121627wd03bd7f07c3f1229@mail.gmail.com">32aa05ee0605130540s3c121627wd03bd7f07c3f1229@mail.gmail.com</a>><br>Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 5/13/06, Alex <<a href="mailto:harvilchuck@yahoo.com">harvilchuck@yahoo.com</a>> wrote: > I'm going to bring up my question from earlier. > > > Why not move the parallel port DSR-1000 control onto JANUS?

<br>><br>><br>> Then we have a 2 board solution (plus the backplane). SDR-1000 users can take advantage of other cards like:<br>> GIBRALTAR -  to provide the 10MHz reference signal to the SDR-1000<br>> SASQUATCH and the it-who-is-not-named gp I/O board  - or computerless SDR-1000 operation

<br>> (the gp I/O board can also replace the UCB).<br>><br>> My vote is not to regress the OZY design, but to put the SDR-1000 interface system requirements onto JANUS.<br>> I know one argument put forward was:

<br>> Why send the SDR-1000 control commands down the ATLAS bus, deal with them at the OZY.<br>><br>>

Well, since we're going to have to handle other i/o commands coming

from the host computer and sending them to the gp I/O card, why not let

JANUS deal with the i/o for the SDR-1000.<br>><br>> I am advocating to not assume SDR-1000 will always be "state of the art", but nor to ignore that installed user base.<br>>

The current card interfacing structure of the SDR-1000 leaves lots to

be desired, the HPSDR can provide a good platofrm for expansion.<br>><br>> No, I don't own any SDR-1000s<br>><br>> We need to keep thinking everything through so the HPSDR will meet the requirements from the two interest areas:

<br>><br>> (a) SDR-1000 upgrading<br>> (b) HPSDR as a full-up SDR itself (and as a real neat and useful generic benchtop device)<br>><br>> Those are my 2 cents<br>><br>> Alex, N3NP<br><br>Yep, we really need to decide whether our primary goal is to support

<br>the SDR-1000 or whether we are buiding or own SDR.  The answer should<br>be obvious...<br><br>With that being said, I am trying to accomodate everyone's wishes as<br>best as I can in the OZY design...<br><br>73 de Phil N8VB

<br>

</blockquote></div><br>

If I understand Phil's comment correctly, we are trying to build our

own SDR. However, given the issues of minimum builds and parts orders,

cost/volume curves, etc. it seems reasonable to view support for the

SDR-1000 as a practical way to facilitate getting to the final goal. I

suppose then that each design change requests for SDR-1000 support has

to be weighed in terms of how much deviation from the final goal it

causes, how much it costs, etc.<br>

<br>

FWIW - I think that a parallel port is/should be simple enough that it

shouldn't disrupt the overall architecture regardless of which board it

is put on. I find the requirement for a parallel control port a

significant deficiency in the SDR-1000 design. The radio should be

controlled using a USB port, and I have heard that a newer, more "open"

USB to parallel cable will be offered by Flex-Radio soon.<br clear="all"><br>

73,<br>-- <br>Larry Gadallah, VE6VQ/W7<br>lgadallah AT gmail DOT com