nanoFlash Public Beta 1.6.226 Firmware Comments

[Andrew Stone]

Hi Dan,

I have used the NF on two occasions doing start/stop takes, flipping on the fly to various bitrates in camera with high bitrate settings in iFrame mode in the unit. Only hickup was pushing the bitrate up to 280 on a Delkin 64GB card.

The flip mode is great for doing a quick and dirty "low mode" switch with a Steadicam. I thank you and whomever solved the puzzle in being able to do this in firmware.

Finally, I know I asked you this before... is it technically possible to do image flip particularly in "E to E" mode but on the "monitor out" image and have it rolled into a future firmware update?

-Andrew

[Dan Keaton]

Dear Andrew,

As you probably know, the Delkin 64 GB card only supports 220 Mbps, not 280 Mbps.

If I understand you correctly, you want to enable E to E, and Image Flip and have the nanoFlash record normal (not flipped) but send the flipped image out the HD-SDI or HDMI outputs.

Could you please let me know if I do understand correctly what you want?

[Andrew Stone]

It would be an either/or scenario. Here are the scerarios. A nanoFlash on a Steadicam. The operator has to invert the sled (i.e., upside down) so they are operating in "low mode" so the camera is close to the ground rather than waist to head height. Sometimes the operator doesn't have time to take the camera off the sled to invert the camera. This is where your veritical image flip is a boon. They just invert the sled, quickly rebalance and normally hit the image flip switch on the monitor. However, some of those operators will have a monitor that does not do image flip. Presently, there is a very attractive one made by Marshall right now that has superb daylight visability but no image flip. It costs about 1/2 the price of comparable monitors with good visibility in broad sunlight. A lot of operators are snapping this one up despite it's lack of image flip. Presently the solution for this is to physically remove the monitor from the bracket and turn it 180 degrees and bolt it back on. This can slow down production and flow on a set.

It would be best if CD was to be able to setup menu options that would allow image flip whether or not the recorded image was flipped, as sometimes the camera will be physically flipped in low mode and other times not. Best to have both scenarios factored in.

"E to E" mode would be on as the operator wants as close to real time preview as possible. I understand image flip in E to E may add some latency but I would hope it would still be close to real time in the monitor.

Thank you and the developers for considering this. I hope it is doable.

EDIT:

Almost all Steadicam people are going to be using the HD-SDI port to their framing monitor but there may be some in the future using HDMI based gear if the newer DSLRs begin to issue a proper signal via HDMI.

And yes, I know the Delkin is only rated to 220. The nanoFlash allowed me to go to 280 iFrame so I thought I would give it a go thinking CD may have done some tweaking to get more out of the Delkin 64GB card.

[Dan Keaton]

Dear Andrew,

I have already spoken with our Chief Engineer about your request.

I am not hopeful that we can do it. I wish I could say yes.

Image Flip does, inherently, involve a processing delay.

Are the recorded files just for you, or are they going to be used as part of the production?

I will send you a Private Message so we can talk about your application.

[Andrew Stone]

Good chatting with you this afternoon Dan. Unfortunate, that it is technically complicated to do an image flip switch on the monitor output. Would have been another practical addition to the long list of production focused improvements your team have brought to the nanoFlash since it has been released.

I really hope one of your programmers has a 3 in the morning "a ha" moment figuring out an unforeseen elegant way of pulling this off.

[Ernie Santella]

Just a suggestion. It would be really helpful to have a switchable T/C display on the HD-SDI out.

[Dan Keaton]

Dear Ernie,

I agree, that would be a very nice feature.

I know that some monitors have that feature built in, and many do not.

However, we will be unable to implement your request.

Displaying characters, superimposed on the HD-SDI or HDMI output requires either very specialized circuitry, or takes up a lot of code.

Regretfully, the nanoFlash, with all of the other features that we have implemented, we can not add the "Character Generator" that would be required.

[Piotr Wozniacki]

Dear Dan,

I understand it's currently not possible to keep the }CFG{ folder permanently on the "production" CF cards, i.e. those cards that are used for actual recording. Also, whenever a card with the }CFG{ folder is inserted, the nanoFlash will automatically prompt for loading one of the configurations...

Is it necessary to be that way? I mean, the }CFG{ folder could be present on each card, and only accessed on user demand. Also, it'd be nice if the nanoFlash could record to such a card.

This is how the SxS cards can be used by the EX cameras.

Do you think it's possible to implement in future firmware?

Thanks,

Piotr

[Dan Keaton]

Dear Piotr,

Yes, that would be very nice.

If we think outside the box, we could conceivably:

1. Prior to a Format, load the }CFG{ files into memory.
2. Format the card or cards.
3. Recreate the }CFG{ file on the card.

Then redesign our CFG support so that the files could be on the same card as a card that we write to.

Alternatively, we may be able to load the }CFG{ files into memory.

It is all just a matter of time, resources, and priorities.

Today, one can just purchase a very low capacity card, of the same brand and type of a qualified card, and use it for the config files. Or use an old card that has been replaced by a higher capacity card.

We highly recommend that one keep their config files backed up, say on a computer, or other device.

[Piotr Wozniacki]

Originally Posted by Dan Keaton

It is all just a matter of time, resources, and priorities.

Absolutely - but don't you agree that the need for inserting a separate card in order to load a desired menu setting configuration can be more tedious than setting such a configuration in the menu, manually?

I mean, the configuration "store" is a great idea, but a need for separate card sort of denies it. Therefore, please consider assigning a high enough priority to my suggested modifications :)

