I bought the nanoflash last week to use with my HDX900 but am having big problems. 75 percent of the time it works fine, but one time out of four after a few minutes of recording it flashes "intermittent source", stops the recording, and starts a new one leaving a three or four second gap. The CD people say they are working on this and hope to have a firmware solution in few weeks, but until then I am left with a very expensive paper weight. Has anyone else had this problem ?

Hi Mark-
Could you call me at 720-221-3861? We have an HDX900 in house, but have not been able to replicate the problem. We need your camera settings.

Thanks-

HDX-900 should work fine, have you tried another cable?

It now seems that it only happens at 720, not 1080. Interesting....

Hi Mark-
Thanks again for your help debugging the firmware. We are hot on the trail for a fix to the intermittent source. Yes, it does appear to be a 720p only issue.

Best-

Is this with the production firmware.. ? 1.5.126

Thanks

Is this with the production firmware.. ? 1.5.126

Thanks

Hi Robin-
Yes, this is a problem with 1.5.126. We are expecting a beta post early next week with the corrected firmware.

Best-

Hi Mike

I also have a HDX900.. luckily I,ve always used the nano with 1080i setting.I have since installed 1.5.249 thinking it was a new production level firmware.

Are the next updates you mention going to be for 1.5.126.. or for 1.5.249.. or will they be separate up dates for each.. getting confused :)

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.

Dan, I think you should have a day off. I have followed your tireless replies to all the postings over the last 10 days and cannot think of another company that supplies such a service. BTW my Nano is working well up to expectations.

Dear Bruce,

Thank you very much.

I will be traveling to a trade show on Monday, that will be a more restful day for me.

The rest of our staff are the ones that deserve all of the credit.

Our engineers who found this "Needle in the Haystack", "Intermittent Source Problem", are due all of the credit.

We really look forward to posting our next firmware release. We will be posting it as soon as it passes all of our internal tests.

Also our manufacturing staff built special heat chambers for extended testing of all of the nanoFlashes.

We typically test 48 nanoFlashes at a time, for a period of days, constantly recording, with the internal temperature of the nanoFlashes cycling between 30 degrees C and 70 to 80 degrees C.

This very thorough testing has allowed us to catch units that may have failed in the field. Since the nanoFlashes are each recording hundreds of files, each of which are individually checked, we are catching any nanoFlashes with marginal parts.

This heat cyclying program has also been a fantastic test bed for our new firmware. Having the firmware run continously for days on 48 or so nanoFlashes, under extreme conditions, has allowed us to catch and fix very elusive firmware bugs.

Up until this weekend, our video source for our heat cycling/major testing program has been a 1080 signal.

On Wednesday, we realized that almost all of the "Intermittent Source" problems were when recording in 720p. Of course, this may be wrong, but it certainly was our perception. This realization helped us track down and fix the problem.

So, at this moment, we are recording 720p to a nice number of nanoFlashes, testing our latest firmware.

We wish to publicly thank Camera Department, in Toronto, for loaning us a Panasonic HDX900 camera so we could find and fix this problem.

Our "Intermittent Source" error message can be caused, by a bad cable, an out of spec cable, electromagnetic interferrence, a camera that "glitches" when it goes into record or at other times, a bad (out of spec) HD-SDI signal, or by just turning off the camera while the nanoFlash is recording. And it can, and was, sometimes caused by a nanoFlash problem.

As part of our efforts to get to the bottom of this, we will be implementing a display on the nanoFlash that shows the number of CRC (cyclic redundancy check) errors that we are getting on the incoming signal.

This will be very nice for our users, as it will allow each nanoFlash user to detect if there is a problem with their cable, camera, connection, or if they are in an electrically noisy environment that is causing problems with the HD-SDI signal.

This new feature will also instill confidence when we indicate that no errors are occurring, as well as allow the user to take corrective action, such as replacing a cable if errors start to occur.

Another great thing about Dan is that he always tells it like it is, with all of the details that really help you to understand what is going on.

I have learned a lot about encoding etc... from speaking with Dan.

He is a great representative for the company.

Dear Tim,

Thank you very much. Comments like yours are very rewarding.

Dear Bruce,
Our "Intermittent Source" error message can be caused, by a bad cable, an out of spec cable, electromagnetic interferrence, a camera that "glitches" when it goes into record or at other times, a bad (out of spec) HD-SDI signal, or by just turning off the camera while the nanoFlash is recording. And it can, and was, sometimes caused by a nanoFlash problem.

