Notifications
Clear all

Proposed Project: Bi-Directional Command and Telemetry System


MicroPaul
(@micropaul)
New Member
Joined: 6 months ago
Posts: 3
Topic starter  

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 6 days ago by MicroPaul

Quote
Inq
 Inq
(@inq)
Reputable Member
Joined: 3 months ago
Posts: 394
 

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, Access Point 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


ReplyQuote