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
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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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@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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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@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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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@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@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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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...
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@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@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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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@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@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@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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On 2 Sep 2017 Ron Economos w6rz@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
-
Andrew Ragone -
Bill Horne -
Brian Kantor -
Mark Phillips -
Michael Fox - N6MEF -
Rob Janssen -
Ron Economos