No announcement yet.

Warm start SYNC

  • Filter
  • Time
  • Show
Clear All
new posts

  • Warm start SYNC


    I've purchased a uCam-TTL with the intention of interfacing it to a PIC 18F part. I've read through the product specification and understand the SYNC process. I've found that from power on the SYNC process occurs as specified - great. However, whilst debugging, if I place a break point that interrupts the command ack/process, then the uCam no longer returns an ACK to the SYNC command on resetting the code. Instead it returns a NACK with the error code set to 0xF0 (Command header error). I have verified that the SYNC command IS correctly formatted (0xAA 0x0D 0x00 0x00 0x00 0x00). This happens regardless of how many SYNC commands are sent.

    The concern is that if an error occurs during transmission of a command how does the host recover communications.

    My question is how do I recover from this state? or have I missed something?

    Any advise on this would be greatly appreciated.


  • #2

    Have you tried one of the 4 different types of RESET commands?


    • #3

      Four! I had tried a reset on power up, with no success, but had missed the 0xFF parameter for Param4.

      I'm away for a few days now so will try that on my return.

      Thanks for you prompt reply.


      • #4

        Well this problem sounds like my problem. After successfully taking and retrieving one photo what, exactly, is one to do next?? The camera module does not respond to further SYNCS, ACKS, INITS or seemingly anything else. I see a lot of NACK's with an 'F0' (command header) error, but nothing seems to get the module out of it's funk. The suggestion to 'try one of the four resets' is not a specific suggestion since only two reset types are mentioned in the documentation, and what are the others anyway and what is going to work?


        • #5

          Reset has 2 options for parameter 1 and 2 options for parameter 4, hence 4 reset types


          • #6

            Thank you for your prompt reply, but I don't agree with it! There are two kinds of reset which are referenced but not explained in any kind of detail to know when you might use one or the other - one is a H/W reset and one is a 'firmware' reset as determined by byte three in the command. Most likely, the firmware reset is just a subset of the hardware reset anyway. According to the data sheet, byte six of the command only determines if the module responds 'immediately' or not (whatever that means). This makes for a most two types of reset, both unexplained, with the option to make each one either 'immediate' or 'slow?', whatever that means. How do you get to four reset types? The big question is why is 'reset' an option for anything after I already have taken a picture and successfully transferred the packages out? I just want to take another picture and having to use a reset appears to me to be a hack. I need information beyond what I can read in the data sheet!