9- and 10-DoF LSM9DS0 shield for Teensy 3.1

Status
Not open for further replies.
Hopefully I am making this sound harder than it really is ?

Yes, indeed.

Use putty or the serial monitor embedded in the Arduino IDE to view serial output from the sketch I wrote that you are using. Change SerialDebug to TRUE and you will get all kinds of data spewed to the Serial monitor. Serial output from the Arduino IDE is Arduino 101 and you can learn how to do it if the above is not enough by googling "Serial out in Arduino" or going to Sparkfun.com and reading their usually excellent Arduino tutorials on this (or any) subject.
 
OK. Thanks. I thought it was 101; I will read the manual on "Serial out in Arduino" to get just what I want..
 
Last edited:
Hopefully I am making this sound harder than it really is ?

Yes, indeed.

Use putty or the serial monitor embedded in the Arduino IDE to view serial output from the sketch I wrote that you are using. Change SerialDebug to TRUE and you will get all kinds of data spewed to the Serial monitor. Serial output from the Arduino IDE is Arduino 101 and you can learn how to do it if the above is not enough by googling "Serial out in Arduino" or going to Sparkfun.com and reading their usually excellent Arduino tutorials on this (or any) subject.

Just thought this sort of bare bones streaming would have already been done long ago.

If so, I don't know about it. Maybe one of the brilliant minds on this forum can better advise you.
 
Again, excellent support; the overall experience exceed my expectations. I am well ahead of plan so I don't need to dive into the raw serial streamer right away, but if I get something of general use I will post it.

One final comment for the day (PT). I am intrigued with the apparent 1784 Hz rate I am getting looping through Madgwick vs. the 145Hz rate quoted in your comments. Do I have that right? I see you have done a separate study on this topic. Any explanation?

Code:
Yaw, Pitch, Roll: -83.19, -2.60, 1.31
[COLOR="#FF0000"][B]rate = 1783.61 Hz[/B][/COLOR]
ax = 47.18 ay = 19.71 az = 978.76 mg
gx = -0.07 gy = 0.20 gz = 0.05 deg/s
mx = 425 my = 198 mz = 708 mG
q0 = -0.82 qx = 0.01 qy = 0.03 qz = 0.57
Gyro temperature is 35.5 degrees C
Digital temperature value = 30.57 C
Digital temperature value = 87.03 F
Digital pressure value = 1007.26 mbar
Altitude = 163.90 feet
Yaw, Pitch, Roll: -82.76, -2.86, 1.24
[COLOR="#FF0000"][B]rate = 1782.96 Hz[/B][/COLOR]
 
Yes, the comment is a residual of using the 8-bit, 3.3V Atmega 328P Pro Mini AVR microprocessor running at 8 MHz. For a ten dollar microprocessor it does very well. But the 32-bit Teensy 3.1 running at 24 MHz does soooo much better. Yes, I performed a reasonably detailed comparison of AVR and ARM processor sensor fusion performance with some common motion sensors and the~2KHz rate you are seeing is about what I would expect.

All Hail Teensy!
 
magnetization data issue

I just received the new micro-shield with the pressure sensor. I am having issues with the magnetization data. It is nonsense - see included output from the default sketch. I checked resistances between the shield and my Teensy3.1 for a bad solder joint and they were all low. I only measured two 4K7 resistors on the board? Also, the zero-ing of the gyroscope is incorrect about half the time - yields something like gx ~0 gy ~ -80 gz ~ -11 deg/s.

Any ideas?

