Notifications
Clear all
Topic starter
2022-06-21 6:46 pm
I’d like to propose a project for the Dronebot Workshop. I’ve suggested an implementation, but I’m not sure that what I’ve suggested is the best way to do it.
In essence, this is a two-station, two-way, stand-alone (no PC needed) control and telemetry system, using the public internet to provide a communications path between the two stations. I’ve shown a pictorial of a simple demo system in the linked PDF ( http://ad7i.net/docs/ESP32-MQTT-Remote-220621-01.pdf ). It proposes to use ESP-32s at each end, since they are common, inexpensive, and their availability (so far) doesn’t seem to be adversely affected by the world-wide semiconductor shortage. It also assumes a WiFi cable modem is available at each end to allow the ESP-32s to have access to the internet via WiFi. I’ve also assumed the use of the MQTT protocol with a server in the cloud, but perhaps there’s a better alternative to MQTT for this application.
I’m interested in having the functionality, because I’d like to use something like this to remotely monitor our ham radio club’s VHF radio repeater system (temperature, humidity, battery voltage, battery charging current, battery operating current, battery cut-out, ,etc).
As shown in the PDF, it proposes control and telemetry paths in both directions. More specifically, that a potentiometer at the West station would control the position of a servo at the East station. It proposes that the environmental data collected by a BME280 module at the East station would be displayed on an LCD display (or OLED display) at the West station. It also shows a simple on-off control mechanism with remote assurance monitoring via push buttons and LEDs. The specifics of that are that activating the push button at the West station would cause the LED at the East station to illuminate and the fact that the voltage driver for the East LED went high would cause a signal to go back to the West station and cause the West LED to also illuminate (confirmation that the command to supply voltage to the East LED was actually accomplished). The same mechanism would be included for the East push button controlling the West LED and the East LED illuminating when voltage was actually applied to the West LED.
There are other embellishments that could be added, but I think that a demo project with the functionality outlined above would demonstrate to an MCU enthusiast how to add additional features that may be wanted.
As to the cloud server that would handle the message exchange between the West and East stations, I’d be curious to know what free-service options might be available. For example, if there was only a small amount of data to be passed between the two stations, would there be any free public cloud-based server options? Would it be possible for the “server” to consist of a Raspberry Pi physically located in a residence, if port forwarding was used in the router of that residence and the system administrator of the East and West stations was willing to manually update the IP address of the server when it changed?
Thanks for your consideration of this project.
Paul
This topic was modified 2 years ago by MicroPaul
2022-06-22 1:43 pm
Bill (@dronebot-workshop) is always very thorough to get a comprehensive tutorial put together. @byron finished a tutorial on MQTT https://forum.dronebotworkshop.com/technology/mqtt-broker/ and is my go to guy for that subject!
It sounds like you have a solid understanding of much of the intricacies.
In my workings through Byron's tutorial, it looks like public Internet facing MQTT broker systems are available. Free ones are public facing to everyone. Do you mind having that IP address and all other info and control (push button) publically accessible and modifiable??? Even if you use obfuscation??? Private ones might be pretty cheap considering you sound like you might have a very light data load. Let us know if you go this route. I'd be interested in what you work out.
Another aspect you might want to consider... have you asked your ISP at one end or the other whether they can provide you with a fixed "static" IP address? I had one from my provider years ago... at one point it was free. Later it was an extra surcharge of $10/month. If you do that you can have the other end just access it directly over the Internet and avoid any public servers/services. You could simply put a MQTT broker (say a Raspberry Pi) on that server and just keep everything in-house. I believe you can set up everything using SSL so it would be protected even crossing the Internet.
As you pointed out in your last paragraph, you could always have a third "house" act as the MQTT broker. The main criteria would be getting a static IP address from that house's ISP.
Another option is using a DDNS service. I've never used one, and am a little fuzzy on details (never researched it). You can get/purchase this service and when your house's IP address changes (from DHCP of your ISP) it will update the service DNS database and using a friendly name like www.MyEastStation.com all connections get the current IP address.
That's all I got! Good luck.
VBR,
Inq
3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide
Inst-Tech reacted
2022-06-30 9:56 am
@inq Thank you Inq. I appreciate your comments and the link to Byron.
I see that Random Nerd has an article on installing a MQTT broker on a Rpi - here is the link
https://randomnerdtutorials.com/how-to-install-mosquitto-broker-on-raspberry-pi/
MQTT would be ideal for telemetry. You need wfi or wired ethernet connection, but telemetry rather indicates the comms would need to be robust and high speed so thats probably what you had in mind in any case.
In the closing time of my working life I remember SAP (who produce enterprise level business software) produced some new database technology that was geared for performance. Their main software database for data input was a SQL relational database (usually Oracle), and for reporting this data was often duplicated into a Star based data warehouse. This new database technology (I forget what they called it) was to do the job of both the existing technologies at high speed. McLaren, of Formula One fame, (rumoured to have a deal going where the boss of SAP ended up with a McLaren sports car) showed off using this new database technology to log incoming real time telemetry from their F1 cars back at their HQ in Woking in the UK. Instant displays of performance data for their engineers to digest. Oh well, I reminisce and digress...
Whilst I haven't used MQTT for telemetry yet (but it is intended when I get around to producing an outdoor bot) I have used it to send instant messages to remote microcontroller boards to switch on lights or heating etc to outside workshops and greenhouses etc. and to receive data from remote sensors to be logged into a database etc.
2022-06-30 11:41 am
In the closing time of my working life I remember SAP (who produce enterprise level business software) produced some new database technology that was geared for performance. Their main software database for data input was a SQL relational database (usually Oracle), and for reporting this data was often duplicated into a Star based data warehouse. This new database technology (I forget what they called it) was to do the job of both the existing technologies at high speed.
A little acquisition history lesson... 😆
At retirement, I last worked for SAP (mother company based in Germany)... in one of their many divisions. I was in a group doing Mobile Device Management (in Atlanta, USA). SAP bought Sybase (corporate home in California) which had previously purchased my device management company. I actually joined at the point in the acquisition history when Sybase was still independent.
Our product (Afaria) originally ran on Sybase, MS SQL Server or Oracle. Whichever the customer already had in-house. From a database standpoint, I was a user of Sybase's version, and not part of that division. Sybase developed the database technology of which you speak before the SAP acquisition and was part of the reasons for its acquisition. The performance technology was really not really that ground breaking. It simply put the ENTIRE data storage in Ram memory. Of course it was way faster... several orders of magnitude I would think. The actual development value added was re-optimizing the code to dynamically backup to persisted media in case of power failure. And even that didn't have to be groundbreaking. Any company wanting such a system, shelling out that kind of cash for Terabytes of ram memory, didn't have much problem spending a little more for good backup power supplies to allow, at least a final commit of ram memory to disk to complete.
I return you to your regularly scheduled program now... 🤣 😋
VBR,
Inq
3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide
Inst-Tech reacted