Dear Friends,

Our engineers have been working very hard to prepare our Second Public Beta.

For the nanoFlash, the firmware number of the Second Public Beta is expected to be 1.5.126.

We are finishing the documentation so we can post this firmware today.

When it is posted, we will also post information on what has been improved.

We have attempted to address all reported issues with the First Public Beta (1.5.31).

Firmware for both the nanoFlash and Flash XDR should be posted today, so stay tuned.
The Flash XDR firmware numbers will be different due to the way that we number our firmware builds.

This firmware has been undergoing substantial testing in our labs. We now feel that it is time to post it so our friends can test it with their cameras and their workflow.

Please note that we have made major improvements with this release, especially in the way that we work with the CompactFlash cards and audio support.

More information will be posted as soon as possible.

Please post all comments, concerns, and any problems with this Second Public Beta in this thread.

Hi Dan:
OK. I will test as thoroughly as possible and post all XDR 2nd Public Beta results in this thread :-) Thank you and the folks at CD for all of their hard work to bring us this update beta firmware. Dan, if this beta is favourable, will CD then post an *Official-Non_Beta release following ?

Dear Dan,
Is there any reasons why the new firmware is a lower number then the old one? Is it a typo or that is the real number? Thank you
Luben

Dear Luben,

The First Public Beta was 1.5.31, or build number 31 of our firmware version 1.5.

The Second Public Beta is 1.5.126, or build number 126 of our firmware version 1.5.

Dear Dan,
Thank you for the explanation! I guess this is a just a numbering issue than anything else. I apologize for the input here, but, isn't instead 1.5.31 to be read/numbered 1.5.031?
The way I learn math and numbering 1.5.126 is a smaller number than 1.5.31 and could be confusing down the road if someone wanna roll back to that firmware. I know it's a beta version, but, could happened to the official version too.
Cheers
Luben

Dear Luben,

Think of it like the Dewey Decimal System.

Dear Luben,

Think of it like the Dewey Decimal System.
Thank you Dear Dan,
Is not a big think at all. Last post on that from me. Just wanna say that Dewey Decimal System uses .0xx to clarify the number under 100. Anyway, glad that I'll be testing the new firmware tomorrow. Thank you
Luben

Dear Dan,
Thank you for the explanation! I guess this is a just a numbering issue than anything else. I apologize for the input here, but, isn't instead 1.5.31 to be read/numbered 1.5.031?
The way I learn math and numbering 1.5.126 is a smaller number than 1.5.31 and could be confusing down the road if someone wanna roll back to that firmware. I know it's a beta version, but, could happened to the official version too.
Cheers
Luben

Luben, the way you learned math probably didn't have multiple decimal points in the numbers also. This should be a clue that the entire number is not to be treated as an integer.

Nearly ALL software revision systems that I've seen, number releases this way. At least least those that are run by experienced developers. I've run a few dev shops in my day and maintained my own code too. The numbering scheme typically goes something like:

[major version] . [ minor version ] . [ build ]

each time you increment the major version, the number in position 1 would be incremented. like from 1 to 2.

each time you increment the number in the middle position, that increments the minor revision. yes, a minor revision of 152 is indeed greater than minor revision 2,.. by 150 revisions!

when the build is incremented, the third number is incremented. again, a build number of 75 is much greater than a build number of 9.

zero filling any of these numbers would be senseless. you'd be supposing that there are a maximum number of digits for each field (which there shouldn't ever be), and adding extra digits to the version number for no good reason.

Nothing gets by this crowd!

Ok - first test (going on a cruise tomorrow morning) so thought I would do a brief trial - this new beta exhibits some of the same behavior as I have reported with the previous beta: http://www.dvinfo.net/forum/convergent-design-nanoflash/474667-record-trigger-not-responding-w-mpg.html#post1498952 - there are some differences - there is still the 1-4 second delay from pressing record to the Nanoflash actually starting to record. When I press clip review button on the camera (have it set for entire clip) - the Nano doesn't record right away but for the last 2-3 seconds (of a 10 second clip) it will record. This time however, when I go to record again it will start recording - either right away or with a couple of seconds delay.

Looks like you guys are close but not quite there yet!

Have you tested the firmware on an EX1 with the new v. 1.20 firmware installed?

Before you ask: - The camera is set to record 1080 30p and Mode: Preset & Run: Rec-Run

The Nano is set to record MXF 1080 30p @ 100mbps, Trigger>TC>Last TC; prebuffer is on, psf on, timecode: embedded. Using Photofast 64 GB card and also Sankisk Extreme iii - 32 GB

