MOCA / DECA Fun

I believe the statistics for DECA adapters come via the network.

The nice thing about Ethernet is that it doesn't require AC power at each end of the cable as DECA adapters do. The power required for DECA is relatively high (as you can tell by looking at the label -- up to 18 watts). How do you plan on powering the DCA2SR1-01?

If you're thinking about diplexing, don't forget about insertion loss.

 

I've given two reasons already and I wasn't really trying.

I'm sure DIRECTV (nor the MoCA Alliance members combined) didn't pay billions to develop DECA. It is not much more than an extension to MoCA 1 using a low frequency band. Of course you have to make sure that your receiver's IF range is compatible with it.

Have you given thought to what is involved in blind scanning in software?

I get that a lot of FTA is about jumping through hoops, but avoiding the first hoop of being able to find and watch TV shouldn't be bypassed.

 

Why add the complication of devices? If all of your terminal devices connect via Wi-fi, what purpose would something like a DECA adapter serve? What do you plan on using for a server to serve up streams those devices? For their part, DIRECTV uses RVU which requires a very special server running software that must be licensed on both the server and the clients.

Are you familiar with what goes into creating software for media servers and device apps?

Are you going to create this hardware to do blind scanning in association with your SDR tuners? If you're going to use conventional tuner chips to do your blind scanning, how will your streaming server collect the results so it knows what is available?

I think you may be getting all gooey about hardware and completely forgetting the software side of things.

What software is it that will do this magic on the server? What about the clients?

Do you know of any apps other than VLC that can handle TS streams or are you envisioning some sort of tuner plug-in for VLC?

 

What do the terminal devices interact with if not a server? Devices like the iPhone and Roku depend on servers to make connections to things like satellite tuners. If you have to develop an API from the ground up, that's a tall order and that's not something that Apple, Google or Roku provides at this point (although Google is arguably the leader here with their AndroidTV product but it still depends on a media server).

What of the TS viewer on the client and how will it choose channels? I submit that you're expecting apps to do things that they have heretofore not done.

For ffplay's part, it is pretty much limited to RTSP streams on iOS and it doesn't exist for Roku.

 

POE tends to be rather expensive and if you're using multiple Raspberry Pis (since the Pi 3 has only two USB ports but can likely only handle one tuner -- if that), it won't handle the power you require (>=24 watts for a pair of Pis). POE is good for a little over 15 watts and POE+ is supposed to be good to 30W but you need power for the Pis and the LNA/LNB(s). DECA isn't set up to pass 5VDC between DECA adapters and injecting and removing it will lead to more insertion loss (remembering that DECA rides on a radio signal).

NEMA 4 or NEMA 6 boxes are great for keeping out the wet, but they are really poor at dissipating heat and protecting from cold (the Pi is rated to operate between freezing and 158F) and something that is burning through 15 watts in a small enclosure will get to the maximum quickly in all but the coldest weather.

So now you've added a server to each tuner (or possibly pair of tuners).

What is this IP SD-LNBF that you're talking about? That may answer many questions if you have a magic feed horn that produces an IP stream rather than a RF signal. This still doesn't answer the question about how the client device chooses channels.

 

8 channel SAT>IP LNB with PoE Adapter

 

What are you trying to do with this? I don't understand?

 

As it turns out, the whole DECA thing was a red herring.

 

At today's exchange rates, that's about $455.95.