search

ArduCAM / Arduino

This is ArduCAM library for Arduino boards
MIT License
473 stars 349 forks source link

Corrupt image from ov5642 via Zigbee module #419

Open Schius opened 5 years ago

Schius commented 5 years ago

Hi,

I checked all the related issues but could not still get any particular solution.

I have been trying to send images from OV5642 cam shield through zigbee module, using these instructions [https://github.com/ArduCAM/Arduino/tree/master/ArduCAM/examples/mini/ArduCAM_Mini_Video_Streaming_Bluetooth], but it seems to be getting corrupt images. I followed all the instructions to the later, and even went through all the related issues. 10-51-36 10-51-34 10-51-35. Please, what can I do? Although, I know bluetooth was used in the examples.

Schius commented 5 years ago

Also, why is the gnd of the bluetooth connected to arduino vin pin? Arducam_Mini_VideoStreaming_BlueTooth

ArduCAM commented 5 years ago

@Schius For some PC, the electric current is too small to run the camera normally. Please try to reduce the baud rate and use a shorter cable line.

Schius commented 5 years ago

I used lesser baud rates and even got shorter cable lines, still got similar results.

The measured voltage at my terminals is around 4.96v. Still pondering on what to do next. Or am I getting the connections wrong? I noticed that the ground from the wireless module was connected to the vin of arduino. Is that connection correct?

ArduCAM commented 5 years ago

@Schius Have you tested it with Arduino UNO paltform? If you have connected it with shorter connect cable and low baud rate. The problem is still exist. Please contact our sales to replacement cameras.

Splitframe commented 4 years ago

Hi, we had similar problems when sending the image over BT UART, Wifi or Software Serial. Our images looked exactly like yours. Our problem that due to the undefined and variable excecution time of whatever code handles the sending of the data you slowly drift out of your burst window. You start lagging behind or even be too fast.

We solved this by reading the microns before sending and then afterward waiting for 15 microseconds (taken from ArduCam example) to pass by comparing to our stored value. This makes sure that you don't drift out of your FIFO burst intervalls.