New Advanced Multi-Pad Controller Success

[flight4]

This weekend at our club launch I field-tested a new multi-pad launch controller I have been working on for the last few months. And it worked! What makes this controller somewhat unique is that almost all the functionality is implemented using microcontrollers. Microcontrollers are a class of small computers often used in robotics and in many kinds of smart devices. There has been some buzz in the forum lately about launch controllers and I thought it would be fun to share some details.

The photo is just the facade. Inside the console are the microcontrollers and a few support ICs. Total component count is kept low by design, and consists mainly of some current limiting resistors for the LEDs, and a few capacitors and protection diodes.

At the rear, not shown, are some Cat5 and RJ-11 connectors. Ordinary Cat5 cables connect to the relay boxes at the pads which have nearly identical microcontroller configurations. The two endpoints communicate and coordinate everything that happens. One advantage to programatic control vs hardwired logic, in addition to much simpler wiring, is you can implement multiple safety and fail-safe protocols. For example, if the master arm is left on by mistake the controller after a proper time can force disable all pads and sound an alarm via sonalerts.

By design certain basic safety functions are not implemented through the microcontrollers. Specifically master arm and the fire command are still wired direct to the relay boxes in traditional fashion via the Cat5 cables. Another safety concern is that historically, continuity testing certain ignitors such as eMatches has been an issue. Current to drive the continuity indicator or alert is not always carefully regulated. This design keeps the real-time continuity test current limited to about .47 mA through 1 ohm, which is quite safe. There are also safety feedbacks built in. For example, if the master arm relay closes for any reason, like the Cat5 cable gets damaged maybe, but the master arm key is not turned. All pads are instantly shut down. Same with the fire signal.

This controller is actually a prototype for a much larger controller that will ultimately manage an insane number of pads. That's why there are two master arm keys, though that seems silly for just eight pads. But in reality, the ability to independently and centrally manage multiple clusters of low, mid, and high power pads on a large field is an advantage. The design also supports wireless for away pads, but that is a whole different technical discussion because of the need to compensate for the loss of some of the physical safety features.

Anyway, the test. First test was a multiple pad drag race and nothing happened. Ooops. Well turns out one of the contacts on my 10 year old Cat5 cable opened up and the master arm relay couldn't activate. Took awhile to figure that out but I was able to fix it with my pocket knife. Second test was a drag race of three saucers with D, E and F motors. This time everything worked perfectly and we made some noise and entertained the crowd. The kids and I then launched a couple more individual rockets that all went fine. And finally a drag race of a D12 powered Alpha upscale and a C11 Stonebreaker. Not much of a race but the ignition was right on.

There's a lot of work to do still. If there's interest here I'll provide updates as it moves along.

 

[ttabbal]

Nice design. Are you willing to share schematics and code?

 

[Indiana]

That's a nice, clean looking panel.

 

[flight4]

Nice design. Are you willing to share schematics and code?

Bits perhaps, and certainly willing to share the knowledge and experience gained through the project with anyone undertaking a similar effort.

Dave

 

[AKPilot]

I'd be very interested. Your design is very clean and is a real credit to the hobby.

Congrats!

 

[bsexton]

If there's interest here I'll provide updates as it moves along.

Absolutely -- and thanks!

 

[Johnnie]

Bits perhaps, and certainly willing to share the knowledge and experience gained through the project with anyone undertaking a similar effort.

Dave

Bits? We can't build an incomplete system here...

Johnnie

 

[Micromeister]

Looks really great with one small but very important hopefully easily correctable error.

The only time the work "FIRE" is used on a model or real rocket range is if the is one..... and for that reason the world wide word used when the ignition button is pushed is the word "START". If you like the word "Launch" can also be substituted.

Really interesting system. I'll be interested to see how the system works over time, and a couple summers in the sun.
How did you achive the .47v 1 ohm continuity check?
I'd like to incorporate it, if possible into my 17 pad satellite system.

 

[flight4]

I'll have to get back to you on the "couple of summers in the sun".

