I would be concerned about unintentionally running afoul of FCC regulations since encryption is not allowed on US amateur frequencies, that means using something like SSH or loading an SSL webpage with this modem would be a violation. I would also be very concerned with the OS background processes that may use encryption by default.
More than just encryption, this will run afoul of FCC part 97.305(c) and 97.307(f)(6) which says on the 70cm band that the maximum symbol rate cannot exceed 56kbaud and the bandwidth cannot exceed 100kHz. However the underlying transceiver chip can also work on the 33cm band where these limits no longer apply.
Original author seems to be based in France, so I don't think FCC limits are being into consideration. Would be interesting if there exists an equivalent limitation by EU regulations.
At international level, encryption in ham bands is forbidden (at least).
The legal definition prohibiting encryption is in §97.113(4) and says that "messages encoded for the purpose of obscuring their meaning" are prohibited. This is generally accepted to be a blanket prohibition of "encryption" in the sense that SSH, SSL, TLS, VPN type traffic would be prohibited.
However, there are some interesting and positive nuances because the rule specifically doesn't ban "crypto". For instance, it is my belief that cryptography for the purpose of authentication or message signing/integrity checking is completely permissable. That is to say that you can even technologically allow things like TLS and HTTPS so long as you force a NULL cipher; so you get message integrity but no encryption so some observer could see all the traffic but not be able to interfere.
More broadly, the purpose of the ham radio allocation is learning / experimentation / personal use between hams / etc., not production services (and not even personal use between a ham and a non-ham, e.g., while listening in on ham frequencies doesn't require a license, a ham intentionally broadcasting to those listeners is not authorized under their license). These rules predate the world in which encryption for everything is commonplace, and they envision a world in which encryption means that other people can't learn from your communications practice. These rules are also written to discourage actual commercial users from using the ham frequencies, to keep the frequencies clear for hams.
Now that we live in a world where my writing this message to you (and, in fact, to the world, publicly under my name) goes over an encrypted channel and it would be unthinkable if it didn't, and where my texts to my friends about where to get dinner happen over an end-to-end secure messenger, and where most competent cryptography is developed in public, it's not clear the rules make sense any more. But that's where they come from.
BTW, one ham has argued that encryption for the purpose of using a standard protocol like WPA/802.1x (or, probably, SSH or SSL) that is otherwise compliant with the intent of the amateur service is legal, because the purpose of the encryption is not obscuring their meaning, the obscured meaning just a side effect of other goals: http://www.n5dux.com/ham/files/pdf/Data%20Encryption%20is%20...
Sometimes I wish a large company, like Google, bought large spectrum and released it to the public. We fight over Mhz here and there, but tons of the spectrum is allocated but barely used.
Speaking as an amateur radio operator who does experimental stations....
Encryption is illegal as you stated. However "Unique encodings of an analog or digital nature" are completely legal. You don't even need to tell the protocol.
We had this issue with D.star where it was an amateur radio digital protocol in which they didn't tell how to encode or decode. Brought up at an FCC hearing and deemed completely legal.
So call all encryption a "Unique encoding" and you're legally in the clear.
We had this issue with D.star where it was an amateur radio digital protocol in which they didn't tell how to encode or decode. Brought up at an FCC hearing and deemed completely legal.
This can't be right. IIRC you have to publish in a public place how your code works, and I believe the D-STAR specs are public; its just that any implementation is blocked because of copyright or whatever dumb crap.
This part of the regs have nothing to do with encryption. This is the so called "documented protocol" requirement. §97.113(4) is the relevant main rule that would govern encryption. There are various exceptions to this through the rest of the document such as spread spectrum, space stations, and telemetry/radio control all having some special case language.
Well, I stand corrected. I had admittedly just googled it myself. I had known the ban on encryption was pretty accepted in the amateur radio community. Thanks for the correction.
The regulation prohibits "messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein" so if you and your friend made up your language to keep your communications obscured, then it seems that it would not be allowed.
If you happen to speak a language that's not commonly known in the area then that would likely be fine.
I think it is also important to understand the "no commercial business" part of it, too. That why the meaning is not to be "obscured", lest you mean to do business over amateur frequencies.
In short, if the traffic is encrypted, how would we know that, say, Verizon isn't off-loading traffic to amateur bands?
The way to think of it is that the FCC needs to monitor communication. (Possibly also other arms of the government.) If they can't eavesdrop, then that is an issue.
They don't allow any prototyping or experimenting on the amateur bands either. That is why this is using the unlicensed ISM bands.
I want to see it adapted for the lower frequency ISM bands. I just got into ham and SDR this last year and I'm looking forward to making a super long distance super low speed link to my buddies on the other coast as a backup comm channel in case the primaries go down.
Despite that petition being denied, Part 47 97.309[1] is pretty clear that as long as the mode's "technical characteristics have been documented publicly" it's fair game, subject to 97.307(f) [2].
If I'm reading it right, the FCC denied the petition because you're already allowed to experiment on the ham bands. The whole point of the ham bands is experimentation!
Who is "they"? Unless I'm confused (which is certainly possible), the 433 MHz ISM allocation doesn't exist in the US. There's only the 420-450 MHz ham allocation.
Is there also a ban on encryption in the countries where it exists, or is that an FCC-only thing?
433.92 ISM is only EU/Africa. So yeah in the US it would be illegal to use encryption. There are quite a few lower frequency ISM bands that might offer much greater range.
They do spread spectrum on ISM bands with extremely low data rates for insane sensitivity. I want to see what kind of stable distance you can get with lower frequencies and possibly even lower bitrates.
I didn't know that. I'm not too familiar with amateur radio around the world. I know people were able to contact other people around the world, so I assumed the bands were similar.
Interesting, can you provide any more information? How could you do radio that far? Googling shows it is at least 2,092 miles. What kind of radio can go that far?
The HF bands (below 3 and 30 Mhz, also called shortwave) propagate by bouncing of the ionosphere. A major part of amateur radio is using them for intercontinental communication.
Also, I'll add a link to http://wsprnet.org/drupal/wsprnet/map . Essentially this shows the transmitter and receiver locations for low power beacons, which might give you a sense of what HF propogation looks like. It will vary according to the time of day and solar conditions.
To expand on the other posters, if you can do voice around the world (a few kHz bandwidth) on those frequencies you should very easily be able to do very low bandwidth modulation for data and at reduced power. It would be nice if I could do typing speed but I'd be thrilled with 1 bit per second. Looking around they do have HF packet capable radios but they are quite expensive. I'm going to research those a bit later.
HF digital modes are very common on the shortwave bands. Look up PSK31, etc.. You can convert any SSB (voice) HF radio to digital by connecting it to a computer's audio card.
Point to point you would have to get into HF or lower frequencies and use the ionosphere. For the hobby of talking long distance as a competition, check https://en.wikipedia.org/wiki/DXing.
"I would be concerned about unintentionally running afoul of FCC regulations since encryption is not allowed on US amateur frequencies, that means using something like SSH or loading an SSL webpage with this modem would be a violation. I would also be very concerned with the OS background processes that may use encryption by default."
And I wouldn't. Not trying to be an arse here... but more importantly, who cares? Someone has to discover whats happening and actually care that a rule is being violated. There really are not many hams that have the skill to figure out what is happening when they hear this on their precious 70cm band and THEN realize encryption is happening on top of the network layer. Sure, they exist, but they are also generally busy doing real things that matter rather than volunteering for the Amateur Auxiliary.
Queue: the relentless flood of pitch forks that "CRYPTION IS AGAINST THE RULE OF LAW ON MY HAM BANDS".
If encryption is allowed, then there can no longer be any restrictions on the use of ham bands - you won't be able to tell the difference between someone calling for help or doing disaster relief and a pizza place using ham radios for dispatch.
But to answer your question "who cares?", hams care, and I'd be surprised if people sending encrypted transmissions are not soon discovered - and if you knowingly violate the regulations, you run the risk of losing your ham license. If you're not licensed, (or even if you are for egregious or repeat violators), there are various enforcement actions the FCC can take including significant fines, equipment confiscation, and other criminal penalties.
>Someone has to discover whats happening and actually care that a rule is being violated. There really are not many hams that have the skill to figure out what is happening when they hear this on their precious 70cm band and THEN realize encryption is happening on top of the network layer. Sure, they exist, but they are also generally busy doing real things that matter rather than volunteering for the Amateur Auxiliary.
In my experience, there absolutely are plenty of hams out there who will triangulate you and report you for violations. You'd probably get away with a warning at first, to be fair, but many hams (at least around these parts) are old retired dudes with nothing better to do.
You're not wrong, but you are also lumping "old hams" into the same category as "hams that use computers". While the old dudes can certainly fox-hunt like no bodies business, they are the same dudes that get irate at the idea of hooking a perfectly good ham radio up to a computer, so that rules them out for figuring out something like ssl is being used ;-P.
If you think I'm wrong, just walk around any ham fest and ask for help setting up your Winlink node ;-).
I mean, the FCC does not really have a track record of enforcing violations. You could probably do whatever you want, until some hams fox hunt you and tell Uncle Sugar you are breaking the rules. Even then, the FCC is likely to only give you a warning rather than a punishment.
That being said these bands are out there for the public to use, the government has set aside a pretty decent portion of the available usable frequencies for use of the public. In my opinion is just in poor taste to not follow the rules here.
In these days when you can get a Baofeng HT for $25, there are already all sorts of unlicensed people stomping all over others just to be jerks.
I listen to folks DXing on CB across the continental US all the time. Not long ago I heard someone in Puerto Rico make a contact in Canada. On a band supposedly limited to 4 Watts. The FCC doesn't care unless there's a complaint, and even then there's definitely a dollar amount attached to an enforcement action. They don't roll huff-duff wagons on a whim. Everyone should watch THX1138.
Useful description from the documentation about what is new about this as amateur packet radio has a long history.
The NPR protocol is designed to transfer IP data over radio links, in a bidirectional way (single frequency).
This protocol is in the middle between old packet radio (AX.25) and HSMM-Hamnet with Wifi equipment.
This protocol is designed by a HAM for HAMs. The project is 100% open source : specification, software, PCB.
This solution is complementary to HSMM-Hamnet (which uses Wifi equipments), on lower frequencies 70cm). Radio links on 70cm band is much more robust to obstacles.
The data-rate available is also much smaller, but yet useable. We can achieve several hundreds of kbps. The protocol is designed for “point to multipoint” topology, with 1 central relay (called Master) and several clients around.
I wonder if IP is really the right decision. AX25 isn't the bottleneck with existing packet radio, and because it's made for hams, it makes it easy to be sure that you're really within your license requirements. ie: identification. It's also difficult to accidentally send encrypted messages over AX25, whereas on IP you have to really watch Wireshark and make sure you're not doing something wrong. It's also not as chatty, which is a real concern when you have a mesh network and someone is hearing you better than you're hearing them --- it could get really messy without coordination. That being said, this is a very exciting project. I'd love to see packet radio make some progress since the 80s (outside of just repurposing 802.11 gear).
We need the ARRL to stop wasting their time on a watered down HOA bill that they've been working on for like a decade, and start talking to the FCC about modernizing regulations for the 21st century. Two things that come to mind are that the spread spectrum/transmit bandwith restrictions are outdated, and encryption requirements need to be formally relaxed so that common digital communication like SSH or HTTPS can be supported to an extent -- I'm not saying I want the ham bands filled with encrypted traffic, but I'm fine with the small community of packet radio enthusiasts being able to remote into a computer from afar.
Packet radio has made some progress since the 80s :). Here in North Carolina we have a network called TARPN http://tarpn.net/t/packet_radio_networking.html. We use re-purposed commercial radios, RaspberryPis, and custom TNCs for 1200 baud packet links. Some folks are experimenting with higher speed links (9600).
These ISM modules will work on low power for close range links, but you can't just slap an amplifier and call it a day. There are regulatory issues with the tech they use (spread spectrum, wide bandwidth, encryption, etc).
I’m ok with cryptographic authentication of unencrypted messages (eg https with null encryption). But as soon as encrypted payloads happen, everyone will be doing way more than the “ssh where no other radio transport is available” use case.
> start talking to the FCC about modernizing regulations for the 21st century
I would have thought that HAM operators need to fight to keep the regulations that they have, and that trying to make big changes would lead to worse outcomes?
Any of the regulations predate most digital communications so there are a bunch of obsolete rules specifying the maximum symbol rate for digital transmissions rather then restricting the bandwidth which is what one actual cares about for sharing the available frequency space. This restriction artificially precludes use of many modern transmission schemes and hamstrings experimentation.
AX.25 was never designed to create very large networks with, it also doesn't integrate well into a modern world. Hams have been using IP technology for a very long time too, this isn't new.
Where do you live? VHF packet radio is extremely active in Wisconsin, and none of it is IP based. Outside of the guys in the northwest doing 802.11 with external amplifiers (hamwan), who else is using IP?
I had an idea for something like this a few years back, would love to experiment!
Any idea where this falls in terms of broadcast regulations? From what I can recall in the US, data must be in the clear and not encrypted on ham frequencies, although I am not a licensed ham so can't say for sure.
It's a little bit more relaxed than "no commerce allowed".
Communications in which the operator has a pecuniary interest are prohibited[1]. But, personal communication with a business is allowed. Ordering a pizza via phone patch is allowed but soliciting orders for your pizza shop is not.[2]
There are other issues that would make connecting to the internet problematic that are prohibited by §97.113. Things like cryptography, obscene or indecent words or language; false or deceptive messages ...
So encryption isn't allowed, but is there any way to authenticate information sent over packet radio? Open communication has plenty of uses, but some of those can be spoiled by bad actors impersonating others.
> So encryption isn't allowed, but is there any way to authenticate information sent over packet radio? Open communication has plenty of uses, but some of those can be spoiled by bad actors impersonating others.
You are not allowed to encrypt data on ham bands (this seems to happen Worldwide, it is also true here in Brazil), but there is no restriction on use of cryptographic primitives for authentication. But some countries (France, AFAIK) also require the protocol specs to be openly available, what should not be a problem in this field.
Digital signatures are Ok as long as the content of the message is not hidden (i.e. all listeners can receive and decode the information) and the transmission is identified (as usual in ham).
There's no problem in principle with using public key cryptography to sign messages sent by ham radio. So authentication is possible although it's not common in practice. It's encrypting the content of messages that's not permitted.
Legally speaking, it's "messages encoded for the purpose of obscuring their meaning" [0] that's illegal, which is fraught with conflicting interpretations and loopholes.
Cryptography is not categorically illegal on the ham bands, and in the case of satellite/remote operation, it's encouraged (possibly required?) that you have some secure mechanism of controlling your radio.
In the general case, there is nothing illegal about sending a PGP-signed email over Winlink, for example. But the message itself must be in the clear. It's just about the fear of foreign spies obfuscating their messages and Red Scare fearmongering.
Of course, in a world with Tor and $30 TracFones with unlimited data, this concern is totally ridiculous. But it is what it is, for now.
Getting a satellite into space is ~50,000$ for a 1U cube sat when I looked around. You might be able to get NASA or somebody to send it up for free if it's educational and they have room.
So it's getting cheaper for sure! While that's certainly not the cheapest, it's now within reach of small startups/passionate makers which is exciting!
More likely in 50-100 years is manufacturing capacity in space gets to the point that building a 1u satellite up there is way cheaper than sending from a deep gravity well like Earth's. I imagine at some point, rockets will only be used for sending people and other things that can't be transmitted or manufacturered.
Still going to pay transport costs on getting raw materials to space, although I imagine raw mats will be densers and the volume savings will reduce costs.
But on currently on earth we have many massive factories to collect, refine, and process just the raw materials. Those factories will require massive amounts of resources to boot, and we don't start with any resources in space....
Right, so it's a bootstrapping question. If this was your long term goal, you'd right now be working on reusable rockets that you'd soon be using at cost to send up large quantities of infrastructure (cough cough Blue Origin and Space X, Space X being further along and openly talking about Starlink). Next step is mining asteroids for stuff like platinum and dropping it down to earth. Step after that is manufacturing with those raw materials in micro G. Now you have a complete manufacturing chain without gravity wells, and ostensibly a multi trillion dollar company.
You'll either need a mesh network (higher latency) or you'll need a backbone (which is an ISP) so you'll still run into similar issues. Not to mention at the lower bands you have limited bandwidth, not just for yourself but for everyone, so bandwidth congestion will become a huge issue if everyone used it for internet.
That said I do hate my ISP (and most others) with a burning passion so...
Could a mesh network be created on existing WiFi hardware? For example with a firmware refresh / OpenWRT? Then it’s just a matter of mass adoption / critical mass in neighborhoods.
I'm going to use Java, the tricky parts will be to build the frequency hopping (for me 410-525MHz) + power lowering (-1-+14/+20dBm) parts so that densely populated areas can function properly.
Largely NodeJS with https://www.npmjs.com/package/serialport but for some of the more ethernet-centric integrations I've been using C++. I haven't gotten to dynamic frequency setups yet, I've actually been lazy and using 2 of these on each side to act as separated TX/RX in different frequency bands. Certainly doesn't scale past a dozen but it made things a lot easier to get started.
I'm curious on your choice of optimization algorithm to balance cell size/interference with relay congestion.
You have access to this, you just don't want it. I like the cushion of corporate incentive which holds up the vast majority of the internet infrastructure. It is very inexpensive to access it, and it remains relatively open. Just because you don't have experience operating or directing a corporation, doesn't mean they are all evil entities which ruin everything.
Can you have a "Hamnet BBS" and if so, do you need a separate radio for each "line" ? Or can the BBS have a single radio that shares incoming connections on different sub-frequencies of (whatever band you're using) ?
This is on the 70cm band so basically line of sight. The curvature of the Earth is the limiting factor (but you can always bounce it off something reflective in the sky; see meteor scatter, airplane scatter, moonbounce, etc.)
You don't need a separate radio for each "line". It's not like a BBS running directly on your modem - you have multiplexing and packet routing, so a single physical channel can accommodate many logical connections.
I’m so happy to see something like this! Communication engineering is a field which impacts everyday life all over the world and more people should have a chance to learn about it. Open hardware and software is an excellent resource.
I'm F4HDK, the creator of these NPR modem. The unprotected telnet access is only for local management, especially when you connect only 1 PC to one NPR Client modem.
If you need security for accessing configuration/management features of the modem, then you can deactivate the telnet server inside the modem, and put a R-Pi dedicated for that feature, which will be plugged locally to the modem via USB. Then you access the R-Pi via SSH. This is explained in the "advanced user guide".
But of course trafic will be kept unecrypted, due to amateur-radio regulations. (telnet is only for management-configuration).
Maybe (I'm also a HAM licensee) but making a device available on a IP network without any authentication and weak protocols such as telnet doesn't justify this.
I love the concept - I've been working on something similar myself using an MMDVM (with custom programming) and a pair of Icom mobile transceivers.
My only comments from reading the protocol spec -- and I need to emphasize, this is one British ham's opinion and is worth precisely what you paid for it, i.e. nowt :)
- Data whitening is a great addition. Too few ham protocols use this, and as a result it's a pain to find suitable transceivers (other than ham-spec ones) for them on the used market.
- Forward error correction scheme looks a bit weak. Nice compared to most ham protocols though (which sometimes just have a CRC).
The main thing is, if you get a burst error which straddles two blocks, you lose block N's CRC and block N+1's first few data bytes -- which would be uncorrectable.
- It'd be nice to see some narrowband modes, maybe 8Kbps in a 12k5 narrow channel or 16Kbps in a 25kHz channel. With 45kHz deviation 360kbps 4GMSK (Mode 22), you're looking at 270kHz bandwidth. That's pretty darn wide! So wide, in fact, it wouldn't be reasonably usable in the UK if you wanted to adhere to the RSGB Bandplan.
I think it should be possible to get some pretty big improvements in error correction by using a better error-correction code (POCSAG's (31,21)BCH code would be a good starting point) and employing bitwise interleaving.
The idea is -- you'd add the error correction first, then interleave the bits. This means that when you deinterleave things at the other end, any burst errors will become single-bit errors in multiple codewords. Single-bit errors are much easier to fix than bursts!
8:1 interleaving with POCSAG's error-correction scheme would give a 21-byte packet size inside a 32-byte transmitted block (giving ~67% efficiency or ~33% overhead). It'd be able to correct up to a 16-bit error burst thanks to (31,21)BCH's ability to correct 2 erroneous bits. This is, actually the same method used by the FLEX-TD paging protocol (documented in ARIB standard RCR STD-43) :)
73's, de M0OFX :)
EDIT: Forgot to show my working, oops! The GFSK occupied bandwidth formula I used was from here: https://www.silabs.com/community/wireless/proprietary/knowle... (bear in mind GMSK is GFSK with the requirement that the modulation be phase-synchronous, i.e. data changes only occur when the IF/RF is at zero phase)
I just calculated the OBW of Mode 24 (4GMSK 500ksym/sec). 750kHz! That'd be 30 of the 25kHz Digital Comms channels... yikes. I'd expect complaints from local hams about the QRM.
I would be concerned about unintentionally running afoul of FCC regulations since encryption is not allowed on US amateur frequencies, that means using something like SSH or loading an SSL webpage with this modem would be a violation. I would also be very concerned with the OS background processes that may use encryption by default.