Uh-oh: Serious problem with NX5U re-occurs with replacement unit

[Adam Welz]

Hi All

Bad news. The buffer-overflow-and-irrecoverable-crash problem I reported with my NX5U has re-occurred with the replacement body that Sony supplied to me on Monday, on my first day of serious shooting with it and less than a minute into a slow-moving shot of a static object, i.e. not very challenging to the codec. (Sony replaced my first body serial #110136 with #110060.)

My original description of the problem is here:

http://www.dvinfo.net/forum/sony-nxc...-hxr-nx5u.html

The only difference is that I was using the cam in 1080/25p mode (it's been WorldCam upgraded, so it shoots 25p) with Kingston 32GB class 4 SDHC cards -- the problem previously occurred while shooting 1080/30p with SanDisk Extreme 16GB class 10 SDHC cards. The cards were formatted in-camera before the shoot.

As before, I was recording simultaneously on to the FMU128 unit (serial 110115). This unit was NOT replaced when the camera was replaced, so it is the same one I was using when the problem first occurred.

The shot that the crash occurred during was pretty steady, of a static subject -- not fast-changing, in other words it should not have been challenging the codec.

In my mind there are a few likely possibilities:

1) A serious hardware/software design error in the NX5.

2) Some widespread incompatibility with the controller chips in SDHC cards.

3) A problem with my specific FMU128 unit, #110115.

I have emailed Sony about the issue, and I'll report their response here. They were pretty good at dealing with the issue the first time, providing me with a replacement camera and a free WorldCam upgrade and 16GB MemoryStick PRO-HG Duo card.

I hope they fix this fast, because there really is a lot to like about this camera and I'd hate to have to stop using it because it was unreliable! Unfortunately I'm now in Africa so dropping in on the Sony Pro Service people in New Jersey isn't so easy ;)

As before, I'd appreciate any comments or suggestions y'all might have. And if any of you have NX5's and have had similar issues, please post about them.

Cheers

Adam

[Benny Ek]

My First Thought has to be that it is a problem with your FM128 Unit or your sdhc card.
To have the same person with 2 cameras with the same problem is really odd. Especially since I haven't heard of anyone else having a similar problem. I certainly haven't with my NXCAM.
Not out of the question that its the cam, but highly unlikely at this point.

[Adam Welz]

Hi Benny

have you been shooting hi-res progressive modes and recording simultaneously on to the FMU128 and SD cards?

Cheers

Adam

[Benny Ek]

The one difference is that I have not been shooting on the FM128 Unit. I am using strictly SHDC Cards. Hi-Res Progressive Modes, Yes.

That's why I have a feeling it has something to do with the Flash Unit. Just my thoughts.

[Adam Welz]

...or something to do with the cam not really being able to record to both the FMU128 and an SD card simultaneously.

Which brand/type/class of SD cards are you using, Benny?

Cheers

Adam

[Benny Ek]

I am using Patriot class 10 32gb cards.
I have shot about 8 total hours of footage within 10 different sessions.
Only hiccup was a final cut pro issue not reading my card due to a formatting problem. Solved that and now running smooth. Overcranking, hi res progressive, all of it.

[Ron Evans]

Adam, I have only just got my NX5U and as such I have only shot a few tests at home. However I have had no problems so far recording to the FMU128 and either a memory Stick Pro Duo or an 8G SDHC micro Class 4 in an SD adapter (use the micro in my headcam ) in all the combination's. Formatted both the FMU128 , the MemoryStick and the SDHC micro in the camera.
In your case the common factor is the FMU128 and should be the one to look at. You may want to try letting the camera do a complete CLEAN cycle ( instructions in the manual) and then a reformat. I would certainly suspect the FMU128 at this point as having write issues. What batteries are you using? Did this occur while you were using the same battery?

Ron Evans

[Adam Welz]

Hi Ron

thanks for your input. I'll do a full CLEAN cycle with it tomorrow.

I usually use NP-F970 batts (I bought two when I bought the cam, which I alternate) and it is with those batts that the original buffer overflow and crash happened. However, today's crash happened while I was using the NP-F770 that came with the cam. So it's happened with more than one batt -- at least two, maybe three different batts.

I never thought the battery could be the issue here, so I have not been paying any attention to it. What particular battery problem could cause a buffer overflow and crash?

This thing gets curiouser and curiouser, as they say in the classics. At least I'm learning something!

Cheers

Adam

[Ron Evans]