Code:
LSM9DS0 WHO_AM_I's returned: 0x49D4
Should be 0x49D4
MS5637 pressure sensor reset...
PROM data read:
C0 = 13633
C1 = 41636
C2 = 44527
C3 = 24780
C4 = 26718
C5 = 29248
C6 = 26683
Checksum = 3 , should be 3
Digital temperature value = 28.79 C
Digital temperature value = 83.81 F
Digital pressure value = 985.08 mbar
Altitude = 777.84 feet
Heading: -56.69
Pitch, Roll: -0.00, 0.02
ax = -0.06 ay = 0.37 az = -1003.91 mg
gx = -0.03 gy = 0.03 gz = 0.16 deg/s
mx = -2.14 my = -1.40 mz = -1.28 mG
gyro temperature = 32.00
Yaw, Pitch, Roll: -175.79, -27.68, -122.56
q0 = 0.13 qx = 0.25 qy = -0.82 qz = 0.49
filter rate = 0.1
Digital temperature value = 28.80 C
Digital temperature value = 83.83 F
Digital pressure value = 985.08 mbar
Altitude = 777.72 feet
Heading: 10.01
Pitch, Roll: 0.04, 0.15
ax = 0.73 ay = 2.62 az = -998.11 mg
gx = 0.23 gy = 0.26 gz = -0.40 deg/s
mx = 0.18 my = -1.04 mz = -1.65 mG
gyro temperature = 31.87
Yaw, Pitch, Roll: -165.60, -18.91, -152.38
q0 = 0.10 qx = 0.27 qy = -0.92 qz = 0.27
filter rate = 1149.4
Digital temperature value = 28.80 C
Digital temperature value = 83.84 F
Digital pressure value = 985.09 mbar
Altitude = 777.63 feet
Heading: 54.46
Pitch, Roll: 0.07, 0.00
ax = 1.22 ay = 0.00 az = -995.54 mg
gx = 0.28 gy = 0.10 gz = 0.01 deg/s
mx = 0.61 my = 0.85 mz = -10.19 mG
gyro temperature = 32.00
Yaw, Pitch, Roll: -160.76, -2.19, -168.52
q0 = -0.01 qx = 0.28 qy = -0.95 qz = 0.10
filter rate = 1148.8
Digital temperature value = 28.81 C
Digital temperature value = 83.86 F
Digital pressure value = 985.09 mbar
Altitude = 777.43 feet
Heading: 21.80
Pitch, Roll: 0.11, 0.12
ax = 1.95 ay = 2.08 az = -999.88 mg
gx = 0.65 gy = 0.00 gz = -0.32 deg/s
mx = 0.24 my = -0.61 mz = 0.43 mG
gyro temperature = 32.13
Yaw, Pitch, Roll: -158.10, 1.70, -176.81
q0 = -0.02 qx = 0.31 qy = -0.95 qz = 0.02
filter rate = 1149.8
Digital temperature value = 28.81 C
Digital temperature value = 83.86 F
Digital pressure value = 985.08 mbar
Altitude = 777.77 feet
Heading: 4.40
Pitch, Roll: -0.01, 0.08
ax = -0.18 ay = 1.46 az = -1006.29 mg
gx = 0.13 gy = -0.31 gz = 0.07 deg/s
mx = 0.12 my = -1.59 mz = 1.22 mG
gyro temperature = 32.00
Yaw, Pitch, Roll: -154.36, 2.90, -179.90
q0 = -0.02 qx = 0.34 qy = -0.94 qz = -0.01
filter rate = 1149.7
Digital temperature value = 28.81 C
Digital temperature value = 83.87 F
Digital pressure value = 985.10 mbar
Altitude = 777.28 feet
Heading: -88.62
Pitch, Roll: -0.03, 0.08
ax = -0.61 ay = 1.34 az = -1001.10 mg
gx = -0.21 gy = -0.29 gz = 0.19 deg/s
mx = -5.07 my = -0.12 mz = 1.83 mG
gyro temperature = 32.00
Yaw, Pitch, Roll: -162.74, 0.62, 175.65
q0 = 0.00 qx = 0.27 qy = -0.96 qz = -0.04
filter rate = 1150.2
Digital temperature value = 28.82 C
Digital temperature value = 83.87 F
Digital pressure value = 985.07 mbar
Altitude = 778.08 feet
Heading: 12.72
Pitch, Roll: -0.23, 0.01
ax = -4.03 ay = 0.12 az = -996.03 mg
gx = -0.01 gy = -0.15 gz = 0.07 deg/s
mx = 0.43 my = -1.89 mz = 1.16 mG
gyro temperature = 32.00
Yaw, Pitch, Roll: -165.68, -0.02, 178.89
q0 = 0.00 qx = 0.24 qy = -0.97 qz = -0.01
filter rate = 1149.5
Digital temperature value = 28.82 C
Digital temperature value = 83.88 F
Digital pressure value = 985.09 mbar
Altitude = 777.51 feet
Heading: 60.42
Pitch, Roll: -0.11, 0.11
ax = -1.83 ay = 1.95 az = -998.11 mg
gx = -0.22 gy = 0.17 gz = 0.08 deg/s
mx = 2.26 my = -1.28 mz = -0.43 mG
 
