Announcement

Collapse
No announcement yet.

uCAM-III get Picture response intermittent in RAW mode

Collapse
X
  • 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,
    Kevin

    Comment


    • #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/
      baudrates


      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,
      Kevin
      Last edited by John Kevin; 14th July 2018, 06:12 PM.

      Comment


      • #18
        frameRateuCAMIIver2.pdf

        Comment

        Working...
        X