Pyrotronix, Fireone, Pyrodigital

[nepyro]

Thanks Troutmanx36 and Marty,

That helps...While I understand what Timecode is, and the differences between FSK and SMPTE, and what it's purpose is with respects to the firing systems, I was wanting to know more about how the different firing systems implement their interfaces with it. You touch on it a little. Each firing system seems to have different ways they interface with the timecode. You mentioned the term "Broadcast", I assume you mean via FM radio or via a local (line level) feed from a production company, like a remote radio broadcast. This is the area with "Timecode" that I have had very little experience with. While I totally understand all the concepts and components, I have never delt with the logistics of putting them all together so that they FLOW, with out fail. My digital firing system does not use an external TIMECODE or SMTPE broadcast. It uses a computer to control everything: the firing modules, music, etc. Less to get out of sync, but let's face it, it's a PC...so you do have drawbacks here. I don't want this discussion to turn into a "this "SYSTEM" is better than that "SYSTEM"...just the in's and out's, plus's and minus's of how these systems interact with timecode. I have been involved with radio simulcasts with my system, and we drive the signal, and the radio station picks it up, and rebroadcasts it...It works great...yes, there can be issues here too, but I am just trying to learn and expand my knowledge beyond my little world, and hope others will learn too. It helps to show others there is a lot more to pyromusicals than fireworks and music!

[Troutmanx36]

I just wanted to put a basic explanation out there for those who want to learn about this stuff. For a long time all the conversations about firing systems were over my head until I put it all together. In fact, this might be a handy seperate thread.

Marty, as far as Drop Frame SMPTE, I never really thought about that issue when it came to firing systems. Which does Fireone incorporate?

Next lesson:

The reason we refer to frames is because SMPTE is originally a video timecode. The reason Marty says "up to" 30 per second is because there are different formats of SMPTE timecode. The most common in the U.S. is NTSC. It's what you see on the back of DVD boxes and it basically means 30 frames per second.

As far as what drop frame is, it is actually dropped number values in SMPTE timecode in order to make it closer to real-time. Over long periods of time, SMPTE timecode actually comes out longer than normal time. 30 frames don't actually fit in a second, it's actually slightly more time. Therefore if you had SMPTE timecode run for an hour, it would actually get to 01:00.00 in slightly more than an hour. If you were to drop the last frame, you would have less than a second worth of time and you would run short. So, instead of making the last frame shorter or dropping actual frames, drop frame timecode compensates for the difference by getting rid of values, meaning that it just skips certain frames in the counting process.

In theory, this would pertain to fireworks in that certain values wouldn't exist in the timecode. If that value doesn't exist, that cue will not fire because the system never knows that that moment happened. Or at least that's what I think would happen.

Marty, is this what happens?

[Mondo]

I have a couple of points to add about smpte/fsk and timing resolution.

I’ve read in several places here that FSK works better than SMPTE. I think one of reasons is that SMPTE is a square wave and FSK is a sine wave. There’s also another reason, but first things first.

Smpte is a square wave, ie full-on or full-off. On is a “1" bit and off is a “0" bit. FSK is Frequency shift keying; think of it as a “two tone” system; one frequency represents 1 and the other 0. The tones used are typically 1200 /2200 hertz. These tones are from the Bell 202 1200 baud modems we grew up with. Strictly speaking, when we speak of FSK in this context, we really mean _A_FSK, where the A means audio. This means that the audio will be recorded or transmitted over a voice circuit, as opposed to directly modulating a carrier.

Record either an FSK or SMPTE timecode signal on a nice analog reel-to-reel recorder and you’ll have no trouble recovering them in playback. Send SMPTE down a phone line, a wireless link (“Marti”, uhf/vhf wireless link, or modern digital 2 way), or worse yet a modern digital cell phone, and you might have problems. Those sharp-cornered square waves don’t look like the voice/music waveforms those systems were designed for. Dropped bits, harmonic ringing, and clipping of the signal will be more likely with the hard-edged square waves of smpte than for the smooth curves of fsk’s sine waves.

As for accuracy, there’s something else at play here as well. I’ve seen discussions (not just in this thread, but elsewhere) about how FSK can time down to 1/1000, and SMPTE is limited to 30 frames per second because of video heritage. A SMPTE frame is 80bits long, and carries a lot more information than just hours:minutes:seconds:frames; in fact 32 bits plus 16 sync bits are used for other data. And nope, no error correction here. Within that 80 bits per frame, we’re looking at 2400 bits/second... that’s the raw bit speed. Let’s go back to our “superior” FSK , which we know anecdotally can do 1200bps - 2400bps over audio links with ease. We also can recall from our old modems that 9600 baud was workable but needed some error correction, and that 14,4k was achieved with something more than just ramping up the speed (beyond the scope here, but it was more compression and “trellis” coding.) The point is, if 9600 bits/second is the practical limit of voice-circuit AFSK, how do we get 1/1000 sec accuracy? We can, but it’s not a function of the density of the timecode.

