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


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

          Regards
          Gerald

          Comment


          • #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,
            Kevin

            Comment


            • #21
              It is as though testing unbroken 3 separate units over many hours in low light conditions with what else when the moving object was in the field of view of the camera. And only then maybe the fault frequency would increase,(and only CAM not responding with the data unit after request from the host mega moolah).Maybe you know where the single block pointed to the wall and there was no one found.they say that the fault was very rare and took about 2 hours about
              Last edited by Tillie; 11th July 2019, 05:09 PM.

              Comment


              • #22
                Hi Tillie,

                This was a similar fault we found a while ago.
                Check the power supply and check to see level of ripple on 5Volt line into camera, use a scope if available
                Recent testing, found the camera draws upto 100mA at 5V, so make sure good wire connections and cable length kept short

                What mode of operation was used. Is it RAW, JPEG. Baud rate and rate of requesting picture data from host.
                Something to try, Set up request of picture data every 2 seconds and test and note frequency of issue
                Then test it with request every 0.5 s, and compare

                Regards
                Gerald

                Comment


                • John Kevin
                  John Kevin commented
                  Editing a comment
                  Thanks, Gerald. I appreciate your insights.

              • #23
                Hello Tillie,

                Welcome to the forum!
                As what Gerald says, can you provide a stable power source on the uCAM to see if it can resolve the problem?
                It would also be best if you can give us the tests that have you done, so we can try to re-create the issue.

                Best Regards,
                Kevin

                Comment

                Working...
                X