Camera Bug when JPEG splits into an integer number of packets

[DavieJG]

Hi guys,

I've been working on interfacing a ucam into both matlab and a picdem-z demonstration board.

It's all been fairly straight forward but on both platforms i have run into the same problem.

If a JPEG image (80x60) splits into an integer number of packets i.e. there is no remainder packet, the camera becomes unresponsive and continually outputs nonsense to the 232.

is this a known problem and is there a known solution?

I have played around with the package size but to no avail.

[ESPsupport]

The only known problem in this area is noted in the documentation, viz
"Package size must not be odd or multiple of 16"

I'm not in a position to test your scenario today, so give me the package sizes you have tried and how long it takes to become unresponsive and I'll try it as soon as I can.

[DavieJG]

i noted that criterion and have tried various package sizes.

As the default size is 64 bytes (which is a multiple of 16, i wondered if there may be a typo).

As this fault only occurs when the jpeg is split into an integer no. of packets the probability is greater for smaller package sizes. So ive been testing with sizes of 18 and 20. The final system needs to forward the packets via an RF link which accepts a packet size of 100 and this is where i first noticed the problem.

Analysing the comms between camera and controller shows that the packets are received as normal but after acknowledging the last packet the camera replies with a blank remainder i.e. 6 bytes with the length field indicating 0x0000. This is then followed by a never ending string of nonsense.

The image itself is correct but its not possible to obtain another image without a hard reset.

I have experimented with a soft reset with some success. First of all, instead of acknowledging the last packet i would send a special reset {0xAA,0x08,0x01,0x00,0x00,0xFF} and this worked about 50% of time but was still not acceptable for my application.

My second solution is to send the reset as soon as i know i have a zero remainder image and this seems to reliably keep the camera going. However, it is not ideal as im now dropping frames.

Any insight you could provide would be greatly appreciated.

Cheers,

Dave.
edit: going back to your demo software i can see that it exhibits the same behaviour and is unable to keep video mode running for very long.

ACK [AA 0E FF 00 2A 01]
(Camera Data received)
ACK [AA 0E FF 00 2B 01]
(Camera Data received)
ACK [AA 0E FF 00 2C 01]
Image size =3600
Get Picture [AA 04 05 00 00 00] Response to Get Picture not correct
Response to Get Picture not correct

Here is a fault with package size = 18. So 0x012C = 300x12 packets. The next get picture command is given and the response of the camera looks like it wants to be another packet. It has an ID number which always equals the number of the last packet and then a zero length field. 0xFFD9 is the EOF for a JPEG which i have already received.

The camera is now completely unresponsive.

[ESPsupport]

Sorry for the delay in responding, once we confirmed your problem we needed to solve it .

The solution is actually rather simple.

If the last packet = the packet size, rather than send the normal ACK send a 'special and state machine reset' (i.e. AA 08 01 00 00 FF)

Egads!

Now that I have read your most recent post I see that you have already
tried that.

Perhaps you need to place a small delay (say 5ms) before you send the reset. I suspect you may already have this delay elsewhere but because of the order of your code it isn't happenning immediately prior to the reset.

[DavieJG]

Ok thanks for looking into the problem for me.

Will you be updating the test software to implement this workaround?

[ESPsupport]

The software has been updated, but I don't think it's up on the website yet, hopefully soon.