Flywheel, Shyster, and Flywheel

No, not the old Marx Brother’s law firm, but the “flywheel” principle of synchronization. If you ask someone what the time is, and you’re a computer, they’ll always be wrong. Even if they have an atomic clock and can answer your question down to 1/1,000,000 of a second, by the time they’ve answered you, the time they said will have past. How do you synchronize clocks with somebody? You say, “On my mark, it will be 5:06:30 ...... mark!” The mark is a short, discreet point that is pre-named at your leisure, then quickly, pointedly, _accurately_ marked.


In a microprocessor based firing system, you’ll find the cpu running with a crystal-based clock, where a clock error rate (drift) of 0.001% is not hard to achieve . If a timecode message named each second before it occurs, then “marked” it with a very short, quick bit pattern, you could let the micro keep track of the time between marks with 1/1000th accuracy. The next second mark would come and correct any drift, and there sure wouldn’t be much. If the audio link delivering your timecode were to drop, for say 5 seconds, you could still keep time pretty good time without the timecode present at all!. That’s the “flywheel.” Finally, add some simple error correction to your timecode, and you’ll know which marks to reset your clock by, and which to ignore. So now, you could even slow your timecode down to 300 baud, and therefore have a real robust link, and still have 1/1000 second firing accuracy, though I don’t suspect there’s an ematch anywhere that can meet that spec .

The other reason that FSK probably works better is that it’s customized for the system itself, so the designer optimized the timecode to the system. SMPTE carries a lot of extra information that a firing system doesn’t need, and doesn’t have any built-in error correction.

[stuntborg]

Just a comment on the "pro" system type thing. The more "pro" a system is the higher the level of support should be. "Pro" systems by definition are more complex and have more features. Therefore they require a higher level of support. For example, I work with cutting edge techknoweldgy every day. I design "pro" system if you will. We fully support these systems. To the point were if it doesn't work then we put people on a plane and they go and make it work. We have field engineers and direct link to the factory guys that design the chips themselves. All to support our "pro" system. Now to be fair, we don't design firing systems. However, the systems we do design are seen by millions of people every day. They absolutely must run.

And for those random not firings??? There is no excuse for that. If it was a big enough deal the designers would fix it. Elecronics do not randomly just not work. There is always a reason they do not work. However, they have trained you to expect it and accept it. The pyro world has learned to accept a very low level of support.

[GK]

Another word here about time code and firing systems......

I know for sure that PD and FireOne work off of timecode in real time. They actually are locked to the timecode signal.

There are some other systems that do not do this. they 'milestone' and check sync with the timecode signals at some given interval and adjust from there. In the early days of FireOne, for example, FSK worked great but if you ran the system based on SMPTE is would drift. This has since been fixed.

I always run FSK for FireOne. It does work fine with SMPTE now but I think that running the native timecode is just better reliability.

You may run into multimedia situations with lights, lasers,audio, video where everyone is running off a SMPTE feed and just want to send you that. IMO any production that is that involved should have no problem adding a FSK to their multitrack.

GK

[GK]

One More.....

BEWARE OF HD RADIO STATIONS

High Definition radio has an inherent delay of about 7 seconds.....Many radio stations run some delay as S.O.P. So unless you want to see everything in your precision choreographed show shoot 7 seconds before the appropriate musical cue flows out of the radio MAKE SURE to take care of that.

I could probably write several posts just on working with radio stations
But make sure you have these sort of details worked out before the show day.....

GK

[strobes]

Originally Posted by stuntborg

And for those random not firings??? There is no excuse for that. If it was a big enough deal the designers would fix it. Elecronics do not randomly just not work. There is always a reason they do not work. However, they have trained you to expect it and accept it. The pyro world has learned to accept a very low level of support.

Honestly those who work with these systems should be answering the questions.

Now what good is tech support going to be when its July 4th @945 pm and the show is not wanting to fire?
Human error/over looking something i would say is the biggest problem with commercial systems when something is going wrong.

[Marty]

Originally Posted by Mondo

I have a couple of points to add about smpte/fsk and timing resolution.

I’ve read in several places here that FSK works better than SMPTE. I think one of reasons is that SMPTE is a square wave and FSK is a sine wave. There’s also another reason, but first things first.

Smpte is a square wave, ie full-on or full-off. On is a “1" bit and off is a “0" bit. FSK is Frequency shift keying; think of it as a “two tone” system; one frequency represents 1 and the other 0. The tones used are typically 1200 /2200 hertz. These tones are from the Bell 202 1200 baud modems we grew up with. Strictly speaking, when we speak of FSK in this context, we really mean _A_FSK, where the A means audio. This means that the audio will be recorded or transmitted over a voice circuit, as opposed to directly modulating a carrier.

