Originally Posted by Tom Frank

If your measurements and trig calcs are accurate, your angles are accurate. I did similar photo/calces for the #11 camera and it was 58.2 deg.

But a couple things to clarify... The AOV of the lens is usually larger than FOV of the captured image, simply because the CMOS design doesn't use the full lens AOV to crop off some of the vignetting and focus/color degradation that naturally occurs at the extremes of the AOV. The manufacturer's specs for lens AOV was quoted to me as 70 deg., and that's how it's being referred to. So that alone can account for most of the difference in the angles mentioned.

To further complicate it, the #16 firmware prior to the latest v0.18 had further cropped the camera's captured image before encoding and saving it, presumably to eliminate more vignetting, and then the image was digital zoomed about 15-20% to restore it to full 1280x720 frame size. This was discovered when comparing the webcam video with the normal recorded video. That digital zooming further reduced the FOV, making objects look bigger, as well as blurred the imaged slightly. The v0.18 firmware has restored the full captured image and focus, at the expense of a little more vignetting, which still might be reduced with the CMOS built-in "lens correction" feature So your measurements were hopefully done using the v0.18 firmware in the camera.

I've attached a frame grab from a comparison video I did during testing of the v0.18 firmware with two side-by-side #16 cameras, one with standard lens and one with the 70 deg. lens. The left edge of the two images are very close to having the same image starting point, so the right edge will show most of the wider FOV of the 70 deg. lens. Looking at that, I'd have guessed maybe just 2-3 deg. difference in FOV, but I never bothered to measure it... it's not much. The bigger advantage of the 70 deg. lens is it's better color rendition with the v0.18 firmware. In cetain lighting, the standard lens takes on a pink hue with gray objects in the scene, sometimes more pronoounced than this particular frame shows. And it has slightly better exposure showing more detail in the darker areas of the video. That's why there is a transition underway to the 70 deg. lens as the new standard lens.

Tom, thanks very much for the 'heads up' on those FOV calcs. I'm pretty sure I got the sums about right for the #16 and calculated the FOV for the #11 808 at around 53 deg, so in that respect, not too far off your benchmark - Absolutley agree with your point about the effective reduction of the lens's FOV because of it's position in relation to the CMOS sensor.

Yes, calcs were made using the 0.18 FW, not the digitally zoomed factory release. Like yourself, I have found the new lens enhances, even 'brightens' darker areas of the frame and to some degree improves the crispness of near-field subjects - particularly noticable indoors with subdued lighting conditions. Whether this has anything to do with it's physically larger aperture is debatable, but think it must be a contributing factor. Looking through each lens from the rear, the new lens lets at least twice as much light through to the CMOS array (see photo below).



As to your point about the both lenses / modules needing extra support in the form of self-adhesive foam to position them properly, well, perhaps it's me just been over-critical (and daft) - a sliver of card wedged between the back of the CMOS module and PCB seems to work well.

Thanks for the frame grabs comparing the FOV of the old and new lenses - hopefully, if this darned UK weather improves, I'll be able to take a few snaps tommorrow. Cheers.

Richard

Originally Posted by ds64

As a test, I downgraded the firmware from 0.18 to 0.16, but that doesn't change the behavior. I completely tested the memory card with h2testw (Writing speed: 7.64 MByte/s). I tried the in-camera formatting on both Linux and Windows XP. The camera works fine with a no-name (brand "Traveler") 4GB card.

Since I have an 8GB class 10 Kingston card that has caused issues for some, I ran H2TESTW on it as an experiment. I got the following:

Warning: Only 500 of 7608 MByte tested.
Test finished without errors.
You can now delete the test files *.h2w or verify them again.
Writing speed: 11.6 MByte/s
Reading speed: 14.0 MByte/s
H2testw v1.4

My card seems to be able to write well above the 7MB/S that the camera (I think) needs. It has always recorded perfectly.

Your card looks like it just barely exceeds the stated 7MB/S data rate, which might explain why the recording fails? It would be interesting to run H2TESTW on your "no-name" card.

Paul

Originally Posted by ds64

I bought a new 16 GB class 6 Transcend microSDHC card, but the camera is not working properly with this card. Video recordings stop after about one minute. I have configured the LED to blink during recording, and when the video stops, the LED stays either on or off, depending on the particular moment. The camera does not return to video standby, because when I press the power button, it does not switch to photo mode. Instead the yellow LED starts to blink very fast (~ 3Hz) until I switch off the camera.

Another problem is that the in-camera formatting does not work as described in the manual. In removable disk mode, I press the shutter button, pull the USB cable, and hold the shutter button for more than 10 seconds, but the red LED won't switch off. The format seems to be successful, because the card is empty afterwards.

As a test, I downgraded the firmware from 0.18 to 0.16, but that doesn't change the behavior. I completely tested the memory card with h2testw (Writing speed: 7.64 MByte/s). I tried the in-camera formatting on both Linux and Windows XP. The camera works fine with a no-name (brand "Traveler") 4GB card.