The output of the gyro above looks fine but I agree the mag data is wrong. I'm sure I checked this board before I sent it out and it was working; but I have seen this kind of presumable malfunction before and I don't know if the mag is broke, shorted, or what. I am happy to refund your money, just send me an email at the Tindie site with your paypal account.
 
Has anyone seen this time waster? I am new to Arduino so likely missing something simple.

I could report on my magnetometer too but I now can't run my MPU9250 Mini Shield; I noted the gyro and accel worked well on my Win7 laptop installation. I had to re-install everything on my XP Notebook while the laptop is being repaired and I get this missing 'Wire" response when I try to compile your example sketch or more simply when I try to compile the i2C_t3/master example from i2c_t3_lib_and_sketch_v6b.zip:

Code:
C:\Program Files\Arduino\hardware\tools\avr\bin\avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=106 -IC:\Program Files\Arduino\hardware\arduino\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\variants\standard -IC:\Documents and Settings\david\My Documents\Arduino\libraries\i2c_t3 -IC:\Documents and Settings\david\My Documents\Arduino\libraries\rbuf C:\DOCUME~1\david\LOCALS~1\Temp\build786119403555596298.tmp\master.cpp -o C:\DOCUME~1\david\LOCALS~1\Temp\build786119403555596298.tmp\master.cpp.o 
master.ino: In function 'void setup()':
master:69: error: 'Wire' was not declared in this scope
master:69: error: 'I2C_MASTER' was not declared in this scope
master:69: error: 'I2C_PINS_18_19' was not declared in this scope
master:69: error: 'I2C_PULLUP_EXT' was not declared in this scope
master:69: error: 'I2C_RATE_400' was not declared in this scope
master.ino: In function 'void loop()':
master:105: error: 'Wire' was not declared in this scope
master:116: error: 'I2C_DEBUG_WAIT' was not declared in this scope
master:124: error: 'Wire' was not declared in this scope
master:128: error: 'I2C_NOSTOP' was not declared in this scope
master:129: error: 'I2C_STOP' was not declared in this scope
master:132: error: 'I2C_DEBUG_WAIT' was not declared in this scope
master:164: error: 'Wire' was not declared in this scope
master:175: error: 'I2C_STOP' was not declared in this scope
master:178: error: 'I2C_DEBUG_WAIT' was not declared in this scope
master:186: error: 'Wire' was not declared in this scope
master:190: error: 'I2C_NOSTOP' was not declared in this scope
master:191: error: 'I2C_STOP' was not declared in this scope
master:194: error: 'I2C_DEBUG_WAIT' was not declared in this scope
master:223: error: 'Wire' was not declared in this scope
master:234: error: 'I2C_STOP' was not declared in this scope
master:242: error: 'I2C_DEBUG_WAIT' was not declared in this scope
master:251: error: 'I2C_NOSTOP' was not declared in this scope
master:285: error: 'Wire' was not declared in this scope
master:290: error: 'I2C_NOSTOP' was not declared in this scope
master:331: error: 'I2C_STOP' was not declared in this scope
master.ino: In function 'void print_i2c_status()':
master:364: error: 'I2C_DEBUG_WAIT' was not declared in this scope
master:365: error: 'Wire' was not declared in this scope
master:367: error: 'I2C_WAITING' was not declared in this scope
master:368: error: 'I2C_ADDR_NAK' was not declared in this scope
master:369: error: 'I2C_DATA_NAK' was not declared in this scope
master:370: error: 'I2C_ARB_LOST' was not declared in this scope
 
Last edited:
Board: "Arduino Uno"

If you are using the mini board on a Teensy 3.1 you need to change this.

-mmcu=atmega328p

