[Mep-dev] Conceptual Block Diagram for review

[Paul Williamson]

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