big trouble with the HDX900

[Mark Job]

Originally Posted by Dan Keaton

Dear Mark:

We do not attribute this problem to be caused by the camera.

As far as I remember, we have only one camera related problem.

The original Varicam, the "F" model, would put out a clean HD-SDI signal, then when the camera went into record, would put out a glitch on the HD-SDI signal, causing us to have to re-sync to the signal.

The Varicam "H" model does not have this problem.

We have thoroughly tested the HDX900, a very popular camera for use with the nanoFlash, and did not detect any problems.


Summary, we still have many nanoFlash users that have never experienced this problem.

We still feel that almost all of these problems were reported when recording 720p and then only when certain circumstances existed.

In any case, we currently believe, based on our thorough testing, this problem has been solved.

....Hi Dan:
It's a known fact different brands of cameras *can* have differing signal output strengths in the HD-SDI & TC signals. I was wondering to what extent this could be the cause of at least some of the strange Nano behaviour with certain models. (??) I was basing my observations on the posts end users were making, but this doesn't tell the whole story. Apparently, none of the story, since you folks at CD are not attributing any of the malfunctions to the camera. Understood.

[Robin Probyn]

Originally Posted by Dan Keaton

Dear Robin,

1.5.126 is the Production Level firmware.

1.5.249 was released as a Public Beta with the "Not for Production Use" label.

Hi Dan

Yes I see that was my mistake.. I guess I should go back to 126.. except if 720p shoot.. or would you suggest going straight to next up date of 249.. as I have 249 already installed.. what would you advise..

Thanks as always

[Mike Schell]

Originally Posted by Robin Probyn

Hi Dan

Yes I see that was my mistake.. I guess I should go back to 126.. except if 720p shoot.. or would you suggest going straight to next up date of 249.. as I have 249 already installed.. what would you advise..

Thanks as always

Hi Robin-
In this instance, I would keep 249. We should have a beta release in a few days with the 720p issue resolved. All internal tests of the new code look extremely positive at this time.

Best-

[Scott Stoneback]

I did another shoot for a 720/30p client two weeks ago. I wanted to forget about it, I guess...!

I had the same problem with the HDX900. I was recording 720/30p, .MOV, Long Gop 50mb, Delkin 64gb cards. Cables are all spec, bought thru NanoFlash.net. Was recording onto tape, as primary format and the Nano was a test/convenience option.

The Nano would run fine for a while and then I would see a dropout on the monitor (monitoring SDI out from Nano to Panasonic monitor) and get the "intermittent source" warning. It was at seemingly random times the drops would occur.

Interestingly, I did the same shoot about two months ago and the only difference was that I recorded .MXF files instead of .MOV. I don't recall having the dropouts occur in that case. (Recording .MXF in 30p Long Gop is another different problem with Avid, though).

I've since shot at 1080/60i and had no issues.

[Mike Schell]

Hi Scott-
We had a definite problem with 720p, especially at high bit-rates. Under certain conditions the internal logic would get tripped up and loose the incoming source. We identified the problem this week and have made the appropriate changes to the firmware. So far the tests look extremely promising, hopefully we can post a correction early this week.

Best-
Mike

[Mark Trottenberg]

I will check it out. meanwhile thanks for all your good works, I finally did get to use the nanoflash (at 1080) on friday and it worked flawlessly. It is a wonderful box and I'm glad I bought it.

MT

[Ernie Santella]

Just wanted to pipe-in, I had a Intermittent Source message last week shooting with my HDX900 @ 1080i/60, 100MBit, QT. I un-plugged the unit and it worked fine after that. Not sure if this is related.

[Mike Schell]

Originally Posted by Ernie Santella

Just wanted to pipe-in, I had a Intermittent Source message last week shooting with my HDX900 @ 1080i/60, 100MBit, QT. I un-plugged the unit and it worked fine after that. Not sure if this is related.

Hi Ernie-
The problem could have effected 1080i video also. The shorter line length of 720p (1280 vs 1920) made failures with 720p much more likely.

Recent tests indicate the problem has been solved with the (yet to be released) new firmware. But, we will continue to exhaustively test.

Best-

