Record trigger not responding w MPG

[Dan Keaton]

Dear Barry,

You will not be stuck with 1.1.154.

We are addressing the SlotDpc:0003 error.

Our next release will have special improvements in our firmware to eliminate this problem.

We have been trying to track down a reason why this was occuring with some cards and some nanoFlashes.

Our breakthrough occurred on Wednesday where we were able to duplicate this in our lab. We were able to pointpoint the problem.

We have added code to our next Public Beta firmware to resolve this issue.

We are delaying the release of the second Public Beta a few days to thoroughly test this change and a few other related changes in the way that we handle CompactFlash cards.


So, some, but not all of the SlotDPC:0003 errors can be corrected by this firmware update.

Other problems, such as a card that is unable to communicate with anything, such as the nanoFlash, a PC or a Mac, will not be helped by our new code.


Also, if there is a hardware problem, such as a broken solder joint in one of the CompactFlash card slots, then the firmware update will not help. In this case, a card may work in Slot 2, but not Slot 1.

[Barry J. Weckesser]

Dan

Thanks for the response.

Does the "SlotDpc:0003 error" also involve the 1-4 second delay when pressing the camera record button before the Nanoflash starts to record and also the failure to record the next clip at all (unless rebooted) after the "record review" feature is activated on the camera?

Have these problems been able to be reporoduced in the lab for the new beta?

[Dan Keaton]

Dear Barry,

I do not know if the SlotDpc:0003 error has anything to do with the 1 to 4 second delay.
I am sorry, but I am not up-to-date on that condition.

But, please remember that we do not start recording, if you are using the timecode trigger, until the timecode advances.

If you are using the Public Beta 1.5.31 and triggering on Incrementing Timecode, if we receive a high timecode value, then recieve a lower timecode value, we will not record until the timecode is a higher value, or the nanoFlash is power cycled.

In the next release, this will be a menu option, with the default being the way we did it originally, "If the timecode moves, we start recording." (if you have the Tigger set to Timecode.

The menu option will be for those that want to review in camera and not have the nanoFlash start recording.

[Barry J. Weckesser]

Dan - I have watched the timecode values displayed on the Nanoflash - with the 1.1.154 firmware there is absolutely no delay when the camera record button is pushed (triggering on embedded timecode). With the beta firmware, I did take note of the timecode value at the end of recording a shot and the timecode advanced to a higher level when the camera started to record but the Nano took 1-4 seconds before it "kicked in" and started recording.

Same way with the record review (with the beta) - once I had reviewed the last shot (I have the camera set for reviewing the entire clip and not just a few seconds) - the same timecode would be on the Nano as prior to reviewing the clip (it did not change since it did not record the clip over again). Then, when I started the camera recording again, the Nano did not record at all - just sat there with the timecode advancing in the window but no recording.

[Tom Roper]

Originally Posted by Barry J. Weckesser

I was shooting MXF@ 100mbps 1080 30p and the NF was set to record on embedded timecode. I was also using the latest firmware (V. 1.20) for the EX1. I also had the NF set with buffer "on". The NF has the new Beta firmware.

Why don't you retry after turning off the prebuffer and choosing 1080/59.97i as a test.

When I do this, it starts recording after a clip review, and does not take several seconds to begin either.

I have my PMW350K timecode set to "preset" and "R-Run." I believe the EX1 has same or similar nomenclature.

For the test, I would also suggest you uncheck the box for "drop frame."

The above is just to see if you can get it working again with the beta firmware, then one by one add back in the features until you can identify what's causing the hangup.

[Barry J. Weckesser]

Tom- Thanks for the input - I did try it with prebuffer off for both the record review and just regular camera recording and the delays were still there. My camera is already set for "preset" and "record run". I also fiddled around with DF and NDF settings which made no difference (I assume they refer to Dropped Frame and Non-Dropped Frame). I did try a couple of other settings which included 1080i and it made no difference.

[Tom Roper]

I wish I had the explanation then, because on the surface, this is illogical. If we're using the same firmware and settings with a different result, the explanation would seem to point to a hardware difference, perhaps board revision, cabling, difference in the flash memory, or camera. The common thread is we both have the beta software. Sorry I can't be any more help except to share findings.

Have a different BNC cable to try?

[Barry J. Weckesser]

Again - I appreciate your input but am leaving for a cruise next Saturday and don't want to take a chance on any beta software "gotchas" while I am shooting video - even if the revised beta comes out there may be some new problems (like audio sync) that won't be recognized until people have thoroughly tested it out. When I get back, I plan on putting any new Beta on the Nano because I do like the feature of not recording on "record review". With the present firmware it is only a minor annoyance and easily corrected by deleting the clips after they are transfered to hard drive backup.

Actually, I have 3 BNC cables of varying lengths but didn't try all of them - when I went from the beta back to the 1.1.154 version I did not physically touch the camera (only removed and inserted CF cards in the Nano which is mounted very firmly on one of Olof Ekbergh's brackets) and when the old firmware was reinstalled the Nano worked perfectly. While tracking down the problem I did try undoing and retightening the BNC cable ends (I have a special screwdriver-like tightener for the part that goes into the camera) but it did not make any difference.

