nanoFlash is Now Shipping
 

Dear Friends,

I am pleased to announce that we started shipping production units of the nanoFlash last night, Friday, July 10, 2009.

These were our limited, initial, shipments; volume shipments will start the middle of next week, around July 15th.

We expect to have shipped all of our priority pre-orders by July 31. Between now and then we will be building, and shipping, the nanoFlash as fast as possible.

We cannot predict demand, but our goal is to have the nanoFlashes in stock for immediate delivery.

Since NAB, we added the following to the nanoFlash: audio inputs, mic and line; headphone out; 140 Mbps and 160 Mbps Long-GOP, and 220 Mbps I-Frame Only; and a Pre-Record Buffer. We also redesigned the case, the keypad and two circuit boards since NAB.

We have more features yet to come. We will be adding over and under-cranking and other features that are in progress. These will come as free firmware updates, just as we have been adding more functionality to the Flash XDR over time.

(Our ASI support is an extra cost item as this is a very specialized feature.)

Very kewl. Congrats. I thought over/under cranking was a feature of the camera? Are you adding a software algorithm to do this for you in the devices, as you can't feed it more frames than the camera puts out.

Is there going to be a more CineForm compression possibility eventually? I know the video looks outstanding, but I'd want to see something like CineForm or REDCODE to have even better source material to work with when moved to the computer.

Again, congrats.

Dear Kevin,

Yes, over and under-cranking is typically done in the camera.

But, since we are doing the recording for the camera, we can add this feature to cameras that do not have over and under-cranking.

We, however, do not create more frames than what is sent to us.

In the example of 720p60, we will do over and under-cranking from 1 to 60 frames per second.

For 1080p30, we will do 1 to 30 frames per second.

Our nanoFlash is not setup to record Cineform internally. But there are many ways for you to still use Cineform, if desired, in your post processing.

Just remember, that if you use our 100 Mbps Long GOP or better, one can not tell visually between live uncompressed and our playback; or your using our files in post (of course, this is dependant on your post workflow).

Hi Dan,

Great news that everything is coming together; congratulations. I have a favor to ask, as well as a question.

(The favor) Now that you're getting into shipping mode for the Nano, could you put together a specification "sheet" of exactly what it (the firmware and hardware) does? I've been reading (and waiting with baited breath) for months, but I no longer have a clear picture of what the shipping units actually do. If I've somehow missed it, and there's a posting somewhere that is current, a pointer to that would be great. If there's a current user manual, I'd love to be able to download it.

(The question) I remember a while ago that there was an XDR failure mode when the input signal was interrupted. I also remember that you came up with a fix, but that the fix only applied if the interruption was long term. (Or something like that). What I don't remember is whether you implemented a fix that deals with momentary (e.g., intermittent connection) interruptions.

Thanks!

Billy

Dear Billy,

We just created an "up to the minute" brochure on the nanoFlash a few hours ago.

We will try to post it on our website on Monday. In the meantime, if you send me a private message, I will send you the brochure. I do not think it would be right to post the brochure here.

We can also post the current nanoFlash user's manual on Monday.

Yes, there was a failure mode if the HD-SDI signal was interrupted.

We now close the current file, stop recording, and then restart recording when we have another good HD-SDI input stream. So yes, we do handle, gracefully, interrmittent conditions.

But, if we have a glitch in the HD-SDI, it takes us a few seconds to do the above, but when the signal is stable again, we will lock on to it and restart recording.

Under normal circumstances, one should not have glitches in the HD-SDI signal.

Thanks Dan,

I also check your main site as well as this one, and if you plan on posting the spec sheet - brochure on your main site, I can just grab it there when I grab the manual you're planning on uploading there; thanks.

Delighted to hear that you deal with interruptions to the SDI input now, that's pretty important to me. (And yes, I realize that the feed shouldn't be intermittent, but I shoot so many "only happens once" things that I tend to prefer equipment that deals well with unexpected circumstance). :)

Billy

Dan,

The AJA Ki is getting the headlines, but you guys smoke that as far as I am concerned. I've seen your ads in HDVideoPro. Nice. But, you should rework it into a 2-column deal, splash of color, and put it in ASC. You've got the goods, go collect your prize.

Great ...
 

Delighted to hear ... I await with pleasure!

you guys are cool ...
 

Just one thing because you could probably do it ... figure out a firmware update that deals with the banding on burst light flashes. Panasonic has done it for their cameras. I just wonder if that's something you can add. I'd expect to pay for it as an added expense but think about all the CMOS camera people that will buy you beers in any joint and any city in the world !!!

