Effect of changing update rate when using SPI + code for how to do it?

[18wi...@abschools.org]

For streaming buses (USB, Serial) the update rate affects how rapidly new data is sent out. What effect does changing the update rate to 200 Hz have for the SPI bus? Will data be available at a higher frequency for it (poll at 200 Hz and new data is available every time, instead of only every 4th time)?

Also, what code should we use for an Arduino to change the update rate to 200 Hz? Based off of what is in Github for the Arduino in navxTestJig, here is what I have written:

void change_update_rate_200hz(void)
	{
	uint8_t spi_data[3];
	/* Transmit SPI data */
	spi_data[0] = 0x80 | NAVX_REG_UPDATE_RATE_HZ; // Starting Register Address + Write Request
	spi_data[1] = 200;
	spi_data[2] = IMURegisters::getCRC(spi_data,2);
	digitalWriteFast(SS, LOW);
	for ( int i = 0; i < 3; i++ ) {
	SPI.transfer(spi_data[i]);
	}
	digitalWriteFast(SS, HIGH);
	}

However, I don't know how to check if I actually managed to change the update rate, so I can't validate my code. Does it look right?

Thanks for the great support!

[admin]

> What effect does changing the update rate to 200 Hz have for the SPI bus? Will data be available at a higher frequency for it (poll at 200 Hz and new data is available every time, instead of only every 4th time)?

Yes, over SPI (and I2C) changing the update rate means that you can read (over SPI, or I2C) the current sensor data at a rate of 200Hz and as long as you wait 5ms between samples, each time you will get a new result

There are two ways to verify 200Hz (or any other update rate) communication:

1) Read back the current update rate configuration:

0x04

Update Rate

Read/write

Unsigned byte (Hz)

2) Retrieve the current update timestamp, and verify the period between successive samples:

0x12-0x15

Current Timestamp

Read-only

Unsigned long

Note that the update rate that can actually be realized is a value evenly divisible by the navX-Model device's internal motion processor sample clock (200Hz). Avaialble values include 200, 100, 66, 50 and 40.  Therefore, the rate that is achieved may be different than the requested sample rate - depending upon what is requested. The achieved sample rate is rounded to the nearest integer that is divisible by the number of Digital Motion Processor clock ticks. For instance, a request for 58 Hertz will result in an actual rate of 66Hz (200 / (200 / 58), using integer math.

- scott

P.S.  If you are reading data from the navX-MXP over the SPI interface, note that the navX-MXP firmware takes a little while after it receives the initial write request to respond with a read response.  That's why at line 100 in the navXTestJig.ino file there is this code:

delayMicroseconds(200); // Read 0xFFs until ready

This delay is only necessary when reading data - when writing commands that don't wait for a response (like changing the update rate) the delay is not necessary.

[18wi...@abschools.org]

Yes, that code works. I tested by printing values at 200Hz while wiggling the sensor.