- Member DIN
- S097
This is a thread for discussion of technologies as they relate to the 405th, our booth activations and our armor. I’m hoping that this thread will promote collaboration and help us to solve some of the more technically complex challenges we face in replicating the armor and weapons we see in the Halo franchise. There are some technologies starting to reach maturity that could open up some cool possibilities for the electronics we use in our sets, suits and props.
As an example, I would like to walk you through a helmet comm system that I have been prototyping.
One late night in a discord VC, we started brainstorming a helmet comm system that would solve the communications problems we experience at large conventions. Some solutions were discussed:
Well… this is where things get a little bit more complicated. Actually, a lot a bit more complicated. Let’s talk about the downsides of Mumble, and of network based solutions in general.
To summarize, a useful comm system would be:
I have been researching and prototyping one such system which I will call CommNet. CommNet is a VoIP based comm system. When users power on their armor, their CommNet client device starts trying to connect to the CommNet network. When it successfully connects, the client automatically joins the voice channel and the wearer is free to begin communicating with other users.
In concept, CommNet utilizes a long range wifi standard called Wifi HaLow (what a name, right?) to connect VoIP clients to an MCU VoIP server running on a micro PC at the booth.
Wifi HaLow (IEEE standard 802.11ah) is a wireless networking standard that operates in the unlicensed 900MHz band to improve range and penetration over typical 2.4 or 5 GHz wifi networks. These improvements come at the cost of bandwidth, which is quoted at being between 150kbps ad 40mbps. I think this should be enough to conduct basic VoIP communications, especially with an MCU running on the VoIP server to minimize the amount of data sent to each client.
I am using FreeSwitch, an open source, highly configurable PBX, for a VoIP server. FreeSwitch is based around Session Initiation Protocol (SIP), which I will not embarrass myself by trying to explain. For the purposes of this overview just know that a SIP client can be run on many kinds of hardware, maybe even an ESP32.
My first client is a Raspberry Pi 4B running OpenWRT, with a HaLow hat for wireless connectivity. I am even housing it in a nifty little IOTA-12 inspired handheld radio.
In order to connect the Pi to my VoIP server, I am utilizing an Alfa Networks Tube-AH access point and a little 5 port gigabit switch. The micro pc running the server has a wired connection to the switch. I am still troubleshooting this configuration. I have experienced some strange errors when trying to get the pi to properly communicate with its HaLow hat which I am currently discussing with the manufacturer. I will post updates if I get it working. Additionally, I have some uncertainty as to whether my Pi Hat will play nice with the Tube-AH, an issue that I discovered while forum diving for a solution to my first problem.
The Access point will be located as high as is allowed per convention by way of a telescoping fiberglass mast. I even made a little Misriah branded housing for it to live in.
Both FreeSwitch and OpenWRT can be controlled with scripting, meaning that the joining of a channel can be made to happen automagically with some clever coding.
While I am starting off with a basic Client-Access Point mode for the wireless network, I would eventually like to explore an 802.11s mesh. A mesh would increase range in situations where a client is out of range of the booth AP, but can “hop” through another client who is. A mesh would make VoIP more complicated, but that is out of the scope of what I want to cover in this post.
Another possibility is that a small number of us have HaLow connections to the booth and are running a standard wifi access point which can bridge members who don’t want to spend the money on HaLow hardware into the CommNet
The goal for CommNet is to develop a hardware and software configuration that can be assembled with as little money and effort as possible. I’m excited to see how far I can get, and I am willing to accept help from anyone who is interested.
CommNet is a cool idea, but I think we can go bigger. With our booth activations growing in size and complexity, I have become increasingly convinced that we need a portable network setup to support things like security cameras and av equipment. If we can get our suits and our booth onto the same network we could make things like Tac Maps that actually work or helmet cam feeds that are transmitted to a display in the booth in real time. Imagine what we could do if we were provided an internet uplink by the convention! Bridging of comms into a Discord channel or live streaming of security camera video live from the con floor.
We have proven through our booth builds that this organization is capable of some remarkable collaboration, and through my experience in writing the hearing assistance system tutorial, I know that there is a desire for useful electronics which improve comfort and convenience in armor. I think we could develop some really cool, useful, open source projects if we put our minds to it.
Please use this thread to discuss CommNet, or any other tech related ideas you may have. I imagine we can spin off other threads which I will link below as they are created.
As an example, I would like to walk you through a helmet comm system that I have been prototyping.
One late night in a discord VC, we started brainstorming a helmet comm system that would solve the communications problems we experience at large conventions. Some solutions were discussed:
- FRS/GMRS Radios: These radios can be bought from most stores that sell outdoor equipment. What would commonly be referred to as “walkie talkies”, these radios operate on a set of frequencies reserved for their use by the FCC. FRS Frequencies are free to use, but GMRS frequencies require a (at the time of writing) $35 10 year license. While FRS/GMRS radios have their benefits- they require little to no setup, are easy to find, and fairly inexpensive- they are also unencrypted and prone to interference (sometimes intentional) by other humans trying to use the limited set of channels available, especially in downtown areas where cons are often held. An ideal solution would be inherently secure and free from interference.
- Licensed Business Radios: Businesses can obtain licenses that reserve frequencies for their exclusive use, but such licenses are not trivial to obtain. Furthermore, a solution which relies on a specific individual being present to provide radios doesn’t seem sustainable. For the purposes of developing a standard, this seems more or less useless to me.
- HAM Radio: I love ham radio, but we cannot expect adoption of a standard if it requires weeks of study and a licensing exam to use.
- Motorcycle Helmet Comm Systems: It seems like there are some cool off the shelf solutions for motorcycle communications but they are $$$$$$ and limited in how many users can connect to a channel. If we want widespread adoption of a standard, it has to be affordable and scalable for as many users as want to use it.
- Network based (Mumble/Discord/Insert chat room software name here): It would be great if we could utilize discord for our helmet comms, but Discord requires an internet connection. While we may be able to connect to Con wifi, who knows if we will have enough bandwidth to use discord. Furthermore, who wants to fiddle around with their phone while walking around in armor. We investigated Mumble, for which you can run your own server on a local network (not connected to the internet), as the core of a network based system, and it does have its advantages. It has a nice GUI for setting up your audio devices and such, and it is available as an easy to install package on linux meaning it is easy to set up on a raspberry pi (I was able to run it successfully on a tiny little PI Zero). In an armor based comm system, size matters, so this is the perfect solution right?
Well… this is where things get a little bit more complicated. Actually, a lot a bit more complicated. Let’s talk about the downsides of Mumble, and of network based solutions in general.
- Range: Assuming we are running a Mumble server on a local network, we need a way for our clients (the device in your armor) to connect to that server. Most Raspberry Pis have built in wifi, but the range of 2.4 and 5 GHz wifi leaves a lot to be desired. We don’t have the ability to spread our own access points throughout the convention hall, so we need a way to connect devices back to a single access point at our booth.
- Bandwidth: For an IP comm system to be truly scaleable, it cannot require more bandwidth as users join the channel. This problem is solved by something called a Media Control Unit (MCU). An MCU serves a mix-minus audio feed to every client (you hear everyone but yourself), allowing each client to receive one audio stream regardless of the number of users in the channel. Mumble sends a client one audio stream for each user who is currently speaking, which then get mixed together by the client. Mumble does not utilize an MCU, meaning that performance will eventually suffer.
- Scripting Integration: The last thing you want to do while walking the con floor is fiddle with your technology, so our comm system needs to be capable of managing comm channel connections automatically. Mumble does not have a robust system for command line control which is the final nail in the Comms-shaped coffin as far as I’m concerned.
To summarize, a useful comm system would be:
- Affordable
- Scalable
- Secure
- Compact
- Long Range
- Hands Free
I have been researching and prototyping one such system which I will call CommNet. CommNet is a VoIP based comm system. When users power on their armor, their CommNet client device starts trying to connect to the CommNet network. When it successfully connects, the client automatically joins the voice channel and the wearer is free to begin communicating with other users.
In concept, CommNet utilizes a long range wifi standard called Wifi HaLow (what a name, right?) to connect VoIP clients to an MCU VoIP server running on a micro PC at the booth.
Wifi HaLow (IEEE standard 802.11ah) is a wireless networking standard that operates in the unlicensed 900MHz band to improve range and penetration over typical 2.4 or 5 GHz wifi networks. These improvements come at the cost of bandwidth, which is quoted at being between 150kbps ad 40mbps. I think this should be enough to conduct basic VoIP communications, especially with an MCU running on the VoIP server to minimize the amount of data sent to each client.
I am using FreeSwitch, an open source, highly configurable PBX, for a VoIP server. FreeSwitch is based around Session Initiation Protocol (SIP), which I will not embarrass myself by trying to explain. For the purposes of this overview just know that a SIP client can be run on many kinds of hardware, maybe even an ESP32.
My first client is a Raspberry Pi 4B running OpenWRT, with a HaLow hat for wireless connectivity. I am even housing it in a nifty little IOTA-12 inspired handheld radio.
In order to connect the Pi to my VoIP server, I am utilizing an Alfa Networks Tube-AH access point and a little 5 port gigabit switch. The micro pc running the server has a wired connection to the switch. I am still troubleshooting this configuration. I have experienced some strange errors when trying to get the pi to properly communicate with its HaLow hat which I am currently discussing with the manufacturer. I will post updates if I get it working. Additionally, I have some uncertainty as to whether my Pi Hat will play nice with the Tube-AH, an issue that I discovered while forum diving for a solution to my first problem.
The Access point will be located as high as is allowed per convention by way of a telescoping fiberglass mast. I even made a little Misriah branded housing for it to live in.
Both FreeSwitch and OpenWRT can be controlled with scripting, meaning that the joining of a channel can be made to happen automagically with some clever coding.
While I am starting off with a basic Client-Access Point mode for the wireless network, I would eventually like to explore an 802.11s mesh. A mesh would increase range in situations where a client is out of range of the booth AP, but can “hop” through another client who is. A mesh would make VoIP more complicated, but that is out of the scope of what I want to cover in this post.
Another possibility is that a small number of us have HaLow connections to the booth and are running a standard wifi access point which can bridge members who don’t want to spend the money on HaLow hardware into the CommNet
The goal for CommNet is to develop a hardware and software configuration that can be assembled with as little money and effort as possible. I’m excited to see how far I can get, and I am willing to accept help from anyone who is interested.
CommNet is a cool idea, but I think we can go bigger. With our booth activations growing in size and complexity, I have become increasingly convinced that we need a portable network setup to support things like security cameras and av equipment. If we can get our suits and our booth onto the same network we could make things like Tac Maps that actually work or helmet cam feeds that are transmitted to a display in the booth in real time. Imagine what we could do if we were provided an internet uplink by the convention! Bridging of comms into a Discord channel or live streaming of security camera video live from the con floor.
We have proven through our booth builds that this organization is capable of some remarkable collaboration, and through my experience in writing the hearing assistance system tutorial, I know that there is a desire for useful electronics which improve comfort and convenience in armor. I think we could develop some really cool, useful, open source projects if we put our minds to it.
Please use this thread to discuss CommNet, or any other tech related ideas you may have. I imagine we can spin off other threads which I will link below as they are created.