In regard to SONY XDCAM PDW800 and PDWF355, can nanoflash record the 1080 60 half resolution they output?

Dear Emmanuel,

One the PDW-800 modes allows for 48p. We do not currently support this, but this is more of having a camera to test and the time to develop the support for this mode.

I feel that we would have to add code to recognize the special half-vertical resolution mode of the PDW-800 camera also.

Since we will need to research these features and disucss it with our engineers, this is not a promise to support this at this time.

It is my goal to fully support this camera if at all possible.

Dear Dean,

I think that is a great idea.

How does this sound:

...What if we detected the bad frame, then duplicated the previous frame, a frame which should not have the problem?

...Would this be good enough, or would we need to check each horizontal row for problems and then replace just one row (scan line)?

...I feel that replacing the entire frame with the previous frame would be best, as this could correct for all defects, those that we can detect, and those that we can not detect.

...This is assuming that there is some image characteristic that we can detect. I feel that there is.

I will check with our engineers. We have recently added a special feature to overcome a problem with a high-end camera. I will be reporting on this soon, maybe this week.

Note: This is a discussion at this time, not a promise. Personally, I think this is a great idea!

it certainly would be interesting ...
 

Panasonic ... as I understand it ... simply took the light that banded across the imagine and applied it to the whole image. I've seen examples of this and it's pretty good. You still see the flash but it's even across the imagine ... it doesn't seem to destroy the imagine either.
I suppose there are other ways to tackle this ... per your suggestion that one sample the frame prior to the flash and see how that plays with the overall imagine. Could be interesting !!

Hey Dan,

Glad you guys are reaching your next milestone.

The repeated frame for the strobe banding sounds like an easy fix.

My only concern is shooting at a lower framerate like 24p might be slow enough that this could be noticeable?

60p would probably have no issues.

It is crazy to think the frames can be analized and corrected whizzing by in HD!

How would the XDR know when to add the correction?

Seems like that parameter would need to be pretty narrow as you wouldn't want that shot of a bride for example with a white dress being confused by the XDR as a white band area and start repeating frames...

Hi Dean-
Can you send (or post) sample images?

Best-

Hi Billy-
We should have the updated brochure and owner's manual uploaded to the website by 14-July. I am working on a major update to the FAQs this week.

Best-

Two other cool features
 

Just wanted to mention that the nanoFlash also includes an auto power-down and battery voltage monitor (voltage is displayed on the LCD screen).

The power-down feature, reduces the power dissipation from 6W to 0.2W whenever the HD/SD-SDI input is disabled (for example when you turn off your camera). The nanoFlash will "boot-up" in about 4 seconds when you turn your camera back on.

If you enable this power-down function and enter record mode, the nanoFlash will automatically close the current file and enter low-power mode whenever the HD-SDI stream is turned off. When HD/SD-SDI reappears, the nanoFlash will boot-up and resume recording. So you could setup the nanoFlash in record mode and simply use the on/off button on the camera to trigger record start/stop. The low active power dissipation combined with auto power-down provides hours of operating time, even on a small battery.

Regarding the battery voltage monitoring, we plan to add more code in the future to automatically close files and enter low-power mode whenever the battery is about to run out of juice.

Best-

Go here ...
 

some examples of Panasonic's solution.
New HPX300 Firmware | CineTechnica

strobe banding ...
 

I suppose if you are going to shot a fashion show or red carpet affair ... you might just want to do it with more frames in the shoot. But on the whole ... it does sound possible to correct this issue in this way. The other main concern would be to turn this function off and on as there are times when you might not want to have it.

I'm super excited about the nano!

I will be posting many interesting image comparisons between on board HDV from the XL-H1, and then various simultaneous SDI/nano recordings as soon as I can get my hands on one in the next few weeks. (I have a good friend on the July pre-order list)

Dear Tim,

I feel that the fix I proposed may be a problem in 24p mode. Also, this new feature must to optional, via a menu selection. But, for higher frame rates it should work find, in my opinion.

This fix, using the previous frame, will not work if there are constant or multiple flashes in successive frames, maybe this is why Panasonic chose the the solution they did.

Yes, it may be very difficult for us to analyze the video and make the corrections.

To start this process, we will need to analyze video from multiple CMOS cameras to determine if we can find a way to detect the problem.

I do feel that it would be worth the effort to determine if we can find a fix for this problem.

If the flash compensation is something you guys could really add it would be another strong reason to go with your products over any other option.

The Ex-1 crowd would be rather happy.

