I am currently in the early stages of a project to create high visibility, WiFi or LoRarWan activated and LoRaWan connected highway safety devices.
Technical GPTs have produced recommendations to this point but proper validation and an implementation plan will be required.
The proposed plan at this point is to use a Pi 4 microcontroller, high lumen LEDs, WiFi modules with hosted page for primary local activation and LoRaWan 1.1 communication modules for connection with remote monitoring. Further iterations will develop v2x and other advanced communications.
LoRaWan 1.1 is intended to establish a self healing, easily extendable network along roadways and extend the range between gateway devices.
The project site (such as it is) is at https://beaconsafe.ca should you wish to look.
A most excellent idea but maybe not for a LoRaWAN install. LW is very very good at lots of small battery driven sensors sending data up to ‘the cloud’. Pretty much anything else starts a rocky road of small compromises. And due to the asymmetric nature of the RF, not good for command & control.
If you are roadside you have to do what with your phone to make this happen? Select the access point if you are in range of a sign and then press a button to turn on the lights?
Nope, no, not even a little bit. Each device is entirely standalone. Self-healing is the sort of buzz phrase used by the mesh network jockeys - which does work but always needs far more overlap of devices than people hope for.
Yes, subject to being able to place gateways on a backhaul.
There is NOTHING in 1.1 that extends the range of gateways which we don’t postfix with the word devices as ‘devices’ are the end nodes.
Using the 915MHz ISM band is not recommended for anything that has to be reliable as its shared spectrum that anyone could turn up and transmit a lot because they aren’t good at sharing.
Bulk cellular modems & SIMS would be my command & control choice - possibly with a LoRaWAN device as a side-channel to report any issues. But I suspect that both cellular & LW coverage may be a challenge in some areas, but with various satellite IoT tech you can fill in the gaps.
In the earliest version, yes, a smart device will connect to a beacon and push a button to activate. WiFi is planned because of ubiquity and standardization. Later iterations will develop other activation methods.
For a variety of reasons, in most applications the beacons will likely be at ~500 m intervals on alternate sides of the road. Shouldn’t that placement also create sufficient redundancy for most applications?
The alternate communication methods that you’ve mentioned have been considered and implementation of them is intended where appropriate but LoRaWan 1.1 seemed to make the most sense as a common backbone for redundancy in areas where other primary communications can be used and as a primary in areas where other coverage is unreliable. The potential subscription costs of other communication methods is also significant for larger deployments.
Given those considerations, is there another backbone for connection that you’d recommend?
Having been on the Rocky Mountain train for 10 days plus watching snippets of Ice Road Truckers, I’ll go with “yeah, sure, except where it won’t” ie, I guess it might but I’m not going to put any money on it. Most of these radio technologies are line of sight - so you’re going to have to do a survey.
The typical topology of LW isn’t a long line of devices - usually the gateway is at the centre of a circle, with other overlapping circles of other gateways. And a gateway out in the middle of no-where will need power & access to the internet - and line of sight in many of the bumpier bits of CA precludes means a lot of gateways.
And this plethora of v1.1 devices, where are they on the market? Making choices about things has to be done in a holistic matter. Otherwise we’d all choose a satellite microwave link for which there are devices, but at a cost. Most LW devices are on either 1.0.2 or 1.0.3, a few on 1.0.4 for which there is an actual relay function possible and almost none on 1.1.
We’d strongly recommend NOT running the stack on a Pi due to timing issues so you’d need a sub-processor to run the LW comms but that’s simple enough. And for a fancy display of LEDs a Pi is well overspecified and you have to deal with flash card wear issues. And then there are temperature considerations - the batteries have to cope with some extremes.
Any well programmed firmware can cope with LW link check (built-in) and escalate to doing a rejoin if appropriate which it rarely is - the gateway(s) are either there and the session will just keep on going on the LNS in the nice warm data centre, or not, which means there isn’t anything to hear the join request.
I have First Responder experience, most people involved in an RTC or stress situation aren’t going to be up to selecting a WiFi access point. Choosing WiFi can’t be done programatically on an app, the user can be prompted but they have to make the change. BLE can be done but has shorter range. SMS can be programmed and even with virtually no signal often gets through. I’d go with an app + WhatsApp chatbot + voice line to access the service - which could then use LoRa/LW/Cellular to get the message to the lights.
There is so much more research to do on RF & LW realities - which may not be the feedback you were hoping for but unless you write a spec & commission someone to build a prototype, you will need to get in to the weeds to see what’s possible. This may involve technologies that we don’t discuss here as it’s LW on TTN/TTI only, but a mesh based LoRa network that can relay messages up & down the road may be feasible - and provide enough overlap to deal with dropout & range issues.
The concept is fine, but it’s going to need some proof of concepts creating to find out what works in reality at -25ºF
Your thoughts are greatly appreciated and give me much to think on.
As I mentioned, at this point it’s exploratory and very subject to change. If things develop further and TTN seems appropriate, I’ll be back to ask and explore more.