SPI: problems communicating with sensor using Arduino

Question

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.1 mm barrel jack by a 1.5 A DC adapter. The 5V, GND, MOSI, MISO, SS and SCK pins on the Arduino are connected to the corresponding pins on the sensor. The sensor receives power from the Arduino, drawing up to 250 mA (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.7 ms 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 second 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.

• JRE: Could you post a link to the data sheet and programming instructions for the sensor? Tha might help in finding an answer.
• user3668294: 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.
• JRobert: May or may not be related but the current draw is out of spec for the chip. From the Atmega 328p datasheet: DC Current per I/O Pin...40.0 mA and DC Current VCC and GND Pins...200.0mA
• user3668294: Thanks for the comments. After I swithched from UNO to Galileo (with the logic level set to 3.3V) it worked fine!
• Chris Stratton: @JRobert - the current specification you site is for the ATmega I/O pins, but the device should be drawing power from the Arduino's regulator, not the ATmega.

Answer 1

Change your chipSelectPin. Pin 10 is exclusively used by SPI library. See Arduino Uno description.

Similar issue has been discussed here.

• user3668294: Thanks for the comment. After I swithched from UNO to Galileo (with the logic level set to 3.3V) it worked fine! I kept the chip select pin as 10 and it wasn't a problem.
• Michal Foksa: Great, I am happy you have solved the issue.
• Chris Stratton: You are substantially mis-stating the issue. First, the posted code is already using pin 10 as the slave select, which is the "default" implied by the hardware. The issues is rather than if pin 10 is being used for a different purpose and as a result is configured as an input then the ATmega SPI engine may operate in slave rather than master mode. It is entirely appropriate to use pin 10 as the slave select. It is also entirely possible to use a different pin, provided that pin 10 is still configured as an output.