Going back to 1.1.154 for my trip.

Audio sync in SD SDI recordings seems spot on... more testing in the AM. EX-3 with SD downconversion via SDI. MOV recorded GOP.

Dear Barry,

Have a great trip.

We will be attempting to test everything you mentioned in our lab.

We have an EX3 in our lab, but not an EX1 or EX1R.

Dear George,

Thank your for testing and your report.

Dear Barry,

Have a great trip.

We will be attempting to test everything you mentioned in our lab.

We have an EX3 in our lab, but not an EX1 or EX1R.

Thanks Dan - I'll bet this is something unique to either the EX1 or the new EX1 firmware and it's interaction with the Nano firmwrare - as soon as I reverted back to 1.1.154 everything works perfectly. Hope that some other EX1 owners with the new firmware (EX1 firmware- v. 1.20) also test this out.

Barry, I have an EX3 and have updated the Sony firmware to 1.10 (which activates the full overcrank on the SDHC cards)

Just loaded up the new beta firmware and will put it through it's paces. Pretty sure the EX1 and 3 are fundamentally the same camera as far as the electronics go.

Like you, I am very interested in the SD functionality of the nanoFlash. I will make a point of shooting some SD footage over the coming days to see if I can replicate what you did and see if the issues are the same on my end.

Barry, I have an EX3 and have updated the Sony firmware to 1.20

Just loaded up the new beta firmware and will put it through it's paces. Pretty sure the EX1 and 3 are fundamentally the same camera as far as the electronics go.

Like you, I am very interested in the SD functionality of the nanoFlash. I will make a point of shooting some SD footage over the coming days to see if I can replicate what you did and see if the issues are the same on my end.

Thought the EX3 firmware was 1.10?

You're correct Dean. I assumed the version number 1.20

I've corrected the offending post.

Andrew - perhaps you misunderstood - I only shoot in HD 1080 30p - don't use SD at all.

Dear Dan,

I'm happy to report that my newest Beta testing so far goes OK. Specifically, the crank function works as supposed to.

In Vegas 9.0c, there are still green frames in MXF clips, and random single frames missing (black) in I-frame only.

As to my problems with the PhotoFast cards, after the initial freezing incident, they seem to work OK so far, too. I'm however afraid that since they're not qualified any more, some minor change in one of the future firmware versions may render them unusable again. Therefore, please conclude our e-mail thread on the subject somehow, so that I can count 100% on my nanoFlash and cards reliability.

Dear Piotr,

I can assure you that we will not withdraw support for the PhotoFast cards.

The Second Public Beta has many improvements in how we work with CompactFlash cards.

Previously, we saw SlotDpc:0003 errors and some DMA errors.

One of the reasons that it took us so long between our First Public Beta and our Second Public Beta was to investigate these errors, determine the cause, fix the problem, then test the solution. We were able to duplicate the SlotDpc:0003 errors in our lab. Then, after we found and fixed the problem, we thoroughly tested the solution and we never saw the error again.

In other words, we have confidence in our solution to the problem.

We determined that some of these problems occured when coming out of Power Save mode.

Both the SlotDpc:0003 and DMA errors have been fixed.


If your two PhotoFast CompactFlassh cards are working with the Second Public Beta, then you are good.

The PhotoFast cards were removed for our list of qualified cards, temporarily, since there were a bad batch of cards. These were DOA cards.

As you may imagine, it reflects poorly on us if we recommend a card, then a customer gets cards just in time for his shoot, and they turn out to be DOA.

When I press clip review button on the camera (have it set for entire clip) - the Nano doesn't record right away but for the last 2-3 seconds (of a 10 second clip) it will record. This time however, when I go to record again it will start recording - either right away or with a couple of seconds delay.



Barry,

I wonder whether your setting of "last clip review" to entire clip rather than the last couple of seconds is the culprit for the delay. When reviewing a long clip, the nanoFlash may enter the low-power mode - and this may be the reason it takes some time to start recording again.

I have tested the TC>Last TC triggering option thoroughly with my EX1, and it works flawlessly - the nanoFlash resuming recording the moment I press my EX1's Record button, without any lag. BUT, I'm only previewing the last couple of seconds...

Andrew - perhaps you misunderstood - I only shoot in HD 1080 30p - don't use SD at all.

I shouldn't post when I am tired. I scanned your post, saw the MPG reference and assumed it was related to the bugs related to shooting in SD that were noted a week or so ago. Sorry for the confusion.

Both the SlotDpc:0003 and DMA errors have been fixed.

