Skip to content

Off-beat use cases

Most use cases for the ManT1S would involve a few ManT1S boards and probably a ManT1S-Bridge forming a distributed system, but this surely doesn't need to be the case. Both the ManT1S and ManT1S-Bridge have some great features that make them useful in their own right!

A single ManT1S by itself?

Why would you ever use a single ManT1S by itself? Well, it is a pretty full-featured ESP32 board: a powerful dual core 240 MHz microcontroller with 8 MB of flash and 2.5 MB of RAM is nothing to sneeze at! With the integrated U.FL connector, both WiFi and Bluetooth are just a cheap 2.4 GHz antenna away should you have a need for them. And what about that amazing power input stage? There are very few boards out there that are reverse polarity protected and can handle power inputs from 5 V all the way to 75 V!

A ManT1S powered from a bench power supply set to 75 V

Great for automotive use where you need to be able to survive load dump scenarios. You can use the screw terminals as your power input—very convenient. But this power input comes with hidden powers: it can double as a communications channel as well! Imagine a few scenarios.

Say that you want to install a device in a difficult to reach place. Once it's installed, all you can easily access is the power cable that runs to it. Now imagine that you need to update the firmware on the device. If this was based on any other micro, you'd have to find a way to physically access it. But if you base it on a ManT1S instead, you just disconnect the cable from the power supply, connect a ManT1S-Bridge instead, and you can now simply OTA update new software to your device! This cable may just supply power for 99% of the time, but you'll especially love its extra powers that 1% of the time that you can save yourself a major ordeal!

Or imagine that you manufacture a device that you sell, and want your field techs—and nobody else—to be able to update or configure it. Your device just has a barrel jack on the case that your customer uses to power it (internally connected to a ManT1S). But your tech has special equipment (also based on a ManT1S!) that can use the networking capability of that barrel jack to do updates and configure the device, without ever opening it up!

Two network interfaces on one tiny board

The dual network capability of the ManT1S makes such scenarios possible, even if your normal application uses WiFi. You could have the WiFi interface be what's normally used by your customers, while the secret T1S interface on your power jack is used as a service port, presenting a completely different (and more capable) interface to your technicians.

Below is a screenshot of a quick experiment you can run on your ManT1S once you receive it. The T1S lan object is already configured by boot.py script on startup. In the following screenshot we are also starting a WiFi connection managed by an object called wlan:

wlan.ifconfig() shows IP 192.168.1.180 and lan.ifconfig() shows IP 192.168.1.183

As you can see, the WiFi and T1S interfaces each were given a separate IP address, and are active at the same time. Here I show pinging each one of them in turn:

ping 192.168.1.180 shows latencies from 8.5 to 88 ms, ping 192.168.1.183 shows latencies from 2.71 to 2.99 ms

As a side node, also notice the significantly lower latency on the T1S connection versus WiFi. Wired FTW! :)

Below is a simple piece of example code that shows how easy it is to present completely different web UIs on each network interface using Microdot, once you have both network connections established as lan and wlan:

import asyncio
from microdot import Microdot

app1 = Microdot()
app2 = Microdot()

@app1.route('/')
async def app1_index(request):
    return "Hello from app1"

@app2.route('/')
async def app2_index(request):
    return "Hello from app2"

async def main():
    await asyncio.gather(
        app1.start_server(host=wlan.ifconfig()[0], port=80),
        app2.start_server(host=lan.ifconfig()[0], port=80)
    )

asyncio.run(main())

The app1 web server is started listening on the WiFi IP address, while the app2 web server is started listening on the T1S IP address. When you point your web browser to http://192.168.1.180/ you will see "Hello from app1" while at http://192.168.1.183/ you will see "Hello from app2". Both served from the same ManT1S, but you can have completely different UIs and security levels on each interface!

Using the ManT1S-Bridge without a ManT1S

And what about the ManT1S-Bridge? What use could it possibly have that doesn't involve a ManT1S-based distributed system?

The ManT1S-Bridge is a transparent network switch, traffic goes both ways. Ethernet to T1S, T1S to Ethernet, it doesn't care. Also, the ManT1S-Bridge is a normal T1S device, so several can be daisy-chained together on a mixing segment just like you can with multiple ManT1S'es. This allows you to use back-to-back ManT1S-Bridges or create heterogeneous distributed T1S systems where some nodes are based on a ManT1S while others have a ManT1S-Bridge that converts the network back to Ethernet + power, to use with off-the-shelf boards such as a Raspberry Pi.

Below is a video I made to demonstrate this functionality. It has a ManT1S-Bridge powered from my PoE switch, with its T1S side connected to a second ManT1S-Bridge working in reverse. The PoE power put on the mixing segment by the first bridge is extracted from the second ManT1S-Bridge's auxiliary header and converted to 5V for the Raspberry Pi, while a short Ethernet cable connects the reverse ManT1S-Bridge's Ethernet to the Pi.

Youtube video demonstrating ManT1S-Bridge to ManT1S-Bridge to provide power and networking to a Raspberry Pi using a single pair of wire

This is just showing the simplest case: bridge-to-bridge, with no ManT1S involved. But you can mix and match ManT1S'es and Bridges as you see fit on that T1S mixing segment. The possibilities are only limited by your imagination!

Another view of the bridge-to-bridge demo setup