<< return to Pixycam.com

Keep Getting Sync Word (0xaa55) After Detecting Object

Pixy Software
#1

Update: Just confirmed this behavior with the PixySPI_SS arduino library with Pixy set to SPI with SS mode so am pretty sure it’s a Pixy firmware problem. Unless my brand new Pixy is a bad unit.

Hi all, can’t seem to figure out what’s causing this problem but I am using SPI with slave select (on a PSoC 4 microcontroller) and it seems that I am able to read the correct data whenever an object is detected (0xaa55,0xaa55, then 6 16 bit words). However, when the object is no longer in view and not detected, I am getting 0xaa55 continuously instead of 0x0000. If I restart the Pixy, I do get 0x0000 but after it detects an object once it continuously sends 0xaa55 even when the object is no longer in view. I am getting the correct behavior with the Arduino ICSP SPI mode (0x0000 when no object is in view). I have attempted to solve the problem by updating to the latest firmware to no avail. This is my code for getWord().

int16 getWord() {
    uint16 word;
    uint8 lsb;

    ss_Write(0u);                              //Set ss low to start SPI
    PixyCom_WriteTxData(PIXY_SYNC_BYTE);       //Write sync byte to Pixy via SPI
 
    while (PixyCom_GetRxBufferSize() == 0) {
        //Do nothing until we hear back from Pixy 
    }
    word = PixyCom_ReadRxData();               //Get the MSB 
    word <<= 8;
    
    //Do the same thing again for the LSB
    PixyCom_WriteTxData(0x00);                 //Send dummy data
    while (PixyCom_GetRxBufferSize()<1) {
    } 
    lsb = PixyCom_ReadRxData();
    word |= lsb;

    ss_Write(1u);                              //Turn slave select back on high 
    return word;
}
#2

Hello Alex,
You might try writing only 0’s to Pixy if you aren’t sending any commands to it. The code above sends a PIXY_SYNC_BYTE and a 0, which might be causing issues, although I’m not sure if that’s the issue. Try replacing the line:

PixyCom_WriteTxData(PIXY_SYNC_BYTE);

with

PixyCom_WriteTxData(0);

Edward

#3

Hi Edward, I tried it but got the same results.

Also, the implementation for getWord() in the PixySPI_SS arduino library seems to do as you suggested after the else statement:

    
    uint16_t getWord()
    {   
      // ordering is different because Pixy is sending 16 bits through SPI 
      // instead of 2 bytes in a 16-bit word as with I2C
      uint16_t w;
      uint8_t c, cout = 0;
       
      // assert slave select
      digitalWrite(ssPin, LOW);

      if (outLen)
      {   
        w = SPI.transfer(PIXY_SYNC_BYTE_DATA);
        cout = outBuf[outIndex++];
        if (outIndex==outLen)
          outLen = 0;  
      }   
      else
        w = SPI.transfer(0);

      w <<= 8;
      c = SPI.transfer(cout);
      w |= c;

      // negate slave select
      digitalWrite(ssPin, HIGH);
      return w;
    }

and it also has given me the same problem.

Could it possibly be a problem with the Pixy itself?

#4

Hello Alex,
Let me see if I understand correctly. You tested with an Arduino and it was fine with Arduino ICSP SPI, but with SPI with SS communication mode, it exhibits the problem. Is that correct?

Edward

#5

Correct.

#6

Hi Alex,
Thanks for the the clarification. I think we’ve found something. Can you give the attached firmware a try, let us know if it fixes the issue?

thanks :slight_smile:

Edward

#7

I tested the new firmware and it appears to be free from the bug. I confirmed with the same setup that the problem still existed with an earlier firmware version (2.0.17) so it is indeed the new firmware that fixed the bug. Great work, thanks guys.

#8

Hi Alex,
Glad to hear-- thanks!

Edward