-1

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.

migrated from electronics.stackexchange.com May 15 '15 at 5:28

This question came from our site for electronics and electrical engineering professionals, students, and enthusiasts.

  • Could you post a link to the data sheet and programming instructions for the sensor? Tha might help in finding an answer. – JRE May 13 '15 at 7:57
  • 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. – user3668294 May 13 '15 at 10:08
  • 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 – JRobert May 15 '15 at 12:52
  • Thanks for the comments. After I swithched from UNO to Galileo (with the logic level set to 3.3V) it worked fine! – user3668294 May 20 '15 at 13:50
  • @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. – Chris Stratton Jun 14 '15 at 14:59
0

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

Similar issue has been discussed here.

  • 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. – user3668294 May 20 '15 at 13:52
  • Great, I am happy you have solved the issue. – Michal Foksa May 20 '15 at 14:21
  • 1
    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. – Chris Stratton Jun 14 '15 at 15:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.