Looks like you have set the board to Arduino Uno yet the i2c_t3.h library that my sketch uses is a Teensy 3.1 only library. Switch to Wire.h and it should work with minor tweaks on an AVR processor.
 
Last edited:
So now up winXP thanks, and the MPU9250 Mini Shield looks reasonable so far vs. the jwrski15's LSM95DS0. (likely a defective STM chip?) For comparison here is some data with the Shield pointing more or less South (Yaw ~+/-180 deg) and the Cortex M4 pointing down.
Code:
ax = 2.87 ay = -160.10 az = -1006.84 mg
gx = -0.63 gy = 0.48 gz = 0.05 deg/s
mx = 402 my = -193 mz = -66 mG
q0 = 0.04 qx = -0.53 qy = -0.84 qz = 0.06
Gyro temperature is 35.4 degrees C
Digital temperature value = 30.54 C
Digital temperature value = 86.97 F
Digital pressure value = 1008.53 mbar
Altitude = 129.20 feet
Yaw, Pitch, Roll: 101.60, -0.22, -171.14
rate = 1771.63 Hz
ax = 1.89 ay = -159.24 az = -1004.58 mg
gx = -0.70 gy = 0.53 gz = -0.02 deg/s
mx = 407 my = -204 mz = -70 mG
q0 = 0.04 qx = -0.53 qy = -0.84 qz = 0.06
Gyro temperature is 35.4 degrees C
Digital temperature value = 30.54 C
Digital temperature value = 86.97 F
Digital pressure value = 1008.57 mbar
Altitude = 127.99 feet
Yaw, Pitch, Roll: 101.74, -0.22, -171.14
rate = 1771.93 Hz
ax = 2.75 ay = -160.46 az = -1009.22 mg
gx = -0.63 gy = 0.47 gz = -0.09 deg/s
mx = 417 my = -199 mz = -63 mG
q0 = 0.04 qx = -0.53 qy = -0.84 qz = 0.06
Gyro temperature is 35.4 degrees C
Digital temperature value = 30.53 C
Digital temperature value = 86.96 F
Digital pressure value = 1008.57 mbar
Altitude = 128.05 feet
Yaw, Pitch, Roll: 101.69, -0.23, -171.14
rate = 1772.98 Hz

Two comments:

1) The magnetometer biases look to be stable, but uncalibrated; derived Yaw is close enough. Nothing remarkable hear.

2) The loop and AHRS filter rate of 1773 Hz is a little curious since the actual MPU9250 sample and hence data-ready interrupt rate is 200Hz. (Confirmed by scope measurement as well as code review.) While the on-chip analog bandwidth is ~250Hz, a higher sample rate should yield better dynamic accuracy for the AHRS filter or any other inertial integration algorithm. Also without an interrupt drive loop some samples could be missed, I think. I will have more to comment when I get further into this.

In summary, the MPU9150 Mini Shield/Teens3.1 worked "out of the box" for me, is conveniently "cross-platform" and has lots of application potential.
 
data-ready interrupt rate is 200Hz

Yes, but the sensor fusion algorithm iterates between new sample data ready events. So it seems to iterate 8 or nine times between data samples. You're right, this is too much, three or four is sufficient. That means you could up the sample data ODR to 1000 Hz or slow the ARM processor speed to 24 MHz or some combination.

Right now, I don't trust the LSM9DS0 mag. I am in conversation with ST about its relatively sudden misbehavior; after using the chip for months without a problem lately most of the assembled boards have a misbehaving mag. I am hoping it is something to do with a change in software, but some of them behave as they should so this problem is perplexing. Unlike the LSM9DS0, I have never had any issue with the MPU9250. In my view, the MPU9250 is the simpler, most sophisticated, and most rugged of the 9-axis integrated motion sensors. The BMX-055 might also be in the running but does anyone know how to convert the magnetic raw data into sensible magnetic fields? Bosch has not been helpful here despite my frequent attempts to find out.
 
