Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
9 years, 8 months ago.
Does mbed.h work correctly with i2c and ble nano? (with code and debugging text)
Hey all, I'm not sure if I have defective sensor, processor, or code. I have a ble nano and adafruit flora compass (lsm303dlh) connected together and am trying to test the sensor data.
running this code:
//LSM303DLHTest/main.cpp #include "mbed.h" #include "LSM303DLH.h" Serial debug(USBTX,USBRX); LSM303DLH compass(p6, p7); int main() { compass.frequency(100000); // set required i2c frequency float hdg; float hdgV; vector acc; vector mag; //debug.format(8,Serial::None,1); debug.baud(115200); debug.printf("LSM303DLH Test\x0d\x0a"); compass.setOffset(0.00,0.00,0.00); // example calibration compass.setScale(1.00,1.00,1.00); // example calibration while(1) { compass.read(acc,mag); hdg = compass.heading(); hdgV = atan2(acc.y,acc.z) * 180/M_PI; debug.printf("ACC: %6.2f %6.2f %6.2f Heading: %6.2f %6.2f\n",acc.x,acc.y,acc.z,hdgV,hdg); wait(0.001); } }
I get these results:
Quote:
ACC: 16304.00 -27225.00 -3759.00 Heading: -97.86 90.00
ACC: 16304.00 -27225.00 -11184.00 Heading: -112.33 90.00
ACC: 16304.00 -27225.00 -18602.00 Heading: -124.34 90.00
ACC: 16304.00 -27225.00 -26019.00 Heading: -133.70 90.00
ACC: 16304.00 -27225.00 32098.00 Heading: -40.30 90.00
It doesn't matter if I move the sensor or let it be, acc.x, acc.y, and hdg do not change while acc.z and hdgV are random.
In case the sensor was defective, i tried this:
//i2ctest/main.cpp #include "mbed.h" Serial pc(USBTX, USBRX); I2C i2c(P0_6, P0_7); // I2C device sda, scl int main() { i2c.frequency(100000); // set required i2c frequency - frequency value following Dave's response pc.baud(115200); pc.printf("I2C Searching!\n\n"); pc.printf("Starting....\n\n"); while (1) { int count = 0; for (int address=0; address<256; address+=2) { if (!i2c.write(address, NULL, 0)) { // 0 returned is ok pc.printf("I2C address 0x%02X\n", address); count++; } } pc.printf("%d devices found\n\n\n", count); wait(.1); } }
which found the sensor device addresses, but all sorts of other, and to doublecheck, i desoldered the wires to the sensor from the ble nano headers and got the same results!
any idea? thx
edit: fixed code formatting
1 Answer
9 years, 8 months ago.
Hi Randy,
Not used this device but have used i2c.
i2c Test you can actually try any frequency from 10KHz to 400KHz yes 10 not 100! I tried this on an old scope and tested the sclk and sure enough you can, but best to keep to 100 or 400 depending on device specs etc.,
I would put a small delay within the iterant loop (for loop) just to give your devices chance to respond say wait(0.1);
For your particular device a finite time is required to aquire data and place into the registers you wish to read. There is a status register you may wish to read before you actually read Data (Status_Reg 0x27). Bits 7,6,5,4 give an indication when the data is ready. This may account for your 'apparent' random, changing readings.
Best Regards
Martin
Hey Martin, thx. I've attempted to add a delay in several places, but am getting the same results. In case the issue is truly my sensor and not the code, I found someone with the same ble nano but using a different i2c sensor, and he reported the same lack of devices found. I am still waiting on whether adding delay changed anything for him.
What might be the odds that my ble nano board is damaged? Something that puzzles me is that the simplest example using the library for my sensor would not act as anticipated.
posted by 07 Mar 2015
Shouldn't I2C frequency be either 100000 or 400000? I've not used the LSM303DLH library having rolled my own code, but it may well be the conversion from the two acquired bytes into a signed 16-bit number - it made me ponder for quite a while.
I found this worked with those pesky conversions:
Use
posted by Erik - 01 Mar 2015<<code>> and <</code>>
on seperate lines, now it isn't readable.Ah, good eye, Dave! I corrected the code and added a similar line to the first code example. The lsm303dlhtest unfortunately repeats the same data. The i2ctest now roughly alternates between finding no devices, or 1 or 2 random devices in 60 or so cycles so far. Unfortunately, the compass device addresses are not discovered
posted by randy pence 02 Mar 2015