Thanks,

Piotr

PS. BTW, all the complications you described above again result from the need of formatting cards, rather than simply deleting files...

[Clarke Thomas]

Just FYI, I loaded the firmware, and today, prepared to depart on a 2 day job. In testing the system, I found the HDMI colors were reversed or something of the sort. I am using a Sony HDR-FX-1000 and recording HDMI in and out of the Nano with .mpg file format at 35mbs rate and analog audio input. i had a similar episode about a year ago, thankfully that made this easier to diagnose.

Backing up to the earlier 1.6.213 version beta, all is good again.

[Andy Mangrum]

Hello Clarke

Inverted Colors may Occur on all Code version, with an HDMI Input, What would be the best test to see if it is a HDMI MPG Input Issue would be disconnect the HDMI and Reconnect it, Most times that will fix the inverted colors that is pretty rare to see, but does happen only with HDMI input. Once in a while,

In our Lab we have had multiple units running HDMI Input all with normal color with the beta,

If you could check that, that would be very beneficial for us to know. And i will double check this in our lab today as well.

Thanks

Andy

[Billy Steinberg]

Originally Posted by Piotr Wozniacki

... don't you agree that the need for inserting a separate card in order to load a desired menu setting configuration can be more tedious than setting such a configuration in the menu, manually? I mean, the configuration "store" is a great idea, but a need for separate card sort of denies it ...

I don't agree at all.

(1) Setting all the different configuration settings takes a VERY LONG TIME, and requires you know exactly what every setting does, where it is in an ever increasing nano menu system, and how it's going to impact your current job. The opportunity to screw up is great. Dumping a pre-checked configuration file takes very little time, and you can spend any extra time you gain by checking to make sure everything loaded properly. Hence the desirability of configuration files.

(2) I don't want a configuration file on the same card as I'm recording. Keeping separate (small, inexpensive) CF cards, CLEARLY LABELED, for each different setup, is the safest, easiest, most sensible scenario. If CD, in some future update, allows for multiple different configurations on a single card, with a menu system in the nano to select which configuration to load, that would be great, but I still don't want my configuration file(s) on the same card(s) that I record to.

Think about the different scenarios in which the nano is used. If you're using a single card to record your whole leisurely shoot, and the nano configuration is unchanging, and you know what all the nano settings are supposed to be, then you don't need a configuration file at all. (You are going to check the settings, aren't you, even when you use a configuration file). If you're shooting something that requires multiple different settings, particularly if fast changes are necessary, do you plan on having a different CF record card for each setup? Do you really want to tie specific configurations to each record card? What if the client wants all his footage on a single card? What if one setup only has five minutes of footage; are you going to "waste" a 64GB CF card on it? What if you have no idea beforehand how much footage is going to be shot in each different nano configuration?

How about when it's not you using your nano? Isn't it easier and safer to tell someone "There are 'Configuration' cards and there are 'Record' cards. When you shoot the inside stuff, put this card labeled 'Inside Configuration' in the nano and load its settings. When you go outside, put this card labeled 'Outside Configuration' in the nano and load its settings. When you get to the stadium, put the card labeled 'Time Lapse Configuration' in the nano, and load its settings. Then just record as appropriate to however many of these 'Record' cards you need to record the footage at each location."

/rant on
Oh, and while we're talking about the new firmware, it's taken two plus years for CD to implement hot swapping. They're the only one in the business to implement anything like it, and many of us have been faithfully waiting all this time for a feature that's very important to us. CD has (patiently) explained why using freshly formatted CF cards is so important to making hot swapping work, and there are still complaints. So my "plea" is to give them a break and accept the fact that this remarkable feature has a minor requirement to make it work.
/rant off

Dan: Please concentrate on finding (and fixing) any bugs in the firmware, and don't waste time and resources by adding new features until you're satisfied everything is stable. Thanks (for everything).

Billy

[Clarke Thomas]

Andy,
Thank you for the suggestion. Unfortunately I had a fllight schedule to make and had to go another route. I did reboot the Nano a couple of times with no change. I then reloaded 1.6.213, and immediately upon the reboot, everything was great. I use exclusively HDMI, and have only had this once in the past. It was about a year ago, and came with a firmware upgrade, and was fixed with a firmware upgrade. I really do think there is a bug in the software somewhere, or possibly I had a corrupt 1.6.226 load? Would the Nano know this, and give an error message?
I will be done with the flight by Friday morning, and if nothing is discovered, I certainly can try 1.6.226 again and report back my resluts.

Clarke

[Adam Stanislav]

Originally Posted by Andy Mangrum

Inverted Colors may Occur on all Code version, with an HDMI Input

Interesting. Would that be caused by a bad HDMI cable?