Announcement

Collapse
No announcement yet.

uCAM-III get Picture response intermittent in RAW mode

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

  • John Kevin
    commented on 's reply
    Thanks, Gerald. I appreciate your insights.

  • John Kevin
    replied
    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

    Leave a comment:


  • geraldd
    replied
    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

    Leave a comment:


  • Tillie
    replied
    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, 06:09 PM.

    Leave a comment:


  • John Kevin
    replied
    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

    Leave a comment:


  • geraldd
    replied
    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

    Leave a comment:


  • John Kevin
    replied
    frameRateuCAMIIver2.pdf

    Leave a comment:


  • John Kevin
    replied
    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, 07:12 PM.

    Leave a comment:


  • John Kevin
    replied
    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

    Leave a comment:


  • geraldd
    replied
    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

    Leave a comment:


  • Eran
    replied
    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,

    Leave a comment:


  • geraldd
    replied
    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

    Leave a comment:


  • Eran
    replied
    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:	124
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,

    Leave a comment:


  • geraldd
    replied
    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

    Leave a comment:


  • Eran
    replied
    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

    Leave a comment:

Working...
X