Print

[Chris]

Im curious since this thread was started if anyone else has purchased or test drove these units and their thoughts on them.

I'm in the process of spec'ing out gear for an upcoming show that will be shot
on 2x RED's, and debating whether to go with Denecke SB-3's on the cameras as well as comteks, or to go the zaxcom (all in 1) route.
I'm curious as to more opinions about range, reliability, audio quality ..etc
out in the field.

I would also want to be able to use a 3rd unit for 2nd boom (he of course
would have to listen to a mix)

Thanks

[glenn]

There is no delay in the time code part of the system. The Audio does have adjustable delay from 0 to 300ms.

We have gotten the latency of the system down to 8 ms. This works out very well as it kind of matches the length of the boom.

Glenn

[rpsharman]

We talked a lot about TC delay in another thread, specifically the 1-2 frame delay in the older "read" type slates like the TS1 and TS2 from Denecke.  Perhaps Glenn can let us know if there is any delay or offset present when encoding TC and other data, broadcasting it, then decoding it at the other end.

Thanks,

Robert

[studiomprd]

"  it has to have been put into the timecode area because "
the proprietary information may be 'traveling' with the TC, but it can not be in the SMPTE TC, for the reasons Courtney pointed out.  after the proprietary data arrives, the information is all decoded, and the TC info is then output as SMPTE TC, the other data is output in proprietary form...

[bigmaho]

Just to be clear...  You're reception tests around your stage and surrounding area were done with these added items?

Yes. 

[Jeff Wexler]

to Courtney, I was just speculating that scene and take metadata was in the user bits --- I really don't know much about these things. I do know that scene and take data is there somewhere and it has to have been put into the timecode area because it functions even if the only connection between the Deva and the IFB is a timecode connection (no audio). With the ERX and a new or modified Denecke slate, scene and take can be displayed on the slate. My point, to Tom, was that it would not be easy or even possible for the manufacturers of other recorders to implement ALL the features of a Zaxcom "system" ("closed system" as Tom calls it) even if Zaxcom were to disclose to the world exactly what it is they are doing.

-  Jeff Wexler

[Phil Palmer]

I forgot to mention that I'm using my ifb transmitter with a wi-fi amp
that boosts to rf output from approx 100mw to 500 mw.  I'm also using
a small panel antenna that provides 12 db of gain in one direction.
Billy Sarokin

Just to be clear...  You're reception tests around your stage and surrounding area were done with these added items?

[cmgoodin]

I believe the meta data and transmitter remote control signals are somehow embedded in the user bits

Don't know for sure but kind of doubt that the Scene and Take metadata is in the User Bits.  Since Zaxcom uses their own proprietary digital transmission scheme for the audio, the metadata could be anywhere in that data stream.  The SMPTE standard for user bits lets you put in only 8, 4-bit hex or BCD numbers into the fields. It usually caries the Year Month Day and a 2 digit take count.  You could define 4 digits for scene and 4 for take.  But the Scene could not have letters greater than F  if using 4 bit BCD scheme. The user bits are not standardized as to content by SMPTE only their structure is defined in the standard.  I doubt Zaxcom is using SMPTE LTC structure to carry time code and metadata since they are the only ones that make a receiver that can decode it.  There is no need to encode or decode the LTC format since it is not output in that form from the receiver. It only appears on an LCD display.

---Courtney

[bigmaho]

The few times I've used radios to transmit time code to slates it's been very finicky.  The gains on both the transmitter and receiver had to be just right or the code would be intermittent at best.  With the zaxcom receivers the slates picked up the code immediately and regardless of the gain setting.  I'm assuming it's because the digital transmission is better at sending square waves than analog.  Not sure if it's technically SMPTE time code, but it's the happiest time code I've ever seen ;-)
Billy

SMPTE specifications for time code are quite thorough and specific.  anything else is non-standard, though that doesn't make it bad, just non SMPTE TC...

[Jeff Wexler]

