Custom system build

I’ve spent many years trying to build a digital fireworks firing system, going all the way back to the old PyroUniverse days.

Back in 2010, I was a contributor on PyroUniverse during the creation of the Pyro Network Control Protocol. I spent several years on and off building my own system around it, but like a lot of projects, it eventually got pushed to the side.

Recently, I picked development back up. This time, I’ve moved away from PNCP and started building my own protocol from the ground up.

My system runs in the 900 MHz band instead of 2.4 GHz, which should help with longer-range communication. The way it currently works is that the main controller sends a small script to each field module when the system is armed. Right now, I’m testing with a 16-cue field module.

Once armed, the main controller sends a heartbeat, and each module uses its own internal timer to fire cues at the correct time. This currently gives me 0.01-second timing accuracy. It may be capable of even faster timing, but I have not fully tested that yet.

The main controller already has several features in development, including:

  • OTA firmware updates for field modules
  • Manual firing
  • Scripted firing
  • Module discovery
  • Continuity checking
  • Script-vs-module validation, which can detect duplicate channels or connected cues that are not included in the script

My long-term plan is to make a lot of this open for others to build on. The modules are running MicroPython, which makes porting much easier. During recent development, I moved from using an RP2040 with an external radio to using an STM32 module with a built-in radio, getting MicroPython running on it, and porting the code with very little effort.

That opens the door to supporting many different hardware modules in the future.

As far as scale goes, the theoretical limit is 65,535 modules per network ID, with 65,534 network IDs available. Each module is assigned a channel and a network ID, and the main controller is set to the same network.

It’s been a long road, but it feels good to finally be making real progress on this project again.

I’ve attached a few photos of the main controller as well.

The field module is still currently on a breadboard, but I’ve started working on the circuit board layout and hope to send it out for fabrication soon.

I’m also building in some additional safety checks on the field module. One of those checks is designed to verify that the cues are not shorted before fire power is applied to the cue firing circuit.

Nice!

Are you looking to make it open source or are you staying closed source?

Are you aware of the limitations of the speed of 900mhz?

The plan is to opensource it. Its written in micropython so it can be ported to other modules supported by micro python. In my testing there has been no issue with speed. I have a ping command that simulates the size of a fire command and its down to 43ms round trip. Modules are loaded with there cues times and the master serves as a “time code generator” it generates a heart beat that the modules sync to. So the cue timing is handled by the modules for the most part. There would be no way for a system to do fast 0.001 timing by just sending a fire command. It does have a fire command for manual mode though.

1 Like

Taken a small break due to this being a busy time for me. Steppedawway from the firmware development and started building this. I thought i had a photo of the scripting aswell but the product designer and scripting side looks alot alike. It works with the pyrolayout.com export file so you can pull it into my program, build your script, simulate the show. by the time im done you will be able to export it back to pyrolayout.com to layout your racks, cakes and all the infield setup.

1 Like