PROBLEM EXPERIENCE
Wasted a whole afternoon shooting a commercial job, high res panoramas (to get big files) of 8 images x 5 AEB (tricky llighting) = 40 frames each panorama.

Downloaded the files and discovered numerous AEB sets missing?  A wasted 300km round trip and 1/2 day of work. Very annoying.

TEST
Ran tests in studio shooting 5 frame AEB's as fast as possible for over 100 frames (20+ AEB sets) and discovered a problem.

RESULTS   (5 frame AEB groups. 'x' = missing frame)
11111 - 22222 - xxxxx - 44444 - xxxxx - xxxxx - 77777 - xxxxx - xxxxx - 1010101010 - xxxxx - xxxxx - 1313131313 - xxxxx - xxxxx - xxxxx - 1717171717 - xxxxx - xxxxx - xxxxx - 2121212121 - xxxxx - xxxxx - xxxxx etc etc*

CONCLUSION
Appears that P4P DUMPS full sets of buffered AEB files in favour of NEWER AEB sets?
This is highly problematic as the controller gives audible feedback when frames are taken (click x 5 etc) but does not indicate when the buffer is full.  Every other camera will stop taking more images until there is buffer space, but DJI chucks them?  There is no way, that I know, to tell if you have images written to card memory except to wait a very conservative time between shots, otherwise you have dropped frames.

REQUESTS
1) Can others please try replicating this test and report results?
2) Can DJI please check that this is not a bug that needs attention?  I can't imagine 5 shot RAW AEB buffering is commonly tested?

*The card was a Sandisk Pro 64gb U3, but similar results with other cards.  Image files 2:3 format RAWs.

Could you happen to provide some samples of some of the pictures you're getting? Did you notice this after a firmware or Go app update?

DJI-Jamie Posted at 2017-4-3 20:26
Could you happen to provide some samples of some of the pictures you're getting? Did you notice this after a firmware or Go app update?

1) Hadn't noticed it prior to the latest update, but then not 100% sure I hit a buffer like this either.
2) Why would providing image files help, other than create more work for me?  The written files are all fine useable RAW images as expected.
Thanks, Rob

From what I have been able to work out, the camera system in the aircraft does not have any real buffer, it writes the shots as quickly as it can and makes everything wait until it is finished.

Are you sure you were using a Micro SD Card with fast enough write capabilities?

Make sure it is a SanDisk Extreme series with UHS-I/U3 rating. 30MB/sec or faster write speeds.  The 80-90MB/sec ratings are READ speeds.

Brian Fist Posted at 2017-4-3 22:02
Are you sure you were using a Micro SD Card with fast enough write capabilities?

Make sure it is a SanDisk Extreme series with UHS-I/U3 rating. 30MB/sec or faster write speeds.  The 80-90MB/sec ratings are READ speeds.

The Phantom camera won't write any faster regardless of how fast or expensive the SD card is.

"This is highly problematic as the controller gives audible feedback when frames are taken (click x 5 etc) but does not indicate when the buffer is full.  "

Watch the ring around the red shutter button on screen.
When you take a bracket, you'll see an animation round the button indicating that image files are being written.  When the animation stops, the buffer is clear
But is there really a need for AEB5 Raw if you are making huge panoramas?
You're going to put them in the blender to stitch and HDR them anyway.
How much better are the results going to be using jpg files rather than raw?
I mean really better ... not just fooling yourself better.

I shoot a lot of very big panoramas using jpg because it would take too long to do them in raw and I'm getting great results.

Geebax Posted at 2017-4-3 21:16
From what I have been able to work out, the camera system in the aircraft does not have any real buffer, it writes the shots as quickly as it can and makes everything wait until it is finished.

I think you need to do some tests before you suggest that.  From my tests it is clear that it does not wait for anything, it just throws images away.  And the results show it does it in blocks of AEB, not randomly dropping frames.

I'd really value others trying to replicate this issue.

Brian Fist Posted at 2017-4-3 22:02
Are you sure you were using a Micro SD Card with fast enough write capabilities?