As part of our efforts to get to the bottom of this, we have implemented a display on the nanoFlash that shows the number of CRC (cyclic redundancy check) errors that we are getting on the incoming signal.

This will be very nice for our users, as it will allow each nanoFlash user to detect if there is a problem with their cable, camera, connection, or if they are in an electrically noisy environment that is causing problems with the HD-SDI signal.

This new feature will also instill confidence when we indicate that no errors are occurring, as well as allow the user to take corrective action, such as replacing a cable if errors start to occur.....Hi Dan: I was wondering about this specific issue myself just the other day when reading over, logging, and taking notes at how many varying problems there has been overall with the Nano (and XDR) not going into record, or going out of sync during record, etc with whatever cameras used on the other end posted on this forum. In my opinion, close to 40 % of Nano record, or losing sync malfunctions *could be* identified as being the result of the variance in camera TC Regeneration and HD-SDI signal output specifications from one manufacturer to another. * My observations are NOT very scientific, however, as they are based on reading over the history of problems posted on this forum. I have been taking note of the amount of problems by camera manufacturer, with Canon producing the least overall malfunctions with the Flash XDR & Nano Flash, while Panasonic cameras seem to be producing the greatest amount of errors overall with the Nano Flash specifically. One of the reasons I think my results are not scientific, is not all users of the XDR & Nano post their problems on this forum, therefore, the forum isn't indicative of absolute performance stability, or lack thereof.

60 % of all malfunctions are Convergent Design firmware in nature. (This is based on folks downloading and installing latest firmware, then posting problems they had with it on this forum).

** Let the reader understand: Only folks who have a problem with the XDR or Nano are posting, while others who are not experiencing any difficulties are not posting here. I think it's important to make this point as well.

***( My personal end user experience shooting with the Flash XDR since purchasing it last Summer):
95 % Great. I use my XDR @ 50 Mbps. MXF for 100 % of any commercial jobs I'm shooting, and I have had Zero malfunctions with my unit on the job ! I use my XDR in what I will refer to as *Black Box* mode.
By this statement I mean I record, then dump straight into NLE - Nothing fancy, such as, Time Lapse shooting, Over/Under cranking, Wireless Jam-Sync shooting (Yet, but I will do shortly). My difficulties have come from using what I refer to as the "fancy features," such as time lapse shooting for visual effects on my personal web series Please Stand By. In the beginning time lapse file size was messed up and header closing was not being performed properly, but all is well with this feature now. I have yet to use the Record Buffer feature to capture lightning, but will try this out this Summer. We are moving into the short severe thunderstorm - Tornado season in Canada, so we'll see how that works. I know Alister (Forgot last name sorry) over in the UK has used this feature quite successfully.

Dear Friends,

Our testing this weekend indicates that we have the intermittent source problem solved.

We used two cameras, both set to 720p, to a two large groups of nanoFlashes.

We had zero "Intermittent Source" errors. Each and every nanoFlash involved in the test was checked within the last 30 minutes.

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.

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.

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

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-

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.

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

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

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.

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-

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

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-

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.

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.

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.)

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

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.

Ok thanks Dan

So far,and in the foreseeable future when using the Nano with the HDX900.. the nano CF is the primary data.. so not really a worry.. but good to know whats going on !

There was mention earlier that 720p 24p still has some TC issue..? what would that be?

Thanks

Hello,
I was fighting with the timecode issue all summer 2009 during a big 100 day shoot, we finally stopped using the nano with the hdx900 but only with the ex3.
If the "tape repositioning" is the problem,then the TC delay should not occure when you use the record button when a shot is recorded on tape after some seconds.
Did anybody tested this?
I would be glad to finally be able to use the nano what I bought it for: Turn the HDX900 to a solid state camera and don't worry to much about databack up, because there always is the tape in the archives.
axel

Dear Axel,

We are here to assist you if you have any problems with the nanoFlash.

Yes, we discovered the cause of the timecode problem, specifically the HDX900 sends out inappropriate timecode while it is re-positioning the tape, prior to when it actually starts to record to tape.

We used what we discovered to create a menu option which allows the nanoFlash to work around this problem.

This firmware has been successfully tested in the field and it works fine.

I can send you a version of the firmware that has this change.

I will send you a private email shortly.