If your two PhotoFast CompactFlassh cards are working with the Second Public Beta, then you are good.

Dear Dan,

Thanks for confirming support for my cards.

It should be stressed however that my severe problems with PhotoFast cards started after I first installed the first Public Beta, and persisted even though I quickly reverted to the official 1.1.154 firmware.

As suddenly as they surfaced, all problems have vanished now (at least it seems so, after 2 days of testing) - also after firmware change (this time, to the second Public Beta).

Since other CF cards' users didn't report similar problems, it's safe to say that PhotoFast cards are particularly prone to the way communication between the nanoFlash and its card slots is carried out. Luckily, the changes to this communication process that the new Public Beta introduced have cured the problem with my particular card units.

It'd be interesting to know whether the batch of DOA cards that made you withdraw PhotoFast from the list of qualified cards could also be "cured" with the new firmware.

I know the above hypothesis might sound unlikely, but it was yourself who stated in another thread that the PhotoFast "were losing their chip code internally" (or something to that effect). Also, they way my own cards behaved might indicate just that.

When I first upgraded my nanoFlash to the newest firmware lately, the first result was scary - my nanoFlash wouldn't see those cards at all; it couldn't even format them and, when one was present in the slot, even the nanoFlash menu buttons were dead. Only after formatting the cards on my PC did they start to function again... All this shows something went deeply wrong in my PhotoFast cards' internal chip code, and this was done by the nanoFlash Public Beta 1.5.31

Dear Piotr,

The DOA cards would not work in a PC, a Mac or a nanoFlash.

Yes, we have heard of the PhotoFast cards losing the "code" or internal firmware for their on-card controller chip.

We understand that PhotoFast has a program to that corrects this problem. But this is hearsay as we have not heard this directly from PhotoFast.

Barry,

I wonder whether your setting of "last clip review" to entire clip rather than the last couple of seconds is the culprit for the delay. When reviewing a long clip, the nanoFlash may enter the low-power mode - and this may be the reason it takes some time to start recording again.

I have tested the TC>Last TC triggering option thoroughly with my EX1, and it works flawlessly - the nanoFlash resuming recording the moment I press my EX1's Record button, without any lag. BUT, I'm only previewing the last couple of seconds...

Piotr - haven't tried that setting yet but what concerns me is the 1-4 second delay when I have not used the clip review function - this is exactly how the previous beta worked - are you using v. 1.20 (new Sony EX1 firmware)?

No Barry - I'm still on the 1.11.

And frankly - at least with my current settings - I don't see any delay of the nano entering record mode. Did you say you have the record buffer on (cache recording)?

I have tried it with buffer on or off - same result (delay)

Dear Barry,

Could you, for a test, turn off the Trigger on Incrementing Timecode?

Then, watching the timecode display on the nanoFlash, press the Record Button on your camera. As the camera starts rolling, check to see if the nanoFlash's timecode display starts rolling at the same time.

If there is a delay in the timecode starting to roll, then this will explain why we do not start to record immediately.

Another Idea:

How are you determining when the nanoFlash starts to record?

Are you waiting for the "Recording" to display on the LCD? If so, this may be after the nanoFlash has actually started to record. Our messages are usually delayed.

Or are you watching one of the Status LED's on the sides of the unit?

For a more definitive test, one can focus on a clock with a second hand then start recording, noticing the position of the second hand.

Dear Friends,

I thought it might be helpful if I post the release notes for the Second Public Beta here.

(Note: Some of these changes were implemented in our First Public Beta, but they are included here for your convenience.)

Our goal was to post the Flash XDR firmware version the same day; we will post it as soon as possible.

Second Public Beta Version nanoFlash 1.5.126 ( 26–Mar-09 )

o Added menu option Video->720p60 to 30, 720p50 to 25.
Cuts the frame rate in half for incoming 720p60 or 720p50 signals.

Useful, for example, with cameras with a 720p30 or 720p25 mode, which then double
the frame rate of the camera's internal recording mode to create the HD-SDI output.

The nanoFlash bit rate in this mode is applied to the reduced frame rate.

For example, @ 280 Mbit from a 720p50 source reduced to 720p25, the 280 Mbit applies
across 25 frames. This increases the effective bit rate per frame, thus offering better quality.

o Added menu option System->Trigger->Remote & Record, in which either the Remote Switch or the Record button can be used for triggering record.

o Added separate menu option System->Trigger-> “TC > Last TC” .
In this mode, the nanoFlash will only trigger to record if the incoming timecode is greater than the ending timecode of the last recorded clip.

