Announcement

Collapse
No announcement yet.

uCAM-III get Picture response intermittent in RAW mode

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • uCAM-III get Picture response intermittent in RAW mode

    Hello,

    I'm using the uCAMI unit to get RAW picture data for 80x60 resolution.every 1 second
    This process works 99.5% of the time but sometimes (rarely) the uCAM-III does not send the picture data

    Normal Sequence
    The host sends the get picture command,[0xaa,0x04,0x02,0x00,0x00,0x00]
    uCAM always responds with ACK response to get picture command [0xAA,0x0e,0x04,0xxx,0x00,0x00]
    Host then waits for picture data block.
    uCAM sends picture data block as one block (4806 bytes)
    Host receives data block and sends Acknowledge of picture block
    Wait one second
    Repeat process

    Fault Sequence
    The host sends the get picture command,
    uCAM always responds with ACK response to get picture command
    Host then waits for picture data block from uCAM.
    uCAM does not respond with picture data block (even after very long timeout period) there is no response.

    Further info
    After fault condition, the Host retries but does not get any response from UCAM.
    Even after pulsing the uCAM reset line the uCAM does not communicate
    Only after a power on/off does the uCAM come back to life and responds to coms

    Setup
    RAW picture mode 80x60
    8-bit Gray Scale (RAW)
    Baud rate is 1843200 baud (1.8Mbaud)
    Communications is direct into host micro processor UART (atmel SAM D21)
    Initialisation {0xaa,0x01,0x00,0x03,0x01,0x03}
    Exposure {0xaa,0x14,0x02,0x02,0x02,0x00}
    Light {0xaa,0x13,0x00,0x00,0x00,0x00}
    Timeout {0xaa,0x15,0x0F,0x00,0x00,0x00};

    Let me know if there are issues around this area and possible solutions to try.

    Thank you for your time
    Regards
    Gerald



  • #2
    Hi Gerald,

    Welcome to the forum,

    Have you tried the uCamIII Demo? If not yet, then I suggest that you capture an image using this and see if the error still occurs.
    You can download the Demo here: https://www.4dsystems.com.au/downloa...CamIIIDemo.zip


    Similarly, you can also try this code and see if the error is still present: https://www.4dmakers.net/projects/details/ucam-iii-demo


    Using continuous capture until capture number 350, I got no issues like stuck-up as you’ve stated.

    If both of these demos run smoothly without errors, then we can assume that your inquiry might have something to do with the communication between your host and the display. Possible reasons might be the protocol or an “out of sync” of both the uCam and the host. Usually, if this syncing problem happens, a call to resync should be done. If the resyncing fails yet again, then resetting action is next.


    Other things to look up on to are the baud rate and the power source. The baud rate might be too high that either one (uCam or host) of the devices can’t catch up to the other one. There’s a small chance that the issue has something to do with the power source, but just to be sure, can you try the other ports of your PC as source and see if the issue is still there?

    Additional troubleshooting techniques can be found here under section 10: http://www.4dsystems.com.au/productp...heet_R_1_0.pdf

    Hope this helps and Best Regards,
    Eran
    Eran

    Comment


    • #3
      Hi Eran

      Thanks for the quick reply
      Will test using ucam-ii-demo software and check power source, baud rate and let you know

      Thanks
      Gerald

      Comment


      • #4
        Hi Gerald,

        I hope one of those could help you and I'm very much willing to hear the result.

        Best Regards,
        Eran
        Eran

        Comment


        • #5
          Hi Eran,

          The power supply seems to be the issue. After using the uCAM demo software in continuous mode (ie video mode) there were no problems with the communication at 921600, and 122880 baud. I could not test at 1843200 or 3686400 as to USB/Serial hardware limitations.

          Coming back to power supply., A scope monitored the ripple on the 5 volt line next to uCAM connector, there was 250mV of ripple present on 5v.Placing a capacitor 10uF helped to reduce this down to 200mV also placing a 10 or 100nF cap reduced the higher frequency noise. .The unit was run for a few hours and no faults present.

          Further stress testing such as running in a hot environment is needed so that 5V supply and performance can be monitored.

          As an observation, when the uCAM would fault by not sending the Picture data block, any further coms by the host to uCAM was unsuccessful.
          No amount of sending sych commands would yield a response. In that case a hardware reset was send. but the uCAM would not respond to any coms from host.
          Only by powering uCAM Off/On would a normal coms link be re-established.

          So it raises questions on
          1) What is causing the uCAM to lock up even after hardware reset issued from host (Is a subsystems not being reset correctly)
          2) Is noise on power supply not being filtered enough in uCAM (What are the specs on uCAM input supply and ripple tolerance. Minimal info is mentioned in datasheet).
          3) Is it possible to see the input power supply filtering circuit of uCAM to see what is present so can adjust external caps to make more robust
          4) It was suggested in other posts to use a FET connected to uCAM 5V to switch 5V off/on when communication cannot be re-established. Is it possible to post this circuit?
          5) What about the TXD/RXD lines would this have to be disconnected at the same time as power disconnection?
          6) What temperate specs can the uCAM-III operate in (application is for outdoor use and temperature can range from -5 to +40 degrees C)

          Let me know what you find

          Regards
          Gerald


          -



          est at a higher baud (Although max baud rate was 122880 due to limitation of usb/serial board)

          Comment


          • #6
            Hi Gerald,

            It’s good to know that you have narrowed down the possible reasons for the issue.
            Am I right on assuming that you have run these tests with other power supplies as well?

            “Some power supplies have a slow rise time, so if you are powering the uCAM-III directly from a power supply and start communicating with it, you may have issues with SYNC as the module may start up in a weird state due to the slow rise time. Testing of power supplies with a rise time of under 5uS resulted in correct operation. Power supplies with a rise time of greater than about 50uS resulted in trouble to SYNC. It however is rare to encounter this issue”
            Additional information can be read on Section 6 of the uCam-III datasheet.

            On the same datasheet under section 10 (Troubleshooting), there’s also a troubleshooting technique about the camera going to sleep mode.
            Section 13 also has the information about the operating ambient temperature that you were asking.

            And Gerald, I think it’s a bit confusing to know that you already solved the issue and yet you’re still having problems:
            “.The unit was run for a few hours and no faults present. “
            “As an observation, when the uCAM would fault by not sending the Picture data block, any further coms by the host to uCAM was unsuccessful.”
            Can you explain more about when you’re having the problem and when you got no errors? It will be a very helpful information for us to help you.

            For now, we’ll make a review of the uCam tests and see if we’ll get the issues like yours. We’ll also include the things that you’ve listed: stuck communications, noise, and ripple tolerance. Please be reminded as well that the previously conducted test was done under the requirements listed in the datasheet.

            Hope this helps and best regards,
            Eran
            Eran

            Comment


            • #7
              Hi Eran,

              The tests have run on four units with its own integrated power supply (power is provided by USB cable to unit).5V is supplied to uCAM. The scope trace is monitoring the +5V close to uCAM board and the power supply does not dip during operation. Only the ripple on the supply is present. The level is dependent on capacitor value (ripple varies from 250mV to 160 mV).
              The fault rate does seem to depend on level of ripple. more ripple higher chance of fault. (This is where ripple tolerance in specs usefull)
              The fault has not been remedied and can be random and occurs once after 1,2,3 hours


              In the comment below, is it related only to a power on condition?. please clarify

              Some power supplies have a slow rise time, so if you are powering the uCAM-III directly from a power supply and start communicating with it, you may have issues with SYNC as the module may start up in a weird state due to the slow rise time. Testing of power supplies with a rise time of under 5uS resulted in correct operation. Power supplies with a rise time of greater than about 50uS resulted in trouble to SYNC. It however is rare to encounter this issue
              The camera sleep mode is disabled on initialisation
              Thanks for information on min and max temperature specs

              I will set up long term tests on scope to monitor uCAM TX,RX coms, +5V power supply under various conditions to extract more info

              Regards
              Gerald

              Comment


              • #8
                Hi Gerald,

                In the comment below, is it related only to a power on condition?. please clarify

                Well, if your power supply doesn’t meet the requirements, then it should be noticeable already upon booting up the camera, but if syncing doesn’t get to be a problem, then you can scratch out the rise time requirement of the power supply.
                Upon upgrading from the previous version of uCAm (uCam-II), the power control is not needed anymore by the uCam-III since uCam-III has a reset pin already. Are all four units that you’re testing uCam-III?

                From the datasheet,
                “Taking advantage of the RESET pin will also enable your project/product/application to have supervisory control over the uCAM-III, in the rare case it becomes unresponsive, and provides your host controller with the means to resume operation without any external intervention.”
                In case you want to use the reset pin, there is a sample routine on the first demo project that I posted. You only have to set the RESET_PIN of the uCAm to HIGH then LOW then HIGH. It is documented in the Sections 4, 6, and 7.6 of the datasheet in case you want more information.

                It’s interesting to know as well that all of your units are behaving differently with the same setup that my end had. I will be waiting for the results of your observation as I conduct mine and see if we get the same results.

                Best Regards,
                Eran
                Eran

                Comment


                • #9
                  Hi Eran,

                  All units are uCAM-III.

                  During operation uCAM +5V is left on. The uCAM is only initialized when power supply is stable.

                  The initialisation sequence is
                  - Host send synch command to uCAM
                  - Wait for valid synch response
                  - Retry 4 times if no sych response.
                  - Reset uCAM for 300ms
                  - Host wait 4000ms
                  - Host sends sych command (repeat upto 10 times)
                  - Host waits for valid sych response

                  Note: During fault condition (when uCAM is unresponsive). The host resets the uCAM. After reset the host waits for 4 seconds and tries to synch with uCAM but the uCAM does not respond even after many synch attempts . This is the original fault condition of uCAM unresponsive. (possibly due to ripple on 5V supply)

                  We have obtained a bench top power supply and will power uCAM with +5v and post results

                  Regards
                  Gerald

                  Comment


                  • #10
                    Hi Gerald,

                    Thank you for clarifying.

                    I'll be waiting for the results and try to make a reset routine for you for additional testing. Am I right on assuming that you are using a 4D display as the host?

                    Best Regards,
                    Eran
                    Eran

                    Comment


                    • #11
                      Hi Eran,

                      Sorry for the response delay have been away overseas.

                      The host is not a 4D display, it is standard off the shelf hardware i.e MKR zero using the SAMD21G18 running at 48Mhz.

                      The issue of uCAM not responding after 2,3 hours of continuous use is still present,(this can be quite random) even when a bench power supply connected directly to uCAM.
                      We have resolved the 2nd issue which was when a reset from host was given the communication link would not be re-established.
                      The issue was related to the host. When a reset pulse was given, the uCAM would reset as expected. We found the fault with host having a UART communication conflict. Two host resources were attempting to use the UART coms (DMA and non-DMA) The DMA resource needed to be released so that the non-DMA resource could receive the uCAM responses correctly. Removing the conflict fixed the problem.

                      As a observation of continuously testing 3 separate units over many hours in low light conditions, when a moving object was in the camera field of view, the fault frequency would increase,(fault was uCAM not responding with picture data block after request from host). Where as a single unit pointed at a wall, no fault was detected.The fault condition was very rare and required 2 hours or more of continuous use.

                      Could this be related to uCAM internal operation for focusing and exposure control causing internal conflicts?
                      As a suggestion to test this theory on a different hardware platform, could you test the
                      1) 4D display with the uCAM pointing at a moving object in changing low light conditions.
                      2) 4D display with the uCAM pointing at a stable image i.e point at a wall with stable lighting conditions

                      The uCAM is a good product and works well for continuous use, but when the coms intermittently does not respond, a host hardware reset can re-establish the uCAM coms

                      Regards
                      Gerald

                      Comment


                      • #12
                        Hi Gerald,

                        It's good to know that you have solved the issue about resetting the uCam.

                        Like what you have requested, I have implemented a setup of two versions: one for a non-moving object and another one for a moving object (ie video).
                        Click image for larger version

