Announcement

Collapse
No announcement yet.

YASP (Yet another sync problem)

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

  • YASP (Yet another sync problem)

    I am using the uCAM II with a Digilent MAX32 board running their "Arduino-ish" bootloader and the UECIDE IDE's "WIRED" compiler. I am communicating at 921600, the max auto detect speed.
    I have my own code running fine with this camera, BUT the camera will only sync if it is just powered up. If I reset the program to run from the start, I'll go the full 60 sync attempts and fail to sync.
    For a while I could sync the first time, but the second time I would run the code (without a power cycle) I would get a NAK instead of an ACK on the sync attempts. Now it simply won't sync unless it is the first thing that happens after the camera is powered on. I am following the exact sync sequence that is in the documentation, right down to waiting 5ms for the first retry and adding 1ms for each retry after that. It isn't clear to me if there are desired delays between commands that should be honored, or what kind of inter-byte delays there might be that I may be violating.

    I am scratching my head on this, where would one look for the source of this problem? I have tried this at 460800 bps and even at 57600, it acts the same.

    regards,
    DLC

  • #2
    Can you reproduce this with the demo software? (maybe trying that will help you understand what is different in your code)
    Mark

    Comment


    • #3
      Many pardons, what demo software? I am not using a 4D display nor the Visi IDE environment.

      DLC

      Comment


      • #4
        If you download Workshop you will find the demo software runs when you start a new project with the uCAM-II. This is described on page 21 of the datasheet.

        Once installed you might like to create a shortcut to C:\Program Files (x86)\4D Labs\4D Workshop 4 IDE\DEP\uCamIIDemo.exe
        Mark

        Comment


        • #5
          I'll see what I can work out. I don't develop on a Windows OS as a rule. This will at least tell me that the camera is working.
          I also noted in my code that I don't get the 0xAA sync byte back properly, I get 0x2A, which is odd.

          Thanks,
          DLC

          Comment


          • #6
            Originally posted by ESPsupport View Post
            If you download Workshop you will find the demo software runs when you start a new project with the uCAM-II. This is described on page 21 of the datasheet.

            Once installed you might like to create a shortcut to C:\Program Files (x86)\4D Labs\4D Workshop 4 IDE\DEP\uCamIIDemo.exe
            The 4D uCam-II demo works fine with the camera, it even gets decent pictures. Since my Digilent MAX32 code does not reliably sync and returns pretty poor images I am assuming that the picture data is probably corrupted. The AA header byte from the camera is always 2A with my code as well. I wonder if the PIC32 USART does not exactly sync up properly to the UART clock in the camera. I will have to experiment with tweaking that. I am running at the 921600 rate to get images faster.

            DLC

            Comment


            • #7
              Hmm, depending on the PIC and its speed you might want to check the 'actual' baud rate, it might not be 921600
              Mark

              Comment


              • #8
                Originally posted by ESPsupport View Post
                Hmm, depending on the PIC and its speed you might want to check the 'actual' baud rate, it might not be 921600
                It fails at every baud rate I select. I don't get AA back on the sync byte, I get 2A. I can't sync on a reset, I can only sync on a cold power up of the camera (not the PIC32/Picadillo board, power cycle of the camera.) I don't get what is going on. This board talks to every other logic-level async serial device I use at speeds up to 1Mbps. The uCam-II is the first device that does not cooperate. The logic level signals from the Picadillo board are 3.3V, the camera says it too wants 3.3V logic so that should all be fine.

                I need to do some more investigating, this is most perplexing.

                thanks,
                DLC
                Last edited by DLC; 15th April 2015, 01:54 PM.

                Comment


                • #9
                  Hmm,very confusing.

                  Are you saying it will sync once after power is applied, but not a second time?

                  Does this mean you can take a pic or two, provided another Sync is not required?

                  Could the camera be going to sleep? (will it sync if you try another sync within 15 seconds?)

                  Could the baud rate possibly be changing?

                  Could the camera be going to sleep and the 'wakeup' sync not quite being sent right, or the response being handle right?

                  Have you got some sort of logic analyser you can use to check the difference between the demo program and your pic? (if not what about using the programming cable to monitor what is being sent, or received with relation to the PIC?)
                  Mark

                  Comment


                  • #10
                    Originally posted by ESPsupport View Post
                    Hmm,very confusing.

                    Are you saying it will sync once after power is applied, but not a second time?

                    Does this mean you can take a pic or two, provided another Sync is not required?

                    Could the camera be going to sleep? (will it sync if you try another sync within 15 seconds?)

                    Could the baud rate possibly be changing?

                    Could the camera be going to sleep and the 'wakeup' sync not quite being sent right, or the response being handle right?

                    Have you got some sort of logic analyser you can use to check the difference between the demo program and your pic? (if not what about using the programming cable to monitor what is being sent, or received with relation to the PIC?)
                    Yes, only on power up. Did this at 57600, 115200, 921600, etc.
                    I run in "video" mode with continual "gets", it runs fine, once it is sync'd.
                    Nope, I get new frames back-to-back.
                    It seems incredibly unlikely that the baud rate would change **
                    No sleep likely.
                    I would have to "hack" a sniffer for the monitor, not sure if the 4D program will monitor without "sourcing" commands.

                    ** I have noticed that the picture quality REALLY degrades as the baud rate increases. At 921600 it is truly awful. I tried an experiment where I set the baud rate, sent a single sync, changed the baud rate to something about 2% lower and finished the sync and video "gets". The picture quality noticeably improved! Making me think that there is something wrong with the sync OR as you suggested, the baud rate on the camera changes. I don't think that the baud rate changes on the Picadillo since that is where I have to drop the bps to get good images. Even this will not sync again on a reset unless I power cycle the camera board.

                    I think that what I am seeing is line noise. I am running on about 25cm long 18 gauge wire. Not twisted pair, just wires. I would think that the lower baud rates would eventually work, but alas, no. Dropping the baud rate AFTER I send the first sync gives way better pictures, which hints that there is data corruption going on.

                    There is so much conflicting information here...

                    DLC

                    Comment


                    • #11
                      Um, if you only fetch frames in Video mode I don't understand why you would ever be doing another 'Sync'.

                      Are you, perhaps, 'aborting' your controlling program and then getting it to restart and expecting 'Sync' is all that is required? Depending on what the camera was doing at the time you pulled the controller this will not work. The safest bet is to have a FET to turn off the camera and repower it in this case.

                      For the sniffer hack use the 4D Terminal program, it won't 'decode' the information, but it will display it just fine.

                      I would think 25cm should be fine (err but at TTL levels, not RS232, see later), but it depends a lot on the noise in the surrounding environment. Try using shorter lines to see if the quality improves

                      When 'highly textured' pictures are taken the quality of the image can drop. In marginal 'highly textured' pictures we have seen the quality flip flop between images. Could this be what you are seeing?

                      Whoah, hang on, you said RS232, didn't you?

                      RS232 cannot do at 921600 over any length. Google for more information (Sorry there's quite a bit said and not all relevant to any particular situation)

                      To summarize, at (these days very) low baud rates RS232 can travel quite large distances, but at higher baud rates it deteriorates very quickly

                      Say at 9600 you can get 500 feet with a certain common type of cable, if you double the speed (to 19200) the allowable cable length is divided by 10 (to 50 feet). Keep that up to 921600 and you are down to around 1mm, so it's just not possible using RS232.

                      Mark

                      Comment


                      • #12
                        Originally posted by ESPsupport View Post
                        Um, if you only fetch frames in Video mode I don't understand why you would ever be doing another 'Sync'.

                        Are you, perhaps, 'aborting' your controlling program and then getting it to restart and expecting 'Sync' is all that is required? Depending on what the camera was doing at the time you pulled the controller this will not work. The safest bet is to have a FET to turn off the camera and repower it in this case.

                        For the sniffer hack use the 4D Terminal program, it won't 'decode' the information, but it will display it just fine.

                        I would think 25cm should be fine (err but at TTL levels, not RS232, see later), but it depends a lot on the noise in the surrounding environment. Try using shorter lines to see if the quality improves

                        When 'highly textured' pictures are taken the quality of the image can drop. In marginal 'highly textured' pictures we have seen the quality flip flop between images. Could this be what you are seeing?

                        Whoah, hang on, you said RS232, didn't you?

                        RS232 cannot do at 921600 over any length. Google for more information (Sorry there's quite a bit said and not all relevant to any particular situation)

                        To summarize, at (these days very) low baud rates RS232 can travel quite large distances, but at higher baud rates it deteriorates very quickly

                        Say at 9600 you can get 500 feet with a certain common type of cable, if you double the speed (to 19200) the allowable cable length is divided by 10 (to 50 feet). Keep that up to 921600 and you are down to around 1mm, so it's just not possible using RS232.
                        It is possible that a reset will catch the camera in a bad state WRT getting a frame. There is a "RES" pin on the header - Is this/can this be used as a reset? Adding a FET switch is a hassle for a "plug n play" part. If there were a reset...

                        No RS232, I went out of my way not to say that. Logic level async serial (will you be doing a SPI version? Way faster with bi-directional comms!)

                        I will try shorter lines since I think noise is creeping in. I think that the board reset may be an issue since streaming data is not ACK'd and can't be interrupted.

                        More as I know it.

                        DLC

                        Comment


                        • #13
                          That pin marked "RES" is NC, it's more to match our cable connections.

                          We hope to actually have it actually be reset one day, but that is for the future.

                          Our Camera was created because there were no serial RAW cameras available in the market. We also saw plenty of SPI cameras available at the point, so no, it doesn't do SPI
                          Mark

                          Comment


                          • #14
                            Originally posted by ESPsupport View Post
                            That pin marked "RES" is NC, it's more to match our cable connections.

                            We hope to actually have it actually be reset one day, but that is for the future.

                            Our Camera was created because there were no serial RAW cameras available in the market. We also saw plenty of SPI cameras available at the point, so no, it doesn't do SPI
                            It is difficult to get async serial to work at high speeds with a single ended channel, using RS485/differential is way easier. I'm finding that I don't get any speed over 230400 to work even on 10cm wiring. I'll try shielding next - Then maybe a half-duplex 485 transmission setup to get the speeds up.

                            DLC

                            Comment


                            • #15
                              I often use a 4D programming cable and that's 1m unshielded and I haven't had any issues at those speeds, so I've got to wonder if there isn't something else going on here?

                              When you did your uCAM-II demo program testing did you use a programming cable, or a PA5 (Which, or course is almost zero length)? If it was a PA5, maybe add some cable to that, just to see if that quickly introduces issues
                              Mark

                              Comment

                              Working...
                              X