SPI: problems communicating with sensor

I have a sensor which I am trying to communicate with over SPI using an Arduino UNO. It is my first time using SPI and I’m experiencing some problems which I’m hoping are just due to some misunderstanding on my part. I have written a simple code to perform one basic operation: turn on the sensor’s fan. The Arduino is being powered through the 2.1mm barrel jack by a 1.5A DC adapter. The 5V, GND, MOSI, MISO, SS and SCK pins on the Ardunio are connected to the corresponding pins on the sensor. The sensor receives power from the Arduino, drawing up to 250mA (with the fan on).

The manufacturer provides a list of commands corresponding to each function of the sensor. To turn on the fan, the command list gives the following information:

Command byte: 0x03
Bytes: 0x03, 0x00
Bytes in: 0xF3, 0x03
Time between current and next byte: 1.7ms, NA
Note: 1ms would be adequate delay between command byte and following byte

Based on my understanding of this, to turn on the fan, I need to send a command byte (0x03), then wait 1.7ms and send another byte (0x00). My code for doing this is as follows:

#include <SPI.h>
const int chipSelectPin = 10;

void setup() {

Serial.begin(9600);

SPI.begin();
pinMode(chipSelectPin, OUTPUT);
SPI.setClockDivider(SPI_CLOCK_DIV32); //set clock to 500kHz
SPI.setDataMode(SPI_MODE1);
SPI.setBitOrder(MSBFIRST);
delay(10000); // Let the sensor settle for 10 seconds

digitalWrite(chipSelectPin, LOW);
indata = SPI.transfer(0x03); //command byte for fan on
Serial.println(indata);// value returned should be 0xF3
delay(2);
indata = SPI.transfer(0x00); //Turn on fan
digitalWrite(chipSelectPin, HIGH);
Serial.println(indata);// value returned should be 0x03

}

void loop() {

}

When I send the command byte, the returned value (which gets printed to the terminal) is 243 which corresponds to the expected Hex value of 0xF3. However, the following command does not turn on the fan and the second returned value is 231 which does not correspond to the expected Hex value of 0x03.

I don’t think it’s a hardware issue because at least one of the returned values is correct and because the sensor does work when used with a different platform. I also experimented with different delays between bytes. If anyone has any insights I’d really appreciate the help.

I actually just realised that although the sensor needs 5V power, it uses 3.3V logic whereas the Arduino uses 5V logic. I also have an Intel Galileo which can be configured to use 3.3V logic so I think I'll try that.