Make sure it is a SanDisk Extreme series with UHS-I/U3 rating. 30MB/sec or faster write speeds.  The 80-90MB/sec ratings are READ speeds.

Hi Brian
Please read my post.  I tried it with several fast cards.  Same issue.  But you're missing my point - why is this camera prioritising the dropping of already taken frames, over capturing new ones.  This is not a sensible design.

Labroides Posted at 2017-4-4 00:06
"This is highly problematic as the controller gives audible feedback when frames are taken (click x 5 etc) but does not indicate when the buffer is full.  "

Watch the ring around the red shutter button on screen.

Hi Labroides

Thanks for your reply.  I take your points, but the point I'm raising is that prioritising the dumping of already taken images, over taking fresh images, is failed logic and no camera works like this for obvious reasons.  Most cameras will not allow the operator to take more images until the camera can.

Can you run a test and see what you find?

PS -  the reason I was taking 5xAEB RAW was not for HDR, it was fast fading light, in the last of the twilight, and multiple lightsources  - lighthouse, sunset, reflected light off sea etc.  I had to work fast so was using AEB to give me scope to get it close enough and pick up the best exposure later in the studio, so I could focus more on flying and framing in the few minutes I had left.

Rob8888 Posted at 2017-4-4 02:14
I think you need to do some tests before you suggest that.  From my tests it is clear that it does not wait for anything, it just throws images away.  And the results show it does it in blocks of AEB, not randomly dropping frames.

I'd really value others trying to replicate this issue.

I am not doubting your test results, I am saying there is no appreciable buffer in the camera, and that may be why it is doing what you said. It normally puts everything on hold while it writes to the card, but a software fault may be allowing it to take the next bracket before the first bracket has finished writing.

Geebax Posted at 2017-4-4 14:02
I am not doubting your test results, I am saying there is no appreciable buffer in the camera, and that may be why it is doing what you said. It normally puts everything on hold while it writes to the card, but a software fault may be allowing it to take the next bracket before the first bracket has finished writing.

Yes, that is indeed what I'm experiencing - the dumping of AEB sets before writing them, so more can be taken.  This can't be a planned feature (software bug) so I hope DJI look at it.  

What would be really helpful is if other people tried replicating it.  No one has yet reported they have tried sadly.

Labroides Posted at 2017-4-4 00:01
The Phantom camera won't write any faster regardless of how fast or expensive the SD card is.

Yeah, but a slow card will slow down the writes to the point of holding back the hardware in the P4Pro.  ie, if you try to write to too slow a card in 4k/60fps it will kick out of recording altogether.

I would imagine if the card you have is slower, than it only makes sense that it would "skip" writing sets due to the same reason.

Also, no one has stated how fast the hardware in the bird actually *CAN* write to the card, just that the write spec published is 100mbps.  Now that sounds exactly like a generalized specification, not a absolute maximum based upon implementation.  Just like USB 2.0 is 480mbps, yet a ton of devices only get to a fraction of that based upon design, as well as USB 3.0 being 5Gbps, yet for card readers it is more like 150mbps even under USB 3.0.  In that example why don't USB 2.0 card readers read at more than 8-9MBps when they should be able to handle at least 45-50MBps based upon a 480mbps max throughput (use a USB 2.0 gigabit ethernet for comparison and they get at least 400mbps throughput, so why not SD card readers?).

Again, just saying that the Micro SD card used *does* play a factor if it cannot keep up with the max write speeds of the AC.

Brian Fist Posted at 2017-4-4 16:40
Yeah, but a slow card will slow down the writes to the point of holding back the hardware in the P4Pro.  ie, if you try to write to too slow a card in 4k/60fps it will kick out of recording altogether.

I would imagine if the card you have is slower, than it only makes sense that it would "skip" writing sets due to the same reason.

Hi Brian,
Sure, I see what you're saying.  But that's not the issue please.  It is: photos should not be dumped so new ones can be taken instead. All other cameras suspend new captures first - a slow card should just slow the time the camera is unavailable.  May we focus back on the observed bug, not on cards?

