Open IP over VHF/UHF Part 5(rowetel.com)
rowetel.com
Open IP over VHF/UHF Part 5
https://www.rowetel.com/?p=7898
23 comments
In some places (including Denmark) encryption is allowed as long as the signal is somehow identifiable (includes your call sign or DMR ID).
I know that some use WiFi outside normal bands (3.3–3.8 GHz) and simply set the SSID to their call sign. This is called HSMR.
https://en.wikipedia.org/wiki/High-speed_multimedia_radio
I know that some use WiFi outside normal bands (3.3–3.8 GHz) and simply set the SSID to their call sign. This is called HSMR.
https://en.wikipedia.org/wiki/High-speed_multimedia_radio
Very interesting, and being the same guy beyond Codec2 it inspires some applications such as audio and data link so that two or more people could communicate, albeit on a traditional simplex channel, while also sharing data from various sensors. That would be trivial using WiFi, but to make it useful it should use illegal power levels.
In the US there's a maximum symbol rate? I guess I thought that'd apply. 1.2 kbps perhaps? My Google foo is failing me.
I believe those regulations have changed.
Not an electronics expert here, sorry if it doesn't make sense but why is there a limit on symbol rate anyway? I understand tx power limits to avoid interference, but why an additional symbol rate limit too?
Because it is a shared resource. It is limited not to exceed the bandwidth of a “typical” SSB transmission.
Typical is in quotes because some people think it is cool to allow their radios to transmit up to 10KHz bandwidth because “high fidelity SSB” is apparently a thing.
Typical is in quotes because some people think it is cool to allow their radios to transmit up to 10KHz bandwidth because “high fidelity SSB” is apparently a thing.
The symbol rate is ultimately linked to the amount of bandwidth a signal uses, i.e. the amount of the radio spectrum that's used by a signal, rather than the physical area over which that spectrum is used (which relates to power).
Anti-encryption I believe, keeping the barrier for receiving low.
Here's my 30 Mbps IP over UHF/SHF system. It takes advantage of a little known driver in the Linux media subsystem that exposes the RF link as just another Ethernet interface. Although not shown in the diagram, it also works with IPv6.
Of course, it's a lot more expensive to implement than the article system (and I used some Cadillac components in the test bed). Someday (when the parts shortage is over), I may productize it.
https://www.w6rz.net/ofdm3.png
https://github.com/torvalds/linux/blob/master/drivers/media/...
Of course, it's a lot more expensive to implement than the article system (and I used some Cadillac components in the test bed). Someday (when the parts shortage is over), I may productize it.
https://www.w6rz.net/ofdm3.png
https://github.com/torvalds/linux/blob/master/drivers/media/...
i wonder if i am allowed to transmit such signals, maybe with some ham license? also, i read "exposes the RF link as just another Ethernet interface" a little wrong. its not like this will demodulate ethernet somehow but extracts frames from the transport stream using usual DVB mechanisms (i.e referencing the data stream in the PAT and similars) or am i wrong?
Those frequencies that I'm using (2305 and 3429 MHz) are in amateur radio allocations, so a license would be required (entry level Technician license will do). Because of that, you can't run any encrypted traffic over the link. So no https, ssh, etc. allowed.
With a license, you could transmit with up to 1500 watts (although it would not be easy). But you could easily run considerably more power than WiFi (like 10 to 20 watts).
Yes, I definitely simplified the explanation of the functionality of the driver. It's really a ULE (Unidirectional Lightweight Encapsulation) protocol driver. It processes Transport Stream packets received from the DVB-T2 receiver on a selected PID and forwards the data payload (IP packets) over the Linux Ethernet interface.
On the transmit side, I implemented the ULE protocol in GNU Radio (Github link in the diagram). To make the interface bidirectional, I capture transmit packets sent to the interface with libpcap as part of the encapsulation process.
https://en.wikipedia.org/wiki/Unidirectional_Lightweight_Enc...
https://tools.ietf.org/html/rfc4326
With a license, you could transmit with up to 1500 watts (although it would not be easy). But you could easily run considerably more power than WiFi (like 10 to 20 watts).
Yes, I definitely simplified the explanation of the functionality of the driver. It's really a ULE (Unidirectional Lightweight Encapsulation) protocol driver. It processes Transport Stream packets received from the DVB-T2 receiver on a selected PID and forwards the data payload (IP packets) over the Linux Ethernet interface.
On the transmit side, I implemented the ULE protocol in GNU Radio (Github link in the diagram). To make the interface bidirectional, I capture transmit packets sent to the interface with libpcap as part of the encapsulation process.
https://en.wikipedia.org/wiki/Unidirectional_Lightweight_Enc...
https://tools.ietf.org/html/rfc4326
I understand that the law requires you to broadcast unencrypted communications - but what happens if you don't and use it for long-distance SSH or something?
Who would respond? I'm genuinely curious - I recall a long time ago hearing a story about FCC vans with antennas driving around a neighbourhood trying to triangulate the signal and find the source but that was a much stronger "pirate" radio station.
Who would respond? I'm genuinely curious - I recall a long time ago hearing a story about FCC vans with antennas driving around a neighbourhood trying to triangulate the signal and find the source but that was a much stronger "pirate" radio station.
Certainly not condoning it, but as long as you don't interfere with another user, you could get away with it.
For the frequencies I'm using, the 3.4 GHz band is very lightly used by hams, so that won't be a problem. Plus wide band OFDM signals just sound like noise in a narrow band receiver. There are government/military radars, but only in certain geographic areas.
2305 MHz is a little different. The 2305 to 2310 segment is shared with band 30 LTE. Band 30 is pretty lightly used by AT&T (the only licensee), but they do use it in some cities. The 2300 to 2305 segment is interesting. Amateur radio is secondary, but there is no primary user. My guess is that it's kept this way to provide a guard band to the deep space band at 2290 to 2300 MHz.
An alternative frequency would be 2395 MHz, but that's very close to the WiFi band. If you really want to be stealth, then 10 and 24 GHz would be ideal.
For the frequencies I'm using, the 3.4 GHz band is very lightly used by hams, so that won't be a problem. Plus wide band OFDM signals just sound like noise in a narrow band receiver. There are government/military radars, but only in certain geographic areas.
2305 MHz is a little different. The 2305 to 2310 segment is shared with band 30 LTE. Band 30 is pretty lightly used by AT&T (the only licensee), but they do use it in some cities. The 2300 to 2305 segment is interesting. Amateur radio is secondary, but there is no primary user. My guess is that it's kept this way to provide a guard band to the deep space band at 2290 to 2300 MHz.
An alternative frequency would be 2395 MHz, but that's very close to the WiFi band. If you really want to be stealth, then 10 and 24 GHz would be ideal.
It depends where you are doing this? US? Australian outback? Developing country? The places you’d want to use it (outback) probably have low enforcement
Why can't we just use TCP over AX.25?
This "problem" (TCP over HF/VHF) has been solved around 1979(sic!).
- https://en.wikipedia.org/wiki/KISS_(TNC)
- https://en.wikipedia.org/wiki/Packet_radio
This "problem" (TCP over HF/VHF) has been solved around 1979(sic!).
- https://en.wikipedia.org/wiki/KISS_(TNC)
- https://en.wikipedia.org/wiki/Packet_radio
Technology has evolved since 1979, modern encodings can get a lot better numbers than what was possible back then. And amateur radio is at least nominally about experimentation, not "only do the same thing we did 40 years ago and question everything newer" or "but somebody else is already working on this".
Yep, and even all of the problems with these, have been solved with new protocols and megabit speeds over long distances:
http://lea.hamradio.si/~s53mv/nbp/nbp.html
http://lea.hamradio.si/~s53mv/nbp/new.html (10mbits over ~100km)
http://lea.hamradio.si/~s53mv/nbp/nbp.html
http://lea.hamradio.si/~s53mv/nbp/new.html (10mbits over ~100km)
Does it need a license?
Yes, you need a ham licence to transmit in those bands (also for the bands in the original article)
Werent UHF freqs license free because of DVB-T adoption? At least in a good chunk of Europe...
Nah, in europe you have PMR446[0] free for all, but this was free even before the dvb-t adoption, and you can use it only for voice communications. Former TV bands were/are used for 4G and 5G (eg 700MHz and 800MHz bands).
In most european countries, getting a ham licence is a pretty cheap process (in slovenia, in some radio clubs, if you don't need a printed book (just a pdf), you can join a 10-15hour theoretical and practical course + licence exam for somewhere around 50eur)
[0] https://en.wikipedia.org/wiki/PMR446
In most european countries, getting a ham licence is a pretty cheap process (in slovenia, in some radio clubs, if you don't need a printed book (just a pdf), you can join a 10-15hour theoretical and practical course + licence exam for somewhere around 50eur)
[0] https://en.wikipedia.org/wiki/PMR446
Can something like this in practice be used with HAM radio via some loophole, or it's basically impossible to use a large fraction of commonly used protocols/payloads (https, ssh, any secured protocols, VPNs, etc) due to encryption not being allowed? I suppose you could argue that the intention is not to obscure the communication, but it seems pretty flimsy.