Memory is sensitive to voltage levels so if a battery is not providing the required voltage and current it could lead to issues. But since you have used three batteries I don't think that is the case. Also the camera should have reported a low battery too if there was a problem. It was just a thought. Looking more like the FMU128 is the source though. You might try a data base repair also. Does the FMU128 work OK by itself? Does the activity light stay on longer than the SD light when recording separately. My FMU light goes off almost instantly while the SD red light takes about 1 or 2 sec.

Ron Evans

[Ned Soltz]

HI, Adam

The more I think about this, the more I feel the problem is your FMU128.

[Dave Blackhurst]

I'd concurr, you've replaced the camera, changed media (that 16G HG Duo), the likely culprit is the flash drive... good troubleshooting so far, you'll nail the bug yet!

[Adam Welz]

Hi All

thanks for input. Sony also thinks it's the FMU128. They have offered to replace it, which is nice. I'm going to do the CLEAN anyway, but I'll see if that changes things. Will be at least a few days until a new FMU gets here.

Juan Martinez of Sony says that they have had no reports of buffer overflows from anywhere else in the world. Seems like I'm the only one... I like being a pioneer, but I'm not so sure I wanted to walk this lonely trail!

Adam

[Bob Hart]

You have to feel some sympathy for the little guys in the R&D departments.



They take the machine-child they have enthusiastically created and talked about at home with their wife and kids, smite it, cook it, abuse it, nurse it through its beta adolescence, love it to death in the environmental tests and it comes up kicking and smiling.

Then it goes out into the world and falters in its adult relationships.

Then the R&D guys have to drop their current project, regain recency in the troubled product and troubleshoot, or the task is given to a new team who have the double-trouble of not having designed the thing and having to learn the thing from scratch and rely on technical notes.


An interesting test for you to try would be to shoot a highly detailed and complex shot, wide-angle, lots of leaves and clutter as fine detail :-


1. Handheld and steady but with the normal weave of handheld trying to be locked off, enough movement to change the image frame-to-frame but not enough to introduce motion blur.

2. Same shot, locked off on tripod.

3. Telephoto shot with background detail blurred out handheld as above.

4. Telephoto shot with background detail blurred out locked off on tripod.

5. Handheld telephoto shot down a very busy multilane freeway with lots of fine movement going on.

6. Telephoto shot down same freeway locked off on tripod.



My wild theory is that under a codec workload of heavy detail, plus having to manage battery power and manage and feed data to the added recorder, there might be a sort of buffer over-run or processor overload sort of thing going on.

It might occur in shot 1, maybe lesser risk in shot 2 unless leaves are trembling in light breeze and 6, where motion blur will not be masking the fine detail changes in the image.


Also try using the slowest shutter speed you can or "shutter off" if this EX1 option is in your camera and see if that makes the problem go away by increasing motion blur.


Try any diffusion filter like a promist and see if that makes a difference on a known shot which provokes the problem.


I theorise on this through observing the ram buffer bar display on the SI2K camera screen.

It ramps up higher on fine details of a wide shot versus the less complex tight shot zoomed in during a live performance. The SI2K can alter its workload and keep going when its "adaptive" mode is selected on.

The Sony may be limited by its processing power when too much tasking is given to it, or it may be adjusted a little too close to the margins for comfort in the quest for best image.


Then again, I am also casting some baseless theory around.

[Ron Evans]

Just as in a PC there are, I am sure, lots of RAM buffers in a camera. Most of the encoding will be done in a custom circuit, the Bionz chip which will have ample processing power for the camera spec ( likely a lot more that isn't turned on !!!). So I don't think this has anything to do with what the camera is shooting or the encoding set up of interlace or progressive since I think the core processing is at 1080 60 p off the sensors and is then reformatted based on selected output. Buffers will be used to write to recording media. Again if the memory unit is within spec there should be no problem. IF however the flash memory cannot write as fast as the data is being delivered then the buffer will fill and eventually overflow. IF , in the NX5U this is a shared buffer then both FMU and card will fail. This is why I asked the question of activity lights since mine certainly complete the write operation at a different time. The FMU being faster than the card to finish ( RED activity light goes off after stop is pressed). Although my SDHC card is only class4.

For Adam I got mixed up with some other equipment and CLEAN should be MEDIA EMPTY. its on page 65/66 in manual.
Ron Evans

[Adam Welz]

Hi All

Sony's Juan Martinez has emailed me, saying that he now suspects a dud FMU128 unit, and is offering to replace it.

I shot with the cam for several hours today on to SD cards (with no FMU128 attached) and it worked great -- no crashes.

Cheers

Adam