It seems that this camera is rather picky about memory cards. This is now the second card I bought for this camera that has problems. The first one (8 GB class 10 ADATA) wouldn't work as removable disk on Linux. I hope the developer reads this and is able to resolve these problems in a future firmware version.

Interesting since my 8GB Transcend CL6 card works OK, as does my Kingston 16GB CL4 card.

My feeling is the memory card controllers are as much to blame as the camera firmware. The larger capacity cards (same brand and same speed class) seem to get slower as the capacity increases. My transcend 4GB CL6 card is faster (twice as fast in the 512k random write speed test, in fact) than my 8GB card, which is more than twice as fast as your 16GB in sequential write speed. So with this much variation between cards of the same speed class from the same manufacturer, and each manufacturer having their own proprietary card controllers embedded in the cards, with different logic and conformance to somewhat nebulous performance standards, I don't see how the camera firmware can be expected to solve all the different issues, any more than a specific card can adapt to all the specific host devices into which it is placed... just like your CL 10 card not working on with your Linux OS. Is anyone asking for the dozens of Linux "implementations" out there to fix code to work with all the flash cards that are connected? It's a problem we just have to live with for now.

But having said all that, your cameras actions are different from mine in other aspects, like the in-camera formatting LED activity. Your camera might have some other issues... not just the different flash cards.

Originally Posted by ds64

...
It seems that this camera is rather picky about memory cards. This is now the second card I bought for this camera that has problems. The first one (8 GB class 10 ADATA) wouldn't work as removable disk on Linux. I hope the developer reads this and is able to resolve these problems in a future firmware version.

Not sure you can place all of the blame on the camera. Class ratings in and of themselves are useless for determining suitability for video recording at 7-10Mbps.

My class 10, 6 and class 4 cards are similar in performance on random write operations.

What's more interesting is that of the cards I have, regardless of class, the smaller capacity cards have the highest random write speeds.

So my 2GB microSD are fastest, next 4GB, then 8GB.

Originally Posted by pgoelz

Since I have an 8GB class 10 Kingston card that has caused issues for some, I ran H2TESTW on it as an experiment. I got the following:

Warning: Only 500 of 7608 MByte tested.
Test finished without errors.
You can now delete the test files *.h2w or verify them again.
Writing speed: 11.6 MByte/s
Reading speed: 14.0 MByte/s
H2testw v1.4

My card seems to be able to write well above the 7MB/S that the camera (I think) needs. It has always recorded perfectly.

Your card looks like it just barely exceeds the stated 7MB/S data rate, which might explain why the recording fails? It would be interesting to run H2TESTW on your "no-name" card.

Paul

Paul, did you manually terminate your card test? I was curious why only 500 of the 7608 MB were tested on the card? If the whole card is not tested, how do you know there are no problems on the rest of the card?

One clarification on the camera data rates. The camera averages about 7mbps with the lower data rate set. That's megaBITS per sec, not megaBYTES that the card speed tests show. So 7Mbps is only about .875MBps.... normally below most Class 4 random write speeds. But that's average speed. I've had max. instantaneous data rates go over 20mbps (2.5MBps) in some high detailed high motion video clips. So the sequential write speeds are never an issue with the camera, but the random write speeds definitely can be as the cards start to get fragmented. But fragmentation should not be an issue, it seems, if the cards have files removed and are clean before starting new recordings. But I guess that depends on how the card controller start a new write sequence. Do they always start writing from a dedicated file block and proceed down a defined path in sequnetial block, keeping a pointer to where the last file segment ended, to continue from there so the next write will always be a sequential write until the card fill up, or do they jump to a new random location on the memory card, causing the card to become quickly fragmented. Only the shadow (and the card controller) knows!

Originally Posted by Tom Frank

Thanks for confirming another Class 10 card incompatibility! I wish I knew more about how/when the video DSP writes to the flash card.

I suspect some card maunfacturer's may be modifying their embedded controllers to favor sequential writing to get their CL 10 speed clas ratings, at the expense of random write speed, and without changing the memory structure itself to get faster writes.

I wish the card speed classification were expanded as a minimum, to take into account the random write speeds, or done away with entirely and just require a manufacturer to post their memory speeds in sequential and random read/writes for all to see up front. The speed class rating are SO misleading!

I don't know that they are doing it at the expense of random speeds, they just are not improving proportionally to the class rating, which disturbs the hell of me when trying to pick one!

I suspect there may be some cache trickery involved as the performance degrades over time on multi-gigabyte transfers.

Of the 6 or so microSD cards I have, class 4-10 (and two unmarked), the capacity of the card is the largest determinant of random write speeds. The smaller the faster.

Originally Posted by Tom Frank

Paul, did you manually terminate your card test? I was curious why only 500 of the 7608 MB were tested on the card? If the whole card is not tested, how do you know there are no problems on the rest of the card?