Name:	staticIMG.jpg
Views:	1
Size:	1.84 MB
ID:	64292 ​​​​​​​


                        The typical time for capturing and printing is 11 seconds. As you can see in the photos, the current number of capture images is over 1640. Doing the math, you'll see that the testing has been running for five hours continuously already, yet no issue like yours happened on my end.

                        You mentioned using two hosts. Have you tried using one host only to capture an image continuously? And out of curiosity, does your setup include other peripherals like sensors or modules?

                        How exactly are you using the images? Are you just displaying it or are you saving it down to a uSDCard?

                        Best Regards,
                        Eran

                        Comment


                        • #13
                          Hi Eran,

                          Good to see setup with no issues with coms. Have a couple of questions on setup used
                          1) you mention frame capture rate is 1 frame per 11 seconds, can this rate be increased to 1 fps
                          2) what is the coms baud rate?

                          I now have 3 separate units back from the field, All have the same software and hardware configuration.
                          The configuration use case is
                          1) image captured from uCAM at rate of 1 per second
                          2) image stored to uSD Card at same rate (after capturing uCAM data frame stored)

                          Other sensor/modules in use, thermal sensor with data captured from sensor at 5 frames per second and stored to uSD Card at same rate.

                          Further tests to under take, run over 5 hours

                          1) 3 units to capture uCAM image at 1 fps (thermal sensor and writes to uSD card disabled) with uCAM pointing at stable image (wall) to simulate uCAM constant light exposure and focus
                          2) 3 units to capture uCAM image at1 fps (thermal sensor and writes to uSD card disabled with uCAM pointing at moving object ie human sitting in chair and moving, to simulate change of light exposure and focus with the aim to increase the frequency of execution in the uCAM re-focus and light exposure algorithms

                          3) 3 units to capture uCAM image at 1 fps (thermal sensor and writes to uSD card enabled) with uCAM pointing at stable image (wall) to simulate uCAM constant light exposure and focus
                          4) 3 units to capture uCAM image at 1 fps (thermal sensor and writes to uSD card enabled) with uCAM pointing at moving object ie human sitting in chair to simulate change of light exposure and focus with the aim to increase the frequency of execution in the uCAM re-focus and light exposure algorithms

                          Will compare results 1 and 2 with 3 and 4 and let you know.

                          Regards
                          Gerald

                          Comment


                          • #14
                            Hi Gerald,

                            To answer your questions,

                            1) The frame capture rate was not really 11 seconds. What's taken it that long was the parsing and printing of the data captured by the uCam. The capture rate is actually shorter than 11 seconds.
                            2) The baud rate that’s used in the setup is 9600

                            Your testing might give us more information of the issue that you’re having and I will be waiting for it.

                            Best Regards,
                            Eran

                            Comment


                            • #15
                              Hi Eran,

                              Testing test case setup
                              1) 3 units at 1 fps continuous (thermal sensor and writes to uSD card disabled) with uCAM pointing at stable image (wall)
                              2) 3 units at 1 fps continuous (thermal sensor and writes to uSD card disabled with uCAM pointing at moving object ie human sitting in chair and moving
                              3) 3) units at 1 fps continuous (thermal sensor and writes to uSD card enabled) with uCAM pointing at stable image (wall)
                              4) 3 units at 1 fps continuous (thermal sensor and writes to uSD card enabled) with uCAM pointing at moving object ie human sitting in chair and moving

                              Testing results( Number of times reset required for test case above)
                              unit number 1, 2 ,3
                              1) 0,0, 0 (test run for 10 hrs,)
                              2) 10,5,25 (test run for 10 hrs)
                              3) 1,2,2
                              4) 25,25,13

                              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.
                              Even when the testing software is simplified (no other sensors, No DMA) and setup to continuously get and read picture data, the fault is still present.(test cases 1 and 2)
                              I suspect when uCAM exposure/brightness/focusing algorithms are running at a higher rate due to varying lighting conditions then fault occur ace is greater.
                              I recommend further testing using the uCAM demo unit running at 921600 baud with the setup/configuration as below and using a moving object with changing focus/exposure. This should test the robustness of the uCAM on a different platform.

                              uCAM setup/configuration at startup (baud rate 921600)
                              RAW picture mode 80x60
                              8-bit Gray Scale (RAW)
                              1) sync command {0xaa,0x0d,0x00,0x00,0x00,0x00}
                              2) initial command {0xaa,0x01,0x00,0x03,0x01,0x03}
                              3) brightness/expo {0xaa,0x14,0x02,0x02,0x02,0x00}
                              4) light command {0xaa,0x13,0x00,0x00,0x00,0x00}
                              5) sleep command {0xaa,0x15,0x00,0x00,0x00,0x00} disabled
                              6) get picture com. {0xaa,0x04,0x02,0x00,0x00,0x00}

                              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.
                              Let me know if you require a image output.

                              Let me know if you need more info for debugging uCAM issue

                              Regards
                              Gerald

                              Comment

                              Working...
                              X