IP over DVB-S2

DB2OS yes... we should do this...

Hello,

To start with, you can visit the "Ron Economos" Github.

https://github.com/drmpeg?tab=repositories

look for gr-dvbgse / grdvbs2 for example

dtv-utils is usefull in general also...and many others

All these blocks for GNU Radio

73 - Christian

DB2OS Everything is possible but your own WB tpx operating rules speak explicitly about 'TV' (DATV, DVB-S2 + bandplan etc). TV has a visual component, i.e. its intention is to transmit pictures/movies etc where sound and/or data component are 'by-catches'. If we leave that perception all (WB) experiments -regardless of their mode of transmission- are 'allowed' on the WB tpx.

Clear explanation, but then the term 'DATV' , 'TV' , 'ATV' needs to be replaced with 'DVB-S2' (to name a suggestion). In the professional world (like SNG (satellite news gathering) several audio channels (digital, VoIP) are normal e.g. to have communication with the studio control room or camera men.

Hi, I am interested for this project but for the moment I do not have WB capabilities.

DH2VA No problem, I sometimes may sound sharp, but my mindset is flexible ; -) If the 'word' is DVB-S2, then it's DVB-S2 : -)

If you are going to be pedantic like this with respect to if it's called TV or not, I would point out amateurs are not permitted to broadcast so using DVB as a term is unwise. DATV-S2 perhaps or DA-S2?

Really? That's unusual I think. You Germans are lucky. Anyway, we are not really broadcasters in the usual sense of Sky, RTL, etc.

Back to the point, I would be interested to try Satellite IP if we have a standard.

Mike

Gentlemen,
with all respect, we have less bandwidth than stations in die WB-transponder for DATV. If we are starting to do pure data-services, where is the bandwidth for TV? What are the next plans to overcrowd that transponder?

Right now, there is already a standard for IP over DVB-S2.
But on the the other hand, we have done data over TV even in the analogue days. Did somebody remember Videotext? In DVB we are just talking about PIDs. If either we are doing SCTP, or MCTP, both are multiplexes.

Right now, even if we transmit a "simple" TV-channel, we are already talking about PMT,PAT, Video PID and Audio PID. Did anybody recognize, that the program-name is our callsign? In fact, we are sending a simple EPG as well.

If there is the need for a "data-channel", just decrease the symbol-rate for video in the beacon and use f.e. 500kSym/s of that stream to multiplex IP-over-DVB-S2 into an new PID.

What are we loosing, when implementing data-services as a new PID into the beacon? Nothing, except a loop-video, we've seen for the past month with full bandwidth.

Just my 2 cents.

Not in an amateur capacity, I have done IP-over DVB-S using a C-band transponder in Kampala, Abuja and a few other places.
This was quite a common way to get bandwith to Africa before fiber infra existed. As Peter suggests, it has a pretty good bit/hz radio and DVB-S2 is probably better. In my case, this was for downstream only; upstream was using common BPSK if memory serves.

The receivers were small PC's with a "DVB-S PCI card" running Linux. I'm not sure about the encapsulation used, too busy making the link work and dealing with other issues and the comfort of doing work in tropical conditions.

Setting up an uplink on a commercial transponder is quite something different than what we are used to on QO100. You don't "just adjust the power"; you call the operator, put your signal on a special test frequency, have the signal optimized (maximal polarization isolation; optimal skew adjustments are a requirement!), have it adjusted for RF signal levels and when all is OK you would be told to move to your allocated frequency. If you would turn up your RF power by as much as 3dB afterwards you will find your transponder notched and you need to call the operator again.

C-band is much more popular because it is less affected by the weather (if you've been in an equator rainstorm, you will understand).

Latency, of course, is an issue. Using decent protocol stacks (FreeBSD) made quite the difference.

I'm currently not set up for the WB transponder but learned *a lot* making this work. If you have the cycles, do try, if must be on a Wednesday..

Hi, I have involved in earthquaqe prediction research for transfering data among others topics. Is it inside the scope of this satellite to transfer such research data once a day at night ?

As a side note, the EUMETCAST service uses DVB-S2 these days to distribute meteo products via IP streams / commercial broadcast sats. This is the METEOSAT/MSG2 data. Beautiful if you ask me, and free for non-commercial/amateur use.

I used to receive it from a sat 5E (?? IIRC, it is a while ago and I forgot the sats name).

In those days it was still DVB-S (non-S2 in other words). I currently do not have a PCI DVB-S2 card so I cannot receive

Wilko

Hello,

I'm the inventor of "New Packet Radio" (NPR), take a look here: https://hackaday.io/project/164092

My thoughts about the discussion:

DVB-S(2) is only well suited for a continuous stream of data at constant bitrate. It's not well suited for burst IP trafic, like we have most of the time when we use IP (web page browsing, e-mail exchange, text tchat). Especially when we consider uplink trafic (from users to servers) for dozens of users, then dozens of constant bitrate channels become a waste of precious radio ressources.

I think I could adapt my NPR protocol (which already transports IP over radio) in order to fit on a portion of the QO-100 WB transponder. It would need lots of modification, but it should be feasible. We could name it "NPR-VSAT".

It could be MF-TDMA (Multiple Frequencies Time Division Multiplexing Access), therefore using multiple timeslots inside multiple frequencies/chanels (for example 5 chanels, each 200kHz wide). Stations would transmit by bursts (instead of continuously for DVB-S2).

A central station (the satellite hub) would allocate dynamically (in real time) these ressources (frequencies and timeslots) between users, according to their need.

All this would be SDR-based, I will try the Adalm Pluto and Lime SDR Mini. The topology could be full-mesh, multipoint to multipoint.

Each user station would transmit on one single frequency at a time (switching fastly between frequencies when needed), and each user station would listen to all frequencies/chanels simultaneously (with one single SDR, it should be feasible).

It would be more efficient than pure DVB streams because of the "burst" type of trafic.

The modulation scheme would be probably less efficient than DVB-S2: 4-levels GMSK seems easy to implement for burst radio frames.

But all together, I still see a great overall improvement compared to the DVB-S2 uplinks initially proposed.

We could even associate it with one single IP-over-DVB downstream channel from the central satellite hub point (Bochum?), in order to optimize the "server to client" trafic.

I agree with DL4OCH : This downstream could even share a single DVB-S2 carrier/chanel with the existing "beacon video".

- "Hub to user" trafic would be IP over DVB.

- "User to user" and "user to hub" IP trafic would be NPR-VSAT.

Tell me what do you think about this ambitious idea.

Do you think it could be usefull that I work on such a project?

Do you accept other modulation scheme than DVB over QO-100 WB?

If we start working together, it would take a lot of time developing such a project, probably more than one year, but I think it’s feasible (not 100% sure yet). For example, it took me 2 years to develop NPR: 1 year for having a proof of concept, and 1 additional year to reach a useable solution.

I'm currently quite busy with my NPR-70 project, but I could start working on this QO-100 project rapidly.

And that's really the kind of thing I like to develop!

Do you know if someone else has already begun to work on an equivalent project?