Hello, I'm new to this forum. I hope I'm posting this in the right place.

I'm working on a project that involves the GPS location of safety lights on radio communications towers. I need to show on Google maps the location of each tower, the current state of the lights and battery state.

I'm thinking in using an Arduino Nano, a GPS Ublox 6 ,SIM 800l V2.0 GSM GPRS and Lora DRF1276DM modules.

The idea is to send data through the GSM Network to a WEB Server and in case of no availability, use the LoRa backup to send the data to the nearest tower with connectivity.

The Nano boards will act as clients to the Web server. To protect the info I need some kind of encryption/authentication, what's your advice on this?

It would be nice if the server is located on a local telecom, but if this is the case, I’ll have to log in into a VPN to access the servers.

To visualize the data I’d like to use a Simple web page with a link to google maps and some relevant info, like the current state of batteries, the cell phone availability and some kind of log to know the last month data.

I was planning on using a database server in order to do this.

Do you think I'm on the right path? Any suggestions will be highly appreciated.

Thank you for your time,
have a nice day.

 

Am I right in thinking the battery you refer to ('battery state') is a backup battery for the safety lights in case of main supply failure? Is there an internet connection to the tower or is this going to be totally standalone communicating only via GSM with Lora backup? What are the required response times? In general your approach is sensible. I'd use a messaging service like MQTT to transmit the data from the tower to the central repository with a local mySQL db on the central server, packing the data tightly to minimise packet size and encrypting it with a simple hash. The mesh implementation via Lora has been done before - here's one simple example . Another option would be to drop the GSM and have dual Lora modules on different channels transmitting the same MQTT messages over parallel meshes. Integration with google maps is relatively easy.

One issue to be aware of - the SIM800 is 2G. Most networks will be dropping 2 and even 3G in the near future...

 

Yes its the backup battery and the bank of batteries from the tower. Sometimes they are on the middle of nowhere on a hill.
The tower has 2G/3G/4G capabilities and you are right that I might be thinking in 3G because 2G is disappearing . Do you know something similar to the SIM800 but 3G so I can use it with the Nano or the ESP32 (I like that I can use almost the 80% of the IDE from Arduino).
The response times are not critical. The GPS part is for "geofencing" to avoid the lights being stolen, and to locate each tower on the map.
You are right that MQTT is the standard.
Ill take a look at the mesh example.
What flag would you take note, in order to notice when the modem has lost the connection and switch to LoRa? Is something similar to the AT command that you test on the serial monitor?

Thank your for your comments.

 

Do you know something similar to the SIM800 but 3G

Depends on where you are in the world, but something like the EA01-SG module from eByte which is a 4G-LTE narrowband IoT device with integrated GPS would be my choice. Its intended for low-datarate intermittent transmission like smart meter reading applications.

What flag would you take note, in order to notice when the modem has lost the connection and switch to LoRa? Is something similar to the AT command that you test on the serial monitor?

I'm not sure there is a specific 'flag' as such. Using MQTT is an intermittent connect-TX/RX-disconnect protocol which doesn't assume a permanent link. Normally you'd have an acknowledgement message response which confirms your last message was received and a timeout to deal with 'no response'. Or transmit via LoRa and LTE simultaneously and let the central system handle the duplicate messages. You have to ask yourself why you need both GSM and LoRa? Is it redundancy against a single point of failure? In which case you need two Nano's or better two alternative MCUs, one doing GSM, the other LoRa so there is no single point of failure, at least at the tower end. A single Arduino handling both transmission routes make the Arduino, and specifically your coding, a single point of failure.

 

A single Arduino handling both transmission routes make the Arduino, and specifically your coding, a single point of failure.

You are right. I should consider that redundancy to avoid a failure. A watch dog timer will come in handy?

 

You are right. I should consider that redundancy to avoid a failure. A watch dog timer will come in handy?

A WDT should be part of your default armoury!

 

For LoRa, there are many purpose built development boards that will offer advantages making them far superior to the Nano. In particular, LilyGo’s TTGO products are very good.

If you are very concerned about maintaining contact with each tower, you might consider a supervised architecture where each tower is expected to contact the supervisor at specific intervals so an alarm can be raised if they don’t. You can also use the LoRa mesh to contact the nearest node that has GSM connectivity for backhaul.

You could work out an arrangement whereby the mesh arranges itself so that GSM capable nodes are enlisted as supervisors for their neighbors, and they can actively report a failure to check in back to the master node. That way, you could reduce GSM connectivity cost by leveraging the LoRa mesh for most traffic and using the GSM only as backhaul and/or backup.

I’d look at the LilyGo products I mentioned before for LoRa, and Particle.IO products, specifically the Boron for GSM network connectivity. The Particle ecosystem has a unique feature in that you pay for the GSM capable hardware and a certain amount of bandwidth per month is perpetually allocated to that device. You can deploy up to 100 devices in the free tier. If you don’t exceed these limits there is no airtime charge. It is quite possible that you could design things in such a way that you would very rarely or never pay for GSM bandwidth aside from buying the device.

In each case (LilyGo, Particle) the development board is focused on the communications technology and so is optimized for it. The LilyGo ecosystem is ESP32-based and works with the Arduino ecosystem or Espressif’s IDE. Because it uses the Espressif technology, OTA updates are very well supported as is low power operation. The boards mostly have LiPo charging built-in, and some have MPPT solar inputs as well.

The Particle ecosystem has an online IDE with fleet management and OTA updates. The Boron has 20 GPIOs (operating as analog or digital pins) and does LiPo charging like the TTGO products, but there is no solar option built-in. Particle boards cost more, but they are intended for commercial deployment and as mentioned above they offer native bandwidth quotas for the life of the product. They use excellent SIMs for mobile connectivity with global coverage.

Since you will already have established a communications network, it might be useful to instrument the towers for other things like climber detection, weather conditions (wind, temp, etc.) or something I am not thinking of but the idea being having redundant surveillance and doing something useful with the heartbeat used to effect the supervision.

It will also be the case that the LoRa network established by the system could be accessed from other devices on-site to report data without a wired connection to the main reporting node by taking advantage of the net. Of course, there is also the possibility of using TTN (The Things Network) or the Lacuna satellite as a backup channel for the GSM.