Rocket Launching System - Design Compromises...

You want a two-way system for more reasons than just to get the continuity signal back to the range head. The primary reason is so that you will know if the remote cell is operating correctly. With a transmit only system, you simply transmit a launch command and hope that something happens. With a two-way system, you can get an acknowledgment of each command.

Plus you can get extra information back such as continuity status, battery condition, and other diagnostic stuff.

Range can be improved by replacing the typical rubber-duck antennas at the pads with a simple (and cheap to build) Yagi.

The system should be designed so that it can use both wired and wireless connections. Wired connections are fine for all of the closer pads (up to K motors or so) but the wireless system works best for those really long runs to the M pads and out.

And keep in mind that most of the modems available are Part 15 devices. That means that if some other RF source interferes with your system, tough. So being able to fall back to a wired mode is a good thing.

Probably not since I am a misfire alley guy (lanes not groups).

I have spent 20x that much on GSE over the fest history.

You are basing your assumptions on CENTRAL CONTROL, which I am a non-believer in.

The plan *is* for it to be a two-way system. The LCO console sends commands out to the pad-group controllers, and they answer back. The difficulty comes in requiring a *third* channel for audio continuity transmitted to the LCO.

True enough. But I'd prefer to put the Yagi at the LCO table, and have each pad box use a rubber-duck antenna... easier to set up that way, since there's only one antenna to 'aim'.

That *is* an option I'm considering... but some of the earlier talk here centered around going totally wireless.

Yeah. One LCO console to control all the pads, including away-cells.

What would you prefer...? One LCO for each pad used? :-)

YES. (You for yours).

If you have a digital system (and I wouldn't trust an analog system), it is just different information in the data packets. No extra channel needed.

This would not work unless all of the pads were located along the same line of sight. I have not yet seen a range setup this way. Not the DARS, LDRS (Kansas), or Rocstock ranges.

All you have to do is put your PAD on a pad and let 'er rip!

JI's mottos: 'buyer beware' and 'flyer beware'. ;-)

-John (trying to ignore the leak in my JI filter)

I believe Rocketfest is.

But - the continuity tones will be pseudo-analog. (555 timers at the 'pad' boxes rigged as voltage-controlled oscillators.)

How do I combine the digital 'command ack' signals with the continuity tones, and separate them at the other end...?

Two way data rf modems are expensive but very little info has to be transmitted. High baud rate is not needed. All data can be put into a packet with a pad address and commands. Add the tell me three times protocol for reliability. A pic can handle it. The problem is finding cheap transmitters and receivers with range greater than a couple hundred ft. with license exempt. Would a preamp boost the range of something like the LINX receivers work? I was going to try the kh series but never got around to it . Gary Deaver

The RF-900CLP analog transceiever is available for $19ea. If you prefer, the RF-2400 is a "data" modem at twice the price.

You can easily send digital data over an "analog" transceiver. The data modems typically just add a data slicer on the RX side. You can build this yourself if you like.

Range is stated as 1,800' l> Two way data rf modems are expensive but very little info has

An ADC captures the continuity info. This is encoded into the data packet. The microcontroller on the other end pulls it out.

Very simple.

Unless you are trying to use a digital system that has a fixed format you can't control. Like a keyfob transmitter.

True. The big question is doing analog and digital simultaneously. Separating the 56kbps digital data from the ~1khz 'analog' isn't something I'm good at. :-)

Actually, with that kind of frequency relationship, it should be easy enough to combine and split them with simple RC networks...

-dave w

Convert the analog data to digital. This is what ADC's are for.

Or build a complicated system that combines analog and digital. I have done this at work but I didn't have to pay for the expensive hardware required. :-)

That's *kinda* what I'm planning. Communications are half-duplex, so the LCO 'Master' can't transmit while any of the 'slaves' are sending data. Since ADC info would be a continuous stream, that's ruled out.

Plus, I was intending to use the pad-relay boxes that John DeMar designed, which send an audio tone that reflects the resistance of the igniter. I'd have to do a frequency-to-voltage conversion, then an analog-to-digital one, to get it into transmittable form.

The digital signal will have significant energy at 1KHz unless it's encoded and prefiltered in an optimal way. Also, the 1kHz 'tone' would have to be a fairly clean sinewave. All of this is much more difficult (and expensive) than just sending the continuity information as a packet along with the digital information.

I'm getting "deja vu all over again" since Len and I exchanged emails about this quite a while back. ;-)

Once the datalink is working for other commands and status, it will be easy to add a request/reply for continuity quality. The VCO is one way to get a tone that's proportional to igniter quality (as in my launch system design... see URL below). Without an A-to-D feature on a microcontroller, you could 'count' the period of this tone and send that value upon a request. With an A-to-D, just read in the voltage level from the sensing resistor and send that when requested. On the receiver end, display this in whatever way you wish. Or reproduce the tone (by toggling a pin on the microcontroller in the LCO's console).

I've replaced the analog VCO (555) with a PIC in my redesigned pad box circuit. With PIC in there now, I can produce different tone features based on low battery and stuck relay. The same PIC could be programmed to handle the datacommunications (lots of code space left). But, I think the added complexity of a smart distributed launch system is asking for trouble. With the 'non digital' distribution system, cabling is fairly inexpensive with only one wire and ground needed for each pad (I combine the 12V launch signal out to the pad with the 0.5V status tone coming back from the pad on the same wire). With standard orange power cords, the third wire is used to distribute 12V power to the pads in a cluster.

ADC info is NOT a continuous stream unless you make it that way.

That is more of a problem. I kind of suspected that there had to be a reason behind your messages. Now they make sense.

But now you don't need an ADC.

AC couple the signal to an op-amp. Amplify and clip the signal into something resembling a square wave. Feed this to an edge triggered interupt pin on the microcontroller. Now all you have to do is measure the time between interupts to decode the signal.

Now your controller sends a message that means: "pad X, tell me your continuity status": and it responds with: "it is N" where N is a number dependent on the frequency you decode.

John you should stick with this subject and stay away from LEUP issues where you are always wrong.