Announcement

Collapse
No announcement yet.

uCam speed

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

  • uCam speed

    Hi,
    I have got some code working to take a picture with the uCam.
    I'm running at 1228800 baud and am taking a160 x 120 8-bit greyscale picture, just using the GET_PICTURE command (not the SNAPSHOT command), which could be part of the problem?
    By my maths this is a transfer of (160 x 120 x 8) 153600 bits, which should take (153600 / 1228800) 0.125 seconds.
    I took some measurements and the transfer is taking 0.283 seconds. So where is the additional 0.158 seconds coming from?
    I did have some trouble syncing the serial port between the uCam and micro and did put in a catch in the for loop that transfers the picture. The code is below.
    // Get response from uCam for (int i=0; i

  • #2


    Your calculation is a bit out, each byte is 10 bits, not 8 (you need to allow for the start and stop bits).

    You are also assuming that the camera has the picture available 'immediately' and that the GET_PICTURE command takes no time at all.

    There's also the possibilty of latency in the serial port on your driving system. For example if you were using a CE5 to connect to the uCam changing the latency timer in that advanced settings from the default of 16ms to 1ms will make quite a bit of difference. Of course other latencies in Windows will need other techniques, eg read timeouts, other applications being dispatched, etc.
    Mark

    Comment


    • #3


      Oh yes the stop and parity bits, forgot about those. That still only accounts for (160 x 120 x 10) 192000 bits which should take 156 ms. So I'm missing 127 ms.
      But I think I have found the issue. Once received I am sending the image to a OLED screen. The time it takes to display on the screen is around 27 ms. 156 ms - 27 ms = 129 ms. Which is really really close to the missing time (especially if you allow of the extra bytes to initiate the GET_PICTURE command and the small delay between sending the command and the uCam responding).
      So what I think is happening is this:The micro gets a picture from the uCam. The image is displayed on the screen. A new picture is requested but because of the time it has taken to display the image on the OLED screen, the uCam has to wait for a new image to become available and we effectively 'lose' 1 frame. This is the missing time.
      Does that sound right?
      Is there anyway to overcome this? (other than not displaying the image?)
      I will test this hypothesis tonight by taking timings while just requesting new images from the uCam (not displaying anything on the screen).
      Martin

      Comment


      • #4


        Not sure how you are getting the image to the oled, but yeah if you can send each byte to the oled at the same time as you receive it from the camera then that should save some time.



        Or would it? I thought the max baud rate to the oled was about 600kbaud, or are you doing something different?
        Mark

        Comment


        • #5


          Good idea, I'll give it a go.
          The OLED I'm using is not a 4D systems product. I'm driving it via SPI at 18 MHz, so it could work.

          Comment


          • #6


            Hi,
            I tried to see how quickly I could get images off the uCam as promised. Results didn't go too well. I'm using a program with a for loop that just asks for a picture. When I have received the last byte and sent the ACK back to the uCam, the loops repeats and I immediately ask for a new picture. I still can't seem to get the next frame, I always miss a frame and get the following one.
            Can someone confirm that it is possible to get successive frames back from the uCam in this manner? If so what image size, colour resolution, and baud rate were used?
            Martin

            Comment


            • #7


              I still can't seem to get the next frame, I always miss a frame and get the following one.
              Ummm, how can you say that? There is no timing relationship between the frames, the next frame is 'when you get it'.
              Mark

              Comment


              • #8


                Ummm, how can you say that? There is no timing relationship between the frames, the next frame is 'when you get it'.
                I don't understand
                I thought that the uCam was continuously taking images and when requested it send the next available image. Is this not true? If this is true at what rate is this for the given criteria?
                Or to put it another way, I'm getting around 3fps out of the module, is there any way I can get a higher frame rate?
                Thanks for your help.Martin

                Comment


                • #9


                  I have done some testing under windows using the 'high performance timer' and the actual frame transfers about 10% slower than the baud rate, which is probably due to 'windows overheads'.

                  The extra delay that you are observing is in the response to 'GET_PICTURE' command. This seems to take roughly the same amount of time for any RAW image (didn't test for jpeg).

                  So the only way to get a higher datarate is to lower the resolution, or the color depth.
                  Mark

                  Comment


                  • #10


                    Hello,

                    Is there anybody still listening on this post?
                    I'm trying to find out why the uCAM stars to stream image data only about 80-200ms after the GET_PICTURE request, This gives me approximately 5FPS...
                    I use the uCAM-TTL.
                    I'm using RAW_80_60 8bit Gray Scale mode UART Baud Rate 1,228,800.

                    The sequence is:

                    Sync
                    Initial
                    For
                    {
                    Request Picture
                    Wait for data
                    Send Ack
                    }
                    End

                    Can anyone help speed things up
                    Thanks

                    Comment


                    • #11


                      Sorry, it's only a tiny camera, it takes time to do things, you can try different modes, but I think they will all take about the same time.
                      Mark

                      Comment

                      Working...
                      X