This helps to minimize unexpected recordings, for example when inserting or removing media in the camera, or playing back video off of the camera's internal media.

Be aware, however, that if the camera's timecode is re-set to a lower value, the nanoFlash may not trigger from the timecode unless the nanoFlash is then turned off and back on.

o The menu option System->Trigger->Timecode can trigger at any time that the timecode is increasing, unlike the above mentioned “TC > Last TC” . This may create unexpected short recordings due to camera timecode behavior.

This is the default mode, as this is actually safer than Trigger-> “TC > Last TC”, since if the timecode is reset to a lower value, then recording will not resume until a higher timecode value is seen by the nanoFlash.

o Added menu option Audio->Audio Channels Monitoring, for monitoring specific channels on the headphones output.

Choose between channels 1 and 2, 3 and 4, 5 and 6, or 7 and 8.

o Added clip skipping during playback, press up arrow during playback to move to next clip, press down arrow to move to previous clip.

(A clip is a single record session, a clip may be composed of several files for a long record. )

o Fixed bugs in cranking, which extends compatibility of 720p24 / 25 / 30 at 50 Mbit and above to Sony Vegas, Edius, and Adobe Premiere CS3 / 4 (with Main Concept plug-in) in addition to the already supported Final Cut Pro.

Other PC-based NLE's may additionally support. 720P24/25/30 50 Mbit and above is not supported by Avid, however, at this time.

o Fixed slight pixelation in playback of Quicktime files from nanoFlash, a problem introduced in version 1.5.31.

o Fixed static on audio channel 1 in standard def MXF recordings, a problem introduced in version 1.5.31.

o Fixed MPG reversed audio channels.

o Repaired 720p pulldown removal embedded timecode.

o Added support for true 30, 60 video formats in Quicktime
(true 24 was already supported).

o MPG playback: pause is disabled, not supported by codec in MPG mode.

Known issues (1.5.126):

o 720P24 / 25 / 30 playback from the nanoFlash is not supported at this time.

o Pulldown removal from JVC 700 requires turning the nanoFlash on first, then the camera, to work properly.

o Playback from nanoFlash (all MXF, QT files): 2 frames out of sync.
Files are in sync when played on a computer.

o HDMI in / out: 2 channel audio support only.
HD/SD-SDI in / out supports 0, 2, 4, or 8 channel audio.

o HDMI Loop Through: Audio missing
When looping from HDMI-In to HDMI-Out, any audio present on the HDMI-In will be missing on the HDMI-Out
(This will be corrected as soon as possible)

Dear Dan,
I just turn on the NF and noticed that it takes a long time for the NF to boot. Also, a message appears on screen and if you do not press the OK button the NF it seems that is not ready to shoot, simply because, after the OK button gets pushed the NF continues to boot for a few more second. Is there any possible way that Mgs. to bypassed by me or by you (I am guessing is in the firmware)? Is there any need of that Msg? Thank you Dan
Luben

Dear Luben,

Are you using the Second Public Beta, 1.5.126?

I am not getting that message where one has to press OK when I am working with 1.5.126.

We do provide more information than before.

In our First Public Beta, we put out a lot of new information.

But, before we put out the Second Public Beta we cut this information down, as well the time to boot the nanoFlash.

What does the message say?

Dear Luben,

Are you referring to the two messages that we display showing the Volume names of the CompactFlash cards in the nanoFlash?

One is on the right side of the screen, one is on the left side.

If so, you do not have to press ok to get these off the screen.

We will be improving this so that at startup we do not show these messages.

Dear Dan,
Yes, I am using Second Public Beta 1.5.126 Tommy sent me the link for the download. It's still available according to the link from my email box. I just try it, but not sure if it's the same file that I downloaded a few day ago. What I am going to do is to upload the file I have on my NF on my wife website for you to download. Please do so, try it and let me know what I need to do to get the Msg. of the screen if possible. I don't think I am using a different Firmware because it says under ABOUT that it is 1.5.126.
Here is the link http://www.annewheeler.com/nanoFlash_1.5.126.zip
Cheers

Luben,

I'm sure you're not doing a simple mistake like this, but I'll ask:

Are you sure you have deleted the }UPD{ folder from your card? When present, the nanoFlash will ask whether to update the firmware - and this, along with formatting cards, are the only circumstances I have ever seen the OK prompt displayed on the nanoFlash display...

Other than that - yes, the boot time seems now very long with all the storage diagnostics being displayed, but you don't need to wait for them to complete before starting recording (not to mention push the OK button).

Dear Piotr,
Thank you for the question, but, no. I have done all by the book. After deleting the }UDP{ folder from the CF card, I formated the card in NF that of course had the new updated firmware.
Please download the file I post and try it. Please tell me if you experience the same as I do. If you do not, than... "Huston!, we have a problem....." ;)
Cheers

