1 Sep
2017
1 Sep
'17
4:40 a.m.
Very interesting indeed!
You are probably aware that there is some activity on Digital ATV and the boards made
for that purpose (and/or the cheap dongles they use) could be used for this as well.
We have a Digital ATV repeater here that is currently under some reconstruction, and I
have suggested putting some IP broadcast on the multiplex. Indeed, as you note, a
Linux-based DVB receiver can easily put the demodulated and extracted IP traffic on its
LAN interface. More than a decade ago I did some "experiment" logging the
downlink of
satellite-internet on a Dreambox and it just used standard features of its software.
But your test of using this full-duplex (rather than just unidirectional as it was
envisioned)
surely is innovative.
It could be useful here as well, indeed as you indicate to make links on amateur bands
for which there is no commercial WiFi equipment. It is not straightforward to use that
equipment with transverters, and a steady fullduplex link would certainly be easier.
Some people are also working on a 70cm digital access with smaller bandwidth, there is
little detail on what modulation they use, it would be interesting to see if using DVB-T2
in halfduplex more is feasible. Probably not, due to high turnaround delays.
Rob
1 Sep
1 Sep
5:32 a.m.
New subject: OFDM Modem
Well aware of digital ATV, I'm the developer of the digital television
component of GNU Radio. The DVB-T2 DSP code was developed by myself and
Charles G4GUO. The DATVExpress transmitter board (that G4GUO is one of
the developers on) could be used for this project along with many other
transmit capable SDR's. However, the Ettus B2x0 is known to have the
best phase noise performance on microwave frequencies.
The cheap DVB-T dongles can work, but the latency of DVB-T is not
controllable due to a fixed "PHY" frame size. In DVB-T2, the frame size
can be made very small and this works wonders for latency. Currently,
I'm using a 3.458 millisecond frame size out of a maximum of 250
milliseconds. However, short frame sizes sacrifice throughput for latency.
The DVB-T2 receiver I'm using is not too expensive, only $69.
http://www.hauppauge.com/site/webstore2/webstore_pctv292e.html
The transmit functionality is accomplished by having an instance of Pcap
running in the GNU Radio ULE block. All the IP packets sent to the
normally receive only dvb0_0 interface are captured by Pcap before they
go to the bit bucket.
Ron W6RZ
On 09/01/2017 01:40 AM, Rob Janssen wrote:
Very interesting indeed!
You are probably aware that there is some activity on Digital ATV and
the boards made
for that purpose (and/or the cheap dongles they use) could be used for
this as well.
We have a Digital ATV repeater here that is currently under some
reconstruction, and I
have suggested putting some IP broadcast on the multiplex. Indeed, as
you note, a
Linux-based DVB receiver can easily put the demodulated and extracted
IP traffic on its
LAN interface. More than a decade ago I did some "experiment" logging
the downlink of
satellite-internet on a Dreambox and it just used standard features of
its software.
But your test of using this full-duplex (rather than just
unidirectional as it was envisioned)
surely is innovative.
It could be useful here as well, indeed as you indicate to make links
on amateur bands
for which there is no commercial WiFi equipment. It is not
straightforward to use that
equipment with transverters, and a steady fullduplex link would
certainly be easier.
Some people are also working on a 70cm digital access with smaller
bandwidth, there is
little detail on what modulation they use, it would be interesting to
see if using DVB-T2
in halfduplex more is feasible. Probably not, due to high turnaround
delays.
Rob
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
8:57 a.m.
New subject: OFDM Modem
Y'know, there is some relevance in a significantly asynchronous circuit
with this stuff.
Put the High speed TX on the top of the mountain and have it push high
speed frames in broadcast or multicast mode whilst the outlying stations
listen to the stream and write down the packets relevant to them. The
outlying stations could then be polled for traffic and would respond at a
lower speed on another frequency. Whilst the net effect would be as though
the whole network were working at (say) 3mbps at least it would be reliable
and sove issues like hidden transmitter etc.
This has been thought of before I'm sure.
On Fri, Sep 1, 2017 at 5:32 AM, Ron Economos <w6rz(a)comcast.net> wrote:
Well aware of digital ATV, I'm the developer of
the digital television
component of GNU Radio. The DVB-T2 DSP code was developed by myself and
Charles G4GUO. The DATVExpress transmitter board (that G4GUO is one of the
developers on) could be used for this project along with many other
transmit capable SDR's. However, the Ettus B2x0 is known to have the best
phase noise performance on microwave frequencies.
The cheap DVB-T dongles can work, but the latency of DVB-T is not
controllable due to a fixed "PHY" frame size. In DVB-T2, the frame size can
be made very small and this works wonders for latency. Currently, I'm using
a 3.458 millisecond frame size out of a maximum of 250 milliseconds.
However, short frame sizes sacrifice throughput for latency.
The DVB-T2 receiver I'm using is not too expensive, only $69.
http://www.hauppauge.com/site/webstore2/webstore_pctv292e.html
The transmit functionality is accomplished by having an instance of Pcap
running in the GNU Radio ULE block. All the IP packets sent to the normally
receive only dvb0_0 interface are captured by Pcap before they go to the
bit bucket.
Ron W6RZ
On 09/01/2017 01:40 AM, Rob Janssen wrote:
Very interesting indeed!
You are probably aware that there is some activity on Digital ATV and the
boards made
for that purpose (and/or the cheap dongles they use) could be used for
this as well.
We have a Digital ATV repeater here that is currently under some
reconstruction, and I
have suggested putting some IP broadcast on the multiplex. Indeed, as you
note, a
Linux-based DVB receiver can easily put the demodulated and extracted IP
traffic on its
LAN interface. More than a decade ago I did some "experiment" logging
the downlink of
satellite-internet on a Dreambox and it just used standard features of
its software.
But your test of using this full-duplex (rather than just unidirectional
as it was envisioned)
surely is innovative.
It could be useful here as well, indeed as you indicate to make links on
amateur bands
for which there is no commercial WiFi equipment. It is not
straightforward to use that
equipment with transverters, and a steady fullduplex link would certainly
be easier.
Some people are also working on a 70cm digital access with smaller
bandwidth, there is
little detail on what modulation they use, it would be interesting to see
if using DVB-T2
in halfduplex more is feasible. Probably not, due to high turnaround
delays.
Rob
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
11:17 a.m.
New subject: OFDM Modem
Ron, this is great work! I know you mentioned there is room for
optimization on the buffering / GNU Radio side of things, but it doesn't
look like any of the links provided were for the actual radio design you
worked on. Were you planning on throwing that up on GitHub or your website?
I have a Pervices Noctar SDR which I wouldn't mind playing with your
project on (and helping optimize).
-Andrew
Kc2LTO
On Fri, Sep 1, 2017 at 7:01 AM, Brian Kantor <Brian(a)ucsd.edu> wrote:
Sounds a lot like the ALOHA network from back in June
1971.
- Brian
On Fri, Sep 01, 2017 at 08:57:38AM -0400, Mark Phillips wrote:
This has been thought of before I'm sure.
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
11:21 a.m.
New subject: OFDM Modem
Er, looks like I stand corrected ... I think this is the project
implementing the GNU Radio functionality: https://github.com/drmpeg/gr-ule
On Fri, Sep 1, 2017 at 9:17 AM, Andrew Ragone <ajr9166(a)rit.edu> wrote:
Ron, this is great work! I know you mentioned there is
room for
optimization on the buffering / GNU Radio side of things, but it doesn't
look like any of the links provided were for the actual radio design you
worked on. Were you planning on throwing that up on GitHub or your website?
I have a Pervices Noctar SDR which I wouldn't mind playing with your
project on (and helping optimize).
-Andrew
Kc2LTO
On Fri, Sep 1, 2017 at 7:01 AM, Brian Kantor <Brian(a)ucsd.edu> wrote:
Sounds a lot like the ALOHA network from back in
June 1971.
- Brian
On Fri, Sep 01, 2017 at 08:57:38AM -0400, Mark Phillips wrote:
This has been thought of before I'm sure.
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
2 Sep
2 Sep
7:59 p.m.
New subject: OFDM Modem
Here's a little more background on the project. First, the DVB-T2
transmitter is part of GNU Radio itself. I developed the original DVB-T2
transmitter as an OOT (Out of Tree) module back in the winter of 2014/2015.
https://github.com/drmpeg/gr-dvbt2
Since then, the code has been integrated into the GNU Radio mainline
along with DVB-T, DVB-S, DVB-S2, DVB-S2X, ATSC and cable QAM
transmitters. There are also receivers for ATSC and DVB-T. The above OOT
module is now deprecated.
Here's an example DVB-T2 flow graph. This one implements the exact same
parameters as used by the BBC for their television transmitters in the
UK. It has 40.2 Mbps of throughput in an 8 MHz channel.
http://www.w6rz.net/dvbt2bbc.png
The blocks in the lower right hand corner implement the interface to the
SDR hardware. The UHD: USRP SInk is for Ettus Research products and the
osmocom Sink is for other SDR's like bladeRF and hackRF.
The flow graph for the OFDM modem looks like this.
http://www.w6rz.net/dvbt2ule.png
The IP over TS Packet Source block is implemented in the gr-ule OOT module.
https://github.com/drmpeg/gr-ule
The other DVB-T2 blocks are just the regular DVB-T2 blocks merged
together to avoid buffering between blocks (to reduce latency). Those
blocks are implemented in the gr-dvbt2ll OOT module.
https://github.com/drmpeg/gr-dvbt2ll
The network interface is provided by a kernel driver. The driver
implements both the ULE protocol and the MPE protocol, but MPE is not
complete for some reason.
https://github.com/torvalds/linux/blob/master/drivers/media/dvb-core/dvb_ne…
The dvb_net driver just exposes a regular Ethernet interface, so all the
routing tools of Linux are available. To connect to the Internet, all I
had to do was make the interface the default route on the "remote" node,
enable IP4 forwarding on the "local" node that's connected to the
Internet, and add the 44.4.15.8/29 route to my Asus RT-AC66U router.
http://www.w6rz.net/dvb0_0.png
Ron W6RZ
On 09/01/2017 08:21 AM, Andrew Ragone wrote:
> Er, looks like I stand corrected ... I think this is the project
> implementing the GNU Radio functionality: https://github.com/drmpeg/gr-ule
>
> On Fri, Sep 1, 2017 at 9:17 AM, Andrew Ragone <ajr9166(a)rit.edu> wrote:
>
>> Ron, this is great work! I know you mentioned there is room for
>> optimization on the buffering / GNU Radio side of things, but it doesn't
>> look like any of the links provided were for the actual radio design you
>> worked on. Were you planning on throwing that up on GitHub or your website?
>> I have a Pervices Noctar SDR which I wouldn't mind playing with your
>> project on (and helping optimize).
>>
>> -Andrew
>> Kc2LTO
>>
>> On Fri, Sep 1, 2017 at 7:01 AM, Brian Kantor <Brian(a)ucsd.edu> wrote:
>>
>>> Sounds a lot like the ALOHA network from back in June 1971.
>>> - Brian
>>>
>>> On Fri, Sep 01, 2017 at 08:57:38AM -0400, Mark Phillips wrote:
>>>> This has been thought of before I'm sure.
>>> _________________________________________
>>> 44Net mailing list
>>> 44Net(a)hamradio.ucsd.edu
>>> http://hamradio.ucsd.edu/mailman/listinfo/44net
>>>
>>
>
9:13 p.m.
New subject: OFDM Modem
Ron,
Unfortunately, these details are outside my expertise.
What I'm curious to know is how this can be used. Specifically, I'm curious
to know if this can be used in a point-to-multi-point configuration as
follows:
-- Central site device accepts connections from multiple clients devices,
much like a packet BBS or dial-up server or WiFi access point or VPN server
or ...
-- Primary application is multiple individuals/sites connecting to a central
server, such as a POP/SMTP email server. Clients connect, up/download,
disconnect, thereby vacating the channel for others to use. MAC capable of
multiple simultaneous connections (albeit slower for each connection), much
like packet or Ethernet or WiFi or ...
-- Secondary application is clients connecting directly to each other, but
also for a brief time (connect, transfer, disconnect) so channel can be
shared by many.
-- Capable of operating within the current 70 cm band FCC restrictions
If so, I think I could find a local team of folks willing to work on and
test a prototype. And, as I've mentioned, we've got plenty of folks waiting
for such a device.
Michael
N6MEF
> -----Original Message-----
> From: 44Net [mailto:44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu] On
> Behalf Of Ron Economos
> Sent: Saturday, September 2, 2017 4:59 PM
> To: 44net(a)hamradio.ucsd.edu
> Subject: Re: [44net] OFDM Modem
>
> Here's a little more background on the project. First, the DVB-T2
> transmitter is part of GNU Radio itself. I developed the original DVB-T2
> transmitter as an OOT (Out of Tree) module back in the winter of
> 2014/2015.
>
> https://github.com/drmpeg/gr-dvbt2
>
> Since then, the code has been integrated into the GNU Radio mainline
> along with DVB-T, DVB-S, DVB-S2, DVB-S2X, ATSC and cable QAM
> transmitters. There are also receivers for ATSC and DVB-T. The above OOT
> module is now deprecated.
>
> Here's an example DVB-T2 flow graph. This one implements the exact same
> parameters as used by the BBC for their television transmitters in the
> UK. It has 40.2 Mbps of throughput in an 8 MHz channel.
>
> http://www.w6rz.net/dvbt2bbc.png
>
> The blocks in the lower right hand corner implement the interface to the
> SDR hardware. The UHD: USRP SInk is for Ettus Research products and the
> osmocom Sink is for other SDR's like bladeRF and hackRF.
>
> The flow graph for the OFDM modem looks like this.
>
> http://www.w6rz.net/dvbt2ule.png
>
> The IP over TS Packet Source block is implemented in the gr-ule OOT
> module.
>
> https://github.com/drmpeg/gr-ule
>
> The other DVB-T2 blocks are just the regular DVB-T2 blocks merged
> together to avoid buffering between blocks (to reduce latency). Those
> blocks are implemented in the gr-dvbt2ll OOT module.
>
> https://github.com/drmpeg/gr-dvbt2ll
>
> The network interface is provided by a kernel driver. The driver
> implements both the ULE protocol and the MPE protocol, but MPE is not
> complete for some reason.
>
> https://github.com/torvalds/linux/blob/master/drivers/media/dvb-
> core/dvb_net.c
>
> The dvb_net driver just exposes a regular Ethernet interface, so all the
> routing tools of Linux are available. To connect to the Internet, all I
> had to do was make the interface the default route on the "remote" node,
> enable IP4 forwarding on the "local" node that's connected to the
> Internet, and add the 44.4.15.8/29 route to my Asus RT-AC66U router.
>
> http://www.w6rz.net/dvb0_0.png
>
> Ron W6RZ
>
> On 09/01/2017 08:21 AM, Andrew Ragone wrote:
> > Er, looks like I stand corrected ... I think this is the project
> > implementing the GNU Radio functionality: https://github.com/drmpeg/gr-
> ule
> >
> > On Fri, Sep 1, 2017 at 9:17 AM, Andrew Ragone <ajr9166(a)rit.edu> wrote:
> >
> >> Ron, this is great work! I know you mentioned there is room for
> >> optimization on the buffering / GNU Radio side of things, but it
> doesn't
> >> look like any of the links provided were for the actual radio design
> you
> >> worked on. Were you planning on throwing that up on GitHub or your
> website?
> >> I have a Pervices Noctar SDR which I wouldn't mind playing with your
> >> project on (and helping optimize).
> >>
> >> -Andrew
> >> Kc2LTO
> >>
> >> On Fri, Sep 1, 2017 at 7:01 AM, Brian Kantor <Brian(a)ucsd.edu> wrote:
> >>
> >>> Sounds a lot like the ALOHA network from back in June 1971.
> >>> - Brian
> >>>
> >>> On Fri, Sep 01, 2017 at 08:57:38AM -0400, Mark Phillips wrote:
> >>>> This has been thought of before I'm sure.
> >>> _________________________________________
> >>> 44Net mailing list
> >>> 44Net(a)hamradio.ucsd.edu
> >>> http://hamradio.ucsd.edu/mailman/listinfo/44net
> >>>
> >>
> >
3 Sep
3 Sep
10:37 p.m.
New subject: OFDM Modem
On 2 Sep 2017 Ron Economos <w6rz(a)comcast.net> wrote:
Here's a little more background on the project.
First, the DVB-T2
transmitter is part of GNU Radio itself. I developed the original DVB-T2
transmitter as an OOT (Out of Tree) module back in the winter of 2014/2015.
https://github.com/drmpeg/gr-dvbt2
Since then, the code has been integrated into the GNU Radio mainline
along with DVB-T, DVB-S, DVB-S2, DVB-S2X, ATSC and cable QAM
transmitters. There are also receivers for ATSC and DVB-T. The above OOT
module is now deprecated.
Ron,
Thanks for your contributions to the hobby and to open-source.
My "physical layer" expertise extends only as far as 1200 Baud
TNCs. Please point me to reference works, how-tos, FAQs, and any
other instructional material that is available. I hope other readers
of the 44-net list will benefit as well, so I'll reply to the list.
Again, my thanks.
73,
Bill, W4EWH
2448
days inactive
2451
days old
8 comments
7 participants
participants (7)
-
Andrew Ragone -
Bill Horne -
Brian Kantor -
Mark Phillips -
Michael Fox - N6MEF -
Rob Janssen -
Ron Economos