[Tom Roper]

Understood. Good luck on the cruise. Remember to put the cam inside a large plastic bag, and warm it up on the balcony before shooting with it outside. If it goes straight from your air conditioned cabin to the high humidity outside (in warm climate), that condensate will fog inside the lens, everywhere...takes a while to dry out.

[Barry J. Weckesser]

Balcony? Ha, ha! Try inside cabin - I count myself lucky to be going on a cruise at all - Obamacare hit those of us in Cardiology Jan 1 with Draconian cuts to reimbursement amounting to 40-50 % reduction in income (has nothing to do with pending "Health Reform"). Anyway to get back on topic - I will probably leave the camera in it's Think Tank bag and bring that with me on deck for awhile before exposing it to the heat and humidity of the Carribbean.

[Dan Keaton]

Dear Barry,

I will be discussing this with our engineers.

Any problems that might be caused by the Public Beta check the timecode for a higher value, if this is actually the cause, will be corrected by the next firmware.

We intended to put out the new firmware this past week.

However, we were seriously investigating the report SlotDpc:0003 errors that some were reporting.

We were able to duplicate the problem on Thursday, then fix it on Friday, and will be incorported into the next Public Beta this weekend. As soon as the new release passes our tests, we will be releasing it.

[Dan Keaton]

Dear Barry,

May I suggest that you use our QT or MXF mode instead of MPG mode?

MPG mode is really designed for minimal editing and does not have the quality options of QT or MXF modes.

If one is just recording an business presentation (or other events), where one has to create a simple DVD or Blu-ray with a minimal amount of work.

Please feel free to call or email me personally.

[Tom Roper]

Cue Play does not seem to be working for me. With the Nanoflash connected via HDMI to an HDTV monitor, I had about 13 clips. It played through them all fine. Then I entered a value into cue play, and I think it did start there and play the first time (maybe), but thereafter if I entered a timecode for cue play somewhere into the 4th clip, it just always went back and started at the beginning of the first clip.

I also noticed something odd, if I scrolled through the playlist of clips, when I got to clip number 5 and number 6, it showed no value for the timecode, 00:00:00:00 for both clips. Most or all of the other clips had the correct timecode shown for them. As soon as I pressed PLAY, it did play properly and it did show the correct timecode, but not when just viewing the clip title by scrolling through the playlist.

Maybe I'm doing something wrong. It sure works great in all the important respects for me.

(This is with the public beta)

[Dan Keaton]

Dear Tom,

May I assume that you were using Internal Timecode?
(HDMI does not support timecode, it is not in the HDMI spec.)

We will look into this.

[Tom Roper]

Dan,
I use the internal embedded timecode that increments when the camera record button is pressed, recorded to the Nanoflash over the SDI.

Yes, playback was over HDMI to the monitor. Is this what you mean?

In other words, not recorded with HDMI, just played back over HDMI.