I like how this looks. I think it will offer significant functionality. I can’t want to experiment with it. Of course, I still need to wait for my uConsole to ship…
Last time I checked they haven’t released the case STL’s yet, but my plan is 3D print a new back cover with a GPIO controlled fan for heat and to attach the antenna in a purposely thinned out spot. I like this PCB idea also, but I’m probably going to make a tumor with a single joystick, a couple shoulder buttons and a lora module over spi or something.
I’ve purchased the SUDOMaker loShark L1x1 development dongle - it has a library for python and interfaces by USB . it’s an external device so I’ll let the forum know… but a built in Software defined Radio or GPS would be so useful - another thread but additional USB etc are being looked at…
I’ve looked at this as well - going down a host /terminal approach at least exploring the possibility - for the the ESP/LORA digital weather station I built Iwant to add a webpage/ gui control for it… right now it uses an onboard display but with the ESP 32 architecture you can set it up as a hot spot with a web terminal… Does Meshtastic have a linux user interface - I have a couple of Meshtastic nodes but am limited to Iphone, Android interfaces.
True, but not for 1080p video or similar content. Also 300Kb/s is probably a best case speed at short range.
For a radiomesh you need to limit sending per channel and use many channels instead. That way you can scale the networks entire bandwidth to maybe 5Mb/s but when saturated you need to remove intense traffic from the network entirely or use very broad spectrum, I think eventually spanning from 169 all the way to 433 and possibly even 915!
I have 2x 169MHz LoRa GPIO hats on the way and will start implementing http://radiomesh.org “soon”.
@tinspin So… I’ve found the decentralized mesh network thing cool for a long time. I’ve also thought about LoRA being a great candidate for such a thing too.
Thoughts and lessions from Helium:
LoRA is nonstandard when not using LoRAWan. Standardize early on what channels, etc.
Hardware MUST be cheap and plentiful for anyone to adopt it. More nodes, more better.
The alternative to this is making the nodes “make money” to encourage people to run them. Helium network did this and took off quick, but it ended kinda pump-and-dumpy.
Anyone needs to be able to stand up a node without specialized hardware.
Helium gatekept keys since there was room for abuse in the making money thing, which ended up on a few gatekeeper scammers selling $800 “mining radio devices” which were arm SBC’s with LoRa modems strapped to them.
Software has to be easy. Anyone should be able to standup and configure a node without a ton of advanced configuration. Avoid Python, Ruby, Shell scripts, etc… Node software ideally could be go-lang or Rust. (portable, static binaries, type safe, etc)
And for usage… the maximum LoRA speeds are slow. Don’t target http, it’s too bloated. Target gemini. It would be a great fit in extremely low-bandwidth situations and has a cool feel to it matching the uConsole .
Err… I think control channel hopping is a LoRaWAN spec thing. You can also do LoRa without the WAN and broadcast on static upstream channels (and listen on static downstream channels)
LoRaWAN comes secured though… and you have to issue up security keys. In your mesh model with LoRaWAN, all nodes would need to have pre shared encryption keys or do self-registration.
Yes. Keep in mind though throughput on a single channel is limited by the number of local devices speaking on it. (27 kbit/s is max for a single channel, if you have 8 nodes on the single channel, they all chirp on the same channel with a combined max of 27 kbit/s)
For those of you wondering why… LoRa can do several miles of range best case (vs wifi’s 150ft)