BTW, it is a greeting Msg. and reminds you to check with CD for a new firmware updates or something like that...
I can't confirm right now exsactly. The NF is out for a shoot with my wife.

Ach, OK. I was sure you couldn't be doing such a trivial mistake:)

If you're seeing some welcoming message, it sounds like Tommy has linked you to some intermediate build (before the 1.5.126 became Public, I also got an earlier version from Tommy).

I think you just should download the 1.5.126 from the CD webpage, and you'll be good.

Dear Luben,

Thanks, I just needed to know which message.

Yes, we put out a "Greeting Message", asking the user to register their nanoFlash.

We want everyone to register their nanoFlash so we can keep them informed of firmware updates.

This message will go away. I do not know the exact circumstances.

If you restart your nanoFlash now, after Ok'ing the message at least once, does the "Greeting" message still come up at startup?

Dear Luben,

Yes, if you are using 1.5.126, you have the latest release, our Second Public Beta.

Dear Luben,

....

This message will go away. I do not know the exact circumstances.

If you restart your nanoFlash now, after Ok'ing the message at least once, does the "Greeting" message still come up at startup?

Dear Dan,
Thank you for the reply. Yes, the Msg. comes every time I restart the NF. Takes a long time and if I do not push the OK button, NF is not fully booted up.
Luben

Dear Luben,

Please check your Date and Time in the System menu.

It may be incorrect.

If so, then we may think that this firmware release is over three months out of date.

If so, then we will put out a message to check our website for firmware updates.

Dear Friends,

Our Quality Control tester, in our lab, has determined that 1.5.126 does not pass audio when using the HDMI-In and looping it through to the HDMI-Out.

We will correct this as soon as possible.

Dear Dan,
Did you see the post I made on first Public Beta 1.5.31?
Also, Anne just got home and the time, date, year was all correct on NF. I did turn on and off more then 10 times to see if that Msg. would go away and it did. It does not appear any more but it did take a lot of on/off's.... I'll keep you posted if I have this Msg. appear again.
Thank you
Luben

Dan,
I exclusively use the mpg format. Are you saying that the audio is still not recording correctly with this second beta? I don't use the hdmi in, or out for audio, strictly the analog. Can I expect this ver to be fixed from the reversed audio?

Hi Dan:
Can you give an ETA on when the XDR 2nd public beta will be released ?

Dear Clarke,

As far as I know, based on our internal testing, MPG works fine with this Second Public Beta.

Yes, you can expect the reversed audio, that was present in our First Public Beta, to be fixed in this version.

Please feel free to test it.

Please note that I said:

o HDMI Loop Through: Audio missing
When looping from HDMI-In to HDMI-Out, any audio present on the HDMI-In will be missing on the HDMI-Out
(This will be corrected as soon as possible)

I learned yesterday that this was not true. During our testing, we thought this was not working. Our engineers retested it and found that it was working afterall.

I have done a short test, and all looks good with the .mpg system. Going on a flight now to do an extended test. Thank you,
Clarke Thomas

Just completed a flight on some electric line ROW with the Beta 1.5.126. The video looks very clean, and both audio tracks are also clean and clear. Recording using Sony HD camera and .mpg format at 35 mbs over HDMI, with analog audio input. All Thumbs UP from me! Thanks for the fixes to the CD team.

Hi Dan:
Can you give an ETA on when the XDR 2nd public beta will be released ?

Dear Mark,

Our testing team found a problem with the Flash XDR code in the Second Public Beta, thus we withheld posting it until the issue was resolved.

This does not affect the nanoFlash Second Public Beta in any way.

I do not have an ETA when the Flash XDR code will be ready, sorry.

Dear Mark,

Our testing team found a problem with the Flash XDR code in the Second Public Beta, thus we withheld posting it until the issue was resolved.

This does not affect the nanoFlash Second Public Beta in any way.

I do not have an ETA when the Flash XDR code will be ready, sorry.OK Dan. Thanks for the update :-)

I was wondering if anyone had tried out the new Nano beta with an EX1 with the new v. 1.20 firmware installed. I experience a 1-4 second delay in the Nano started to record once I press the camera record button. I have the Nano set to the new TC trigger setting. I also have prebuffer on (works the same without prebuffer) and am shooting at 1080 30P MXF at 100mbps.