[Jeff Silverman]

Mike,

I think it would be very useful for you to make a definitive statement on which version of firmware people should use until the new firmware is released. I for one have several Nanos out on rentals tomorrow for example. Failure would potentially result in the loss of not only the footage but several thousand dollars in camera rental as well.

Thanks

Jeff

[Mike Schell]

Hi Jeff-
My best recommendation is to use the new beta firmware 1.6.18. We have tested and tested and tested this code. We may still have missed some issues, but it's our best offering to date.

Best-

[Allen S. Facemire]

I'm starting a new show for DIY and planned to use the Nano Flash as a logging device, dumbing it down to 18mbs and hitching to my HDX900's. Works really great except the TC on the Nano once mounted to Quicktime Player, doesn't match what's on tape. Thought it was a FCP anomaly but not so much. It seems when in REGEN, the camera likes to jump back a few frames to determine the proper time line and then it skips ahead to catch up. This is why the 5-second pre-roll rule should apply. Me thinks the Nano wants to grab the first TC number is sees because that's what's triggering the RECORD function . The result is at the head of each clip, there is a jump in TC on tape but then it settles out as the TC catches up. The Nano is still recording from the very first TC indicator and is not actually reading the TC as it's being laid down but laying it's own TC down based on the first TC numbers it sees. That's the only explanation I can come up with for the TC variance

Now here's the strange part. If you take the Nano, plug the SDI output into an A/B monitor, take the tape which has a TC burn in window, and plug it into the other port (via a deck) and pause the Nano at a point of the video you can visually count on...in my case a clap slate that I slowly move out of the frame, and then using the deck to find the same TC via the window burn, they will be dead on. You can do that all the way through the tape and they will be dead on. But drop the Nano video into Quicktime, there will be anywhere from a 4 to 28 frame variation.

I've dedicated today and tomorrow to do some comprehensive testing using each of my HDX900's, my HDX2000 P2 camera and my PDW700 XDCAM. The P2 camera should prove to be interesting because with no actual transport, maybe that will make a difference.

But to everyone using the Nano with the HDX900...be forewarned the TC on the device will NOT match that on tape. Not a problem if you are using the Nano as your source but if like me, you planned to use the Nano for logging, they won't match.

The folks at Convergent have been very responsive and now that I have a bit of time, I am going to do as much testing as possible and hopefully furnish them with enough info that this issue can be solved.

[Allen S. Facemire]

After an exhaustive day of testing the Nano Flash and related TC issues, I found some interesting things. First off, the HPX2000 P2 camera and I suspect ALL P2 cameras have NO TC issues. The TC you record on the Nano matches the P2 to the frame. The PDW700 XDCAM and I sure the rest of the family is only one frame off...consistently...not a problem at all. But the HDX900 is all over the place and I found out why. Since it's a tape based camera, it goes into what we used to call "Back Space Edit" in the old Beta days. This is when the tape actually goes back a bit to find the TC break and once that point is reached, it's skips a beat or two to start laying down TC. The Nano reads the very first TC number and assumes the sequence. However as the tape has caught up to real time, the Nano has already been recording for for 28 frames or so, thus no matching TC.

The fine folks at Convergent have been made aware of this anomaly and have assured me that a firmware fix is in the offing. Basically they will come up with an optional 3-5 frame preroll option so that the Nano won't actually be accepting TC until the tape has settled down. This will solve everything. So until they release the firmware upgrade, the way to make sure the TC on tape matches TC on Nano, is to simply disable the TC trigger option and manually record. A bit of a pain but knowing a fix is in the future, I'm good with that.

Thanks Dan, Tommy and Mike for coming to the rescue.

[Dan Keaton]

Dear Friends,

We have been working behind the scenes to assist Allen Facemire and Jim Bridges in these timecode issues. Our Tommy Schell has done extensive testing in our lab.

A couple of hours ago, Allen and I were on the phone and we determined the problem.

The HDX900, when it goes into record mode, typically respositions the tape.

While it is doing so, it is sending out timecode.

When we see that the timecode is incrementing, we start recording, if we are set to start recording on incrementing timecode.

The first timecode that we see is what we place into the file header.