Brian Fist Posted at 2017-4-4 16:40
Yeah, but a slow card will slow down the writes to the point of holding back the hardware in the P4Pro.  ie, if you try to write to too slow a card in 4k/60fps it will kick out of recording altogether.

I would imagine if the card you have is slower, than it only makes sense that it would "skip" writing sets due to the same reason.

"Again, just saying that the Micro SD card used *does* play a factor if it cannot keep up with the max write speeds of the AC."

You are talking about cards that are too slow to work properly.
I wasn't.  I was talking about cards that are faster than the camera can write.
They won't write any faster in the Phantom because that's where the speed bottleneck is.
The Phantom camera won't write any faster regardless of how fast or expensive the SD card is.

Rob8888 Posted at 2017-4-4 02:26
Hi Labroides

Thanks for your reply.  I take your points, but the point I'm raising is that prioritising the dumping of already taken images, over taking fresh images, is failed logic and no camera works like this for obvious reasons.  Most cameras will not allow the operator to take more images until the camera can.

I agree with the responses by Labroides and Geebax, the write process just takes time. You can't happily click away like for a high end DSLR and it is a good tip to wait for the animation of the 'trigger button' to stop before you take the next sequence of frames.
Anyways, I'm sure this post will be noted by DJI.

I too have lost frames. I've just adapted to the situation, which is a limitation and interpretation of implementation (the current shot is the one I really wanted, otherwise why be impatient and shoot again so soon after a previous shot?) Yeah, an issue with panoramas but maybe not for most other situations.

Mike-the-cat Posted at 2017-4-4 17:14
I agree with the responses by Labroides and Geebax, the write process just takes time. You can't happily click away like for a high end DSLR and it is a good tip to wait for the animation of the 'trigger button' to stop before you take the next sequence of frames.
Anyways, I'm sure this post will be noted by DJI.

Thanks Mike-the-cat, you're the first person to actually report anything.

Point I'm making is whoever wrote the code forgot an important step
All digital cameras:
1) operator initiates photo 2) IF files can be written to card or buffer THEN take photo, ELSE wait until files can be written (or buffer frees space)
P4P situation is:
1) operator initiates photo 2) IF files can be written to card or buffer THEN take photo, ELSE dump all previous unwritten files and take photo  This is an oversight/bug

Rob8888, in all actuality, does it really even matter of it is either situation???

The fact is it will drop files.  Whether or not it dumps a previous one or a later one, it is still dumping what it can't write.

I am pretty sure it is six of one, half dozen of the other.  And why would it matter?

Unless they build-in massive high-speed buffer memory to store multiple RAW files before writing then the point is moot.

Brian Fist Posted at 2017-4-4 19:35
Rob8888, in all actuality, does it really even matter of it is either situation???

The fact is it will drop files.  Whether or not it dumps a previous one or a later one, it is still dumping what it can't write.

Thanks Brian.  I/m not sure I agree.  No other camera does it this way. Having to guess at the 'buffering' time while you're doing 20 other things isn't the right approach.  The camera should not be able to shoot more images if it can't handle what it has.  This is surely a simple coding issue?

Has anyone tried to replicate this bug yet?  Seems others probably aren't too worried about getting it fixed?

Dear Rob8888

I too have experienced the same issues, although with the X5 camera on Inspire Pro.
On quick succession with 5 shot AEB, It appears that every second, sometimes third - (set of five) images are dumped.

I have tried all different parameters, including card write speed.
I thought I was going mad but have resorted to 3 AEB - and IF I need that wider dynamic range of 5 AEB, I slow the whole capture process down.
No consolation that you have experienced the same issue but I am glad you have identified an issue.

I'd also love for the exposure range to be adjustable within the AEB settings - similar to a DSLR range - say brackets of a full stop.

Rob, by any chance, have you done any died-time tests between groups of 5 AEB? I mean, to wait a few seconds between groups, and see if all the frames are there.