I wanted to control a farm gate over LoRaWAN. I’ve been using WiFi but the setup is horrible and it drops out a lot as it’s a far distance.
But I’ve recently been reading about the limitations, mainly on the down-link. If I can only send an open/close/keep-open command from a PC to the gate a maximum of 10 times a day, that would probably prevent me from going ahead. Usually it’ll only be opened/closed no more than 5 times a day, sometimes less, but I don’t want to invest in the time and money of setting it up if that one day I need to open it an 11th time, it won’t work…
I was wondering if these regulations are in place, and if they will always be in place? What can I do about it?
I wanted to have some sort of UI hosted elsewhere, possibly at home which I can access over the internet. Probably just a basic site. This can control the gate. Originally my plan was to have the gate send some data such as battery voltage, solar output voltage and gate status every half hour, but when you send an open/close command to the gate, it’ll response to acknowledge it, and once it finishes opening or closing, once again send a bit of data to say it opened, closed or failed.
Is all this too much data to be a possibility?
Currently I’m using an ESP8266, hosting a web server on board to control the gate, but there’s a lot of issues. So if I could use LoRaWAN and move the web UI onto a separate server with a direct internet connection I would love to.
Also I read somewhere that Class A devices can only listen for 1 second after sending a command for downlink data, but Class C devices can receive data at any time. Obviously for a gate it would need to be Class C, but is this allowed on TTN?
Sorry for all the questions. Thanks for any help in advance. Hopefully this can still work but I am doubting it with these limitations.
At the moment I’m using WiFi + HTTP Client on the ESP. I just wanted to switch to a more reliable way to transmit data to the gate, while keeping the gate connected to the internet. That’s why I thought LoRaWAN would be a good choice. I can still have a web interface that tells the gate to open or close from anywhere on the planet.
I already have a 433Mhz remote to open the gate when I’m in range. But I also like to be able to control it from elsewhere, when I’m far away, which is why it’s currently connected via WiFi.
I also have a weather station I built that also connects to WiFi. It’s outside, probably no more than 50m away and thought it would be a good project to have it use LoRaWAN.
But if these are too short range, what use is LoRaWAN? I’m in Australia but I couldn’t think of many other uses. Any further away and I would be putting devices in other peoples property.
there are many other uses, especially on a farm, you can put sensors on your land, cows, machinery ect.
ok off course you can control a gate over lorawan, but as you stated the gate should be always listening hence you need class C and that is not operational on the community network @ this moment.
Once Class C becomes available, do you think controlling a gate is still sensible? Or is it incorrect usage of LoRaWAN? I guess also the rules are not set in stone, regarding down-link limitations? Because of course, if there’s a limit of 10 down-link messages, it is basically impossible to use for a gate. Thanks for the help and information, by the way.
It’s probably not a great use case unless as @BoRRoZ hinted you are doing other useful things around the farm. Whilst 100m may be short range in this context if you have more distant gates then that is a possibility. Just remember that TTN =/= LoRaWAN & LoRaWAN =/= TTN, though as one of the high profile examples and by virtue of being on this forum people often confuse the two! TTN imposes its own FUP that limits use cases beyond any technical and regulatory limits inherent in the LoRaWAN technical implementation. (Hence the 10 DL limit motivated in large part by fact when GW tx’ing it can’t listen to other people’s nodes making it deaf and antisocial for others if over used). However, please be respectful of the fact that just because the regs & tech will allow the use of more down links on other networks or private instances that doesn’t mean you should abuse…spectrum & GW capacity is limited & precious!.
If it helps any from prior history I know of a hill farmer who has a water level sensor on a cow trough close to a gate, and where he is also measuring rainfall and temp/humidity, wind speed/direction etc using a small LoRa connected weather station run off a small solar panel with back up battery. His system sends data every 20 or 30 mins I think, and when he knows he is heading up there he hits a bit red switch in the farmhouse (he jokes it is his ‘nuclear button’!) that schedules the download msg on next uplink to open the gate before he gets there…typically a 30sec to 20min latency avg 10 min, which is fine as by time he is togged up, wellies on got tractor or quad bike out of shed loaded feed and headed off the gate is open waiting for him. He thinks it speeds up things for him and more importantly he doesn’t have to get out of tractor cab in inclement weather to fight opening the gate but get gets through delivers feed etc and heads back to base and the warm asap!
Obviously he is doing this on Class A devices/network using the RX1 & RX2 Windows, YMMV.
Yeah I don’t want to abuse the spectrum, even though I’d be the only one in the area using it. Can I use the hardware (915Mhz) another way? Not sure how to explain it but use it with different software, reduce the radio power, etc? I’ve got one of the Core Electronics uGateway units and an Arduino MKR WAN 1300. Can I use the equipment in a different way that better suits my needs? WiFi is too short range but LoRaWAN is a little over the top. We need LoRaWAN Lite.
@aaroncm, while TTN doesn’t support Class C, you may find Lora may be a better solution than LoraWan. This would support a simple open and close command for your gates along with an acknowledgement. As soon as you start adding a Weather Station and extra data from the gates like Battery Voltage, Solar, etc etc you are adding complexity and LoraWan starts becoming attractive again.
Be aware the rules in Australia regarding maximum duty cycle are different than in Europe…
Which State are you located as there is an active community both in Adelaide and rural South Australia who could assist if you are nearby.
I’m in Western Sydney. I do definately want to add more stuff around the yard. The gate, weather station and maybe some yard lighting. Just because I can.
But I’m open, if lorawan is better to use for all this together I’ll stick with it, but I assume I’ll still have to wait for class c support?
No reason why you can’t run both. As an interim strategy run the gate open/close on Lora and the rest of the yard on LoraWan and migrate across when Class C becomes available.
Thanks for the advice. I’ll look into it. The only other thing I’m worried about is the imposed limitations on Class C once it’s available but I’ll guess we’ll just have to wait and see? Just hopefully not a 10 message limit.
The government regulation on air time and therefore duty cycle is different in Australia compared to Europe. The comes about as there are only 8 channels available in Europe compared to 64 in Australia. It would require a lot more traffic to reach the same level of congestion in Australia so the regulator has not imposed the same restrictions. Similarly the maximum allowable transmit power levels are higher here as well.
As a result a LoraWan system has different configurations in each region.
I’d expect it’s still the same low limit for the public network, as like mentioned:
Gateway’s won’t suddenly become full-duplex when V3 is introduced in the community network.
A private V3 instance won’t have these limitations though, and can be set up to roam with the public network, some day.
Something else to keep in mind: without an uplink to trigger a class C downlink, it’s not clear to me which gateway(s) will be used to transmit the downlink. I guess TTN selects one of the gateway(s) that received the last uplink, whenever that was, but I’ve not peeked into the code to validate.
Agree, GW’s typically 1/2 duplex by design & implementation…full duplex is theoretically poss but extremely expensive & impractical to implement in this tech due to proximity of channels & rf co-channel interference, plus need for separate tx & rx antennas with significant location separation to avoid front end overload/destruction and can never be full duplex on same bands!
That sucks. Would anyone know of any other system I could set up that better suits my needs? Possibly compatible with the lorawan hardware/915Mhz? I’ve been searching around trying to find something but I’ve had no luck and don’t really know enough about radio, duty cycle, etc to choose. I really wanted to use the Arduino MKR WAN 1300. I think I’ll have to stick to WiFi and send back the lorawan gateway.
Just want to be able to set up a few devices up to a couple hundred meters away and be able to send a few Kbps (or even bps) both ways and only have 1 gateway and maybe setup a MQTT server to interface everything, and some sort of security/encryption.
Hello aaroncm,
If you’re into HW and getting your hands dirty with coding and Arduino type boards and only interested in P2P, you can use LoRa wireless modules to talk to each other directly and easily. The Microchip RN2903 (USA made, manual good) and RAK811 devices are very similar, and can communicate with each other on the 915MHz AU band. RAK811 China made and manual a bit sub-par, but good enough. RAK has configurable band but RN2903 fixed to 915MHz = AU okay.)Take your pick. They both work well. They’re easy to talk to via serial from an Arduino or any other micro processor bd. Download the programming command manuals for these two devices and have a read in the P2P sections. Just create you own handshaking code. For the application you describe, the ESP8266 is not the device for you I’d say. Unless you want to make your own gateway. Both modules above are XLNT devices. The value for money is incredible.
Depending on the region, beware that for a DIY solution one might need to implement some Listen Before Talk, or even some channel hopping when using high output powers. For example, for US915 the LoRaWAN 1.1 Regional Parameters document summarizes:
915 MHz ISM band end-devices are required to operate in compliance with the relevant regulatory specifications, The following note summarizes some of the current (March 2017) relevant regulations.
Frequency-Hopping, Spread-Spectrum (FHSS) mode, which requires the device transmit at a measured conducted power level no greater than +30 dBm, for a period of no more than 400 msec and over at least 50 channels, each of which occupy no greater than 250 kHz of bandwidth.
Digital Transmission System (DTS) mode, which requires that the device use channels greater than or equal to 500 kHz and comply to a conducted Power Spectral Density measurement of no more than +8 dBm per 3kHz of spectrum. In practice, this limits the conducted output power of an end-device to +26 dBm.
Hybrid mode, which requires that the device transmit over multiple channels (this may be less than the 50 channels required for FHSS mode, but is recommended to be at least 4) while complying with the Power Spectral Density requirements of DTS mode and the 400 msec dwell time of FHSS mode. In practice this limits the measured conducted power of the end-device to 21 dBm.
Devices which use an antenna system with a directional gain greater than +6 dBi, but reduce the specified conducted output power by the amount in dB of directional gain over +6 dBi.
And:
Note: FCC regulation requires hopping over at least 50 channels when using maximum output power. It is possible to have end-devices with less channels when limiting the end-device conducted transmit power to 21 dBm.
Other regulations apply to other regions. One of the beauties of LoRaWAN, when one’s use case allows for it, is that all those regulatory limitations have been investigated by the LoRa Alliance. (Even when not explicitly noted in the LoRaWAN documentation.)
Hopefully this can still work but I am doubting it with these limitations.