Yes, I am thinking of a 1 kHz ODR and modifying the loop flow control to sync it to the interrupt. I am also drveloping another algorithm in place of AHRS. I will baseline with the solid INVN and then down select among this, STM, Bosch and a few other high performance MEMS options available to me. For the latter I will need some shields made when the time comes. I really like your Shield/Teensy architecture for doing this kind of development and trade. I have your STM shield and will likely get the Bosch too. Gyro and accel are the drivers for so I will let you smooth out the mag issues. I'll let you know if I find anything about Bosch mags.
 
I've have done and am still doing similar kinds of compare and contrast testing. I am currently designing a Teensy 3.1 add-on board for the new LSM9DS1 9-axis motion sensor, the smaller, lower power version of the LSM9DS0. I only hope it doesn't have mag problems.

You might want to add the 6-axis accel/gyro MAX21100 to your list, sinceit is small and I find it stable and accurate as well as providing hardware sensor fusion solution. And the Bosch BNO-055 is a 9-axis motion sensor with an embedded M0 Cortex for hardware sensor fusion. These two are or will soon be available in Teensy-3.1-sized boards. Not available yet but in the works is a variety of these same 9-axis motion sensors connected to an EM7180/SENtral sensor fusion hub; the SENtral takes data from slave sensors and fuses it in hardware with only ~1% of the consumed power as a Cortex M0 sensor fusion engine, according to the claims. I am interested in the current fashion of hardware sensor fusion and I am comparing and contrasting these interesting yet different solutions to the problem. I will make these boards available on Tindie when I get enough of them built and tested. What fun!
 
Onehorse,

I bought a LSM9DS0 Teensy 3.1 Micro Shield a while back and finally got around to soldering it on to a Teensy 3.1. However, I'm having an odd behavior with it - my computer running Arduino IDE doesn't see it on the USB port. Another Teensy 3.1 plugged in to the exact same setup is recognized fine. The solder points look good under magnification and the voltages on the Teensy perimeter pins look correct. I can't check the pins on the LSM9DS0 since they are on the bottom.

Any ideas?
 
Are you saying the Teensy 3.1 itself is unrecognized, or you can't get the proper WHO_AM_I response from the LSM9DS0?

If it's the former, I really don't know how adding the micro board to the Teensy 3.1 could affect it's performance unless you also soldered pin 33, which can enable the EZ mode boot loader or some such thing and could interfere with the Mini54 flashing of the Teensy. I don't know exactly how this could make the Teensy 3.1 misbehave, Paul can help with the explanation, but I do know that you do not want to solder this pin. This is likely what is messing you up.

I posted a warning on the Tindie site with links to Teensy Forum threads that discuss the issue in some detail. The older version of the micro board (which I suspect you have) has an interrupt broken out to pin 33, so I redesigned the board to reroute this interrupt so this pin 33 issue would not arise. I don't know if there is a cure beyond desoldering pin 33. Maybe Paul can suggest a course of action. Sorry for the trouble...
 
Yes, the Teensy itself isn't recognized by the PC.

I thought I got one of the newer boards where you fixed the pin 33 issue, so I soldered all the pins. Of course, trying to unsolder it from the Teensy was pretty much impossible and I ended up pulling a pad off the Teensy and the copper out of a few of the half holes I my haste and frustration...
 
I am sorry for this trouble.

If you have one of the newer boards there is no signal connected to pin 33 so it is unlikely that the act of soldering the board caused the Teensy 3.1 to misbehave. Now that you have removed the board, does it act any differently?

I have never seen this behavior but I have only solder these micro boards onto Teensies a few times. The always work as expected.

This pin 33 issue is an issue with the Teensy 3.1 and nothing I can do anything about. IIRC once the Teensy is placed in the EZ mode boot condition it is difficult to return it to normal. I am not an expert on this topic and I suggest you solicit Paul's help to diagnose what went wrong and how to fix it.

And I am not sure it is a pin 33 issue, but this is the most likely cause of the symptom you described.

Anyone else have a suggestion?

Edit: I have noticed that when I inadvertently have a short in a circuit connected to the Teensy it will not respond in any way. Is it possible that there was a solder jumper shorting the 3V3 and GND pins?
 
Yeah, the Teensy is in some odd state now. The PC only sees it as a "USB input device" (or something like that). I'm out of time for the next few days to mess with it, but I'll get back to it next week.
 