Although now that Panasonic has this for their CMOS camera, one would think Sony would offer a solution to the EX series, but maybe not.

Flash compensation could be really undesired when shooting either explosions or fireworks, but I repeat myself.

Dear Bill,

Yes, this would have to be an option, selectable via the menu. Only those that would need this would turn it on. Anyone with a CCD camera would probably not need this.

For some it might be a huge help, for others, it may not.

If one is at a major press conference, with flashes going off in most every frame, my solution would not be so good.

We may be able to make a trigger that could distinguish between fireworks and photographic flashes.

Agree ...
 

Here's the thing ... it might be going with the light flow to sample the flash and spread it through-out the imagine instead of cutting it out. That is I think the approach Panasonic is doing. It's worth the effort. Good luck!

Dear Dean and Tim,

In an ideal world, a nice tool, in all of the NLE's that would correct for the image problems would be great.

This tool would thoroughly examine the contents of each frame, and

1. Drop the video from certain frames if a Flash occurred, and the frame rate was high enough, and the previous frame was good.

2. Adjust the light level in each frame where the previous frame also had a problem, as one cannot drop more than one frame, in my opinion, without the effect becoming noticeable.

A tool in post would be far superior to what we can do since whatever we do is permanent.



In the real world, it will take time for the NLE's of the world to add this tool.

And in the real world, we have limited time to analyze and process each frame. The HD video is coming at us at 1.485 Gbps!



I like Panasonics approach for when there are flashes in successive frames or the frame rate is low, as in 24 fps.

I like my idea of duplicating the previous frame when there is only an occasional flash.

I like the idea of doing it in post, as the original footage is not affected in any way.

With all due respect to those looking for image manipulation as part of the XDR and Nano, I would much rather see time spent on making the units bulletproof and utterly reliable. I would also like to see many of the features which are more important as a recorder such as 10 bit, hot swapping, Raid 1, locking keyboard and time lapse for example completed and solid before time is spent to fix a problem which is from a camera and probably could be more appropriately fixed with a plug-in in editing or in the camera itself.

Sorry to be blunt.

Jeff

Dear Jeff,

This is just been a discussion of what we may be able to do to respond to a customer's problem.

At this time, no engineering time has been spent working on a solution to this problem.


We have spent many hours making the Flash XDR and nanoFlash reliable. Time will tell if we have achieved our goal. This has been our number one priority.

In our quest to achieve perfect reliability, we have found that some cameras put out illegal values, codes that, according to the spec, have special meanings.

With these cameras, exceptionally bright points of light will cause illegal codes to be generated. With others, just a very bright overall scene will cause these codes.

An example would be the bright sun reflecting off chrome or glass.

We now have firmware that detects these codes and takes corrective action.


We also have built into the firmware support to gracefully handle a long term, or very short-term loss or glitch in the HD-SDI signal. This support closes the file gracefully and restarts recording when we lock on a good HD-SDI signal again.

At this time, this support works, but we want to improve upon it, as it currently takes us 4 to 10 seconds to perform the above steps. We will improve upon this in a future release.


Here is our priority list.

1. Investigate and fix any reliability problems that are reported.

2. Build a "Golden Image" into the nanoFlash.

We have had many instances of our firmware update process being interrupted. This typically occurs when someone uses an almost dead battery, the power is interrupted, or a person interrupts the process by powering off the device or removing the CompactFlash card.

The nanoFlash was designed so that we can store a "Golden Image". This is backup firmware that allows the unit to function, even if the firmware update is interrupted.

We will be working to incorporate this "Golden 'Image" into the nanoFlash.

3. Hot Swapping.

We intend on adding Hot Swapping into the nanoFlash and Flash XDR as soon as possible.

And, of course, we have other items on our list.

To be clear, I agree that the flash band thing is out of the XDR's main role.

Would it be a positive, yes.

Is it a deal breaker, no.

Are other features more important, yes.

Dan's suggestion about NLE's is a better way as it is not permanent.

But this is a discussion forum and I see no harm in the topic being thrown around.

Hi Jeff-

We agree! We have another XDR update in final test this week which corrects an issue with the Cumina camera. The Cumina camera produces HD-SDI luma and chroma values which are technically outside the legal range. These values caused processing errors in our HD-SDI detection which resulted in drop-outs during record. The new firmware corrects this problem.

We also found an issues with some of the QT/MXF file headers which occurred about once every 500 files. The files were repairable, but
had to be e-mailed to us for the correction. This issue has also been fixed with the new firmware.

We continue to test on a daily basis to identify and fix any remaining issues.

Best-

