[Mep-dev] Conceptual Block Diagram for review

[Roger Thompson]

I may be unnecessarily bound by current terminology regards the term LNB.
DSS type LNBF conversions only drop the signal to around a Gigahertz.  Older
C-Band big dish units went to 70 MHz, I think.  The point is there probably
needs to be a final down conversion to something in the range current
reasonably priced A/D can handle, maybe less than 40 MHz.  The stability and
LO noise requirements for the down conversion probably need some attention,
but there are millions and millions of microwave digital video receivers
working today with bandwidths like these or greater, so it can't be that
much of an issue.

Would adopting standard TCP/IP between the system components enhance the
flexibility of the design?  

As to the remote operations, I'd expect network bandwidth would fade as an
issue over the next 5 to 7 years for "cloud" operations, and more local
operation using short range wireless, coax or fiber would be facilitated
today with local power options.  I'd think being able to plug the outdoor
unit, indoor unit, and controlling PC into just any of my Ethernet ports
should work somehow, and that's the reason for the remote power comments
because there are switches and routers involved that don't necessarily
support POE.  

If cost, development resources, or other considerations limit initial
configurations and capabilities, a more generalized and capable design
framework would allow for future enhancements to be made in a more directed
manner.

-----Original Message-----
From: mep-dev-admin@uppermeadow.com [mailto:mep-dev-admin@uppermeadow.com]
On Behalf Of Paul Williamson
Sent: Sunday, November 02, 2008 7:58 PM
To: mep-dev@uppermeadow.com
Subject: Re: [Mep-dev] Conceptual Block Diagram for review

On Sun, Nov 2, 2008 at 5:25 PM, Roger Thompson <rogert@traceroad.net> wrote:
> May need a down converter shown between the 5.6/3.4 GHz receive LNA/LNB
and
> the A/D due to the frequencies and bandwidth involved.

Maybe I'm misusing the terms. I thought the difference between a LNA
and a LNB was that a LNB had a built-in block downconverter. By
specifying LNA/LNB I meant to imply that a downconversion might or
might not be required.

> Local power options for the remote would allow for non-metallic Ethernet
> connections, facilitating far remote operation.

Bandwidth might or might not allow that, and there are other
considerations. Latency jitter, for one thing. If you try to run the
indoor/outdoor link through any kind of network cloud, a lot of things
get complicated and less reliable. I don't think that really makes
much sense for this application. In particular, I didn't envision that
the outdoor unit should be smart enough to be a full internet node, or
even that the indoor/outdoor link would necessarily be standard
TCP/IP. Ethernet is just a handy physical layer here, with sufficient
bandwidth (?) and readily available interface hardware. Sending power
over Ethernet is just a bonus, if indeed it turns out to be capable of
supplying enough power.

If you wanted remote operation, you'd put more than just the outdoor
unit at the remote site, I think.

> Likewise, generalizing the user interface/PC to a generic Ethernet
> non-metallic interconnection would allow for remote "indoor unit"
operation.

I don't think I understand you here. Could you clarify?

If we end up building hardware to run the signal processing parts of
the indoor unit, then we'd need to select a data interface to get
application-level bits in and out. I'd favor Ethernet for that,
because it's cheap and because interfaces from Ethernet to just about
anything else you might like are readily available.

If the signal processing stuff ends up in a generic PC, then whatever
network hardware that PC has should be fine. If it's the same PC
that's running the user I/O (camera and screen in the diagram) then no
interface at all is needed.

This kind of hand-waving is why I call it a "conceptual" block diagram!

> Multiple "outdoor units" on one "indoor unit" or one "outdoor unit"
> controlled by multiple "indoor units" should be feasible and perhaps the
> designs could generally address this sort of deployment.

Processing horsepower might be a problem, but it would be good to
leave that option open.

73  -Paul
kb5mu@amsat.org
_______________________________________________
Mep-dev mailing list
Mep-dev@uppermeadow.com
http://lists.uppermeadow.com/mailman/listinfo/mep-dev
No virus found in this incoming message.
Checked by AVG - http://www.avg.com 
Version: 8.0.175 / Virus Database: 270.8.5/1762 - Release Date: 11/2/2008
7:08 PM