No announcement yet.

Last package size bug - Fixed maybe?

  • Filter
  • Time
  • Show
Clear All
new posts

  • Last package size bug - Fixed maybe?

    Dear allI have have been working on my own hobby robot project using your uCam serial camera module (TTL). Just today I think i made a discovery that I would like to share with you, and maybe someone with better knowledge to validate. Coming from the field of business, programming isnt maybe what I do best. In your datasheet you mention on page 17 the following bug: * : Due to a bug in the uCAM firmware, if the last package is the same size as the package size, then ratherthan send an ACK a reset command should be sent with the 'Special Reset' and 'Reset State machines only'options set. Note that you may need to pause for a couple of milliseconds before sending this reset, toensure it is accepted.Isnt that a bummer? Don't worry, I might or might not have a fix for this.Lets start from the beginning.
    • It is the DATA command from camera that tells us the real imagesize we are about to receive. Bytes 3, 4 and 5.
    • By knowing the image size, we are able to calculate the amount of packages to be received, just like it is told in the datasheet: "Number of packages = Image size / (Package size – 6)"That is an easy calculation, so we store the number of packages in a variable. But this is where the issues often began. We obviously need to add one
    • to the number of packages variable, as otherwise we would totally ignore the contents of the last package.

      Usually the calculation to get the number of packages would be something like this, exampleimage size)/(packagesize-6)
    • || 2500/(100-6).
    • This would give us around 26.596
    • ... So if we prepare to receive 26
    • packages, it is not enough, so we round it up, or add one to the calculation.

      In most cases this works out beautifully, but when the last package size is exactly the same as our determined packagesize, if we try to receive that one additional package in the end, it will cause a lot of trouble.

      We can solve this by doing the following:
    • storing the number of packages to be received in a variable that is more accurate than int. For example float. (to get the x.xx
    • number of packages needed instead just x
    • packages)store also the inaccurate number of packages, rounded down, for example int 15.67 would store 15
    • compare the rounded down number to the accurate number. Foe example: int 15/15.67
    • , this would give us 0.957...
    • . Then we store that into a variable that rounds down to the closest integer. So int comparison = rounded/exact
    • .
      Do a logic test, if (comparison == 1)
    • {
    • we know that the last package happens to be the same size as our set package size, so lets deduct 1
    • from the variable storing the number of packages }
    After doing this, I have been able to take countless number of pictures with my robot without having to use the special reset. I am working with arduino microcontroller, so this might not be the solution for every individual system, but at least it worked out for me.

    Tell me what you think about this? If this really solves something, I would be more than happy. (What was the address to send the bill again? )

    Henry Verlin

  • #2

    I didn't realise sending a special reset, etc. at the appropriate time was so difficult


    • #3

      ESPsupport wrote:
      I didn't realise sending a special reset, etc. at the appropriate time was so difficult
      Well, in my opinion it is fundamentally not right to fix the symptoms when the actual cause is quite simple to fix. What I liked to point out here is that there maybe isnt any "bug" in the firmware in the first place.

      Because if you can avoid the whole issue with some change of code, the problem cant be in the gear, right? And please note that what I did there is not really difficult, I just covered it quite in depth. But thanks anyways for the support.

      //edit.. and also it does give a bit sloppy feel about a product when there is a statement in the datasheet saying that the product will fail 1% to 0.02% while doing what it is supposed to do. So not being a firmware problem would be a good thing for the product and the company behind it, right?