No announcement yet.

FPGA uCAM communication

  • Filter
  • Time
  • Show
Clear All
new posts

  • FPGA uCAM communication


    anyone attempted to use a FPGA development board to grab frames from the uCAM?
    I'm having troubles getting the uCAM to acknowledge the commands sent to it from the FPGA.
    I know thats the board is transmitting the correct commans in hex because I've tested it by connecting it to the computer and used Matlab to act as the uCAM.

    The development board I am using is the "LiveDesign Evaluation Board" with the Spartan 3 XC3S1000-4FG456 chip.

    So what I've been trying to do is actually sync the camera with AA 0E 00 00 00 00h.
    Either the uCAM doesn't recognise the command or the board is transmitting gibberish which should'nt be the the case because I've used Matlab to obtain an image.

    Anyone know if its a serial communications protocol problem? or if its uCAM problem?


  • #2

    In order to initialize the cam, you must send the SYNC sequence
    0xAA, 0x0D, 0x00, 0x00, 0x00, 0x00
    up to 60 times. Once the cam is initialized, you will receive the sync ack
    0xAA, 0x0E, 0x0D, 0x00, 0x00, 0x00

    here is part of a 4DGL code example that may help.

    byte sync 0xAA, 0x0D, 0x00, 0x00, 0x00, 0x00
    byte ack 0xAA, 0x0E, 0x0D, 0x00, 0x00, 0x00

    func main()
    var retry;
    retry := 60;
    if (command(sync, ack, 3)) break; // send sync, expect ack, timeout = 3 msec
    // cam is now initialized if retry is non zero

    Notice with all the cam commands, the ACK packet returned has 0Eh as the second byte, and the second byte that was sent becomes the third byte received. This makes it fairly easy to re-organize the packet sent into a template for the expected ACK.
    Here is some other useful commands and the expected ACK' s

    byte take_snap 0xAA, 0x05, 0x01, 0x00, 0x00, 0x00 // uncompressed snapshot
    byte take_snap_ack 0xAA, 0x0E, 0x05, 0x00, 0x00, 0x00

    byte get_pic 0xAA, 0x04, 0x01, 0x00, 0x00, 0x00 // Snapshot pic
    byte get_pic_ack 0xAA, 0x0E, 0x04, 0x00, 0x00, 0x00

    byte sync 0xAA, 0x0D, 0x00, 0x00, 0x00, 0x00
    byte ack 0xAA, 0x0E, 0x0D, 0x00, 0x00, 0x00

    //Baud rate = 14.7456MHz / 2 x (2nd Divider + 1) / 2 x (1st Divider + 1)
    byte set614kb 0xAA, 0x07, 0x02, 0x01, 0x00, 0x00
    byte set115kb 0xAA, 0x07, 0x0F, 0x01, 0x00, 0x00
    byte get_baud_ack 0xAA, 0x0E, 0x07, 0x00, 0x00, 0x00

    // init for different sizes
    word displayMode init80x60,init128x96,init128x128,init160x120
    byte init80x60 0xAA, 0x01, 0x00, 0x06, 0x01, 0x00, 80, 60 // 16 bit raw, 80x60
    byte init128x96 0xAA, 0x01, 0x00, 0x06, 0x0B, 0x00, 128, 96 // 16 bit raw, 128x96
    byte init128x128 0xAA, 0x01, 0x00, 0x06, 0x09, 0x00, 128, 128 // 16 bit raw, 128x128
    byte init160x120 0xAA, 0x01, 0x00, 0x06, 0x03, 0x00, 160, 120 // 16 bit raw, 160x120
    byte init_ack 0xAA, 0x0E, 0x01, 0x00, 0x00, 0x00


    • #3

      Thanks for the quick response.

      Yeah I've done pretty much the same thing. In Matlab it occasionally takes 2~3 Minz to pick it up and sync but at least once it is in sync i can communicate with it.

      In my code for the FPGA, I've also pretty much done the same thing as well. But no matter how long I left it to keep trying, the uCAM never picks up on the sync command from the board. I'm certain that the command the board is sending to uCAM is correct, uCAM seems like it just ignores the repeated messages.

      I've even double checked that the board's transmission to the camera had the correct voltages.

      Any other suggested problems are welcome. There maybe things that I have overlooked.

      Thanks heaps.


      • #4

        unless its a typo, you were saying that you were trying to sync with the sequence "AA 0E 00 00 00 00" - this may be an oversight, or it could be your problem ??


        • #5

          The uCam generaly responds to Sync on the first go after a power up.

          If you have previously communicated with it and have 'abandoned' it in the middle of a command or command sequence, it can be very difficult to get it to respond to Sync. In this situation a 'Full' Reset will often get you control back, but not always.


          • #6

            I double check with the guide before I send the command.

            I've tried turning off the camera then powering it up again. I'm pretty sure I've also tried the full reset but I'll try that again through Matlab. Once its full reset, I'll reconnect it to the board and attampt to sync it again.

            I know there area people trying to use the camera while programming PICs, but I haven't come across a user with this problem where the camera is ignoring the board/pic.