The "hwtest" utility lets you specify what size to use, I think 500MB is the default. It is useful to validate the capacity of the card.

I prefer to use Crystal Disk Mark for benchmarking performance.

PS: Flash memory controllers use techniques like 'wear leveling' and bad block management but I have no idea how that effects performance.

Originally Posted by capnchaos

I don't know that they are doing it at the expense of random speeds, they just are not improving proportionally to the class rating, which disturbs the hell of me when trying to pick one!

I suspect there may be some cache trickery involved as the performance degrades over time on multi-gigabyte transfers.

Of the 6 or so microSD cards I have, class 4-10 (and two unmarked), the capacity of the card is the largest determinant of random write speeds. The smaller the faster.

See to a computer dummy like myself this makes perfect sense to me.. As the bigger the area that you have to test the random write speed in the slower it should be as it has to cover a bigger distance.. And to a dummy like myself I can't see where the random write speed is that important on the camera where you are I would think recording in lets say a straight clean line and not having to be jumping around trying to find a space to drop some information where a previous file was deleted....

Originally Posted by capnchaos

I don't know that they are doing it at the expense of random speeds, they just are not improving proportionally to the class rating, which disturbs the hell of me when trying to pick one!

I suspect there may be some cache trickery involved as the performance degrades over time on multi-gigabyte transfers.

Of the 6 or so microSD cards I have, class 4-10 (and two unmarked), the capacity of the card is the largest determinant of random write speeds. The smaller the faster.

Since the class speed rating has no component measuring random write speeds, it's pure marketing advantage to make the controller favor sequential write speeds. I think the degradation over time with multi-GB file transfers is due to less contiguous memory space being available as the card fills up, and the gradual transition to more random searches for empty space which takes time.

Smaller cards should be faster since there is much less memory geometry and paths to have to negotiate to find empty space to write to (or so it would seem).

Originally Posted by capnchaos

The "hwtest" utility lets you specify what size to use, I think 500MB is the default. It is useful to validate the capacity of the card.

I prefer to use Crystal Disk Mark for benchmarking performance.

PS: Flash memory controllers use techniques like 'wear leveling' and bad block management but I have no idea how that effects performance.

The default is the entire disk memory, but you can specify a smaller size. But I only use this for verying memory write/read integrity (and hence always test the whole memory space), not the reported speed, which is only the sequential speed. I also use the CDM utility for speed tests.

The "wear leveling" must just be keeping read/write cycles fairly equal across the whole memory space over time, so this must keep a constantly changing map of memory usage to do this, and keep allocating available memory based on the map. And mapping out bad blocks just makes them permanently unavailable. So bottom line seems that both force writes to be less sequential than they otherwise could be. Since memory has a limited numer of cycles before it wears out, I guess this all makes sense for long term life cycle of the entire card.

File slow down over time
One of the problems of FAT filing system is call Fragmentation, thats why modern file systems dont use FAT.
A FULL format solves the problem, for a while, but the card will fragment as you create and delete files, it is inherent in the simple design of FAT filing.
The Wear Equalising and bad block management will make it worse.
I could explain it but I'd hate to put half the world to sleep...
Mike
(Industrial Archaeologist)
P.S. it is possible that a card could be too fast, and the camera firmware misses a control signal because the signal comes too soon.
I've seen that in the past, on other systems, but I have no proof it is happening here.

Originally Posted by empeabee

File slow down over time
One of the problems of FAT filing system is call Fragmentation, thats why modern file systems dont use FAT.
A FULL format solves the problem, for a while, but the card will fragment as you create and delete files, it is inherent in the simple design of FAT filing...

As long as you delete all of the files that were created before the next write to the card, a reformat is not necessary from a fragmentation standpoint.

I record whatever, plug in the camera, cut/paste all files from the camera and unplug/whatever.

Originally Posted by timetec

...
Looking through each lens from the rear, the new lens lets at least twice as much light through to the CMOS array (see photo below).


...
Richard

The rear view is quite revealing. It's also interesting that in photo mode, there's a bunch of meta-data recorded with each photo. And for both the new and old lenses, it reports the f-stop for both lenses as f/2.8. So that number must be hard-coded into the CMOS controller, and not really reporting anything about the lens currently in use. I guess that makes sense with no way for the camera to know what lens is on it.

It was previously formatted with SDFormatter and since it had data on it, recorded the 2GB available.

Here is what CrystalMark reports with the card in the camera
Random Write 512KB : 1.255 MB/s

Note that is about 0.3MB/s slower than using the USB card reader. The 808 #3 was also slower at read / write.

That is why I remove the card and insert it into a card reader, much faster (8MB/s v 19MB/s).

I set the camera to record at 20 and even 40 min interval clips. Every time the video is recorded in 5 mins intervals, annoying to have a bunch of files. Is there a fix to this?