I'll attach part of what I call the continuity sense circuit. Out at the pad in the ready state the ignitor is connected through the NC contact of the launch relay to an input pin of the microcontroller. A 10k pullup resistor keeps the input high when the ignitor is open or not connected. When properly connected the ignitor pulls the input low.

The rest is software. The micrcontroller detects the current state of the input (several inputs actually, there is a lot going on at the pads) and communicates that with other information to the microcontroller at the LCO position. That microcontroller then turns the appropriate continuity LED on or off. This basically happens continuously in real-time. When launching the relay opens and isolates the microcontroller input from the launch voltage. The microcontroller will detect the entire launch sequence so you can also do things like if you try to launch but the pad has no continuity, don't launch, but rather alert the LCO by beeping the sonalert a few times. I'm not that far along with it yet though.

As you can see the nominal current through the ignitor should be around .0005 A. I actually measured it through a 1ohm 1% power resistor at .47ma.

One way to do it without a network of microcontrollers is to just use an inverter capable of driving 20ma to the led. Then bring the continuity sense to the inverter from the pad. Just adjust the pullup resistor value for your actual supply voltage.

View attachment ContinuityCheck.JPG

 

[falingtrea]

So do you have enough spare pins to hook up a 16 x 2 line LCD? You would need like 11 pins for a parallel port and about 5 for serial one. Sparkfun has the parallel ones for $15. And code to run them as well. If you used an ADC port for continuity you could even do a go/nogo test based on resistance of the ignitor. Also there is an digital recorder chip you can buy that is controllable via SPI where you can record and playback audio signals. Made by ISD, I think.

edit, Also you might want to attend TI's 430 day in March. They will be giving away free development kits base on their MPS430 chip. The eval kit is a wireless unit, in fact.

 

[flight4]

So do you have enough spare pins to hook up a 16 x 2 line LCD? You would need like 11 pins for a parallel port and about 5 for serial one. Sparkfun has the parallel ones for $15. And code to run them as well. If you used an ADC port for continuity you could even do a go/nogo test based on resistance of the ignitor. Also there is an digital recorder chip you can buy that is controllable via SPI where you can record and playback audio signals. Made by ISD, I think.

edit, Also you might want to attend TI's 430 day in March. They will be giving away free development kits base on their MPS430 chip. The eval kit is a wireless unit, in fact.

No spare pins. I'm using them all. I did allocate one as a debug out pin. So I can use any kind of serial display device as a console or for debugging. In fact I actually used a 20x4 LCD display w/ serial input from Reynolds Electronics during initial development. That is, until I burned it up by sticking my 12v line in the wrong place. The same debug signal also works direct into the RS232 port of my laptop so that works just as well. I'll get a new 20x4 LCD eventually.

At both the LCO and pad ends I bring both the serial debug out and the ICSP (in-circuit serial programming) lines out to a separate Cat5 connector for easy access. I can program/reprogram and monitor all status and communications without ever opening the case. Love it. There's power for the 20x4 LCD in the Cat5 connector, or I can just run the debug out to my laptop. The LCD/laptop are normally not used for regular operation but they could be.

 

[flight4]

I finally got around to finishing the wiring on the second half of the controller and had the console open so I took a picture. This is what the guts look like. See attached.

The pad end is similar. Except the PCBs and relays and circuit breakers and connectors and all the 10 and 12 AWG wire for 8 pads are stuffed into a 14" tool box. That's fun.

Still too many wires I think, But it works. The microcontrollers are the lower right IC on each PCB.

 

[...]

I would be wary of using stranded wire in those cat5 connectors, they are only designed to work with solid #24 wire. Personally I would just use board mount jacks and have them soldered directly into the board.

Although the redundant safety features would prevent an unexpected launch, it would still be quite a nuisance... Especially on a pad with a large number of pads, you really want to rule out the possibilities of a loose wire causing problems.

Looks good otherwise!

 

[flight4]

Just so not to leave this hanging, I'm not too concerned about poor connections at the punchdown style connectors. Having worked with IDC and punchdown connections for many years I know that poor connections are mostly caused by incorrect wire size/type or improper tools or technique. These will work fine. I'm more worried about the external cables that people might be walking on, etc. For those we have spares. But thanks for the comment.