There is a lot more to this (and I'm not sure you read my reply carefully). Sorry about the term "open source" as I used it incorrectly.

"I dislike the term open source.  I feel we really need an industry leader to dictate what the standard should be withe respect to meta-data and timecode.  There must be an inflection point for lost sales of Deva/Fusion units compared to licensing revenue, and I would guess that they have much more to gain from increased IFB sales compared to lost recorder sales."

There are definite standards for smpte timecode and Zaxcom has not hidden or abused these in any way. I believe they are using USER BITS and the user bits are just that: bits (area) the a user can use. So, Zaxcom is using this area to embed all sorts of control data, metadata, etc.. There is nothing proprietary, nothing that says the user bits have to be used just for this or that. The problem is not a lack of standards it is that no other manufacturer that I know of is putting control data and metadata in their implementation of timecode. If one wishes that scene and take information could be put in the user bit area of the timecode output of a Nagra VI or a Fostex 606 or an SD 788T, this is not something that Zaxcom can do. Therefore, whether there are standards, whether Zaxcom doesn't want to tell anybody else what they are doing because it will hurt sales, whatever, some of the functions of the ERX or Zaxnet or remote control of wireless transmitters, etc., is just not possible when using another recorder.

[Tom Visser]

There is also the Sony DWR / DWT slot-in units.  I'd rather buy American made, but the Sony does offer some pretty cool encryption options, remote control of the transmitter from the receiver, and offers AES/EBU (like the Lectro D4) and WC, where the Zaxcom is "only" analog.

I dislike the term open source.  I feel we really need an industry leader to dictate what the standard should be withe respect to meta-data and timecode.  There must be an inflection point for lost sales of Deva/Fusion units compared to licensing revenue, and I would guess that they have much more to gain from increased IFB sales compared to lost recorder sales.  The last time I looked inside my Nagra VI, I briefly studied the logic control board.  They are using a relatively ubiquitous off the shelf control processor which uses a fairly high level development kit for programming... Nagra is not programing these things in assembler.  If the timecode output is driven through the logic control processor and not using a dedicated embedded DSP chip, then the ability to embed additional signaling into the timecode output is relatively "rudimentary".  Even if the disk file structure is different and they use different formats, as long as someone (Zaxcom) is specifying exactly what the timecode user bits protocol is, any 3rd party that is modifying their firmware to enable this signaling can do so regardless of the file system behavior... all that other stuff is really abstracted from the timecode signaling.

[studiomprd]

SMPTE specifications for time code are quite thorough and specific.  anything else is non-standard, though that doesn't make it bad, just non SMPTE TC...

[studiomprd]

" Since the Zaxcom wireless system is the only one (at present) that uses a pure digital transmission through the airways "
this is not exactly the case...
Lectrosonics has been doing this for several years now with their 700 series, and now have added their D-4 systems...
AKG is now delivering their 700 series, which is also a "pure digital" transmission system.

[Jeff Wexler]

I would encourage Zaxcom to open the engineering and software specifications of this feature up to other manufacturers, in the interest of making it n evolutionary standard to the timecode specification with respect to field production.

Even if Zaxcom were to "open" the engineering and software specification to other manufacturers it would be of little use to them I imagine. Each manufacturer has designed the structure and architecture with regards to metadata --- if you look at the placement of Scene and Take metadata, for example, across all the machines out there, it is very variable. Remember all the discussions about file names? Sure, it might be great if every file from every recorder had as its file name the Scene and Take. Not so fast... there are a lot of reasons why this should NOT be the file name (I won't discuss all of this now). There are other obstacles present to the other companies that make implementation of a lot of the things Zaxcom does impossible for them. Since the Zaxcom wireless system is the only one (at present) that uses a pure digital transmission through the airways, other systems that use FM have no way of transmitting digital data.

I understand the spirit of "open source" and "industry standards" but a company like Zaxcom cannot accomplish many of these things by adhering to standards and conventions that other companies may be using because Zaxcom is doing things that no one else is doing.

[Tom Visser]

I would encourage Zaxcom to open the engineering and software specifications of this feature up to other manufacturers, in the interest of making it n evolutionary standard to the timecode specification with respect to field production.  I think it would strengthen their position in the professional markets, not simply as the manufacturer of an outstanding and innovative closed system, but also as a general purpose IFB, timecode, and logging vendor.  I understand and respect the nature of intellectual property, and possible licensing frameworks, and I would respect them for keeping the spec closed if that is the way they choose to remain, too.