Record either an FSK or SMPTE timecode signal on a nice analog reel-to-reel recorder and you’ll have no trouble recovering them in playback. Send SMPTE down a phone line, a wireless link (“Marti”, uhf/vhf wireless link, or modern digital 2 way), or worse yet a modern digital cell phone, and you might have problems. Those sharp-cornered square waves don’t look like the voice/music waveforms those systems were designed for. Dropped bits, harmonic ringing, and clipping of the signal will be more likely with the hard-edged square waves of smpte than for the smooth curves of fsk’s sine waves.

Thanks Mondo,
I didn't know how to really explain the difference between FSK and SMPTE. For all you have explained is why FSK can be transmitted so easily unlike SMPTE which is incredibly fussy about it. A little over-modulation or distortion and no system will lock on to it.

[stuntborg]

Anyone know why they are using video protocols for this? Knowing the technology available today I can't see any reason why you would need to incorporate the hassle of frame timing. The overhead for something like that isn't worth it. Frame timing just doesn't add much benefit.

[Troutmanx36]

As GK mentioned before, sometimes the fireworks are a part of a larger production that is using SMPTE timecode. That's probably why it's still an option.

[Marty]

Originally Posted by Troutmanx36

As GK mentioned before, sometimes the fireworks are a part of a larger production that is using SMPTE timecode. That's probably why it's still an option.

Yep, amusement parks are the biggest ones using multi-media and fireworks timed with SMPTE.

IIRC, GK got one of his clients to burn a FSK track in addition to the SMPTE. Easy to do these days with just a 4 channel mini disk, stereo sound on tracks 1&2, SMPTE on track 3, FSK on track 4.

In shows like these the fireworks are an enhancement to a larger event and are also subject to certain rules. Everything must be able to be shut down in one emergency stop action. Typically everything is shut down by stopping the soundtrack which means the internal backup features of the firing system must be disabled.

[GK]

Originally Posted by stuntborg

Just a comment on the "pro" system type thing. The more "pro" a system is the higher the level of support should be. "Pro" systems by definition are more complex and have more features. Therefore they require a higher level of support. For example, I work with cutting edge techknoweldgy every day. I design "pro" system if you will. We fully support these systems. To the point were if it doesn't work then we put people on a plane and they go and make it work. We have field engineers and direct link to the factory guys that design the chips themselves. All to support our "pro" system. Now to be fair, we don't design firing systems. However, the systems we do design are seen by millions of people every day. They absolutely must run.

And for those random not firings??? There is no excuse for that. If it was a big enough deal the designers would fix it. Elecronics do not randomly just not work. There is always a reason they do not work. However, they have trained you to expect it and accept it. The pyro world has learned to accept a very low level of support.

The problem(s) would be a lot easier to diagnose and prevent if they were well documented and the setup was preserved to detemine the cause of the failure after the shows.

In the real world, the setup is being taken down and perhaps the shooter noticed that part of the show didn't fire. Sometimes it is obvious, an ematch wire or other connection came loose during the show. But other times a cue doesn't fire and after the show it can be manually fired by the system without changing anything.

There is nothing more frustrating (difficult to diagnose) than a failure that is intermittent or can't be re-created.

On the issue of tech support, a 'professional' system for professional pyrotechnicians should have technical support. However, the level of technical support is typically on application issues rather than operational ones.....A professional should understand the equipment that they are using, its limitations, and potential problems. There is a lot of information available when running the system diagnostics....A professional should be able to diagnose and correct a problem.

GK

[GK]

Originally Posted by Troutmanx36

As GK mentioned before, sometimes the fireworks are a part of a larger production that is using SMPTE timecode. That's probably why it's still an option.

Exactly. But remember when going into these situations, you are (or should be) the pyro expert (professional) it is up to you to make sure the pyro works with the rest of the production.

Most times there are many tracks rolling at the same time from SMPTE to video, digital contol, audio cue tracks....etc. Providing the technical production staff a simple .wav file with FSK and audio (they use the audio to sync the copy of FSK on their multitrack will assure that you are doing the best job for your part of the overall production.

GK

[mutski]

Originally Posted by stuntborg

Anyone know why they are using video protocols for this? Knowing the technology available today I can't see any reason why you would need to incorporate the hassle of frame timing. The overhead for something like that isn't worth it. Frame timing just doesn't add much benefit.

Because a long long time ago, the Society of Motion Picture and Television Enginners (SMPTE) developed a timecode system that was developed by video people for use by video people in video production environments. The original use was to automatically synchronise film and audio tracks. Hence the 25/30 frames per second. They relate directly to a frame of film or video.

It just happened that because audio and video gear was coming out with SMPTE timecode sync abilities, that I guess mainly theme park people were using it to sync audio, lighting, video, staging, effects, automation etc. And then everybody was using it.

Matt