Dan and Mike,

You know I appreciate your work in making the units more reliable. I have taken exceptional heat from clients when we have had problems in the past but I agree that I am much more comfortable than ever with the improved reliability of the units.

I realize that much of the firmware architecture will be shared between the XDR and Nano. That should go a long way to making the Nano's release smoother than the year we have spent improving the XDR. I always clearly knew what I was getting into as a early adopter.

When these boxes work they are exceptionally valuable to productions. I have not run into one client who isn't fascinated by potential of the systems. I only ask as always that the number one priority is reliability. That should trump new and cool features, and release dates. No doubt we are going to find other new cameras and NLE's which don't behave exactly within spec.

And I know we all would appreciate a current and updated list of known shortcomings in the units. That is the first I heard about the Cumina camera, thanks for mentioning it. I don't see sharing issues such as that as any sort of a negative. It is a great way for everybody to avoid repeating problems until they are solved.

Thanks again.

Jeff

Reliability Remains our #1 Priority
 

Hi Jeff-
Thanks for the feedback. We wholeheartedly agree that reliability must remain our first priority. We do have a rather exhaustive test procedure in place now. Every new code release now requires one full week of testing, including extensive recording in which every file is checked for proper playback in the XDR/nano and on a PC/MAC. It has become quite an arduous task.

That said, I'll be the first to admit that we do make mistakes and can overlook some test cases. We have a limited amount of hardware (cameras, supplies, etc) and we certainly cannot test under all possibly conditions or with every possible app (we do regularly check files on FCP and Avid). So problems and issues can slip through.

I do agree that making everyone aware of problems, such as we recently found (and corrected on the next firmware release) on the Cumina camera, is in our best interest. It's far better that a user know about a particular problem beforehand, rather than miss a critical shot. We will try to be more forthcoming when these problems arise in the future.

Best-

Mike, there are those of us out here with the means to do some checking for you guys. I have access to 3 editing machines and have an FTP server. It would take absolutely nothing for me drop a short file into one of my NLEs and run it through a battery of standardized tests. Right now, I have Vegas 9.0 64bit, 9.0 32bit (both running on Windows 7 and about to install on XP64), I have Vegas 8.0b and 8.1 running on XP64, and Vegas 8.0c running on Windows 2003.

-P

Dear Perrone,

That you for your generous offer.

You could be of great assistance to us.

For Sony Vegas, we need 8.0(c) or above, as 8.0(b) does not support the XDCam files, such as ours or the ones from the Sony PDW-700/800 cameras.

Dan, as mentioned, I have 8.0c available and installed, and 9.0 64 and 32 bit. If you're serious PM me, and we can discuss what you need.

Dear Perrone,

Sorry, I was just trying to say that you will not need to test in 8.0(b), just 8.0(c) and above.

We appreciate you very kind offer. I will send you a PM shortly.

Who got the nano's first off ... I suspect people who are going into a production ASAP or who are doing some high end production that will test the nano/flash. I haven't received any notice that mine has been shipped ... so, I'm assuming early adaptors have not been shipped yet.

Dear Dean,

We have had a delay in shipping.

On Friday, our testing uncovered a problem when we record long files, say 10 minutes or longer.

The Flash XDR and nanoFlash code is very similar, in fact they share the same code, except for the physical differences between the two units.

We thought it was best to delay shipments until this problem is resolved. We believe this to be a firmware issue and our engineers were working today to fix it.

Since this is a repeatable problem, not an intermittent occurance, we are confident that this will be resolved in a few days.

We based this assessment on past experience with the Flash XDR. We have had similar problems with the Flash XDR firmware, ones that were detected in our testing program, and in all cases, it never took more than a few days to correct the problem.

In the mean time, we are still building nanoFlashes and will be able to resume shipments as soon as we correct the firmware.

yep ...
 

Seems like they've found a problem. Would like to hear about a revised schedule?

Dear Dean,

Yes, we have a problem in the firmware.

We are still working to determine the problem.

While this sounds like a big deal, it is not.

A FPGA, Field Program Gate Array, is one of the main parts in the nanoFlash.

This is like a microprocessor, except that it does everything it is programmed to do at once (in parallel).

A normal microprocessor does what it is programmed to do in sequence, step by step, one instruction at a time. Of course some microprocessors are capable of executing a few instructions at a time, up to 8 or 16.

The FPGA does thousands of things at once.

It is typically much more complicated working with a FPGA than a microprocessor, but the rewards are much faster operation for a given amount of power.

We will announce when we have this fixed. Typically these problems take a few days to find and fix.