Announcement

Collapse
No announcement yet.

uCAM-III JPG does not display, data seems correct?

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

  • pauleilio
    replied
    Hello,

    Thank you for sharing your solution.

    Best regards

    Paul

    Leave a comment:


  • NVergunst
    replied
    Originally posted by NVergunst View Post
    Is there a trick to getting another picture after the first? Using the snapshot mode, is that a once and only once forever? Do I have to tell it to reset? Or can I just ask for another snapshot? Right now the first one works perfectly, but the second image, I get no response back...
    To answer my own question the problem comes from not sending the last ACK package with the package ID of 0xF0F0. I did not read this as being required. I read it as that was the largest packet so after reading n packets, you were good to go. If you do not send what I am calling the "final packet ack", the camera is essentially a state of uselessness. Any command you send will get no response. The camera will be "frozen" and there is no recovery other than pull the power. This seems like a pretty major design flaw. To me, if a user explicitly sends another command to start a new capture, it is obvious that you can blow away the buffer and respond to the command given. Doesn't matter if the user has only read 1 packet from the buffer, a new capture should over-write...

    This seems to have solved the problem. To me at least, the datasheet was not very clear about that. I only realized it by looking at the flow-charts and noticed it and the end of each of the sequences with the same discrete value instead of a variable value indicating N-length.

    Leave a comment:


  • NVergunst
    replied
    Is there a trick to getting another picture after the first? Using the snapshot mode, is that a once and only once forever? Do I have to tell it to reset? Or can I just ask for another snapshot? Right now the first one works perfectly, but the second image, I get no response back...

    Leave a comment:


  • pauleilio
    replied
    Hello,

    Glad you manged to alter the file to get a image to display.

    We noticed that your first screenshots have lots of unexpected ? marks, this seems to indicate that whatever it is that is writing to the file is trying to ensure the file contains what it considers to be valid characters.

    Paul

    Leave a comment:


  • NVergunst
    replied
    It appears that the RAM->PC through debugger flipped a few bits which is disturbing in its own right... Exporting it from the RAM throguh the debugger as a much larger ASCII based text file then stripping away the extra and pasting into a hex editor, resulted in a real image. A terrible image, but an image.
    Attached Files

    Leave a comment:


  • NVergunst
    replied
    Here is the jpg image wrapped in a zip file. I can't seem to upload it otherwise.
    Attached Files

    Leave a comment:


  • NVergunst
    started a topic uCAM-III JPG does not display, data seems correct?

    uCAM-III JPG does not display, data seems correct?

    I have a uCAM-III that I am interfacing to. I am sending and receiving data, and it the data looks good. The problem is that it doesn't make an image that is readable in any of my software (including Adobe Photoshop and Win10 built in image viewer). When I read the data back it said the image length was 0x2E96 and that's exactly how many bytes I have. It starts with 0xFF 0xD8 0xFF 0xDB and ends with 0xFF 0xD9. That looks good to me. Looking at the bytes on an oscilloscope, in my MCU's RAM using the debugger, and on the PC using a hex editor.

    When I open it in Photoshop I get "Could not complete your request because a JPEG marker segment length is too short (the file may be truncated or incomplete". When I try to open it in the built in Windows Viewer it just says it can't open it.

    When I try to upload it here, I get told that it can't be uploaded because the file contents do not match the extension!

    Also, when I read in the data I get the proper packet ID's and even every single verify code is correct. I assemble each packet into a large array and it looks good.

    Any ideas?


    Attached Files
    Last edited by NVergunst; 5th June 2017, 05:27 PM.
Working...
X