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

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:

rawvals[0] = (int16_t)((uint16_t)(rawdata[0]) <<8 | (uint16_t)(rawdata[1])); 
posted by Dave Turner 01 Mar 2015

Use <<code>> and <</code>> on seperate lines, now it isn't readable.

posted by Erik - 01 Mar 2015

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

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

Accepted Answer

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 randy pence 07 Mar 2015