No announcement yet.

uCAM-III get Picture response intermittent in RAW mode

  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Hello geraldd,

    Eran might not be able to reply this week, so I will try and simulate your current setup.
    I will get back to you as soon as I can when I get some results.

    Best regards,


    • #17
      Hello geraldd,

      I have done similar testing at a baud rate of 921600 using the
      4D uCAM-III demo application and using the 4D Display with a baudrate of 153000
      (baudrate may be limited because of the hardware limitations).

      - this is a dynamic testing which constantly
      changes because people are passing/moving for every minute.

      I have not experienced the errors that occured in your setup.
      Based on your tests using the parameters that you have.

      80x60 - Raw Resolution
      8bit - Color Type
      1 frame/sec

      Note: The setting that you have used is applicable on lower baudrates, you can use this formula
      for reference when you want to compute for your fps/

      From the results when the uCAM running in continuous mode has a moving object,
      the frequency of reset is higher, where as when uCAM is facing a non-moving
      object in low light (ie wall) the fault frequency is less.
      I have done similar testing as yours but I do not think that an external
      environment (dim light/moving object)will affect the capture rate of the uCAM-III,
      something might be happening during the transmission of data(internally).

      As an observation by monitoring the tx and rx lines on a scope during the fault condition,
      the uCAM does not respond with the picture data after a getPicture command response.
      Probably because it is already out of snyc, a re-snyc is necessary for establishing connection.
      It is explicitly said on the datasheet that -
      "Sometimes up to 25 to 60 SYNC commands maybe required before
      the module will respond."

      I just see on the above posts that on the flow of your program you are using 10 retries if
      no snycing response from the uCAM-III.

      If you can reduce the ripple to below 25mV, even better. The aim is to eliminate the power supply ripple
      as root cause of the issue. This 'ripple issue' might be the one that affects your data communication.
      Some effects can be:
      -heating in DC circuits components
      -give incorrect outputs and data being corrupted.

      As you can understand, we aren't able to replicate the issues in our testing.
      I hope it helps.
      Best Regards,
      Last edited by John Kevin; 14th July 2018, 06:12 PM.


      • #18


        • #19
          Hi Kevin,

          Have finally had time to investigate coms issue with camera.
          Found issue with power supply voltage variation causing voltages to range from 5.03 to 4.85V. This was happening on the test unit. Looks like supply was sensitive to small changes in load
          Fixed issue by using DC to DC regulator to create stable 5 volt.

          Thanks for the frameRate document, very useful to have



          • #20
            Hello geraldd,

            Thank you for coming back to us. I am glad to know that you have been able to pinpoint
            the root cause of the problem. If you have any inquiries on the future, please don't hesitate to
            contact us.

            Best Regards,