I also had the magnetometer problem with the LSM9DSO. When logging data then suddenly the z-axis value of the magnetometer is completely wrong, ouputting a a value that is 10000x higher than what it should be. Looks like a software problem, how the data is read from the sensor. Using the Sparkfun library this problem happens a bit randomly. One sensor was always outputting wrong mag data on the z-axis. But when using the Adafruit library the same sensor output looked suddenly correct. So my guess is that the mag problem is software related.
 
This LSM9DS0 mag behavior is somewhat perplexing.

I have sent two misbehaving boards to ST Microelectronics for diagnostics; I am hoping they can tell me whether the board design, LSM9DS0 chip, or software is at fault. I will report when I learn something from them.

I redesigned the LSM9DS0 micro board again since ST told me to keep all traces and vias, as well as the back ground plane out of the sensor footprint. I am expecting the new boards next week from OSH Park and at least I can check if these boards behave better.

Lastly, I designed a Mini add-on board for the new LSM9DS1 which is a smaller and lower power version of the LSM9DS0 and have kept the sensor footprint copper free, as suggested by ST. I will also write from scratch a new sketch to access the features of this new sensor so I might be able to answer the software vs. hardware question, since I expect to be able to run the LSM9DS0 also with the new sketch and see if I can find any differences between the Sparkfun sketch and the one I will write.

The LSM9DS0 is a fine chip and we should expect to get excellent data from it; but apparently I have a bit to learn in order to use it well...

I am committed to fixing this problem and making boards available that do what they should.
 
Maybe it's at least partly a software problem. When logging data with the command dof.calcMag(dof.mx) and in the same time also just dof.mx it looks that sometimes the dof.mx is changing, too high or too low, just as it would be a scaling problem, like the LSM9DO would be configured to another scale. But the value from dof.calcMag(dof.mx) is completely weird, so it might be that part of the problem is the implementation of dof.calcMag(dof.mx).
 
I haven't ruled out a software problem. I took a look at the Sparkfun library and there are a few thins I don't like even though I wrote several of the modules. So I plan to just write a sketch for the LSM9DS1 and then modify it to use with the LSM9DS0 and then I will at least have two independent sketches to try out.

I did get some of the redesigned boards from OSH Park and assembled and tested two of them. They report magnetometer values just what I would expect; the LSM9DS0 works just fine. I am beginning to hope simply removing (or minimizing, since traces just skirting some land pads is almost unavoidable on a 0.3 in x 0.6 in board) traces and vias from the LSM9DS0 footprint and getting rid of the back ground plane underneath the chip might be enough to fix this problem. In other words, ST Microelectronics' guidelines are no copper within the footprint of the motion sensor. It looks like having some copper (meaning current) very near or under the sensor can in some cases (but not all) seriously mess up the magnetometer reading.

I plan to assemble and test the other ten new boards; if they all behave well I might just declare victory. I will still report whatever findings I get from ST when they test the old board design.
 
Just an update on the misbehaving mag issue: I discovered that the cause of this problem is one or more cold solder joints, which in hindsight is obvious. I was looking at one of the misbehaving boards (yes, I have more than one!) and noticed that one of the pads looked more gold than silver. This was pin 7 which is connected to 3V3. I added a dab of solder paste and put some flux on nearby pin pads and reflowed the board again (heated it up with hot air). Afterwards, the solder joint on pin pad seven looked normal and when I tested the board all of a sudden the magnetometer was working as it should. I suspect the mag was either not getting power or not getting enough current to operate properly through this not quite soldered connection. I proceeded to 'cure' three more of the misbehaving boards with this kind of 'therapy' and I am now convinced that this problem is due to poor workmanship on my part. How embarrassing! At least I know what went wrong and what to look for.

I have been careful since I discovered this problem to thoroughly test each board before I ship it out, but if any of my fellow forum members have this problem, you might try to cure it in this way. Or if you bought it from me I would be glad to refund your money or replace it with a working board as there is no reason for you to have to put up with a shoddy product. Just let me know...
 
Status
Not open for further replies.
Back
Top