Some Non-Linear Editors and players will take this "Starting Timecode" from the file header, then increment it for every frame. Thus, the first timecode is critical.

For non-tape based cameras, the starting timecode that we see is the starting timecode of the file.

But for some tape based cameras, the starting timecode that we see is not the "real timecode", not the actual timecode when the camera lays the first frame down to the tape.

During the last two hours we have been discussing this internally.

We will add a new feature to the nanoFlash and to the Flash XDR.

We will have a "Delay Start" menu item, where one can enter the number of frames to delay before we start to record.

With this, we will ignore all "bogus" timecodes, for xx number of frames.

Then we will start to record, and place the "good" timecode in the file header.

It is our goal to include this in the next release and to release the next release as soon as possible.
As always, we have to go through extensive testing before we can release the new firmware.


Note 1: Allen Facemire came up with the idea for this new feature. We appreciate his support and that of Jim Bridges who also did extensive testing.

Note 2: We actualy record timecode in two places.

One, the starting timecode in the file header.

Two, the timecode for each frame is recorded within each frame.
(Most Non-Linear Editors do not use this timecode.)

[Robin Probyn]

Originally Posted by Allen S. Facemire

After an exhaustive day of testing the Nano Flash and related TC issues, I found some interesting things. First off, the HPX2000 P2 camera and I suspect ALL P2 cameras have NO TC issues. The TC you record on the Nano matches the P2 to the frame. The PDW700 XDCAM and I sure the rest of the family is only one frame off...consistently...not a problem at all. But the HDX900 is all over the place and I found out why. Since it's a tape based camera, it goes into what we used to call "Back Space Edit" in the old Beta days. This is when the tape actually goes back a bit to find the TC break and once that point is reached, it's skips a beat or two to start laying down TC. The Nano reads the very first TC number and assumes the sequence. However as the tape has caught up to real time, the Nano has already been recording for for 28 frames or so, thus no matching TC.

The fine folks at Convergent have been made aware of this anomaly and have assured me that a firmware fix is in the offing. Basically they will come up with an optional 3-5 frame preroll option so that the Nano won't actually be accepting TC until the tape has settled down. This will solve everything. So until they release the firmware upgrade, the way to make sure the TC on tape matches TC on Nano, is to simply disable the TC trigger option and manually record. A bit of a pain but knowing a fix is in the future, I'm good with that.

Thanks Dan, Tommy and Mike for coming to the rescue.

Hi Allen & Dan

I also have the Pana HDX900.. if using the nano as primary source and tape as back up.. would this TC discrepancy be a problem.If so how? and /or what could be done.How would the new function mentioned by Dan work if the HDX900 TC difference is not a consistent number of frames each time record is hit?

Thanks

[Dan Keaton]

Dear Robyin,

When one presses the record button on the HDX900, under certain camera setups, the camera starts putting out timecode, which is typically bogus timecode. The problem is this initial stream of timecode is not valid until the camera repositions the tape and actually starts recording.

(This can be easily checked with your camera by connecting the camera to a timecode display and carefully watching the timecode as the camera sets up to record.)

Thus, this timecode does not go onto the tape, but it is sent to us.

With our new menu option, you will be able to specify how many frames of video we are to ignore, prior to going into record. A certain value will allow you to skip the bogus timecode that we receive.

This will allow the nanoFlash to be tailored to your camera, and to allow the nanoFlash to operate with a wide variety of tape based cameras. Of course this value can be set to zero.

With any tape based camera, there is a delay before the camera actually starts recording, and a camera operator ususally plans for the delay. Of course, when the heads are spinning and the tape is positioned in the correct place, the delay can be minimal. At other times, when the tape needs a lot of repositioning, the delay can be longer.

Please understand that all of this is moot if you are using the nanoFlash as the primary recorder.

But, if you are using the tape as the primary recorder and the nanoFlash is for proxy recording, then the timecode displayed in the NLE or Player is important, and the timecode on the tape must match.

Also, please note that every frame of video recorded in the nanoFlash has the exact timecode that the camera has provided. It is just that many NLE's and Players do not actually use this recorded timecode, only the timecode recorded in the file header.