firmware VS chirpstack

This is a fantastic idea, thanks for sharing. I feel like LoRaWAN and LoRAMESH are the perfect solution for shuffling messaging around for home and property sensors, easily traversing a couple miles in poor conditions.

Prior to seeing this I was thinking about how to use the Meshtastic [0] project to fundamentally provide simple UDP services for message brokering over LoRa. There are so many sensors that could easily hook or connect to devices acting as network routers that could bridge other protocols across long distances very easily.

Have you looked at doing something similar with ZWave at all?

[0] https://meshtastic.org/

Truly independent peer-to-peer internet when?

Seriously, I think more and more about building a LoRa network with friends. https://meshtastic.org/

Agreed-- at least relaxing the restriction for UHF/SHF signals on a "secondary usage" basis (traffic must yield to plaintext). Potentially with with reduced power (say 100w) or minimum directionality, but I think a 'secondary usage' would be sufficient. Without doing so virtually all experimentation will continue to be deflected onto the ISM bands and we will lose our allocations through disuse.

So long as identification is still decodable, spectrum usage can be managed.

It's sufficient to prohibit commercial usage you don't need plaintext to do so. The old threat of tow trucks and cab services moving onto ham-bands had long since been mooted by ubiquitous cellular, but even if it weren't any significant commercial usage will eventually have a whistleblower. Usage that is obscure enough to not be vulnerable to whistleblowers could also be hidden just as well in "plaintext" traffic that was really uncrackable steganography.

As it stands you can't even lawfully log into your own personal systems over amateur radio even if you take the unreasonable steps of using specially modified software to authenticate-but-not-encrypt because inevitably some third party will send a message to you via the internet that contains some naughty words that aren't permitted over the radio.

Without relaxing the encryption rules, innovative radio usage like meshtastic (https://meshtastic.org/) will continue to be pushed onto ISM bands where (1) they're still technically unlawful because the homebrew hardware is not type-accepted (amateur bands are the ONLY place where homebrew intentional radiators are allowed!) and (2) where the band choices, power limit, and EIRP limits are detrimental to full exploration of the possibilities.

Besides, the FCC has long allowed proprietary, license fee bearing, patent encumbered digital modes. These are very close to encryption in terms of their ability to lock others out of ham comms, and have frequently been used by amateur radio groups to establish "lid free" communications channels. (Because most of the more irritating people aren't technically sophisticated enough to adopt some new mode without help, and people won't help them...).

The rules as they stand punish honest people who follow the intent and spirit of the rule in favor of people willing to just ignore the rules (including operating unlawful devices in ISM bands), willing to use stego, or willing to use obscure protocols to achieve the same ends that they'd otherwise achieve with encryption. It blocks modern networking by disallowing standard internet-grade software use with radio since all of it has integral encryption which generally can't be disabled to prevent downgrading and cross domain attacks in contexts where the encryption is needed -- or because in some cases the protocols are designed in such a way that authentication without encypherment isn't possible.

Meh.... very very low range.

For ~$20 you can get a LoRa dongle and https://meshtastic.org/, and with some luck (someone putting a node on a hgh building or a hill), you can reach quite impressive distances.

Meshtastic (version 30109): An inexpensive open-source GPS mesh radio for hiking, skiing, flying, marching.

can you help me please? I wish to use the Postgresql database I installed using "apt install..." locally on the machine in a container of a Chirpstack. IP of my machine is 10.0.2.45 and Postgresql is running on ports 5432 and 5433. I know I should be able to reach it because I made a container in the same docker network 172.19.0.0/16 and installed postgresql client to try to connect to a database on the same machine 10.0.2.45 and it did. But then I try again multiple time with chirpstack and I keep getting this error: ... 2023-03-12T21:24:30.454103Z INFO chirpstack::storage: Setting up PostgreSQL connection pool Error: Setup PostgreSQL connection pool error Caused by: timed out waiting for connection: could not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 5432? could not connect to server: Cannot assign requested address Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 5432? 2023-03-12T21:25:02.132215Z INFO chirpstack::cmd::root: Starting ChirpStack LoRaWAN Network Server version="4.3.0" docs="https://www.chirpstack.io/" ... and then it restarts again and again.

I "play" with LoRa and LoRaWAN devices for work so can add a few comments here to help you on this. Apologies if I'm repeating stuff you already know. LoRa (I'm going to use LoRa and LoRaWAN interchangeably cause I'm lazy) is a small packet unidirectional periodic communications protocol. More accurately you can talk to it from the gateway to the device but for class A it only opens for a very short period after it transmits, class c is always receiving but at the cost of battery life. Because it uses small packets it has limited things to send (and is encoded so needs to be decoded at the receiver so to make it simple you will want to limit what is sent). It is NOT for real time communications ie send and receive now. I have seen an article which suggested using LoRa instead of pagers for emergency services but that has limits. In terms of the system you would require to make this idea work you would need gateways (or access public gateways if available), a server stack so either Chirpstack if you want to run your own server and device manager, or use the Things Network for a managed server more info on servers. Each device that you want on your network needs to be activated and registered which if you are thinking of making it widely available becomes difficult in managing and scaling. In terms of security it's pretty good. I had a 15 second look at that link someone else has posted and have made a LoRa device with the FiPy, it's easy to get going (lots of python libraries and example code) but challenging to program well. As I said I've done a lot of research and playing with these trying to build a private network for work; I've tried to be concise but hopefully covered most things. Ideas for disaster work are critical so even if this idea doesn't pan out keep up the good work and keep the ideas coming.