PDA

View Full Version : Prop Shield Beta Test



Pages : [1] 2 3

Paul
03-03-2016, 07:57 PM
We're going to begin a beta test for the Prop Shield.

The Prop Shield features 10DOF motion sensors, 2 watt audio amp, high speed 5V buffers for driving APA102 LEDs, and an 8 Mbyte flash memory for images, sound clips, or data logging. It's approximately the size of a Teensy, just slightly longer to allow space for mounting holes and connections for power, speaker, and LEDs.

PJRC will send free beta test boards to the following people. We'll pay for shipping too. For packages outside the USA, you'll have to pick up any extra tariff/fee the carrier charges upon delivery.

adrian, Ben, blackketter, cartere, christoph, Constantin, craiglindley, cyborgv2, Defragster, dgarcia42, doughboy, duff, el_supremo, embedded-creations, Epyon, Experimentalist, fms1961, FrankB, GremlinWrangler, Headroom, HWGuy, JBeale, jimmayhugh, joe_prince, johnnyfp, Jp3141, Koromix, kriegsman, KurtE, LAtimes, linuxgeek, manitou, MichaelMeissner, MickMad, monkeybiscuits, mortonkopf, MuShoo, mxxx, Nantonos, nlecaude, nox771, onehorse, pawelsky, Pedvide, Pensive, pictographer, potatotron, robsoles, stevech, sumotoy, syso2342, teachop, Theremingenieur, tlb, turtle9er, whollender, WMXZ, Wozzy, Xenoamor, xxxajk


Over the next few days, Robin will contact everyone on this list to confirm current shipping addresses. If you're really excited about the Prop Shield, the magic words for a free upgrade to expedited shipping are "I have time to do substantial beta testing". Even if you're busy, we still want to send you one. Everyone on this list has contributed to the community in great ways, so this is our way of saying thanks for all the awesome things you've done!

I will post more info about the Prop Shield here over the next several days. However, I would like to ask everyone to refrain from posting pictures until we have a pre-order page live on the website.

Robin
03-03-2016, 08:17 PM
We're going to begin a beta test for the Prop Shield.

Over the next few days, Robin will contact everyone on this list to confirm current shipping addresses. If you're really excited about the Prop Shield, the magic words for a free upgrade to expedited shipping are "I have time to do substantial beta testing". Even if you're busy, we still want to send you one. Everyone on this list has contributed to the community in great ways, so this is our way of saying thanks for all the awesome things you've done!


I'll be sending out forum notifications starting today. If you are on this list you can also email me directly - robin at pjrc dot com. Be sure to include your forum user name so I can identify you right away. :)

MichaelMeissner
03-03-2016, 09:43 PM
Cool. I've been waiting for this shield since I learned about it.

While I can of course not post pictures until you are ready with pre-orders, do I need to keep it away from places where somebody might snap a picture? In particular, if I make something with it to go with my steampunk setup, where it is just part of the costume (and normally hidden away) should I wait until it is more formally announced?

whollender
03-04-2016, 12:11 AM
Cool. I didn't even know this was in the works. I don't have a lot of time to do much beta testing, but I'll be really excited to play around with one when it comes.

Thanks!

johnnyfp
03-04-2016, 01:23 AM
Can we have the specs for the 10DOF please. And also is the FLASH, SPI connected?

Wozzy
03-04-2016, 02:23 AM
Woot woot.
This sounds like a fun and useful addon board.
It combines a lot of the different components I've been experimenting with individally.
I'll need to order some APA102 strips ASP as I only have ws2811s currently.
I'm assuming that Paul will help with some libraries to get us started.
Thanks for selecting me as a Beta tester.

Experimentalist
03-04-2016, 07:05 AM
Wow, I didn't know this was in the pipeline so this is a great surprise. Thanks for the nod, I look forward to playing with this and hopefully unlocking its potential. I will PM Robin with my address details. Thanks again.

christoph
03-04-2016, 07:53 AM
Thanks for adding me to that list! How long will the beta test period be?

defragster
03-04-2016, 08:32 AM
We're going to begin a beta test for the Prop Shield. ...

Nice, 'Prop Shield' makes sense now after seeing the name dropped. Glad you got over its issues - and to be included, Thanks. Looked at the LC - 5V buffers allows 'output a 5V logic signal'. How many pins @5V? Is this the right family to order: Adafruit DotStar (https://www.adafruit.com/products/2237)

Experimentalist
03-04-2016, 08:42 AM
We're going to begin a beta test for the Prop Shield

Out of interest what were the design goals and intended purpose considering the mix of technologies?

mortonkopf
03-04-2016, 09:46 AM
Out of interest what were the design goals and intended purpose considering the mix of technologies?
Thanks for the opportunity to beta test. A list of key functions and combinations to be tested would be a good starting point. Hammering the memory and component combination playing (issues with multiple SPI) would be a high up my test list.

mortonkopf
03-04-2016, 10:03 AM
Code snippets and lib links for DOF, amp and flash read write on the Prop shield page please.

cyborgv2
03-04-2016, 11:20 AM
Very excited, finding the email this morning. Would love a link or two, to some reading material :)

PaulStoffregen
03-04-2016, 01:49 PM
Here's a first draft of the schematic.

6561
(click for full size)

PaulStoffregen
03-04-2016, 02:32 PM
Beta test boards will begin shipping today. Here's a picture of all the betas.

6562

When we sell these, 2 options will be available. A low cost version will omit the 3 motion sensor chips, and the full version will have them. Internally, we're called these "wit" and "witout", named after the Philly Cheesesteak ordering protocol (www.cheesesteaks.co.uk/orderingcheesesteaks/). That's why the label on this bin says "WIT". ;) All the betas are "wit".

I know there's a good number of unanswered questions at this point. Please be patient as I get all this stuff published over the next few days.

MichaelMeissner
03-04-2016, 03:25 PM
If I'm reading the schematic right, it looks like the SPI for the flash memory shares the SPI pins MOSI/DOUT (pin 11) and SCK (pin 13), using pin 6 as the select pin for flash and pin 7 as the select pin for the APA102 lights. According to (https://forum.pjrc.com/threads/33014-SPI-Chip-Selects-(Teensy-3-1-vs-3-2)?p=96072#post96072), I assume that the APA lights would not use the advanced SPI hardware support, but use normal digitalWrites to do the select pin.

Have the various libraries that deal with APA102 (such as FastLED) been modified to do whatever SPI locking is needed so the flash memory and APA102 can operate independently? This is more of theoretical interest, since I haven't gotten any APA102 (Dotstar) lights yet

How about using either 13 or 11 for WS2812B lights instead of APA102? Would this work fine? Or would I have to do the read from flash and wait for it to finish and then do the normal sequence to do the lights? Given pin 17 is used for WS2812B on the LC, it might have been useful to have a 3rd 74AHCT1G08 for using WS2812B lights, and reusing scripts, etc. But I can understand these things are full of compromises.

Ben
03-04-2016, 03:52 PM
Wow, thanks for selecting me. I just dropped Robin a mail.

How shall we beta testers share data (like experiences with the shield, code, pictures,...) with PJRC and each other? If PJRC doesn't want this data public, how about a subforum with restricted access or a mailing list?

Ben

Wozzy
03-04-2016, 04:31 PM
Internally, we're called these "wit" and "witout", named after the Philly Cheesesteak ordering protocol (www.cheesesteaks.co.uk/orderingcheesesteaks/).

YO! I like dat!

Tip: Never order a Cheesesteak outside of Philadelphia, It'll only lead to disappointment.

Robin
03-04-2016, 04:43 PM
YO! I like dat!

Tip: Never order a Cheesesteak outside of Philadelphia, It'll only lead to disappointment.

At the risk of going waaayyy off topic. Several years ago I was in Philly for work and went to the famous cheesesteak corner to visit Pat's King of Steaks and Geno's. Luckily my co-worker and I read up on the ordering protocol before we went. After than I've never been able to bring myself to order a cheesesteak on the West coast. I miss that sandwich.

Epyon
03-04-2016, 07:56 PM
I have time to do substantial beta testing :D .

At least what the flash storage and audio amp concerns :rolleyes: . Coincidentally I'm just designing a new iteration of dataloggers based on the Teensy 3.2, and I'm kinda fed up with the SD+Ethernet quirks. I was gonna look at some SPI flash solutions anyhow. And one of the side-projects I'm working on is audio-related, so bring it on. My boss will pay for the extra postal tariffs ;) .

defragster
03-04-2016, 09:04 PM
Would it be easy to pop up the new Forum - and such that Beta users have exclusive access to it. That way any prop shield discussions or changes wouldn't confuse the final product? Assuming the T_3++ is done before the forum swap - it could be used the same way. In the end the Forum software would be beta tested too.


At the risk of going waaayyy off topic. ... I've never been able to bring myself to order a cheesesteak on the West coast. I miss that sandwich.

Worthy digression I'd say - Spoiled for life - some local places in PA make similar great cheesesteaks - at least where I grew up - WA/west coast rolls are weak and that kills the cheesesteak/sub. The highlight of a flight back east/home was going to Sal's (at least once a day when possible) - they use their 'custom' pizza dough for fabulous rolls.

KurtE
03-04-2016, 09:46 PM
Here's a first draft of the schematic.

6561
(click for full size)

Looks interesting. Will be fun to play with!
Could be a fun different version of my "Teensy Arbotix Pro" board, which emulates Arbotix-Pro which emulates Robotis CM-730... The boards I am semi emulating use separate Accelerometer and Gyroscope, mine I have Adafruit BNO055 IMU... I also had driver for Neopixel, really primitive sound... So this shield could take over probably at least half the stuff...

Again sounds like fun!

Robin
03-04-2016, 11:47 PM
I have time to do substantial beta testing :D .

At least what the flash storage and audio amp concerns :rolleyes: . Coincidentally I'm just designing a new iteration of dataloggers based on the Teensy 3.2, and I'm kinda fed up with the SD+Ethernet quirks. I was gonna look at some SPI flash solutions anyhow. And one of the side-projects I'm working on is audio-related, so bring it on. My boss will pay for the extra postal tariffs ;) .

Be sure to send me your shipping info (and include your phone number) and I'll get a board out to you right away. :)

manitou
03-05-2016, 01:24 PM
How does the shield connect to the teensy 3? All of my teensy 3's have male pins for breadboard use.

Cosford
03-05-2016, 01:46 PM
Neat. These look like fun.

KurtE
03-05-2016, 01:56 PM
How does the shield connect to the teensy 3? All of my teensy 3's have male pins for breadboard use.
My guess would be using something like: http://www.pjrc.com/store/header_14x1_d.html
6566

cyborgv2
03-05-2016, 02:48 PM
Hopefully no pins so we can connect it how we wish... have my Teensy pins "upside down"; would like the same with this board. Once the projects complete, pins will be removed :)

Ben
03-05-2016, 03:22 PM
I don't yet have the shield, but from the schematic one can derive that the audio amp will clip with a full scale input from the teensy DAC.
The gain will be 2*(40k/(20k+2.2k) = 3.604 = 11.1dB (see the datasheet (http://www.ti.com/lit/ds/symlink/lm48310.pdf) on page 13).

The Amp's outputs can swing to the rails, but for a reasonable THD+N-figure it needs about 300 to 400mV headroom.***
400mV headroom means a maximum differential output swing of 2*(Vdd-400mV) = 9.2V
Input by the DAC is 3.3V peak-peak, so maximum allowed gain without severe distortion is about 9.2V / 3.3V = 2.788 = 8.91dB.

I guess you used 2.2kOhms for the input low pass because 2.2k is already used on the shield. Fair point from a manufacturing perspective. But this other 2.2ks are I2C-pullups, quite non-critical regarding their value.

My suggestion is to:
change all 2.2k resistors on the board to 6.8k and the 3.3nF caps to 1nF for a gain of 2.98 = 9.48dB
or
change all 2.2k resistors on the board to 8.2k and the 3.3nF caps to 680pF for a more conservative gain of 2.84 = 9.06dB

Another thought: you can omit the RC-lowpass on the inverting input and connect the 1uF do AGND directly (and recalculate the remaining lowpass on the DAC output to readjust gain). pro: less parts. con: degrades PSRR and CMRR due to input impedance mismatch, so this might be a bad idea in an unshielded mixed-signal environment.

I hope I didn't miscalculate anything :rolleyes:

***One can calculate that by extracting data points from the Output Power vs Supply Voltage graphs, page 8, then use P=Urms^2/R --> sqrt(P*R)=Urms, and Urms*sqrt(2)=Upeak)


Ben

christoph
03-07-2016, 10:32 AM
Got my prop shield, thanks! That was fast. I hope to begin testing on saturday.

Frank B
03-07-2016, 05:15 PM
Mine arrived too !
With longer header pins, my "connector board 2.0" fits great and is still breadboard compatible (sorry, no pics allowed :) )

(@Paul i sent you a photo)

Now some testing..

Edit: I2C works..


Scanning...
Device found at address 0x1E (LSM303D,HMC5883L,FXOS8700,LIS3DSH)
Device found at address 0x20 (MCP23017,MCP23008,FXAS21002)
Device found at address 0x60 (MPL3115,MCP4725,MCP4728,TEA5767,Si5351)
done


Edit:
Amplifier works. Needs the following:


pinMode(5, OUTPUT);
digitalWrite(5, HIGH);


Edit: 5-Volt Outputs: Work both (tested with DVM only)

KurtE
03-07-2016, 06:04 PM
Mine arrived today as well!

Thanks, should be a lot of fun.

But looks like I may need to order a few more T3.2s :D

Also may make an order to Adafruit for the LEDS or any other suggestions.

Thanks again!

Kurt

Frank B
03-07-2016, 06:26 PM
hmm.. there is a problem with the flash.


Flash Memory has 8388608 bytes.
Erasing ALL Flash Memory:
estimated wait: 20 seconds.
Yes, full chip erase is SLOW!
.....................
Erase completed
actual wait: 22 seconds.



Raw SerialFlash Hardware Test

Read Chip Identification:
JEDEC ID: EF 40 17
Part Nummber: W25Q64FV
Memory Size: 8388608 bytes
Block Size: 65536 bytes

Reading Chip...

Writing 4096 signatures
error writing signature at 0
Read this: FF FF FF FF FF FF FF FF
Expected: 00 00 00 00 15 F5 95 4B

Tests Failed :{

The flash chip may be left in an improper state.
You might need to power cycle to return to normal.


The hardware, at least the connections, seem to be ok as it reads the JEDEC ID correctly.. so it can't be a problem with cs, sck, miso or mosi. correct ?
Unfortunately i have no access to the flash-WP pin (board is soldered under the teensy) to check the voltage.

MichaelMeissner
03-07-2016, 06:43 PM
Mine arrived today as well.

I still find through hole soldering slow going, so I tend to move my Teensys from breadboard setup to breadboard setup rather than dedicating them to a particular build. But with the prop board, I'm going to have to dedicate a Teensy to being used by the prop board so that I can solder pins to connect the DAT pin for speaker output.

It might be useful to include a set of 5 pin male headers in the retail package similar to the 2 sets of 14x1 male headers provide, in case people don't have their own set of headers. By now, I have headers of every sort, but I'm thinking of somebody just starting out that gets a Teensy and Prop kit and wants to make something for an upcoming convention. I see complaints on the Sparkfun board from time to time about lack of headers (Adafruit tends to provide them, so you don't see it there).

I looked around for drivers for the FX0S8700, and I didn't see any. Google search would deliver pages mentioning the Pololu LSM303* boards (but in the link FX0S8700 was not mentioned). Is the FX0S8700 compatible with the LSM303* boards at the i2c level, or it there another set of libraries we should use for the motion sensing and compass functions. I see the datasheet at http://cache.nxp.com/files/sensors/doc/data_sheet/FXOS8700CQ.pdf?pspll=1, but I would prefer not to have to re-invent the wheel to access it.

<edit #1>
If you ever re-do the PCB, it may make sense to add something like 'speaker' near the front 4 pins for the speaker output. Given these pins are directly under the micro USB port of the Teensy, I suspect somebody may mis-read it, and think the +/- refers to the USB interface and not the audio interface. I don't expect too many people to be confused, but you never know.

Frank B
03-07-2016, 06:56 PM
good news..
i hav'nt found the exact problem (maybe later this this evening), but after adding some delays into SerialFlashChip.cpp the flash works!!!

so, my board is 100% ok.

MickMad
03-07-2016, 07:31 PM
Hey there,

What a nice surprise! I'd be very glad to beta test this.

Thanks guys :D

Frank B
03-07-2016, 07:48 PM
Bugfix for my flash problem:

In SerialFlashChip.cpp,
void SerialFlashChip::write(uint32_t addr, const void *buf, uint32_t len) {

add a delay:


CSASSERT();
// write enable command
SPI.transfer(0x06);
CSRELEASE();
max = 256 - (addr & 0xFF);
pagelen = (len <= max) ? len : max;
//Serial.printf("WR: addr %08X, pagelen %d\n", addr, pagelen);

delayMicroseconds(1); //<------- ADD THIS !!!!

CSASSERT();
if (flags & FLAG_32BIT_ADDR) {
SPI.transfer(0x02); // program page command
SPI.transfer16(addr >> 16);


I have no idea why this is needed, but now it works (with 120MHz, too)
The documentation of the chip mentions no delay (?!)

Edit: This is sufficiant, too:
asm volatile("NOP");

(hm. suspicious. could it be a compiler problem (too much optimizing for CSRELEASE()...CSASSERT()? between them there should one F_BUS cycle pause minimum, correct? I#m using a newer compiler)

Edit:
making "max" volatile, works too... :) - but a NOP is the better way, i think.

Pensive
03-07-2016, 07:53 PM
Ever so excited :)

Thanks for including me :)

I'm not 100% sure what to do with it yet but definitely will involve an audio library Synth and my usb midi keyboard ;)

...

...

...

I lied. My plan is complete. :)

cyborgv2
03-07-2016, 08:30 PM
It might be useful to include a set of 5 pin male headers in the retail package...

Quite agree, I am one of those that are starting out on Teensy; returning to "electronics" after a 20 year-ish break. Including a few cheap headers will please a fair number of customers.


I looked around for drivers for the FX0S8700, and I didn't see any...

I'm a seasoned programmer, since aged 6! So I'm coming at this from a programmers point of view. I recently bought a HMC5883L and quite frankly think that there's a better way of doing things than the Arduino way. I'll will almost certainly be writing my own code for some, if not all of this board. I'm also quite happy to shared relevant code with, at least, this group. After all, if no-one had re-invented the wheel, we wouldn't have created the tyre!

defragster
03-07-2016, 09:43 PM
I did one search - turns out onehorse put something on his GitHub:[/URL]
https://github.com/kriswiner/FRDM-FXS-MULT FXOS8700CQBasicExample.ino (https://github.com/kriswiner/FRDM-FXS-MULT/blob/master/FXOS8700CQ/FXOS8700CQBasicExample.ino)
FXOS8700CQ combination 14-bit accelerometer/16-bit magnetometer
FXAS21000 14-bit gyroscope

USMail said I'd have my Prop board today - but apparently the wormhole Portland to Seattle opened again and 2 days isn't enough to cover 180 miles.

Frank B
03-07-2016, 09:48 PM
:) a black hole where gravity is too high and time goes slow.. Einstein was right.
ha!. or somebody inserted too many "NOP"s

The wormhole was between OR and Germany :) Never got anything from US so fast ! Somebody pressed the "turbo" knob..



good night.

pictographer
03-07-2016, 09:58 PM
Trying to think of a project within my reach. Here are some ideas in case anyone else wants ideas:

POV globe
POV top
Poi, etc.
Ball with LEDs that responds to acceleration, e.g. bouncing, spinning, changing direction
Weather station with anemometer based on deflection either of the module hanging from a cord or deflection of the module mounted on a spring (think car antenna)
Handheld sensor including compass, temperature, barometric pressure, inertial navigation for orienteering or add a GPS module and display for full nav system.
UAV guidance system
Student lab instrument for learning about the physics of motion, i.e. force, gravity, friction, momentum, momentum, etc.
Combine with audio shield to make a toy that responds aurally to being moved, tossed, dropped, etc.
Estimate fluid flow rate in a pipe based on the vibration of the pipe

defragster
03-07-2016, 10:00 PM
If it was a black hole - I would expect to never see it (though that has happened). :( I think the USMail has those with an aversion delivery in inordinately fast times - when they saw the wormhole they choose select packages for alternate means of delivery - slower than the pony express

manitou
03-07-2016, 10:37 PM
My prop shield arrived.

Testing with teensy 3.1 96mhz opt (clip-jumpers for now), IDE 1.6.7, loader 1.27

I2C scan OK
I2C device found at: 0x1E
I2C device found at: 0x20
I2C device found at: 0x60

SPI serial flash: EraseEverything and RawHardwareTest OK (lastest SerialFlashlib from github), also created and read some files
(reran tests @120mhz, all OK). serial flash OK with teensy LC @48MHz

Used https://github.com/sparkfun/MPL3115A2_Breakout
pressure/altitude and temperature OK
Altitude(ft):625.82 Temp(f):78.01
Altitude(ft):626.85 Temp(f):78.01

used Paul's https://github.com/PaulStoffregen/Magnetometers_Test

FXOS8700: 11.20 19.10 95.30
FXOS8700: 10.50 18.80 98.10
seems to be doin' something
added readTemp (0x51) get 22C OK

used https://github.com/sabas1080/FXAS21002C_Arduino_Library
T Gyroscope: 9
Gyroscope X: 16301 Y: 105 Z: 16362
T Gyroscope: 0
Gyroscope X: 16287 Y: 128 Z: 16362
T Gyroscope: 0
Gyroscope X: 16320 Y: 111 Z: 16371
doing something, but temperature T is funky ?
FIX: added false to endTransmission in readReg(), fixed temperature
T Gyroscope: 26



used https://github.com/mlwarner/fxos8700cq-arduino
Mag X: 16375 Y: 16379 Z: 16381
Accel X: 1806 Y: 60 Z: 12848
doin' somethin
added temperature and change readReg to use false in endTransmission, temp 22C ok

sine wave to DAC, AGRND, Vin, Grnd, pin 5 HIGH, DAC and opamp output to cheap scope, all with jumper wires. DAC 3.3v wave looks fine, opamp + output is very jagged (spread spectrum?), but opamp path looks operational

No LEDs, but with pin 5 HIGH, confirmed DATA and CLK are OK with logic analyzer.

KurtE
03-07-2016, 11:21 PM
USMail said I'd have my Prop board today - but apparently the wormhole Portland to Seattle opened again and 2 days isn't enough to cover 180 miles.
It worked for about 75 miles north of you :D

defragster
03-07-2016, 11:42 PM
Has anyone tried the linked onehorse lib? Or another?


It worked for about 75 miles north of you :D

:) Could be - I'll need to deal with import from Canada ... 2.5 days on the road - even the post office isn't sure where it went.

6597

xxxajk
03-08-2016, 10:52 AM
Got my beta yesterday in good order, and I think I have a nifty idea for this. I'll have to look into it a bit deeper before I say anything though :-)

xxxajk
03-08-2016, 11:13 AM
Paul, dude... this has everything I've been looking for, all in one nice small neat package! This is useful for SO many things!
So here's one of my crazy idea that has been brewing for a long time, but haven't had a chance or excuse to do.
Slotcat + teensy3.x + prop shield == slotcar that could:
* Not wipe out... accellerometer could detect when bad motion is happening, and slow down for me
* Drive the track on its own
* Provide nifty race sounds as it goes around the track
* Crazy cool lighting on the car.
* other strange things like send data back to phone/tablet and graph out G-forces and the like.

NICE!!!

Ben
03-08-2016, 11:52 AM
can someone confirm or deny the clipping issue I suspected in post #28 (https://forum.pjrc.com/threads/33328-Prop-Shield-Beta-Test?p=98345&viewfull=1#post98345)? Mine's still on its way.

PaulStoffregen
03-08-2016, 12:23 PM
Bugfix for my flash problem:
....
Edit:
making "max" volatile, works too... :) - but a NOP is the better way, i think.

Thanks!

I'll get this merged in a few days. At the moment I need to clean up the IMU code....



I looked around for drivers for the FX0S8700, and I didn't see any.


Please hold on for a day or two. I'm still cleaning up the magnetic cal stuff.

Or if you *really* want to play now, there's this very rough code...

https://github.com/PaulStoffregen/Magnetometers_Test


can someone confirm or deny the clipping issue I suspected in post #28 (https://forum.pjrc.com/threads/33328-Prop-Shield-Beta-Test?p=98345&viewfull=1#post98345)? Mine's still on its way.

You might be off by a factor of 2, or something, since the specs are fully differential. Sorry, didn't have time to go through your analysis in detail right now.

But I can tell you a 3.3Vp-p full scale DAC output is able to make the amp clip somewhat. A 1.2Vp-p can not. (yes, I've already done quite a bit of testing) Those two DAC ranges actually work out pretty nicely, 1.2V for normal to quiet rooms, and use 3.3V (not quite the full range) for noisy rooms or outdoors.

The seemingly redundant or unnecessary parts connected to the inverting input (pin 2) are meant to balance the impedance seen by the LM48310. There's a least a couple old threads on this forum and at least one youtube video where people experienced quite a lot of switching noise coupling when they tried to use class D amps. This board also has APA102 LED signal output, so we can expect people to use it together with dozens, perhaps hundreds of LEDs, where the current can rapidly switch by multiple amps as the LED turn different colors, or use different PWM patterns. My cautious approach here is meant to allow this chip's good CMRR to (hopefully) give us nice, clean audio even in the presence of a tremendous amount of power supply noise, from the class D switching and massive LED current changes.

Please be patient, and then you can test with the real hardware.

mortonkopf
03-08-2016, 02:05 PM
Nice, 'Prop Shield' makes sense now after seeing the name dropped. Glad you got over its issues - and to be included, Thanks. Looked at the LC - 5V buffers allows 'output a 5V logic signal'. How many pins @5V? Is this the right family to order: Adafruit DotStar (https://www.adafruit.com/products/2237)
@defragster, yes, particularly the APA102 leds (Adafruit calsl them dotstar). These have rapid update and are the 'current' goto led for props that get twirled, thrown, spun, POVed, etc.

christoph
03-08-2016, 02:18 PM
Teensy LC with its two SPIs seems like it could do cool DMA stuff with the flash chip and APA102 LEDs.

Frank B
03-08-2016, 03:22 PM
Flash:
@Paul, i think we can replace all the delayMicroseconds in that lib with faster delays - but, maybe, this needs some testing with other chips ?

Edit: just tested it with with the W25Q64FV. Indeed, it works.
The Datasheet mentions a delay of 5 ns "relative to clk" - with SPI @ 30MHz a clk is 33ns.

manitou
03-08-2016, 04:39 PM
Flash:
@Paul, i think we can replace all the delayMicroseconds in that lib with faster delays - but, maybe, this needs some testing with other chips ?

Edit: just tested it with with the W25Q64FV. Indeed, it works.
The Datasheet mentions a delay of 5 ns "relative to clk" - with SPI @ 30MHz a clk is 33ns.

FWIW, I re-ran my SerialFlash tests on prop shield with teensy 3.1 @120mhz and experienced no problems ...

Frank B
03-08-2016, 04:58 PM
FWIW, I re-ran my SerialFlash tests on prop shield with teensy 3.1 @120mhz and experienced no problems ...

reducing the delays is an optimization (faster). my issue was solved with _inserting_ a short delay.

nlecaude
03-08-2016, 05:26 PM
Nice !
Seems like a very useful shield ! Eager to test it out and thanks for putting me in the list !

fms1961
03-08-2016, 06:42 PM
Wow! Very rare, such a fast delivery ... thank you, guys! But when I see the size of the PCB - the question arises: "When will we be able to transport this via the network ... ?" :cool:

Theremingenieur
03-08-2016, 06:56 PM
Lucky you in Germany... To France, it seems to take more time. My small packet left the USPS distribution center in Los Angeles only yesterday...

defragster
03-08-2016, 11:22 PM
@defragster, yes, particularly the APA102 leds (Adafruit calsl them dotstar). . . .
mortonkopf thanks!

Post Office got the Prop Shield delivered! ... and no Jury Duty this week . . . now to build it . . .

Headroom
03-09-2016, 12:28 AM
WOW. Thanks for the consideration!

pictographer
03-09-2016, 03:53 PM
Got Paul's Magnometer_Test code running after commenting out the code for the devices I don't have:

Magnetic TestBegin FXOS8700
id = C7
FXOS8700CConfigured
FXOS8700: -10.20 -6.40 78.00
FXOS8700: -9.60 -24.90 59.80
FXOS8700: 1.40 -37.70 70.20
FXOS8700: 2.50 -19.10 96.10
FXOS8700: 7.80 -40.70 91.20
FXOS8700: 2.90 -17.40 104.00
FXOS8700: 10.90 -17.90 97.20
FXOS8700: -7.10 -14.50 81.00
FXOS8700: -12.10 -13.70 60.10
FXOS8700: -5.80 -33.20 64.90
FXOS8700: 2.10 -35.50 86.30
FXOS8700: 5.50 -16.50 103.10
FXOS8700: -24.40 -49.70 101.80
FXOS8700: -34.70 24.70 97.30
FXOS8700: -54.00 48.40 108.60
FXOS8700: -81.30 149.10 168.20
FXOS8700: 86.20 18.60 302.50
FXOS8700: 81.30 28.70 301.20
FXOS8700: 43.40 96.50 270.80
FXOS8700: -25.10 167.90 84.00

Quick test was performed waving around the Teensy 3.2 with Prop Shield by the USB cable.

By the way, I went ahead and soldered the headers that came with the Prop Shield, but if I thought about it some more, I might have used different headers, like long pin female machine headers or something. For testing, I'll need to figure out a convenient way of getting to some of the Teensy GPIO.

JBeale
03-09-2016, 05:51 PM
I gather the FXOS8700 has a 3-axis accelerometer and a 3-axis magnetometer. I don't know the details but is your code reporting the X,Y,Z components of the local magnetic field? If it is a uniform field I would expect the magnitude of the vector (sqrt of sum of squares) to stay the same, but clearly (-10, -6, 78) doesn't have the same magnitude as (81, 28, 301). Were you waving it near a magnet or large chunk of metal? Or the three axes have very different sensitivities, and have not been calibrated (normalized)?

PaulStoffregen
03-09-2016, 06:27 PM
Here's newer code to read all the motion sensors.

https://github.com/PaulStoffregen/NXPMotionSense

The magnetic sensor has significant offsets which require calibration to remove. If you install it near any ferrous metals, it also need "soft iron" calibration. I've been working on a nice GUI-based tool for this, but it's not quite ready. For now, I'd recommend using only the accelerometer and gyroscope as 6DOF.

I'd hoped to get a 1st beta published today... but Arduino just made a 1.6.8 release, so for right now I've got a put together a Teensyduino beta to support it.

pictographer
03-09-2016, 07:08 PM
One discrepancy I noticed is that the code assembles a 16-bit value, but the datasheet says we're dealing with two 7-bit quantities.

onehorse
03-09-2016, 08:37 PM
Here (https://github.com/kriswiner/MPU-6050/wiki/Simple-and-Effective-Magnetometer-Calibration) is some simple code to calibrate the magnetometer well enough for most uses.

JBeale
03-09-2016, 08:48 PM
I see the data sheet for the NXP FXAS21002 turn-rate sensor http://cache.nxp.com/files/sensors/doc/data_sheet/FXAS21002.pdf?pspll=1 mentions a rate sensing noise of 0.025 (degrees/sec) / sqrt(Hz). If I'm reading that right, the noise level with one second integration is around 0.025 degrees per second, which is a rotation rate of one full turn in 4 hours (!) In other words, could clearly resolve the rotation rate of the minute hand of a clock (if it moved smoothly, instead of ticking), with a noise level only 6x more than the rotation of the earth. That seems like a phenomenal degree of sensitivity. The offset drift with temperature, 0.02 (X,Y) and 0.01 (Z) deg/sec per degree C also seems good. I look forward to trying this thing out!

PaulStoffregen
03-09-2016, 09:04 PM
I'm pretty sure it's not good. There's a constant offset in addition to noise. Maybe we can characterize and calibrate it out? So far, I haven't done that...

defragster
03-10-2016, 12:33 AM
Paul noted 1.6.8 IDE release - I saw this: Reference.CurieIMU (https://www.arduino.cc/en/Reference.CurieIMU)

<edit - add> :: The Curie IMU library enables an Arduino or Genuino 101 to read the output of the on-board IMU (Inertial Measurement Unit) containing an accelerometer and a gyroscope and elaborate the raw data coming from it.

blackketter
03-10-2016, 01:39 AM
Hey,
I just noticed my name on the beta list and am emailing Robin. Very exciting, can't wait to put it through its paces.

I can't tell from the schematic whether this will be mechanically and electrically compatible with the LC or just the 3.2. Is it intended for both?

I'd also love to hear a little backstory on how the choices were made to include the various peripherals. I'm sure everybody has their own set that they'd love to see...

-dean

MichaelMeissner
03-10-2016, 04:01 AM
Blackketter: The label on the Prop board anti-static envelope says it is for Teensy 3.2 and LC. I imagine you might not be able to use some of the advanced audio stuff on the LC, and of course the LC runs at a slower speed than the 3.2 depending on how many calculations you need to do for the various sensors.

FWIW, I did put my LC with pins soldered into the prop board, and the i2c scanner was able to see the 3 sensors.

johnnyfp
03-10-2016, 04:07 AM
Got my board, Just testing it now, will update if I find any software issues.

Comment on the Hardware. Would be nice to have a duplicate program switch added to the board. In the configuration of Pro board under the Teensy, The Teensy's lower pads are no longer readily available, you can solder out some wires but there is no or little room to break them out as the IO pins encase the the area, specially with the speaker and Power pins potentially connected.
If we then mount the Teensy underneath so that we can gain access to the pads we then can't access the Program Switch.

The mounting holes are a little tight for generally available hardware, Would be good to have M3 or 1/8 size holes maybe. Could you get away with removing the 5v and GND at the speaker end and pushing the holes out? and thus larger?

The 5v and GND at either end of the board could potentially lead to confusion with incorrect connections as they are opposite to each other, where as if they where both 5v top GND bottom then you could also easily daisy chain.

The X-Y Silkscreen, might be worth putting a copy underneath as well, because as soon as the Teensy is put on top it will hide the direction.

-jfp

MichaelMeissner
03-10-2016, 04:22 AM
Johnnyfp -- you could always mount a wire connecting the program pin on the back to a button, and connect it to ground to move the program switch away from the Teensy. I believe the only pin you need to connect on the back set of pins is the DAC pin if you want to use the speaker.

<edit>
In trying it, I found 2-56 screws (US imperial measures) to work well for the mounting holes, though 2-56's are small enough I lost 3 hex nuts under the desk in trying to attach them.

defragster
03-10-2016, 07:06 AM
My unit working! I cut removed a onehorse ESP unit - full pinned the T_3.2 and headers on the Prop.Shield (with 9 selectively long pins to hit the ESP again)

> SerialFlash ( RAWhwTest, EraseEverything from GitHub (https://github.com/PaulStoffregen/SerialFlash) )
> i2c scanner found three device ID's
> 9DOF read and debug spew runs.
> I quick hacked the onehorse P#64 code to get something that is numbers? Missing details - did I read these are 7 bit values? Probably have to read some words there . . .
<edit>: these zero values cause the d1[] values to come up zero:

MPU9250magCalibration[3] = {0, 0, 0}; // Factory mag calibration and mag bias


Mag Calibration: Wave device in a figure eight until done!
Mag Calibration done!
Mag Cal_d1:0.00
Mag Cal_d1:0.00
Mag Cal_d1:0.00
__________Mag Cal_d2:0.61
__________Mag Cal_d2:1.71
__________Mag Cal_d2:1.30

** On Windows with Python 2.7.11 (needed for ESP8266 on Arduino) I didn't have pyserial needed for SerialFlash\..\rawfile-uploader.py
I couldn't find a way to install it - this link showed me this that worked from a CMD prompt:: pip install pyserial
pyserial-for-python-2-7-2 (http://stackoverflow.com/questions/8491111/pyserial-for-python-2-7-2)

Epyon
03-10-2016, 09:42 AM
Received mine today. Probably gonna start testing friday afternoon, when my students are working on their own Teensy projects :D .

Xenoamor
03-10-2016, 09:46 AM
A kalman filter (https://en.wikipedia.org/wiki/Kalman_filter) should be used to keep track of heading. This will automatically compensate for errors.

Accelerometers are accurate in the long term
Gyroscopes in the short term
The magnetometer will correct the drift

Quaternions will need to be used to avoid gimbal lock.

You won't find any of the sensors particularly useful on their own unless you wanted something simple like a tilt sensor

I don't know about this specific barometer but normally you have to input your local barometer pressure for your area on that day to get any reasonable data from them. A more accurate reading can be achieved by also using a temperature reading from ground level

Ben
03-10-2016, 12:46 PM
A kalman filter (https://en.wikipedia.org/wiki/Kalman_filter) should be used to keep track of heading. This will automatically compensate for errors.
Yes, a extended kalman filter is needed, as the angualar movement introduces nonlinearity. However...


Accelerometers are accurate in the long term
Gyroscopes in the short term
The magnetometer will correct the drift
...You are correct about the gyro and magnetometer part, but "Accelerometers are accurate in the long term" would mean they had no offset and zero drift. To my understanding accelerometers are like gyros as they measure the derivative of the physical state (location and direction respectively). So Accelerometers are the "short term" input for the filter, and GPS would be the drift corrector as it provides absolute position (with great uncertainty, but that's what the kalman filter will take care of). So with the Prop Shield having no GPS, I think it's important to provide a routine to build a calibration table at least for the accelerometer, preferably at several different temperatures, to compensate offset and drift as good as possible.

I'm sorry all I'm providing so far is theoretical babble - my shield is still on it's way, but it's already in Germany, yay :)

-Ben

christoph
03-10-2016, 01:04 PM
I'd also say that this is a good opportunity to write a Kalman filter that processes the prop shield's data, with GPS being an optional extra. I've never done that myself, though.

PaulStoffregen
03-10-2016, 01:14 PM
I'm porting Freescale's Kalman filter and soft iron calibration code now....

Xenoamor
03-10-2016, 02:07 PM
"Accelerometers are accurate in the long term" would mean they had no offset and zero drift

I was under the impression they only drift with temperature which can be compensated for.. but it's been a while
Most accelerometers have calibration routines that spoof 1g forces on each axis so you can remove the offsets


I'm porting Freescale's Kalman filter and soft iron calibration code now....
Can you post a link to this, it'd be interesting to see Freescale's code

I found a lot of use out of the kalman filter from the multiWii (http://www.multiwii.com/) project

Frank B
03-10-2016, 05:59 PM
Paul,

do you want pull.request for NXPMotionSense, or is it too early ?
There are some functions missing, like reading the temperature data, altitude or pressure.

And, should it contain only "raw" data, or additionally "human readable" data like C or F (=floats ?) ?

MichaelMeissner
03-10-2016, 06:15 PM
Paul,

do you want pull.request for NXPMotionSense, or is it too early ?
There are some functions missing, like reading the temperature data, altitude or pressure.

And, should it contain only "raw" data, or additionally "human readable" data like C or F (=floats ?) ?
Speaking as a potential user, I think having helper functions that convert the data into human readable values is useful.

defragster
03-10-2016, 07:03 PM
IMU now has a standard in Arduino - unfortunately they picked a different chip than PJRC did when he did this last year - but prior link new to IDE 1.6.8 shows a developed API set for their 6DOF IMU interface. onehorse has a technically well developed quaternion and more interface to his MPU9250 unit - would have been cool had it come 'wit' that chipset - not sure if it maps well or not.

MichaelMeissner
03-10-2016, 07:20 PM
I haven't actually started using the prop shield yet, but I had some thoughts on layout:

1) I plugged in an LC that I had bought from PJRC with the pins soldered on, and it was a very tight fit. I had to slightly bend the pins so that it would fit (but that may be due to the breadboards I've been using). On Teensy's where I have soldered pins (using the generic pins I have from other builds) the pins are thinner, and fit easier.

2) If you are not going to solder the speaker wires and VIN ouput for APA102 leds directly to the board, you probably want to use a right angle female header (such as https://www.pololu.com/product/2704) for at least the speaker connections since the USB plug otherwise would be in the way. If you want to use Frank B's proto board (https://oshpark.com/shared_projects/cYQjHdCu) to bring out the bottom pads on the 3.2, you would also need to use a right angle header for the connectors for APA102 LEDs. It may be useful if PJRC could stock similar headers (and perhaps include them in the retail package).

3) For protoboards/breadboards, it seems a shame to use a big 30 pin breadboard on something that is meant to be small and handheld. Some of the boards I've been thinking about using include:

Tiny breadboards (https://www.adafruit.com/products/65 and elsewhere) -- I'll probably use these for initial code development;
Adafruit perma-proto for small mint tin: https://www.adafruit.com/products/1214 -- these are nice, particularly if it fits inside the Altoids small min tin (I haven't tried it yet) -- having the power rails in the middle saves on space, but it may mean you will need to solder in the wires before soldering the prop shield to the perma-proto board;
Adafruit quarter sized perma-proto (https://www.adafruit.com/products/589) -- a little wider than the above board, but it has separate power rails for easy connection;
Azzy's Electronics 1"x2" protoboard (https://www.tindie.com/products/DrAzzy/1x2-prototyping-board/) -- this gives one row of pins for each side, with a middle section of 3 rows of pins.

Frank B
03-10-2016, 07:56 PM
I have built my "Prop Teensy" with my "Connectorboard v2" (link below, same size and price as before, but single-sided, without vias and no traces on the teensy-side) and the Prop Shield under the Teensy. This allows to acces all pins / solderpads and the button.

I don't know if this can cause troubles with the magnetometer. I hope, not.

It is very compact. Teensy + Connectorboard is still a bit smaller than the shield. Sorry, no picture allowed...

https://oshpark.com/shared_projects/0T6ZdhhG

MichaelMeissner
03-10-2016, 07:58 PM
Frank, I suspect there isn't room, but it would be useful if you release another version if one of the sides of the silkscreen could indicate which pin is which.

Frank B
03-10-2016, 08:06 PM
Good idea.. :)

cyborgv2
03-10-2016, 08:21 PM
Woo hooo, it arrived... thank you very, very much.

I'm soldering in male headers tonight, I'll begin in earnest tomorrow.

First observation, if we've received the "retail package", is that there's only enough header supplier for the side connections; I would suggest enough to fill all the connections to the Teensy are provided. Extra headers (may be angled as previously suggested) for the amp and LED port would be a bonus.

cyborgv2
03-10-2016, 09:05 PM
Technical questions... what are the total power requirements esp. the 3.3v? Also, what's the differance between the two 3.3v connections?.. and what about the the two gnd and agnd? Sorry thinking about my power supply; using a Teensy 3.1 (lower 3.3v power output.) But also, I wish to run Teensy and Prop from and external source, cutting Teensy's usb supply.

PaulStoffregen
03-10-2016, 10:23 PM
do you want pull.request for NXPMotionSense, or is it too early ?

Probably a bit early. I'm very actively working on the PC-side calibration program. I had hoped to wrap this up last week... but everything always takes longer than anticipated!

Here's where the cal program is at so far. If you compile on Linux without a custom built wxwidgets lib, use "make imuread" to build only the command line which opens a bare opengl window.

https://github.com/PaulStoffregen/IMUread


Speaking as a potential user, I think having helper functions that convert the data into human readable values is useful.

Yes, I like this too...


IMU now has a standard in Arduino - ... - but prior link new to IDE 1.6.8 shows a developed API set for their 6DOF IMU interface.

I'm not very excited by their API on the Curie board. It's very complicated.

My guess is things will eventually settle to a simple API, perhaps like Adafruit is using?



onehorse has a technically well developed quaternion and more interface to his MPU9250 unit - would have been cool had it come 'wit' that chipset - not sure if it maps well or not.

My (behind schedule) plan involves a hybrid of stuff I recently put on github, and Freescale's library (minus the MXQ dependency) and that PC/Mac program to visualize the calibration process. Perhaps this is a little on the ambitious side, but I feel pretty good about making it work.

Freescale's library already has really good Kalman-based sensor fusion and magnetic calibration algorithms. I'm working now to integrate those. I look very briefly at Onehorse's stuff a while back. Will give it another look next week. But I'm very sure we're going to go with Freescale's code for the Kalman filter.



Technical questions... what are the total power requirements esp. the 3.3v?

Good question. On 3.3V, not a lot. The sensors are a few mA when fully active. Flash write/erase might add a bit. I haven't really worried about this. Answers in the datasheets...



Also, what's the differance between the two 3.3v connections?.. and what about the the two gnd and agnd?


The two 3.3V pins are connected together. Likewise for the GND pins. AGND is only used for the audio signal. For details, see the schematic posted on msg #14.

defragster
03-11-2016, 12:51 AM
...
I'm not very excited by their API on the Curie board. It's very complicated.
...
I look very briefly at Onehorse's stuff a while back. Will give it another look next week. But I'm very sure we're going to go with Freescale's code for the Kalman filter.


That API list looked very involved and HELPFUL - detecting/supporting all that will need lots of resources from the Curie setup.

Perhaps the 9250 chip was cost prohibitive? - having picked the 'FXOS8700' probably ends up on a new path - the onehorse software maturity w/support for hardware fusion w/Cortex M0 had me buy in.

johnnyfp
03-11-2016, 03:33 AM
You probably want to use a Complementary Filter rather than a Kalman filter as it's less complicated than a Kalman, but has very similar properties. Easier for us mortals to understand. :)

onehorse
03-11-2016, 08:00 AM
Thanks Paul for the gift of the Prop Shield! I'll need some help figuring out what to do with the audio amplifier but I know what to do with motion and pressure sensors. I combined my separate sketches for these sensors into one more or less integrated sketch (https://github.com/kriswiner/Teensy_Prop_Shield) that parametrizes the registers, configures all the sensors, does some simple offset calibration and outputs the data to the serial monitor. It's been almost two years since I used these sensors and I forgot all of the cool motion detection built in. The sketch allows tap and double tap detection, rotation rate threshold detection and direction detection as well as portrait/landscape detection. It's really a lot of fun to see how the sensor board responds to various motions and it is infinitely configurable. So have fun!

I still need to get the Madgwick and Mahony sensor fusion connected and add a simple magnetometer calibration. All straightforward. These would not be my first choice for small accurate sensors but they work well enough and have a lot of built in features that can be quite useful.

defragster
03-11-2016, 08:18 AM
C:\tCode\Prop\Teensy_Prop_Shield\quaternonFilters. ino:174:38: error: 'eInt' was not declared in this scope


My bad - #if 0 those two functions in quaternonFilters.ino - as noted not connected.

Showing results - seems to see the taps too

PaulStoffregen
03-11-2016, 09:12 AM
I'll need some help figuring out what to do with the audio amplifier...

The audio amp is really simple. Just use pinMode & digitalWrite high on pin 5 to enable it. Then use the audio lib to send sound to the DAC pin. If you start with any of the audio lib examples, delete all the SGTL5000 stuff, and change AudioOutputI2S to AudioOutputAnalog (i2s vs dac in the design tool).

MichaelMeissner
03-11-2016, 11:39 AM
Paul, IIRC parts of the Audio library are Teensy 3.2 (and 3.1) only, due to the use of M4 instructions. The anti-static bag the shield came in says it is compatible with the LC and 3.2. When it is officially released, you may want to clarify what works on the LC (i.e. the 'wit' parts), and what doesn't (audio using the audio library).

Or perhaps there is a simple library that works on the LC that plays pre-recorded sounds from both the shield's flash memory and from the program flash memory with 'const'.

Or perhaps officially limit it to the 3.2.

PaulStoffregen
03-11-2016, 11:41 AM
Thanks. That's a good point. Eventually I'm going to port parts of the audio lib to LC, and much prep work has already been done, but it's still not actually working.

onehorse
03-11-2016, 05:32 PM
I added the Mahony and Madgwick sensor fusion filters to the Teensy Prop Shield code (https://github.com/kriswiner/Teensy_Prop_Shield); I am getting 660 Hz fusion rates at 72 MHz on a Teensy 3.1. This is a little lower than I would expect but adequate. There must still be some delays built in that can be eliminated for faster fusion speeds.

I also got the mag calibration almost done, just need to cast the properly scaled mag bias values into the offset registers. The mag values in general seem about a factor of four too low. Not quite sure why yet.

Frank B
03-11-2016, 06:07 PM
You should use sqrtf instead of sqrt. sqrt is for doubles.

Edit: same atan, asin or other functions.... use atanf and asinf !

onehorse
03-11-2016, 06:37 PM
Yeah, you're probably right. Too bad Teensy doesn't have an FPU!

Frank B
03-11-2016, 06:38 PM
It will have.. but float.

Even with FPU for doubles, that "f" functions are better, since all your vars are float - otherwise they are converted to double and back to float, i think (<- is this correct, Michael ?)

Your code looks good. What's the license of the code from the Freescale-Appnotes you used ?

stevech
03-11-2016, 06:53 PM
For (most) ARM Cortex M MCUs that have hardware floating point, it's most always a 'single' precision type. The word 'double' yields code for single. It's said that for an MCU without hardware floating point, if you use 'single' and don't need the precision of double, then there's a big size and speed advantage in being explicit with double. Or redefine its macro.

MichaelMeissner
03-11-2016, 07:36 PM
It will have.. but float.

Even with FPU for doubles, that "f" functions are better, since all the vars are float - otherwise they are converted to double and back to float, i think (<- is this correct, Michael ?)

Your code looks good. What's the license of the code from the Freescale-Appnotes you used ?
Yes and no.

The current Teensys do not have hardware FP, but it takes longer to emulate double precision than single precision. Even outside of the cost to emulate a single operation, the sqrt function probably needs to execute an additional round or two of Newton-Raphson to get the precision right.

Code imported from the AVR machines like most of the Arduino, sometimes uses doubles, but the compiler silently treats double like float.

However, it isn't always true that single precision is faster than double precision. There are machines that internally do things in double precision and do single precision by doing a rounding step after doing the calculation in double precision. Because C was developed on such a machine (PDP-11 and PDP-8 before the 11) is why C defaults to double precision for constants. The PowerPC that I work on also internally does things in double precision format and scalar 'single precision' values are stored in the register in the double format. Before SSE extension was added to the X86 architecture, floating point was always done in 80-bit floating point on a stack, which was loads of fun to run code that depended on exact IEEE semantics.

Frank B
03-11-2016, 08:02 PM
Kris, your sketch says:

pressure is 102695.00 Pa, altitude is 65423.69 m, temperature is 27.88 C

Hm. not really.

johnnyfp
03-11-2016, 08:22 PM
I think there's a slight output error at line 548 where it should be the following instead

from

baroin = altimeter_setting_pressure_mb * 0.02953;


Serial.print("pressure is "); Serial.print(pressure, 2); Serial.print(" Pa, "); // Print altitude in meters
Serial.print("altitude is "); Serial.print(altitude, 2); Serial.print(" m, "); // Print altitude in meters

to


float alt = altimeter_setting_pressure_mb * 0.02953;


Serial.print("pressure is "); Serial.print(baroin, 2); Serial.print(" Pa, "); // Print altitude in meters
Serial.print("altitude is "); Serial.print(alt, 2); Serial.print(" m, "); // Print altitude in meters

However not sure what the point of the Altitude mode vs the pressure mode is. And reading the Barometer twice. Probably something to do with temperature and base compensation?

Also you will need to set your station_elevation_m to your barometer base or start height in the world.

Pensive
03-11-2016, 10:15 PM
Received mine yesterday, thank you :)

its late tonight, should play with it tomorrow

Ben
03-11-2016, 10:24 PM
Yes and no.
Even outside of the cost to emulate a single operation, the sqrt function probably needs to execute an additional round or two of Newton-Raphson to get the precision right.

Is there a step before N-R when taking the sqrt on a micro? LUT? Given how quickly N-R converges for all real numbers with f(x)=sqrt(x) i somehow thought it would do N-R from start to end. But you mention one or two rounds of N-R, which on it's own wouldn't be enough, so there must be something else?
I don't want to bother you giving me a detailed explanation, but if you happen to have a link that offers some insight that would be most kind of you :D

On Topic: IMHO it's a good idea to use single precision as it will yield the same results as code running on a future T3++ or T4 that uses a hardware FPU.

-Ben

Pensive
03-11-2016, 10:39 PM
called these "wit" and "witout", named after the Philly Cheesesteak ordering protocol (http://www.cheesesteaks.co.uk/orderingcheesesteaks/).

Thanks to this beta program, I have now discovered I can get philly cheesesteaks inside of a 3 hour round trip from house. They have a co.uk and mobile vans, with permanent residence in spitalfields market in london.

This is the best thing EVER. :)

MichaelMeissner
03-11-2016, 10:50 PM
Is there a step before N-R when taking the sqrt on a micro? LUT? Given how quickly N-R converges for all real numbers with f(x)=sqrt(x) i somehow thought it would do N-R from start to end. But you mention one or two rounds of N-R, which on it's own wouldn't be enough, so there must be something else?
I don't want to bother you giving me a detailed explanation, but if you happen to have a link that offers some insight that would be most kind of you :D
-Ben

I meant you probably would need 1-2 EXTRA rounds of N-R due to the extra precision when calculating sqrt for double compared to float, not that you could get away with 1-2 rounds. Note, I'm not really up on the fine points of numerical analysis.

Ben
03-11-2016, 11:33 PM
I meant you probably would need 1-2 EXTRA rounds of N-R due to the extra precision when calculating sqrt for double compared to float, not that you could get away with 1-2 rounds. Note, I'm not really up on the fine points of numerical analysis.
Ohh now I see, thanks. Yeah 1-2 rounds sounds right for a single->double precision increase.

PaulStoffregen
03-11-2016, 11:35 PM
Does N-R really converge that quickly? Double precision has a *lot* of bits in its mantissa!

onehorse
03-12-2016, 01:09 AM
Kris, your sketch says:

pressure is 102695.00 Pa, altitude is 65423.69 m, temperature is 27.88 C

Hm. not really.

This is likely a result of poor signed integer casting. I had to fix a few of these errors to get reasonable sensor output. I do not claim this is a perfectly well-executed, error free code. Just that it is a good place to start from...

OK, I fixed the integer casting for the MPL3115A2 pressure, altitude, and temperature. See if it works better for the lowlands...

Ben
03-12-2016, 01:39 AM
Does N-R really converge that quickly? Double precision has a *lot* of bits in its mantissa!
Yes, best case convergence with NR is quadratic (each iteration doubles the number of "usable" bits in the mantissa). How fast it actually converges depends on the function, with sqrt it's pretty good. There are other functions that don't converge at all with certain initialisations (seeds). But that never occurs with sqrt except you initialize with x=0, but you wouldn't do that anyway. When taking the sqrt of a binary number m^e one would seed with 1^(e/2) if e is even and 1^((e-1)/2) if e is odd (I'm not completely sure about this, but I think I got it right)
-Ben

Edit: My Shield arrived today, on my birthday. Thanks you PJRC, this is a nice birthday gift :o

onehorse
03-13-2016, 04:15 AM
OK, I finally figured out what I was doing wrong with the magnetometer. The signed 16-bit (2-byte) magnetometer counts is in units of milliGauss, not sure why I had the conversion factor I did two years ago. Anyway, I added a manual magnetic calibration which just measures the min and max, takes the average and stuffs the result into the mag offset registers. In the initialization I choose auto calibration so the mag will start out reasonably well calibrated (the bias offset is huge on my prop shield) and just get better with subsequent use.

Now all of the sensor data is properly scaled and calibrated for offset bias, and the Madgwick fusion algorithm produces quaternions and Euler angles derived therefrom. Enjoy!

I tried Frank's squartf instead of sqrt and found the fusion rate dropped from 660 Hz to 650Hz, so it is a little less efficient. Is it more accurate to compensate? I don't know.

Here (https://github.com/kriswiner/Teensy_Prop_Shield) is the sketch repository.

PaulStoffregen
03-13-2016, 06:11 AM
I got the magnetic cal going today on Linux. Will clean it up soon and port to Mac and Windows on Sunday.

defragster
03-13-2016, 08:04 AM
Odd #1: often when I re-compile the thing hangs after printing 'Scanning...' - it takes a power cycle to run (not a reset). I'm suspecting this is from the upload interrupting an in process I2C transaction?
[ I had an active ESP8266 on PWR/GND and sharing pins 8,9,10 and 15,16,17 - none of which appear to be common to the Prop shield? - I unplugged that and the next re-compile/upload stuck at "Scanning..." ]

Odd #2: (sometimes?) sitting 'still' roll/pitch/yaw seem to vary. Moving it some direction 90 seems to take a second (couple of updates) to filter in?

My edited file : 6641

I'm running my Prop's T_3.2 at 96 MHz and the fusion rate was under 700 to start then was steadying at ~710 with peaks in the 850+ using the GitHub code.

Looking at the code I wondered about text macros for the q#==q[#-1] refs and recompiled with first edits below in the quaternion.h file - the code and ram use basically unchanged.

With macro edits :: running the same Prop on T_3.2 at 96 MHz and the fusion rate was under 700 to start then was steadying at ~750 with peaks in the 850+.

5% faster??? Not sure why the code size didn't change more - but this saves two sets of four float transfers in and out of the q# stack locals - perhaps the refs to the globals are more efficient, or fit the cache better? All changes to global q[] are after the early return testing.

Attached my file - I didn't do a FORK so I can't do a pull request - there was a second set edits of using pre-calculated 2.0f multipliers where they were duplicated (before q# was changed?). These made it start at or above 700Hz and steady state closer to 760Hz, and the occasional outliers hit 880 Hz.

I'm tempted to do a DEBUG set of SPEW where only data values changing (by x%) are shown so that without gross movement the SPEW would stay quiet - and then on motion only the altered value would change - and only for as long as they took to stabilize. I think this would point out the behavior of the math more easily (like ODD #2). Maybe that would be best done by sending the data stream out SERIAL1 to a second Teensy to do that math in a second monitor window?



#define q1 (q[0]) // short name macro for readability
#define q2 (q[1])
#define q3 (q[2])
#define q4 (q[3])

void MadgwickQuaternionUpdate(float ax, float ay, float az, float gx, float gy, float gz, float mx, float my, float mz)
{
//xx float q1 = q[0], q2 = q[1], q3 = q[2], q4 = q[3]; // short name local variable for readability

// ...

// replaced these :: q[0] = q1 * norm;
q1 *= norm;
q2 *= norm;
q3 *= norm;
q4 *= norm;
}

void MahonyQuaternionUpdate(float ax, float ay, float az, float gx, float gy, float gz, float mx, float my, float mz)
{
//xx float q1 = q[0], q2 = q[1], q3 = q[2], q4 = q[3]; // short name local variable for readability

// ...

// replaced these :: q[0] = q1 * norm;
q1 *= norm;
q2 *= norm;
q3 *= norm;
q4 *= norm;
}




//xx float _2q1q3 = 2.0f * q1 * q3;
//xx float _2q3q4 = 2.0f * q3 * q4;
float _2q1q3 = _2q1 * q3;
float _2q3q4 = _2q3 * q4;

// and these >> _2q1mx = 2.0f * q1 * mx;
_2q1mx = _2q1 * mx;
_2q1my = _2q1 * my;
_2q1mz = _2q1 * mz;
_2q2mx = _2q2 * mx;

onehorse
03-13-2016, 08:48 AM
Normally when I run this same Madgwick filter on the MPU9250 I get fusion rates near 1600 Hz at Teensy MCU speeds of 72 MHz. That is because I am only reading data once (all data registers at the same time). In this code I am reading from two completely different sensors and there will be some latency. I haven't spent any time trying to make the fusion rate faster other than moving the MPL3115A2 sensor data read into the 2 Hz display loop. There are plenty of ways to speed it up without changing the quaternionsFilter.ino file. For example, accel and mag data can be burst read instead of individually read as currently, the gyro and accelerometer temperatures don't have to be read (or can be moved into the display loop), and data ready interrupts could be better used.

Still, a 700 Hz fusion rate is plenty fast for most applications. The Madgwick (or Mahony) filter is computationally efficient but is barebones as far as sensor data filtering is concerned. They will provide a pretty good absolute orientation estimation if the underlying sensors are (1) accurate, 2) stable, and 3) well calibrated. The calibration functions in the github repository are also bare bones, call them good enough to show the method but could be improved. The entire code shows the basics and its up to the user to configure for their own application.

If you are running with a data sample rate of 100 - 200 Hz, bandwidth of ~25 Hz, and fusion rate at ~1 kHz, you are in the sweet spot. The prop shield with this code is pretty much there. Residual jitter in the orientation estimation is likely a result of the underlying sensor behavior as opposed to the quality of the sensor fusion algorithm. I have shown this through basic testing here (https://github.com/kriswiner/MPU-6050/wiki/Hardware-Sensor-Fusion-Solutions) and here (https://github.com/kriswiner/EM7180_SENtral_sensor_hub/wiki/E.-Typical-Results-Using-the-SENtral).

onehorse
03-13-2016, 08:58 AM
Your code looks good. What's the license of the code from the Freescale-Appnotes you used ?

The code was written entirely by me. I took some register defines and a basic tap detection scheme from a Sparkfun sketch. Nothing came from the Freescale AN except the basic register and function information in the datasheet. I took Madgwick's algorithm for his and Mahony's sensor fusion and modified it to work with an Arduino IDE. The I2C read and write functions were suggested to me by Brian Knox. And that's about it.

There is no license required as far as I am concerned; this is completely open source and available to anyone to do as he or she will with it. Of course, I would appreciate attribution as a common courtesy, etc. And if you make it better or find errors I would like to know about it. Pretty simple...

defragster
03-13-2016, 10:41 AM
There are plenty of ways to speed it up without changing the quaternionsFilter.ino file.

Independent of any hardware and data reading :: These edits to the quaternionsFilter.ino file are just pre-compile fluff where the readability/functionality was maintained (if I read the code right) - another way of doing the same thing while reducing run-time processor overhead - amounting to a free 5% throughput improvement - I only looked because you noted lost Hz from using the sqrtf() - this gave it back for free, and the same macro work applied perfectly to both functions. The second set added marginally - I just noticed some explicit pre-calculation efforts were not fully utilized. Any reduction in spurious (2.0f * xyz) math seemed to be the goal of the intermediate variables - with or without the T_3.2's lack of FPU- the second edits just built on those existing variables already in the code - and the first set of improvements show that while intermediate variables improve readability - they can come at a cost - so doing them without fully using them is just adding delay.


If you are running with a data sample rate of 100 - 200 Hz, bandwidth of ~25 Hz, and fusion rate at ~1 kHz, you are in the sweet spot. The prop shield with this code is pretty much there.

This confuses me - maybe it is because the sensors produce data at different rates and efforts are made to get data fusion as each set is presented? : I understand 'fusion' to be the association of a set of data points to its 'usable value'. Getting 1,000 Hz fusion points from 200 sample points seems counter intuitive? Is it interpolation by design to get optimal use of each data point and factor out the 'crosstalk' caused by gravity?

Looking at the current quaternionsFilter.ino I see this one was not changed to sqrtf()? :: _2bx = sqrt(hx * hx + hy * hy);

Given that I have the ESP8266 on a serial port already - if I were to push this (currently displayed or more) Teensy data to the ESP8266, it could monitor that data and spit it out to a formatted web page rather than a scrolling Serial stream. This is partly for my own understanding of the 3 DOF data components and being able to get 'fusion' of my own understanding of how they relate to Pitch/Yaw/Roll - all directly inline with my intended usage case.

MichaelMeissner
03-13-2016, 03:30 PM
I decided to try onehorse's code last night. I had to do some mechanical changes to get it to work with the way I installed it, renaming quaternonFilters.ino to quaternonFilters.cpp, and adding a quaternonFilters.h for the global variables. I haven't looked into the various warnings that are emitted:



Teensy_Prop_Shield.ino: In function 'void FXOS8700CQMagOffset()':
Teensy_Prop_Shield.ino:890:47: warning: narrowing conversion of '32768' from 'int' to 'int16_t {aka short int}' inside { } [-Wnarrowing]
Teensy_Prop_Shield.ino:890:47: warning: narrowing conversion of '32768' from 'int' to 'int16_t {aka short int}' inside { } [-Wnarrowing]
Teensy_Prop_Shield.ino:890:47: warning: narrowing conversion of '32768' from 'int' to 'int16_t {aka short int}' inside { } [-Wnarrowing]
Teensy_Prop_Shield.ino:891:9: warning: variable 'dest1' set but not used [-Wunused-but-set-variable]
Teensy_Prop_Shield.ino:891:31: warning: variable 'dest2' set but not used [-Wunused-but-set-variable]
Teensy_Prop_Shield.ino: In function 'void initFIFOMPL3115A2()':
Teensy_Prop_Shield.ino:1377:11: warning: variable 'temp' set but not used [-Wunused-but-set-variable]
Teensy_Prop_Shield.ino: In function 'void initRealTimeMPL3115A2()':
Teensy_Prop_Shield.ino:1414:11: warning: variable 'temp' set but not used [-Wunused-but-set-variable]


I haven't gotten around to soldering up a Teensy 3.1 to the prop shield, so I used my LC which tightly fits into the shield without soldering. If I just run it with just the LC and the shield, it runs fine.

If I put the shield into one of the tiny 170 tie-point breadboards (http://www.ebay.com/itm/5x-Transparent-Mini-Solderless-Prototype-Breadboard-170-Tie-points-for-Arduino-/231242048856?hash=item35d719a558:g:nOEAAOSw0vBUdnb L), it sometimes prints unknown error 0x1 in the i2c scan. Sometimes it hangs at that point, sometimes it eventually continues. This is similar to what defragster reported.

Similarly if I put the LC + prop shield into a small protoboard (https://www.tindie.com/products/DrAzzy/1x2-prototyping-board/) it prints the unknown error, and may or may not hang.

Once I've put in some more Serial.println calls (one after the Serial.begin, one before the Wire.begin, and one before the I2Cscan), it now seems to come up all of the time.

So maybe the LC just needs a little more time to settle before doing the i2c devices.

Ben
03-13-2016, 04:15 PM
I read through the sqrt page at cppreference.com (http://en.cppreference.com/w/c/numeric/math/sqrt) and it says that sqrt, sqrtf and sqrtl are required to be exact, which means accurate to within 0.5 LSB of it's return data format. I think it might be worth a try to investigate which parts of the algorithm can make do with less precision and try the "fast inverse square root" algorithm in those places instead. Especially if you need the inverse anyways, like when normalizing vectors (dividing by sqrt(x^2+y^2+z^2) ).
-Ben

manitou
03-13-2016, 06:06 PM
Good question. On 3.3V, not a lot. The sensors are a few mA when fully active. Flash write/erase might add a bit. I haven't really worried about this. Answers in the datasheets.

I was checking 3.3v power usage with meter, all seemed reasonable at first. But now reading the gyro consumes 20ma ?? (datasheet says 2.7 ma active). I wonder if I fried something jumpering meter inline here and there??? gyro seems to be sending out different values when unit is moved ....

SPI flash was only taking 2.8ma doing erase and 1.5ma doing reads. altimeter 2.5ma, accel/mag 0.26ma

onehorse
03-13-2016, 07:57 PM
the various warnings that are emitted

Since I wrote a lot of this "code" two years ago (a month after I first heard the word "Arduino") there is bound to be a lot of sloppiness wrt use of int16_t and int, etc. I cleaned up quite a bit of nonsense already to do with 2's complement but I would not be surprised if more surgery would be required. Please let me know about any errors or poor programming choices.


This confuses me - maybe it is because the sensors produce data at different rates and efforts are made to get data fusion as each set is presented? : I understand 'fusion' to be the association of a set of data points to its 'usable value'. Getting 1,000 Hz fusion points from 200 sample points seems counter intuitive? Is it interpolation by design to get optimal use of each data point and factor out the 'crosstalk' caused by gravity?

Yes, this confuses a lot of people. Sensor fusion is not analytical, it is iterative. The simplest way to think about sensor fusion is as an iterative error correction algorithm not unlike a Newton-Raphson iterative method. For each data sample, the fusion algorithm needs to iterate four or five times to asymptote to a stable solution. So the right way to "construct" the timing is to choose a sensor data rate that meets the needs of the application, then size the processor to allow fusion rates at 4 or 5 times the data sample rates. So for 200 Hz sample rate, typical for human activities, you need a processor capable of running the fusion at 1 kHz. That's why I transitioned (https://github.com/kriswiner/MPU-6050/wiki/Affordable-9-DoF-Sensor-Fusion) from the lovely Arduino Pro Mini (fusion rates of ~100 Hz) to the even lovlier Teensy (fusion rates ~1500 Hz).

defragster
03-13-2016, 08:24 PM
Yes, this confuses a lot of people. Sensor fusion is not analytical, it is iterative.

Thanks onehorse - going to the bank and standing in line with a deposit slip 5 days a week when you only get checks one day each week just didn't seem to make sense.

I ignored the compile warnings assuming they were known 'work in progress' when I focused on the simple cleanup notes I made.

stevech
03-13-2016, 08:52 PM
I've worked in fields where "Sensor Fusion" means improving an estimate of a real world event based on analysis of multiple sensors' data that observe the same event. The sensors can and normally differ in what they measure. More fusion leads to higher degree of confidence. For me, this comes from working in defense and intelligence systems where the kinds and places of sensors measuring a singular event differ greatly.

Another example: dead reckoning navigation (heading/speed) fused with GPS x,y,z estimate (that may be short-term absent or inaccurate due to satellite geometry, sky occlusion, etc.)

whereas improving single-sensor estimates isn't fusion, but rather statistical data analysis/reduction.

onehorse
03-13-2016, 08:54 PM
Agree, but this describes what, I was describing how...

defragster
03-14-2016, 02:33 AM
I've worked in fields where "Sensor Fusion" means improving an estimate of a real world event based on analysis of multiple sensors' data that observe the same event. The sensors can and normally differ in what they measure. More fusion leads to higher degree of confidence. For me, this comes from working in defense and intelligence systems where the kinds and places of sensors measuring a singular event differ greatly.

Thanks stevech! That furthers my understanding - in line with what I was thinking when I acknowledged my confusion.

Ben
03-14-2016, 02:53 AM
I'd like to make the case for this faster 1/sqrtf() implementation (http://www.lomont.org/Math/Papers/2003/InvSqrt.pdf) again.
It's twice as fast. Worst case error I found so far was better than 0.00005 absolute.

-Ben



#define TESTCOUNT 10
#define TESTLENGTH 5000

elapsedMicros time;
unsigned int sqrtfTime;
unsigned int qsqrtfTime;
void setup() {
Serial.begin(9600);
delay(500);

for (int test=0 ; test<TESTCOUNT ; test++) {
Serial.print("Test #"); Serial.println(test+1);
// ***** generating random values to test on
randomSeed(analogRead(0));
float randomNumber[TESTLENGTH];
for (int i=0 ; i<TESTLENGTH ; i++){
randomNumber[i] = float(random(1E9)) / 1E6;
}

// ***** calculate normal sqrtf() *****
float normalroot[TESTLENGTH];
time = 0;
for (int i=0 ; i < TESTLENGTH ; i++) {
normalroot[i] = 1.f / sqrtf(randomNumber[i]);
}
sqrtfTime = time;
Serial.print("Computing "); Serial.print(TESTLENGTH);
Serial.print(" inverse square roots using the normal sqrtf() function took ");
Serial.print(sqrtfTime); Serial.println(" microseconds.");

// ***** fast qsqrtf() *****
float fastroot[TESTLENGTH];
time = 0;
for (int i=0 ; i < TESTLENGTH ; i++) {
fastroot[i] = qsqrtf(randomNumber[i]);
}
qsqrtfTime = time;
Serial.print("Computing "); Serial.print(TESTLENGTH);
Serial.print(" inverse square roots using the fast qsqrtf() function took ");
Serial.print(qsqrtfTime); Serial.println(" microseconds.");

// ***** finding maximum error made by faster function
float maxErrorFast = 0.f;
int maxErrorIndex = 0;
for (int i=0 ; i < TESTLENGTH ; i++) {
if ( (fastroot[i] - normalroot[i]) > maxErrorFast ) {
maxErrorFast = fastroot[i] - normalroot[i];
maxErrorIndex = i;
}
}
Serial.print("maximum absolute error with fast sqrt was: ");
Serial.println(maxErrorFast, 15);
Serial.print("and occurred when computing qsqrtf(");
Serial.print(randomNumber[maxErrorIndex], 15); Serial.println(").");

Serial.print("normal sqrt was "); Serial.print(float(sqrtfTime) / float(qsqrtfTime), 4);
Serial.println(" times slower");

Serial.print("End of test #"); Serial.println(test+1);
Serial.println("");
}


}

void loop() {
delay(1);
}


float qsqrtf(float x) {
long i;
float y;

float x2 = x * 0.5f;
y = x;
i = * (long * ) &y;
i = 0x5f3759df - ( i >> 1 );
y = * ( float * ) &i;
//Newton-Raphson:
y = y * ( 1.5f - ( x2 * y * y ) );
return y;
}


And the serial output:


Test #1
Computing 5000 inverse square roots using the normal sqrtf() function took 36711 microseconds.
Computing 5000 inverse square roots using the fast qsqrtf() function took 18242 microseconds.
maximum absolute error with fast sqrt was: 0.000000000000000
and occurred when computing qsqrtf(4.941257953643799).
normal sqrt was 2.0124 times slower
End of test #1

Test #2
Computing 5000 inverse square roots using the normal sqrtf() function took 36710 microseconds.
Computing 5000 inverse square roots using the fast qsqrtf() function took 18234 microseconds.
maximum absolute error with fast sqrt was: 0.000000014901161
and occurred when computing qsqrtf(54.022491455078125).
normal sqrt was 2.0133 times slower
End of test #2

Test #3
Computing 5000 inverse square roots using the normal sqrtf() function took 36715 microseconds.
Computing 5000 inverse square roots using the fast qsqrtf() function took 18239 microseconds.
maximum absolute error with fast sqrt was: 0.000000003725290
and occurred when computing qsqrtf(864.105102539062500).
normal sqrt was 2.0130 times slower
End of test #3

Test #4
Computing 5000 inverse square roots using the normal sqrtf() function took 36711 microseconds.
Computing 5000 inverse square roots using the fast qsqrtf() function took 18248 microseconds.
maximum absolute error with fast sqrt was: 0.000000000000000
and occurred when computing qsqrtf(0.789928972721100).
normal sqrt was 2.0118 times slower
End of test #4

Test #5
Computing 5000 inverse square roots using the normal sqrtf() function took 36714 microseconds.
Computing 5000 inverse square roots using the fast qsqrtf() function took 18237 microseconds.
maximum absolute error with fast sqrt was: 0.000000000000000
and occurred when computing qsqrtf(1.512629985809326).
normal sqrt was 2.0132 times slower
End of test #5

Test #6
Computing 5000 inverse square roots using the normal sqrtf() function took 36714 microseconds.
Computing 5000 inverse square roots using the fast qsqrtf() function took 18237 microseconds.
maximum absolute error with fast sqrt was: 0.000000003725290
and occurred when computing qsqrtf(300.916290283203125).
normal sqrt was 2.0132 times slower
End of test #6

Test #7
Computing 5000 inverse square roots using the normal sqrtf() function took 36705 microseconds.
Computing 5000 inverse square roots using the fast qsqrtf() function took 18233 microseconds.
maximum absolute error with fast sqrt was: 0.000000007450581
and occurred when computing qsqrtf(75.223937988281250).
normal sqrt was 2.0131 times slower
End of test #7

Test #8
Computing 5000 inverse square roots using the normal sqrtf() function took 36708 microseconds.
Computing 5000 inverse square roots using the fast qsqrtf() function took 18241 microseconds.
maximum absolute error with fast sqrt was: 0.000000014901161
and occurred when computing qsqrtf(18.799392700195312).
normal sqrt was 2.0124 times slower
End of test #8

Test #9
Computing 5000 inverse square roots using the normal sqrtf() function took 36717 microseconds.
Computing 5000 inverse square roots using the fast qsqrtf() function took 18229 microseconds.
maximum absolute error with fast sqrt was: 0.000000029802322
and occurred when computing qsqrtf(4.698485851287842).
normal sqrt was 2.0142 times slower
End of test #9

Test #10
Computing 5000 inverse square roots using the normal sqrtf() function took 36713 microseconds.
Computing 5000 inverse square roots using the fast qsqrtf() function took 18242 microseconds.
maximum absolute error with fast sqrt was: 0.000000003725290
and occurred when computing qsqrtf(300.983123779296875).
normal sqrt was 2.0126 times slower
End of test #10

onehorse
03-14-2016, 03:32 AM
I just revised the sketch (https://github.com/kriswiner/Teensy_Prop_Shield) to improve the fusion rate. I moved the accel and gyro temp fetch into the 2 Hz loop. Now the fusion runs at 780 Hz (with the Teensy at 72 MHz) when the accel is in the active state and 840 Hz when the accel enters low-power mode after 36 seconds of no activity (user configurable). I also corrected the Madgwick fusion call for the actual alignment of the prop shield sensors and changed the Euler angles for the heading reads from 0 to 360 like a compass. I also changed the order of the bias calibrations so the accel, then gyro and lastly mag are calibrated since the two former require no motion and the latter requires figure-eight motion. Everything should be working properly now.

onehorse
03-14-2016, 03:46 AM
I'd like to make the case for this faster 1/sqrtf() implementation again.

I tried this (and updated the gihub repository with it), but it didn't change the fusion rate so even if it is much faster, it is not the rate limiting step...

johnnyfp
03-14-2016, 04:49 AM
Hi,

I've tried the Audio Amp with the code Below, and can't get any sound out of the amplifier. I've got a signal from the DAC if I connect directly just no sound from the prop board.

Could someone else try the code please see if you get some sound from the board?


#include <Audio.h>
#include <SerialFlash.h>

// GUItool: begin automatically generated code
AudioSynthWaveformSine sine1; //xy=180,469
AudioOutputAnalog dac1; //xy=380,468
AudioConnection patchCord1(sine1, dac1);
// GUItool: end automatically generated code

int freq = 1100;

void setup() {
Serial.begin(115200);
while (!Serial);
Serial.println("Setting up");
pinMode(5, OUTPUT);
digitalWrite(5, 1);//Enable Amplified.
AudioMemory(12);
sine1.amplitude(1.0);
sine1.frequency(1000);
Serial.println("Send Serial Char to increase freq");
}

void loop()
{
if (Serial.available()) {
Serial.read();
sine1.frequency(freq);
Serial.println(freq);
freq += 100;
}
}

defragster
03-14-2016, 08:43 AM
Hi,

I've tried the Audio Amp with the code Below, and can't get any sound out of the amplifier. I've got a signal from the DAC if I connect directly just no sound from the prop board.

Could someone else try the code please see if you get some sound from the board?


Yes, I can and did try it, CODE worked as copied from post 129. 8ohm 0.5W speaker makes tone on both: GND to DAC and USB end across AMP:: - and +.

<edit> Also tried Talkie lib and it worked. (https://forum.pjrc.com/threads/33446-Talkie-speech-library?p=99240&viewfull=1#post99240)

Ben
03-14-2016, 10:56 AM
I tried this (and updated the gihub repository with it), but it didn't change the fusion rate so even if it is much faster, it is not the rate limiting step...
Ok, thanks for testing this. If there is no improvement I suggest reverting to normal sqrtf() to get the full float accuracy.
-Ben

manitou
03-14-2016, 04:16 PM
I'd like to make the case for this faster 1/sqrtf() implementation (http://www.lomont.org/Math/Papers/2003/InvSqrt.pdf) again.
It's twice as fast. Worst case error I found so far was better than 0.00005 absolute.

-Ben



I thought I would compare your qsqrtf() with cortex M4F hardware SQRT (think teensy 3++) on MK64F @120MHz (albeit MBED with different compiler), here are the numbers for 5000 reps



sqrtf took 1647 us
qsqrtf took 917 us
qsqrtf error 1.86265e-09
sqrtf 1.796074 slower

and on a 180Mhz Cortex M4F (not freescale )
sqrtf took 1090 us
qsqrtf took 634 us
qsqrtf error 1.86265e-09
sqrtf 1.719243 slower

The hardware manual says SQRT and divide each take 14 cycles, so your qsqrtf() is faster than the hardware SQRT.

EDIT: By comparison, sqrtf() on teesy 3.1 @120MHz took 32358us, so this shows the speedup from the MK64F's hardware floating point

NOTE: mbed MK64F has on-board FXOS8700Q

stevech
03-14-2016, 05:09 PM
I thought I would compare your qsqrtf() with cortex MF4 hardware SQRT (think teensy 3++) on MK64F @120MHz (albeit MBED with different compiler), here are the numbers for 5000 reps



sqrtf took 1647 us
qsqrtf took 917 us
qsqrtf error 1.86265e-09
sqrtf 1.796074 slower

and on a 180Mhz Cortex M4F (not freescale )
sqrtf took 1090 us
qsqrtf took 634 us
qsqrtf error 1.86265e-09
sqrtf 1.719243 slower

The hardware manual says SQRT and divide each take 14 cycles, so your qsqrtf() is faster than the hardware SQRT.

But the strange thing is that the teensy 120mhz times are so much slower than mbed ??? 5000*28/120mhz should be about 1166us, about what the mbed results show. But teensy sketch shows


Computing 5000 inverse square roots using the normal sqrtf() function took 32351 microseconds.
Computing 5000 inverse square roots using the fast qsqrtf() function took 17610 microseconds.


I'm still trying to figure that out ....?

Compiler switches/config enabling hardware FP? Perhaps Arduino or Teensy defaults don't tell compiler to use hardware FP?
Or you have to declare floats as type single rather than double since the ARM FP is single precision.

MichaelMeissner
03-14-2016, 05:36 PM
Compiler switches/config enabling hardware FP? Perhaps Arduino or Teensy defaults don't tell compiler to use hardware FP?
Or you have to declare floats as type single rather than double since the ARM FP is single precision.

Right now, since the current Teensy's do not have hardware floating point. If you use the Teensy setup, floating point is always done via emulation. In the future, when the next generation of Teensy comes out, it will have single precision floating point in the hardware, but any use of double precision is done by emulation. So to pave the way for this, it is a good habit to use float instead of double, use single precision math functions (i.e. sqrtf instead of sqrt), and add a 'f' suffix to all floating point constants. I know Paul adds the switch to make constants single precision by default (which has its own set of issues if you really need the higher precision), but it is a good habit to get into to be type correct, in case your code is moved to a different system.

manitou
03-14-2016, 05:38 PM
Compiler switches/config enabling hardware FP? Perhaps Arduino or Teensy defaults don't tell compiler to use hardware FP?
Or you have to declare floats as type single rather than double since the ARM FP is single precision.

Ooops, I was operating in a fog as usual. The fast MK64F times show the speedup from the Cortex M4F hardware floating point. (I edited my previous post.)

manitou
03-14-2016, 06:01 PM
As another "teensy 3++" comparison here are times for single call to MadgwickQuaternionUpdate() from
https://github.com/kriswiner/Teensy_Prop_Shield using invSqrt()

teensy 3.2@120MHz 216us
MBED MK64F @120MHz 8us (Cortex M4F hardware floating point)
MBED F446RE @180MHz 5us (Cortex M4F hardware floating point, not freescale)

Mahony: teensy 133us, MK64F 5us

Paul's NXPMotionSense
kalman fusion: teensy 3648us, MK64F 468us

MichaelMeissner
03-14-2016, 09:24 PM
As I think about the prop shield, what is needed to help make it a success is examples to help people put the pieces together. So off of the top of my head, some examples might be:

Doing something with persistence of vision (poi) using a simple string of APA102 lights, such as http://orchardelica.com/wp/?page_id=597 redone with the shield (and hopefully at some point FASTled using the SPI hardware).

Something with the compass, such as this 3d compass: https://github.com/jrleeman/3DCompass/blob/master/README.md.

Play sounds stored in flash memory. However to do this, you need to be able to download sounds to the flash memory (such as the zmodem thread that went by a few days ago). For zmodem, you probably want to refashion it as a library, to include in other things, but given it uses a lot program memory, we may be stuck having to flash the zmodem downloader, do the downloads, and then reflash the main program. It might be better if somebody used to hacking USB and filesystems, adds a rudimentary USB external disk support. However nice that is, I suspect it is a lot of work.

Similarly using the prop shield for a simple data logger, that can upload its data when connected to a computer (perhaps acting as a USB keyboard, and spitting out logs as text files).

Frank B
03-14-2016, 10:18 PM
I wrote a little tool to transfer files to the Teensy. I hope we can use it to fill the SPI-Flash easyly. Thispart has to be done - but the lib works for any kind of data. Could be useful for SD, too. Or perhaps to transfer soundfiles and play them "live" ?

Works for any OS.

https://forum.pjrc.com/threads/33463-Teensy-3-2-as-HMI-display-%28Editor-development%29?p=99308&viewfull=1#post99308

Ben
03-14-2016, 10:53 PM
As I think about the prop shield, what is needed to help make it a success is examples to help people put the pieces together.

I agree. The additional hardware required to experience these examples should be kept to a minimum and should in general only consist of stuff you'd connect to the Prop Shield anyway, like APA102s and a small speaker (or headphones). A simplified version of Mortonkopf's Pixel Poi is a good idea, the 3D-Compass IMHO not so much as it requires NeoPixel Rings which use WS2811 instead of APA102 LEDs and requires you to arrange the LEDs in this specific pattern, which means basically you must have two of the NeoPixel Rings or you must brew your own PCB.

Examples can be educational without being complex by just showing certain features of the prop shield and the associated libraries. A talking compass (with talkie lib) might be worth considering. Or a audio playback example that maps a 3-channel equalizer (lows, mids, highs) to the 3 axis of orientation of the prop shield. These are not much more than simple update loops in the arduino sketch, yet IMHO entertaining and educational.
-Ben

pictographer
03-14-2016, 11:46 PM
A 3D compass example without any addional hardware could work as follows:


Direction printed to the console whenever the bearing changes by greater than 1 steradian or so
LED 13 blinks faster the closer the bearing is to magnetic north

KurtE
03-15-2016, 12:05 AM
I am looking forward to playing. I should just start doing so, but currently in the process of debugging my own new board, also was waiting for my order from Adafruit with some APA102s (1 meter of 60per...) was tempted to get the 8x8 grid (https://www.adafruit.com/products/2734), as this might be fun with this board.

Will also be interesting to see how well these IMU components work as compared with the board I am playing with, which is setup to install a BNO055 IMU (https://www.adafruit.com/products/2472).

Now back to play!

defragster
03-15-2016, 06:42 AM
As I think about the prop shield, what is needed to help make it a success is examples to help people put the pieces together. So off of the top of my head, some examples might be:
...
Similarly using the prop shield for a simple data logger, that can upload its data when connected to a computer (perhaps acting as a USB keyboard, and spitting out logs as text files).

More samples would be cool - if only there were a Wiki. It would be Nice if there were a link for common expendables: Suitable speaker - a headphone jack that could go on - is the $20 DotStar really the cheapest strip to get a few LED's?

As noted above I tried Talkie - watching the speaker while sounds played got really boring, even that cool two minute Diner song . . . I posted here Talkie-speech-library (https://forum.pjrc.com/threads/33446-Talkie-speech-library?p=99330#post99330) about making a non-blocking version of Talkie.

Frank may like this - I just took my Interrupt driven non-blocking TALKIE library and made a sample playing the 2 minute song: PropTomsDinerInt (https://github.com/Defragster/Talkie/tree/master/examples/PropTomsDinerInt)

It is set to work with the Prop Shield - with the linked Altered Library from GitHub.

Having good data logging Examples to access the Flash would be cool. Would be a challenge to feed Talkie from data stored there - have to buffer through local RAM - to not let it boundary cross or run out any single sound set would have to be cached locally.

JBeale
03-15-2016, 06:45 AM
Just wanted to report the Prop Shield Beta arrived here! Only had a few minutes so far, but Paul's "RawData" code at https://github.com/PaulStoffregen/NXPMotionSense shows signs of life; it looks like it sends about 100 readings per second. Looks to me like ax,ay,az are always multiples of 4, in other words the two LSBs are always 0 ?
Swinging around on USB cord:

ax, ay, az, gx, gy, gz, mx, my, mz
-27624,1748,14344,-11619,13526,8754,515,328,742
-26820,680,14308,-12082,11813,11169,499,257,825
-26180,-572,13940,-12681,9350,13410,467,167,886
-25692,-1672,13084,-13400,6141,15159,426,67,908
-25132,-2472,11896,-13993,2449,16067,377,-54,923
-24756,-3016,10472,-14259,-1500,15982,330,-148,875
-24820,-3564,8964,-14035,-5385,14831,274,-219,810
-25856,-3772,7564,-13383,-8799,12645,201,-250,719
-28128,-3384,6376,-12523,-11457,9674,143,-277,646
-31280,-2436,5804,-11626,-13244,6438,84,-267,562
-32768,-1376,5596,-11040,-14320,3400,52,-254,524
-32768,-184,5372,-10843,-14882,633,5,-224,465
-32768,988,5060,-10634,-14981,-1950,-29,-190,434
-32768,1928,4676,-10003,-14705,-4345,-57,-160,401
-32768,2544,4292,-8958,-14209,-6453,-82,-139,387
-32768,2932,3956,-7883,-13523,-8209,-109,-119,375
-32768,3368,3592,-7210,-12698,-9628,-122,-103,371
-32768,3960,3104,-7031,-11690,-10733,-126,-71,360
-32768,4464,2384,-7084,-10467,-11538,-142,-72,367
-32768,5056,1676,-7032,-9071,-12227,-137,-59,351
-32768,5368,728,-6768,-7645,-12764,-125,-45,346
-30200,5840,-136,-6392,-6173,-13243,-130,-54,341
-26848,6016,-908,-6153,-4579,-13537,-125,-35,340
-24880,6768,-1368,-6328,-2799,-13679,-121,-33,312
-24264,7696,-364,-6853,-549,-13555,-95,-20,310
-24520,7992,844,-7581,1703,-13000,-89,-4,285
-24592,8496,1996,-8327,3868,-12399,-55,29,264
-24752,9016,3312,-8741,6116,-11830,-26,58,249
-25784,9040,5416,-8922,8436,-10995,17,90,222
-27132,8876,7736,-9407,10627,-9747,84,136,221
-28048,8648,9708,-10205,12504,-8021,143,199,204
-28344,8120,11112,-10943,13990,-5817,203,280,230
-28020,7548,11888,-11366,15070,-3289,286,349,273
-27532,6216,13044,-11400,15847,-462,353,408,353
-25592,5176,13884,-11427,15978,2439,402,448,437
-23416,4192,13820,-11525,15174,5330,452,443,554
Sitting still on desk:

ax, ay, az, gx, gy, gz, mx, my, mz
544,348,8424,-2,-3,4,168,216,286
532,344,8408,-1,0,7,158,220,284
536,348,8384,4,5,3,157,213,273
544,352,8400,-5,-1,2,156,196,272
544,348,8404,-3,1,3,168,210,285
536,336,8412,-1,1,2,182,201,289
552,348,8428,-1,-2,3,164,215,260
552,344,8404,-1,5,-1,161,217,291
544,352,8384,-10,4,-2,161,202,282
548,352,8424,-10,0,1,146,218,274
532,348,8408,-1,-3,3,162,214,285
540,340,8384,-8,1,2,160,206,290
536,364,8404,-2,0,1,156,198,301
532,360,8408,0,0,5,142,219,279
552,356,8408,-3,1,4,163,218,280
532,364,8416,0,1,-2,152,202,289
540,336,8400,-3,-1,2,151,208,301
532,360,8388,-5,-5,2,154,196,294
540,344,8400,-2,1,1,169,210,278
544,344,8380,-2,3,4,166,203,289
544,344,8400,-1,4,0,159,215,282
524,352,8404,-5,5,-4,166,211,275

trying to get ax,ay near zero (level):


4,40,8412,-4,7,0,196,277,313
4,48,8400,-12,9,4,202,286,328
-16,24,8436,-8,7,0,199,294,335
-4,24,8424,9,3,0,206,285,324
-16,20,8432,2,-1,-2,201,288,327
0,16,8420,-4,-2,-7,193,290,328
4,32,8428,3,-1,-11,195,293,333
4,44,8396,8,-4,-13,201,287,322
4,80,8436,-18,-2,-15,192,288,329
4,40,8444,-25,4,-6,200,286,319
-16,48,8388,-12,-3,0,197,293,312
4,48,8396,-3,-2,-6,191,286,326
28,4,8420,4,0,-2,188,285,324
-4,52,8432,11,5,0,211,290,317

onehorse
03-15-2016, 07:08 AM
@Ben
I'd like to make the case for this faster 1/sqrtf() implementation again.

I made a mistake in testing this by changing the Mahony algorithm but not the Madgwick, which I am calling in the sketch. So, here is the comparison:

Method sensor fusion rate
sqrt 730 Hz
sqrtf 780 Hz
InvSqrt 815 Hz

the InvSqrt is indeed faster using the Madgwick algorithm (and i suspect the Mahony too) and is worth the effort. This was with the Teensy running at 72 Mhz.

mortonkopf
03-15-2016, 10:52 AM
just starting on the shield. ran erase everything, all good:

Flash Memory has 8388608 bytes.
Erasing ALL Flash Memory:
estimated wait: 20 seconds.
Yes, full chip erase is SLOW!
....................
Erase completed
actual wait: 24 seconds.

and then raw hardware test:

Raw SerialFlash Hardware Test

Read Chip Identification:
JEDEC ID: EF 40 17
Part Nummber: W25Q64FV
Memory Size: 8388608 bytes
Block Size: 65536 bytes

Reading Chip...

Writing 4096 signatures

Double Checking All Signatures:
all 4096 signatures read ok

Checking Signature Pairs
all 2047 signature pairs read ok

Checking Read-While-Write (Program Suspend)
write 256 bytes at 256
write time was 450 microseconds.
read-while-writing: 00 00 00 00 15 F5 95 4B
test passed, good read while writing

Checking Read-While-Erase (Erase Suspend)
erase time was 187406 microseconds.
erase correctly erased 65536 bytes
read-while-erasing: 00 00 00 00 15 F5 95 4B
test passed, good read while erasing

All Tests Passed :-)

Test data was written to your chip. You must run
EraseEverything before using this chip for files.
Will try and get on to using flash with POV APA102 this week.

mortonkopf
03-15-2016, 11:57 AM
Testing the NXPmotionsense with ws2811 led string, using as a tilt indicator. working well with FastLED test strip using simple cutoff values of -/+1500 in ax and ay directions

vid with micro controller hidden https://youtu.be/r2bdu4xeJmM
(hope that this is not against no showing of board rules)

PaulStoffregen
03-15-2016, 01:26 PM
@onehorse & defragster - I'm looking at the quaternonFilters file. The Madgwick look the same as this Arduino library (https://github.com/arduino-libraries/MadgwickAHRS) (which happens to have the infamous Carmack WTF inverse sqrt optimization (https://en.wikipedia.org/wiki/Fast_inverse_square_root#Overview_of_the_code)). Is there any reference for the source of the Mahony algorithm? Is it open source?

If Mahony is open source, I'd like to package it up into a similar library with the same API. I'm also working towards doing the same with Freescale's filter... but that's going to take me another day or two, since their code is very complicated.

PaulStoffregen
03-15-2016, 01:38 PM
I've updated the NXPMotionSense library (https://github.com/PaulStoffregen/NXPMotionSense) with an API very similar to Arduino's for Curie's IMU. This is intended to become the primary library for using the Prop Shield, so I'd like to ask everyone to please give it a try. Of course, comparisons against other code are always welcome.

The library has 2 examples so far. MadgwickIMU runs the sensor and Madgwick filter, printing roll/pitch/yaw. It works with the Processing visualization program on Arduino's page.

The other example is CalibrateMagnetometer (formerly named RawData). It's meant to be run with an OpenGL-based GUI (https://github.com/PaulStoffregen/IMUread) I've been developing. The GUI requires wxWidgets (which is a pain to set up with OpenGL support). On Linux, there's a non-wxWidgets command line program, which opens up another blank window for the OpenGL graphics. If anyone wants to give this a try, use "make imuread" to build only the command line version. If your Teensy isn't /dev/ttyACM0, edit the port name in imuread.h.

The GUI collects and shows hundreds of magnetometer readings. As you move the Teensy, it collects more and update the calibration. As you get a good calibration, you'll see the points form a nice sphere. When you're happy with the shape, press any key in the graphics window and it'll transmit the hard+soft iron calibration to Teensy, where it's stored in EEPROM. NXPMotionSense automatically reads the EEPROM and applied the calibration when you read the magnetometer as floating point. Results are reported in uTesla units.

Later today I'm going to add some bare necessities to the wxWidgets version (like being able to select the serial port, and a button to send the cal) and get Windows and Mac versions for you.

This is my first ever OpenGL program. I really need your help getting it tested on different versions of the operating systems and a variety of computers, especially with different graphics cards!

mortonkopf
03-15-2016, 02:05 PM
@Paul, for the MadgwickIMU to compile without errors I have had to add in the lines:
#include <Wire.h>
#include <EEPROM.h>

and install the MadgwickAHRS.h lib into my libraries folder.
https://github.com/arduino-libraries/MadgwickAHRS

Frank B
03-15-2016, 04:16 PM
As i understand it, both implementations are GNU General Public License: http://www.x-io.co.uk/open-source-imu-and-ahrs-algorithms/

The link "C Code" downloads a zip-file which contains both algorithms, code is written by Madgwick in both cases.

Paper by Mahony: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4608934&url=http%3A%2F%2Fieeexplore.ieee.org%2Fstamp%2Fsta mp.jsp%3Ftp%3D%26arnumber%3D4608934

http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4650766&url=http%3A%2F%2Fieeexplore.ieee.org%2Fstamp%2Fsta mp.jsp%3Ftp%3D%26arnumber%3D4650766 (http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4608934&url=http%3A%2F%2Fieeexplore.ieee.org%2Fstamp%2Fsta mp.jsp%3Ftp%3D%26arnumber%3D4608934)

PaulStoffregen
03-15-2016, 05:34 PM
@Paul, for the MadgwickIMU to compile without errors I have had to add in the lines:
#include <Wire.h>
#include <EEPROM.h>


Oh, opps. Fixed (https://github.com/PaulStoffregen/NXPMotionSense/commit/204ece7829c1d52046c23df7f208a41d37cbfe67). I've been testing on Arduino 1.6.8 which automatically discovers the libs.

mortonkopf
03-15-2016, 05:47 PM
aha.. You found me out (i'm running 1.6.5.....)

Frank B
03-15-2016, 06:08 PM
Play sounds stored in flash memory. However to do this, you need to be able to download sounds to the flash memory (such as the zmodem thread that went by a few days ago

USB takes care about tx/rx errors. No need to add an additional protocol.

I posted the "easiest" way to transfer data yesterday. It's not optimal due to other issues, i know.
Currently, i'm writing better a data-transfer-tool which uses RAW_HID. I miss something like this for a long time, and now it's time to finally do it:)
It will allow to use several devices which are connected to the teensy - one is external flash.

PaulStoffregen
03-15-2016, 06:25 PM
Currently, i'm writing better a data-transfer-tool which uses RAW_HID. I miss something like this for a long time, and now it's time to finally do it:)


Wanna take a look at MTP instead?

blackketter
03-15-2016, 06:29 PM
My prop shield arrived last night and am inspecting it. Lovely.

My first observation is that it would be great if the pin headers and socket were shorter, it seems unnecessary to have 11mm of space between the boards.
I'm considering soldering the header directly to both boards and avoid the socket. Anybody think this is a terrible idea? (I can put the RTC crystal on the top of the Teensy PCB...)

Frank B
03-15-2016, 06:36 PM
Wanna take a look at MTP instead?

My problem is: I don't know, how.. and i don't want to read tons of docs.
Do you have some consice information ?

PaulStoffregen
03-15-2016, 07:05 PM
My problem is: I don't know, how.. and i don't want to read tons of docs.
Do you have some consice information ?

Nope, I only have the PTP and MTP specs from www.usb.org. Well, I also bought a Sandisk MP3 player which implements MTP (intended for reverse engineering), but apparently it has a buggy implementation that Linux rejects, but Windows allows. Truth is, I'm still figuring this protocol out too, and the MTP spec leaves a lot to be desired. :(

JBeale
03-15-2016, 08:03 PM
>...soldering the header directly to both boards...
I did that with the first audio shield. It has the obvious consequence that you won't be re-using that Teensy again for other purposes, at least not without a lot of work. If you already know that your particular Prop Shield has no hardware problems, and you'll never want to access the inner surface or use it or the Teensy standalone or mount it differently, then go ahead.

blackketter
03-15-2016, 08:30 PM
Nope, I only have the PTP and MTP specs from www.usb.org. Well, I also bought a Sandisk MP3 player which implements MTP (intended for reverse engineering), but apparently it has a buggy implementation that Linux rejects, but Windows allows. Truth is, I'm still figuring this protocol out too, and the MTP spec leaves a lot to be desired. :(

I worry that MTP isn't widely supported.

I know that there has been some effort towards support of Mass Storage Device class and understand that there are some issues, especially surrounding the teensy and host arbitrating read and write. It seems, though, for a majority of applications that there will only be a single writer (i.e. the host loads up files on the teensy or the teensy writes some log files).

It makes the most sense to me to have a Teensy MSD library make the sketch decide if it's a writer (i.e. it can only open files for write and not read) or a reader (it can only open files for read and not write). When the sketch is a writer, the host sees a write locked device. When the sketch is a reader, it waits until the host has unmounted the device before reading safely.

I'd love to be able to plug in my teensy, drag a file or two to it and then unmount it and reboot on a battery and have the teensy then have access to the files.

MichaelMeissner
03-15-2016, 08:51 PM
FWIW, I wanted to connect my Samsung Galaxy S5 to my Linux computer recently via USB. The last time I had connected a phone as a remote disk, it was when I had my Samsung Galaxy S2, which supported USB mass storage. However, the S5 no longer supports USB mass storage, and only supports MTP. I discovered that even after I loaded the simple-mtpfs program on my Fedora 22 system, it no longer auto mounts, and I had to explicitly use simple-mtpfs to mount things by hand. Progress I guess (more, it reminds me of what I needed to do 5+ years ago).

Anyway, you might look at what the LInux support looks like (https://github.com/phatina/simple-mtpfs), but not it is licensed by the FSF, so be sure that you are comfortable with the copyright.

onehorse
03-15-2016, 09:01 PM
If Mahony is open source, I'd like to package it up into a similar library with the same API.

Madgwick and Mahony algorithms are open source. Frank listed the references and I have been using them (https://github.com/kriswiner/MPU-9250) (re-written for Arduino and readability) that way for two years.

Frank B
03-15-2016, 09:09 PM
I think i have my result faster with my RAW_HID idea.
It can be used from commandline, from a script - and you can drag'n drop files to it if you place it on the desktop (as with every commandline tool)

More than i need :)
( i'll publish it on GitHub in a few days - if someone is interested and has additional ideas: mail me)

pictographer
03-15-2016, 10:33 PM
[...] NXPMotionSense library (https://github.com/PaulStoffregen/NXPMotionSense) [...] I'd like to ask everyone to please give it a try.

Been using code like this make a crude realtime visualization in the serial monitor.



int16_t x = 10.0f * logf(10.0f * (mag[0] < 1.0f ? 1.0f : mag[0]));
Serial.println(
"999999999 888888888 777777777 66666666 555555555 "
"444444444 333333333 222222222 111111111 000000000" + (100 - x));


Looks promising. Once I got an initialization error from one of the sensors and needed to power cycle the board. If it happens again, I'll make note of which device it was.

MichaelMeissner
03-15-2016, 10:34 PM
Yeah, using RAW_HID is probably simpler if you can do it on Windows and Mac systems.

Frank B
03-15-2016, 11:02 PM
Yes, i use code from Pauls example which can be compiled on Linus, Windows, and MAC.

(at the moment i have problems with argp.h which seems not to be available for mingw - i use a Lubuntu virtual machine to compile.
i think i have remove that from my already written code and work with getopt instead..and i hope that it works :) )

KurtE
03-15-2016, 11:27 PM
My Adafruit parts arrived :D Now time to assemble.

Now for some dumb questions ;) Are most people installing with prop shield above or below the T3.2? Are you using the 14x1 sockets and headers. I assume you would still need to connect up the pins on the A14/Dac row as well.
Thanks

PaulStoffregen
03-15-2016, 11:31 PM
Ok, here's the first beta test for the magnetic calibration gui:

Linux 64 bit: (32 bit coming later...)
http://www.pjrc.com/teensy/beta/imuread/gui.linux64

Macintosh:
http://www.pjrc.com/teensy/beta/imuread/gui.mac.zip

Windows
http://www.pjrc.com/teensy/beta/imuread/gui.exe

To use this, first program your board with the NXPMotionSense CalibrateMagnetometer example. Open the serial monitor to check that it's rapidly printing raw data (9 comma separated fields).

Then close the serial monitor, and run this program. Use the Port menu to select the serial port.

As you move the prop shield around, you should see red dot appear as magnetic calibration data is logged. If things go well, the data should form a sphere that rotates perfectly centered. The "hard iron" cal is how well the sphere turns on its center, and the "soft iron" is how spherical it looks.

This thing has a LOT of rough edges still. The GUI is pretty spartan, and there's no visual feedback about many little things. Good GUIs take a lot of work. At this very early stage, I'm mainly just looking to find out if it works at all? If it does run, how much CPU load does it put on your machine? Is your video card's GPU able to keep up?

PaulStoffregen
03-15-2016, 11:34 PM
Also, please let me know if are you able to resize the window? If you can, does the graphic part grow as you change the window size?

Ben
03-16-2016, 12:11 AM
The GUI behaves as you describe. Visually the red-dot sphere rotates around it's center. I'm on Windows 7 Professional SP1 and i can _not_ resize the window.
Also, while my teensy/prop shield are not moving, the sphere slowly rotates. is this normal?
The dot's are more or less all on the sphere surface, with the exception of maybe 6-8 points after swinging the teensy/shield to cover the whole sphere surface for about 15 seconds.
The "File" -> "Send Calibration" option is greyed out. So I actually can't calibrate the compass.
The "Communication" and "Gyroscope" areas are empty boxes in the window.

If you wish I can add screenshots

-Ben

Edit: After letting the GUI sit there connected to the teensy/prop for a minute the "Send Calibration" option is no longer greyed out. I sent the cal and restarted by deselceting and selecting the com port. Visually I think the sphere looks a bit better now, bit this may be expectation bias.

blackketter
03-16-2016, 12:12 AM
Got the following message when clicking on the menus the first launch on OS X:
6682

johnnyfp
03-16-2016, 12:12 AM
I'm assuming the NXPMotionSense CalibrateMagnetometer example is from your Github repo. In which case there is an issue with the update() method int the NXPMotionSense.cpp where you don't set newdata=1 for any new data. So nothing is outputted.

EG


void NXPMotionSense::update()
{
static elapsedMillis msec;
int32_t alt;

if (FXOS8700_read(accel_mag_raw)) { // accel + mag
//Serial.println("accel+mag");
}
if (MPL3115_read(&alt, &temperature_raw)) { // alt
//Serial.println("alt");
}
if (FXAS21002_read(gyro_raw)) { // gyro
//Serial.println("gyro");
newdata = 1;
}
}


Should be


void NXPMotionSense::update()
{
static elapsedMillis msec;
int32_t alt;

if (FXOS8700_read(accel_mag_raw)) { // accel + mag
//Serial.println("accel+mag");
newdata = 1;
}
if (MPL3115_read(&alt, &temperature_raw)) { // alt
//Serial.println("alt");
newdata = 1;
}
if (FXAS21002_read(gyro_raw)) { // gyro
//Serial.println("gyro");
newdata = 1;
}
}

pawelsky
03-16-2016, 12:12 AM
Here's newer code to read all the motion sensors.

https://github.com/PaulStoffregen/NXPMotionSense

Paul,

did you consider using the 1.5 library format (https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5:-Library-specification) to take advantage of the new library manager (https://github.com/arduino/Arduino/wiki/Library-Manager-FAQ) and autoupdate?

KurtE
03-16-2016, 12:33 AM
I attached the boards and I am running the Gui test on Windows 10. I do see the read dots, and not resize the window.

Kurt

defragster
03-16-2016, 12:35 AM
Are most people installing with prop shield above or below the T3.2? Are you using the 14x1 sockets and headers. I assume you would still need to connect up the pins on the A14/Dac row as well. Thanks

For me - I debated for some hours . . . and then I under pinned a T_3.2 and did top header on the Prop board. I put pins across the T_3.2 power/DAC end too (not included). I'm okay with it working like this. I also pulled 9 short header pins and changed for 9 long header pins to attach the onehorse Serial2 ESP8266 unit below that since I had top headers on that ESP unit it works - but stands a gross 1 1/4 inches tall . Avoided all the active Prop pins on that end.

To get this I cut and un-soldered some header pins before (the T_3.2 was pinned under the ESP8266) - the Prop board is probably stuck with header on top - the ESP could still be adjusted again.

Ben
03-16-2016, 12:44 AM
For me - I debated for some hours . . . and then I under pinned a T_3.2 and did top header on the Prop board.

Same here, but I didn't connect the 5 pins on the short side. For the Prop shield only the A14/DAC pin is needed, and I haven't yet tried out the speaker. I have ordered female headers like the ones that came with the Prop Shield and will use these on the short side once they arrive.
If I really couldn't wait to try the speaker a straight bent paperclip would be my solution for the DAC connection. But I'm playing it safe since it would be a shame if i wrecked my prop shield. It's currently resting on it's ESD-safe throne ;)

defragster
03-16-2016, 12:46 AM
Also, please let me know if are you able to resize the window? If you can, does the graphic part grow as you change the window size?

On Windows I cannot resize the window. Maximize and titlebar icon is grey, and no resize borders. Image below with a yellow highlight where I see the active jitter as it sits after waving it around.
6683
I powered down and pulled off the ESP board and the speaker - then wiggled it around on the USB cable and got the second rounder image.
6684
<edit>: interesting VOID area persists after sitting and moving - it is visible in the _Cal2 image.

KurtE
03-16-2016, 01:31 AM
Thanks, for now, I went with the T3.2 above. I cut another Arduino expansion header to size to fit the center pins (actually a few attempts), with file and like to get them to fit properly... I then used some extra long breakaway headers (https://www.adafruit.com/products/400), that I soldered to T3.2, so the bottom part connects into the shield headers, and they extend up above the Teensy such that I can hook up jumpers and/or Logic Analyzer...

Next up hook up Dotstar. Currently trying to decide what connectors I want to use...

Wozzy
03-16-2016, 02:28 AM
I soldered up headers to my PropShield today.
I downloaded and installed Arduino 1.6.8 and Teensyduino 1.28B1 without issues.
I have a Teensy 3.1 plugged into the PropShield.
My PC is a 3.4 Mhz 6-core Haswell-E running Windows 10 with an AMD Radeon R9-200 graphics board

I compiled the MadgwickIMU program at 120 Mhz and it seemed to compile and run fine.
I compiled the CalibrateMagnetometer program at 120 Mhz and it seemed to compile and run fine.
When running the Windows IMU.exe program, Windows Sysinternals Process Explorer (https://technet.microsoft.com/en-us/sysinternals/bb896653) shows less than 5% CPU usage and less than 3% GPU usage.
The graphics window seem smooth and responsive.
I ran FRAPS (http://www.fraps.com/) on the GUI window and it reported a consistent 21 frames/second.
On my system I am unable to resize or maximize the window.I am unable to catch the corner to drag to resize, and the maximize Icon in the upper left corner is greyed out.

Here's screencap with FRAPS running:
6688

MichaelMeissner
03-16-2016, 03:23 AM
I finally soldered my 3.2 to the shield and switched to that. I updated my sources, and moved on to Arduino 1.6.8 to run the CalibrateMagnetnometer example. The first few times I ran it, I kept getting a configuration error, but now it runs fine.

On my Fedora 22 system, I can resize the window, and the graphic inside DOES resize. I am using the mate window manager.

JBeale
03-16-2016, 05:20 AM
I was able to mostly fill in the calibration sphere by much trial and error, slowly pointing the board in different directions. I clicked on the item to load the calibration but I don't know if it did anything.
6690
To compile the Madgwick example I had to separately download the library from https://github.com/arduino-libraries/MadgwickAHRS

The Madgwick sketch driving the orientation display example in Processing sort of works, but there are some regions where the graphical motion wobbles in a way the board doesn't, and some angles where the image abruptly flips 180 degrees when the real board turns smoothly. Maybe the calibration didn't get loaded, or used, or wasn't accurate enough? Or it's some kind of "gimbal lock" coordinate difficulty (if that's even meaningful with this type of sensor?)

PaulStoffregen
03-16-2016, 10:47 AM
I've added the advanced Freescale sensor fusion algorithm to the NXPMotionSense library (https://github.com/PaulStoffregen/NXPMotionSense).

There's a new "Orientation" example showing how to use it. I tried to keep the API very similar to the existing Madgwick library. The same Processing sketch can be used to view the results.

PaulStoffregen
03-16-2016, 10:55 AM
I've also updated the magnetic calibration utility for Mac and Windows. The only (intentional) change is fixing the window resize bug.

http://www.pjrc.com/teensy/beta/imuread/gui.mac.zip

http://www.pjrc.com/teensy/beta/imuread/gui.exe

To use the Freescale sensor fusion, you must complete the calibration process (hopefully with a nice round & centered sphere) at least once. After you send the calibration to Teensy, it's stored in the non-volatile EEPROM memory.

MichaelMeissner
03-16-2016, 12:11 PM
It might be useful in NXPMotionSense.h and in the library documentation to note that bytes 76-127 of the EEPROM space are used by the calibration part of the library.

It might be useful to switch the reading and writing of the EEPROM information to use eeprom_read_block and eeprom_write_block, rather than iterating byte by byte.

mortonkopf
03-16-2016, 12:17 PM
@Paul, it might be useful to include a link to the madgwickAHRS lib, or add in the lib within the nxpmotionsense lib. The madgwickAHRS licence is:

License

Copyright (c) Arduino LLC. All right reserved.

This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.

Ben
03-16-2016, 12:19 PM
the updated gui is resizable on Win7Pro SP1. Looks good. A feedback whether the cal data was written to EEPROM successfully would be nice. I know I'ts not in line with the linux philosophy of "only talk if something went wrong", but as a windows user I expected some popup with a message at that point. Does the NXPMotionSense lib support reading the cal data back from the EEPROM?

Maybe we should collect some cal data samples and look for an average? PJRC could program that average to the prop shield with the bed-of-nails test jig I'm sure Paul has to enhance initial accuracy and customer experience?

Edit: I still see the sphere rotate while the PropS is stationary, is this normal? The "wiggle" where red dots are updated rotates with the sphere and thus is stationary relative to all dots.

PaulStoffregen
03-16-2016, 04:23 PM
It might be useful in NXPMotionSense.h and in the library documentation to note that bytes 76-127 of the EEPROM space are used by the calibration part of the library.

Yes, agreed. The details like location are likely to change somewhat before the final release.

If I forget, please remind me of this after I've made a page to document the library.



It might be useful to switch the reading and writing of the EEPROM information to use eeprom_read_block and eeprom_write_block, rather than iterating byte by byte.

Are those functions available through Arduino's EEPROM library API? Even though Teensyduino emulates the avr-libc eeprom functions, I'd prefer to use only Arduino's API. I like to imagine a world where things aren't hard coded to AVR...



A feedback whether the cal data was written to EEPROM successfully would be nice.


Yes, this is on my list. :)



Does the NXPMotionSense lib support reading the cal data back from the EEPROM?


No, not yet, but it probably should.



PJRC could program that average to the prop shield with the bed-of-nails test jig


I've seriously considered doing something like this. The W25Q64 flash chip does have a 256 byte area which can be used for serial numbers or other stuff. I believe those 256 bytes survive the normal chip erase, but I haven't tested.

But calibration here is not so simple. We can't possibly collect enough motion data during the brief time it's pressed onto the pogo pins, where it stays in pretty much the same orientation the entire time. To calibrate the sensor here, we'd have to add another test where a person (or specially built machine) does the cal, similar to how you're doing it. Doing this would significantly increase the cost. I believe we're on target for the "wit" version to retail at approx $20.

I also *really* want people to run the cal, so they can see the data. Especially when something interferes with the magnetometer, figuring out why things don't work is almost impossible without this visualization (trust me... I've spent a lot of frustrating time, only to later learn there's a lot of strong but localized magnetic fields in various places around my workbench). This is the main reason I've delayed the prop shield for months.... to figure out this cal with opengl visualization, to make the magnetometer function observable and apparent.



I still see the sphere rotate while the PropS is stationary, is this normal?


No, that's a bug. Or if not a bug, certainly not working as well as I'd like. I have a couple ideas/theories I'm going to try. As you can see in the source code (https://github.com/PaulStoffregen/IMUread), these algorithms are quite complicated. Not entire sure if I'll be able to fully fix this one.



The "wiggle" where red dots are updated rotates with the sphere and thus is stationary relative to all dots.

That wiggling is the new data being added, but usually replaced immediately by the next new data. It actually happens faster than the GUI refresh rate.

Much of the work left to do involves algorithms to show metrics of the quality of your sphere, and for new data to tend to replace previously collected data that's not as good. This turns out to be a pretty difficult problem. Earlier I put a couple solid days into the code we have now... but it's far from where I want it to be. Much work remains to be done....

PaulStoffregen
03-16-2016, 04:46 PM
@Paul, it might be useful to include a link to the madgwickAHRS lib

Done.
https://github.com/PaulStoffregen/NXPMotionSense/commit/ebefe88b0da934e5bd35a07b77e4ee7654a3ee2d

defragster
03-16-2016, 05:25 PM
New version is nicely Windows resizable. Good uniform sphere. Did Send Calibration.

opps - reached to right and sphere got odd ... got near (couple inches) a magnetic closure on a phone wallet - repeated to be sure and the sphere went super nova.

Can LED do a sign of life blink? I tapped the unit on my ring and the GUI display stopped - don't know If I took it offline - restarted fine.

A couple times I start it up and it shows no dot data - turn of monitor none and back, nothing. Then none, TYQT monitor see's streaming data - monitor off and back to GUI port and there it is.

Frank B
03-16-2016, 05:32 PM
Calibration test:

My system is a Core i5 3570K @ max 3.4 GHz 8GB Ram, AMD Radeon 7700 Series GPU
Running gui.exe after a while 5..7% CPU Usage, GPU between 0.6.. 2.2%

I got a nice sphere, despite of my compact build with an additional "connector"board between the prop-shield chips and the Teensy,

Closing gui.exe gives an error:

"Gui.exe funktioniert nicht mehr.
Programm schliessen.
Program Debuggen"

(gui exe stopped working)

Ben
03-16-2016, 05:33 PM
No, that's a bug. Or if not a bug, certainly not working as well as I'd like. I have a couple ideas/theories I'm going to try. As you can see in the source code (https://github.com/PaulStoffregen/IMUread), these algorithms are quite complicated. Not entire sure if I'll be able to fully fix this one.
It might be a problem with my hardware, sometimes when I move the Shield, like when filling the cal gui with data points, the orientation begins to drift on all axes in a weird but repeatable pattern. I'm using the "Orientation" example modified to 2000ms update intervals right now to record this behaviour on the arduino serial plotter. I'll edit a screenshot here in a couple minutes.

Edit:
6703

PaulStoffregen
03-16-2016, 06:13 PM
Any chance you could try this with the Magdwick & Mahony filters?

Ben
03-16-2016, 06:32 PM
Of course, but I don't actually know how :rolleyes: I'm more of a hardware guy... so any help/hint appreciated!

PaulStoffregen
03-16-2016, 06:34 PM
Use the MagdwickIMU example that comes with the library. Maybe grab the latest copy of the library, which has a little more documentation in the comments.

PaulStoffregen
03-16-2016, 06:37 PM
I started running the Orientation example, with the printing interval edited to 2500 ms.

Here's what I'm seeing so far:

6704

Ben
03-16-2016, 06:41 PM
Okay, expect results in about an hour, wife's home, dinner time!

Pedvide
03-16-2016, 07:38 PM
I've tried the GUI and the orientation sketches and both work as expected (although it'd be nice if the gui told you that the "Send calibration" was completed correctly).
This is really nice piece of hardware and together with this software it's really nice!

Ben
03-16-2016, 07:50 PM
Magdwick:
6705

Mahony:
6706

doesn't look good...

onehorse
03-16-2016, 08:09 PM
See here (https://github.com/kriswiner/Teensy_Prop_Shield) for a different(?) implementation of the Madgwick filter.

Make sure you pass the filter the data in the correct (for NED convention) order:


// Sensors x (y)-axis of the accelerometer/magnetometer is aligned with the x (y)-axis of the gyro on the prop shield;
// All three sensors have the positive z-axis up.
// The long axis of the prop shield is in the x-axis direction, which we will designate as North
// Then x is North, -y is East, and -z is Down for a NED convention
// Invert accel data since gravity == positive when up
// Pass gyro rate as rad/s
MadgwickQuaternionUpdate(-ax, ay, az, gx*PI/180.0f, -gy*PI/180.0f, -gz*PI/180.0f, mx, -my, -mz);

Also, if the mag is not calibrated for offset you will just get garbage.

JBeale
03-16-2016, 08:15 PM
Looks to me like Ben's system is not accurately calibrated, or not calibrated at all. It would be easier to debug if (1) there was some confirmation that the calibration data was written to memory and (2) some quality metrics on the calibration data (self-consistency) and maybe (3) some real-time monitoring for self-consistency, eg. does the currently measured field vector have the same magnitude as the original calibration did, and does the magnitude change with time? If it's too big that implies a local magnetic source. If it's too small, it means presence of an opposing field, or that you've moved into a magnetically shielded chamber, or well away from the planet's surface...

PaulStoffregen
03-16-2016, 08:17 PM
I've been running it here for 2 hours. I changed the code to print once every 10 seconds. Here's what I'm seeing with the Orientation example.

6707

Edit: this was with the Teensy and Prop Shield hanging on the end of a short USB cable, dangling off a USB hub that's mounted to the side of my workbench.

onehorse
03-16-2016, 08:19 PM
Paul, In your Madgwick implementation it looks like you are not using the mag data at all. Do I understand this correctly? In this case the gyro drift will be all too apparent very quickly...

PaulStoffregen
03-16-2016, 08:24 PM
Looks to me like Ben's system is not accurately calibrated, or not calibrated at all.


Yeah, my first guess is maybe the calibration didn't get properly written to EEPROM.



It would be easier to debug if (1) there was some confirmation that the calibration data was written to memory and (2) some quality metrics on the calibration data (self-consistency)


Yes, I'm working on these. I plan to have both later this week.

I'm also going to polish the GUI quite a bit, but that might happen over the weekend or early next week.



and maybe (3) some real-time monitoring for self-consistency, eg. does the currently measured field vector have the same magnitude as the original calibration did, and does the magnitude change with time? If it's too big that implies a local magnetic source. If it's too small, it means presence of an opposing field, or that you've moved into a magnetically shielded chamber, or well away from the planet's surface...

That sounds really useful. I'll expand the calibration to 56 bytes tomorrow. All the existing EEPROM-stored cals will become invalid to the new code. This is a beta test, afterall...

PaulStoffregen
03-16-2016, 08:30 PM
Paul, In your Madgwick implementation it looks like you are not using the mag data at all. Do I understand this correctly? In this case the gyro drift will be all too apparent very quickly...

Yeah, by default the magnetometer is only used by the Orientation example (https://github.com/PaulStoffregen/NXPMotionSense/blob/master/examples/Orientation/Orientation.ino).

If you look at the Madgwick example code (https://github.com/PaulStoffregen/NXPMotionSense/blob/master/examples/MadgwickIMU/MadgwickIMU.ino), you'll see there's a commented out line where it updates the filter. MadgwickAHRS supports either 6 or 9 input. I honestly haven't had much time to experiment with the 9 input version, and I probably won't for the next couple days while I'm working on improving the calibration app. I could really use some feedback on the 9 input Madgwick and Mahony filters, if anyone wants to test them.

Ben
03-16-2016, 09:02 PM
I recalibrated the mag and then ran the Madgwick example.
I tried all possible combinations of both Madgwick and Mahony with


// Update the Madgwick filter
//filter.updateIMU(gx, gy, gz, ax, ay, az);
//filter.update(gx, gy, gz, ax, ay, az, mx, my, mz);
filter.update(-gx, gy, gz, ax, -ay, -az, mx, -my, -mz);

but while they all compiled, nothing helped.

The third line of code was my try to adapt the NED-convention onehorse mentioned.

But all in all, as JBeale said, I can't confirm the mag config was written. So maybe changing the filters and its inputs' signs is barking up the wrong tree :confused:

-Ben

Edit: On the other hand, the roll/Pitch/Yaw even drifts with the mag data not used at all...

filter.updateIMU(gx, gy, gz, ax, ay, az);
...so it can't be missing calibration?

PaulStoffregen
03-16-2016, 09:05 PM
I've added a PrintCalibration example (https://github.com/PaulStoffregen/NXPMotionSense/blob/master/examples/PrintCalibration/PrintCalibration.ino), just now. :)

When you run it, the output should look similar to this.

6708

You'll get all zeros if the calibration is missing or invalid.

Ben
03-16-2016, 09:10 PM
My serial output:

Magnetic Calibration

Hard Iron Offset
41.88
-5.18
91.78

Soft Iron Mapping
0.9777 0.0009 -0.0118
0.0009 1.0017 0.0005
-0.0118 0.0005 1.0213

Expected Magnetic Field Strength
50.00 uT

looks ok.

mortonkopf
03-16-2016, 09:25 PM
using orientation sketch to output Yaw indication to APA102 leds using FastLED on pins 11 and 13 (I believe that the choice of pins 11 and 13 should cause FastLED to select Hardware SPI - but not sure on this)
(hardware covered)

https://youtu.be/zNKY0U7-Qzs


#include <NXPMotionSense.h>
#include <Wire.h>
#include <EEPROM.h>
#include <FastLED.h>

#define NUM_LEDS 11 //number of leds in strip length on one side
#define DATA_PIN 11
#define CLOCK_PIN 13
CRGB leds[NUM_LEDS];

NXPMotionSense imu;
NXPSensorFusion filter;

void setup() {
Serial.begin(9600);
imu.begin();
filter.begin();
// FastLED.addLeds<APA102, DATA_PIN, CLOCK_PIN>(leds, NUM_LEDS);
FastLED.addLeds<APA102, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
}

void loop() {
float ax, ay, az;
float gx, gy, gz;
float mx, my, mz;
float roll, pitch, heading;

if (imu.available()) {
// Read the motion sensors
imu.readMotionSensor(ax, ay, az, gx, gy, gz, mx, my, mz);

// Update the SensorFusion filter
filter.update(gx, gy, gz, ax, ay, az, mx, my, mz);
}

// roll = filter.getRoll();
// pitch = filter.getPitch();
heading = filter.getYaw();

if(heading<(-1)){
for (int x=0;x<4;x++){
leds[x]=CRGB(0,55,255);
FastLED.show();
}
}
if(heading>(1)){
for (int x=7;x<11;x++){
leds[x]=CRGB(200,155,0);
FastLED.show();
}
}
if(heading>(-1)&& heading<1){
for (int x=5;x<7;x++){
leds[x]=CRGB(0,155,0);
FastLED.show();
}
}

for (int x=0;x<NUM_LEDS;x++){
leds[x]=CRGB(0,0,0);
FastLED.show();
}
}


// Decide when to print
bool readyToPrint() {
static unsigned long nowMillis;
static unsigned long thenMillis;

// If the Processing visualization sketch is sending "s"
// then send new data each time it wants to redraw
while (Serial.available()) {
int val = Serial.read();
if (val == 's') {
thenMillis = millis();
return true;
}
}
// Otherwise, print 8 times per second, for viewing as
// scrolling numbers in the Arduino Serial Monitor
nowMillis = millis();
if (nowMillis - thenMillis > 125) {
thenMillis = nowMillis;
return true;
}
return false;
}

Ben
03-17-2016, 12:05 AM
I added code to CalibrateMagnetometer.ino to blink the LED slowly while the sketch runs. When a config is received and written to EEPROM, the Led blinks fast for two seconds.
https://github.com/PaulStoffregen/NXPMotionSense/compare/master...Ben-Rheinland:master

pictographer
03-17-2016, 01:17 AM
[Update: Also crashes without the LC plugged in. Can make it crash by running it and quitting without doing anything. Haven't been able to make the display show anything other than labels and blank content panes.]

Had an LC plugged in.
Launched the GUI application holding the control key to temporarily bypass the restrictions on application launching.
Plugged in my T 3.2 with Prop Shield.
Selected a port from the port menu.
The following error appeared:
6709
And here's what Apple's crash utility had to say:


Process: gui [77248]
Path: /Users/USER/Downloads/gui.app/Contents/MacOS/gui
Identifier: com.pjrc.teensy
Version: ??? (???)
Code Type: X86-64 (Native)
Parent Process: launchd [255]
Responsible: gui [77248]
User ID: 501


Date/Time: 2016-03-16 18:17:48.551 -0700
OS Version: Mac OS X 10.9.5 (13F1603)
Report Version: 11
Anonymous UUID: F4335842-4EF9-0B79-3DB7-D9A0441E0985




Crashed Thread: 0 Dispatch queue: com.apple.main-thread


Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000010


VM Regions Near 0x10:
-->
__TEXT 0000000100000000-000000010049a000 [ 4712K] r-x/rwx SM=COW /Users/USER/Downloads/gui.app/Contents/MacOS/gui


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.pjrc.teensy 0x000000010007669c wxMenu::DoRemove(wxMenuItem*) + 156
1 com.pjrc.teensy 0x000000010018471d wxMenuBase::DoDelete(wxMenuItem*) + 13
2 com.pjrc.teensy 0x00000001001847b2 wxMenuBase::Delete(wxMenuItem*) + 18
3 com.pjrc.teensy 0x0000000100032502 MyMenu::OnShowPortList(wxMenuEvent&) + 210
4 com.pjrc.teensy 0x00000001002d7f44 wxEvtHandler::ProcessEventIfMatchesId(wxEventTable EntryBase const&, wxEvtHandler*, wxEvent&) + 84
5 com.pjrc.teensy 0x00000001002d8f64 wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) + 132
6 com.pjrc.teensy 0x00000001002d9023 wxEvtHandler::TryHereOnly(wxEvent&) + 67
7 com.pjrc.teensy 0x00000001002d90bb wxEvtHandler::ProcessEventLocally(wxEvent&) + 59
8 com.pjrc.teensy 0x00000001002d9125 wxEvtHandler::ProcessEvent(wxEvent&) + 69
9 com.pjrc.teensy 0x00000001002d8ac6 wxEvtHandler::SafelyProcessEvent(wxEvent&) + 22
10 com.pjrc.teensy 0x00000001001ccfe0 wxWindowBase::HandleWindowEvent(wxEvent&) const + 16
11 com.pjrc.teensy 0x0000000100075dc5 wxMenu::DoHandleMenuEvent(wxEvent&) + 69
12 com.pjrc.teensy 0x0000000100076b89 wxMenu::DoHandleMenuOpenedOrClosed(int) + 89
13 com.apple.AppKit 0x00007fff8e0df1aa -[NSMenu _populateFromDelegateWithEventRef:] + 337
14 com.apple.AppKit 0x00007fff8e0dc189 -[NSMenu _populateWithEventRef:] + 80
15 com.apple.AppKit 0x00007fff8e0de2e0 -[NSCarbonMenuImpl _carbonPopulateEvent:handlerCallRef:] + 431
16 com.apple.AppKit 0x00007fff8e0ddff6 NSSLMMenuEventHandler + 716
17 com.apple.HIToolbox 0x00007fff916431d4 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 892
18 com.apple.HIToolbox 0x00007fff91642787 SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 385
19 com.apple.HIToolbox 0x00007fff916425f7 SendEventToEventTargetWithOptions + 43
20 com.apple.HIToolbox 0x00007fff91688d18 SendMenuPopulate(MenuData*, OpaqueEventTargetRef*, unsigned int, double, unsigned int, OpaqueEventRef*, unsigned char*) + 277
21 com.apple.HIToolbox 0x00007fff916a4f19 SendMenuOpening(MenuSelectData*, MenuData*, double, unsigned int, unsigned int, __CFDictionary*, unsigned char, unsigned char*) + 279
22 com.apple.HIToolbox 0x00007fff916c7651 DrawTheMenu(MenuSelectData*, __CFArray**, unsigned char, unsigned char*) + 194
23 com.apple.HIToolbox 0x00007fff916c7459 MenuChanged(MenuSelectData*, unsigned char, unsigned char) + 375
24 com.apple.HIToolbox 0x00007fff916b4c1c TrackMenuCommon(MenuSelectData&, unsigned char*) + 1476
25 com.apple.HIToolbox 0x00007fff916c6f70 MenuSelectCore(MenuData*, Point, double, unsigned int, OpaqueMenuRef**, unsigned short*) + 441
26 com.apple.HIToolbox 0x00007fff916c6cb1 _HandleMenuSelection2 + 446
27 com.apple.AppKit 0x00007fff8e05062c _NSHandleCarbonMenuEvent + 284
28 com.apple.AppKit 0x00007fff8deaf52e _DPSNextEvent + 2170
29 com.apple.AppKit 0x00007fff8deae89b -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
30 com.apple.AppKit 0x00007fff8dea299c -[NSApplication run] + 553
31 com.pjrc.teensy 0x00000001000d253e wxGUIEventLoop::OSXDoRun() + 254
32 com.pjrc.teensy 0x00000001002b00ef wxCFEventLoop::DoRun() + 31
33 com.pjrc.teensy 0x000000010022c936 wxEventLoopBase::Run() + 86
34 com.pjrc.teensy 0x00000001001f7ae7 wxAppConsoleBase::MainLoop() + 103
35 com.pjrc.teensy 0x000000010008ee87 wxApp::OnRun() + 39
36 com.pjrc.teensy 0x000000010025c00d wxEntry(int&, wchar_t**) + 141
37 com.pjrc.teensy 0x0000000100030d04 main + 20
38 com.pjrc.teensy 0x0000000100030bd8 start + 52


Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0 libsystem_kernel.dylib 0x00007fff8d109662 kevent64 + 10
1 libdispatch.dylib 0x00007fff9131d421 _dispatch_mgr_invoke + 239
2 libdispatch.dylib 0x00007fff9131d136 _dispatch_mgr_thread + 52


Thread 2:
0 libsystem_kernel.dylib 0x00007fff8d104a1a mach_msg_trap + 10
1 libsystem_kernel.dylib 0x00007fff8d103d18 mach_msg + 64
2 com.apple.CoreFoundation 0x00007fff84de0f15 __CFRunLoopServiceMachPort + 181
3 com.apple.CoreFoundation 0x00007fff84de0539 __CFRunLoopRun + 1161
4 com.apple.CoreFoundation 0x00007fff84ddfe75 CFRunLoopRunSpecific + 309
5 com.apple.AppKit 0x00007fff8e04f05e _NSEventThread + 144
6 libsystem_pthread.dylib 0x00007fff84fc0899 _pthread_body + 138
7 libsystem_pthread.dylib 0x00007fff84fc072a _pthread_start + 137
8 libsystem_pthread.dylib 0x00007fff84fc4fc9 thread_start + 13


Thread 3:
0 libsystem_kernel.dylib 0x00007fff8d108e6a __workq_kernreturn + 10
1 libsystem_pthread.dylib 0x00007fff84fc1f08 _pthread_wqthread + 330
2 libsystem_pthread.dylib 0x00007fff84fc4fb9 start_wqthread + 13


Thread 4:
0 libsystem_kernel.dylib 0x00007fff8d108e6a __workq_kernreturn + 10
1 libsystem_pthread.dylib 0x00007fff84fc1f08 _pthread_wqthread + 330
2 libsystem_pthread.dylib 0x00007fff84fc4fb9 start_wqthread + 13


Thread 5:: com.apple.appkit-heartbeat
0 libsystem_kernel.dylib 0x00007fff8d108a3a __semwait_signal + 10
1 libsystem_c.dylib 0x00007fff8d083dd4 nanosleep + 200
2 libsystem_c.dylib 0x00007fff8d083cc6 usleep + 54
3 com.apple.AppKit 0x00007fff8e11317d -[NSUIHeartBeat _heartBeatThread:] + 2132
4 com.apple.Foundation 0x00007fff92135d8b __NSThread__main__ + 1318
5 libsystem_pthread.dylib 0x00007fff84fc0899 _pthread_body + 138
6 libsystem_pthread.dylib 0x00007fff84fc072a _pthread_start + 137
7 libsystem_pthread.dylib 0x00007fff84fc4fc9 thread_start + 13


Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x0000000100505c10 rbx: 0x000000010071cb40 rcx: 0x00000000000fc080 rdx: 0x000000000003dbf0
rdi: 0x000000010069da00 rsi: 0x0000000091120003 rbp: 0x00007fff5fbfe3d0 rsp: 0x00007fff5fbfe3a0
r8: 0x000000010109d510 r9: 0x000000010109e6e0 r10: 0x000000006d32caeb r11: 0x00000000db13e675
r12: 0x000000010104a950 r13: 0x0000000000000000 r14: 0x0000000000000004 r15: 0x0000000100773ef0
rip: 0x000000010007669c rfl: 0x0000000000010246 cr2: 0x0000000000000010

Logical CPU: 0
Error Code: 0x00000004
Trap Number: 14




Binary Images:
0x100000000 - 0x100499ff7 +com.pjrc.teensy (??? - ???) <A232C836-DF59-8B70-7235-D93CBCEA6EB0> /Users/USER/Downloads/gui.app/Contents/MacOS/gui
0x10068f000 - 0x100693fff com.apple.agl (3.2.3 - AGL-3.2.3) <21798BC5-8F01-345B-B27B-1037CF71D166> /System/Library/Frameworks/AGL.framework/Versions/A/AGL
0x101692000 - 0x101698ff7 libCGXCoreImage.A.dylib (599.35.12) <561A549F-2E79-38B8-90E3-115D3D6038BB> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXCoreImage.A.dylib
0x1016b1000 - 0x1016b1ffb +cl_kernels (???) <92D80B5E-13FF-4C67-AE96-C3412174CEA1> cl_kernels
0x1017dd000 - 0x1017e5ff3 libCGCMS.A.dylib (599.35.12) <E27B2C59-AC0B-3B1F-86BC-FF0B9C7743F8> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGCMS.A.dylib
0x1017ed000 - 0x1017f0ffa libCGXType.A.dylib (599.35.12) <48401CB4-1E4C-3BC4-96AB-272067F622B5> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib
0x1036f6000 - 0x10371effb libRIP.A.dylib (599.35.12) <B2F65393-2660-36FB-B5A4-082481E27704> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib
0x103a3a000 - 0x103a45fff libGPUSupport.dylib (9.6.5) <7262B5E5-AA02-3916-9E78-071502F4F1BE> /System/Library/PrivateFrameworks/GPUSupport.framework/Versions/A/Libraries/libGPUSupport.dylib
0x103a4c000 - 0x103a75fff GLRendererFloat (9.6.5) <D216C628-95EC-346C-A4EE-C88A750ADF5F> /System/Library/Frameworks/OpenGL.framework/Resources/GLRendererFloat.bundle/GLRendererFloat
0x1051d8000 - 0x105378ff7 GLEngine (9.6.5) <30643C97-7EBB-36EE-BEEA-13844EA0F680> /System/Library/Frameworks/OpenGL.framework/Resources/GLEngine.bundle/GLEngine
0x106000000 - 0x10674aff7 libclh.dylib (4.0.3 - 4.0.3) <355B99B6-B262-346C-899D-B674873A389F> /System/Library/Extensions/GeForceTeslaGLDriver.bundle/Contents/MacOS/libclh.dylib
0x108097000 - 0x10817dfef unorm8_bgra.dylib (2.3.58) <641EC871-01E8-301F-8695-B92993AD7E23> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/ImageFormats/unorm8_bgra.dylib
0x123440000000 - 0x12344086dfff com.apple.GeForceTeslaGLDriver (8.24.17 - 8.2.4) <E7BF5771-102B-3DD1-AD4A-E62606132A0E> /System/Library/Extensions/GeForceTeslaGLDriver.bundle/Contents/MacOS/GeForceTeslaGLDriver
0x7fff67e4a000 - 0x7fff67e7d817 dyld (239.4) <042C4CED-6FB2-3B1C-948B-CAF2EE3B9F7A> /usr/lib/dyld
0x7fff84cc4000 - 0x7fff84cdcfff libexpat.1.dylib (12) <97F4A9A7-CB3E-3BBF-9314-4997FC770E52> /usr/lib/libexpat.1.dylib
0x7fff84cdd000 - 0x7fff84cddffd com.apple.audio.units.AudioUnit (1.10 - 1.10) <68B21135-55A6-3563-A3D6-3E692A7DEB7F> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
0x7fff84ce9000 - 0x7fff84cedfff libpam.2.dylib (20) <B93CE8F5-DAA8-30A1-B1F6-F890509513CB> /usr/lib/libpam.2.dylib
0x7fff84cee000 - 0x7fff84d6ffff com.apple.CoreSymbolication (3.0.1 - 141.0.6) <B594EF34-A1A3-3631-914E-6FD129291983> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication
0x7fff84d70000 - 0x7fff84f55fff com.apple.CoreFoundation (6.9 - 855.17) <729BD6DA-1F63-3E72-A148-26F21EBF52BB> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x7fff84f94000 - 0x7fff84fafff7 libsystem_malloc.dylib (23.10.1) <A695B4E4-38E9-332E-A772-29D31E3F1385> /usr/lib/system/libsystem_malloc.dylib
0x7fff84fb0000 - 0x7fff84fb1fff liblangid.dylib (117) <9546E641-F730-3AB0-B3CD-E0E2FDD173D9> /usr/lib/liblangid.dylib
0x7fff84fbf000 - 0x7fff84fc6ff7 libsystem_pthread.dylib (53.1.4) <AB498556-B555-310E-9041-F67EC9E00E2C> /usr/lib/system/libsystem_pthread.dylib
0x7fff84fc7000 - 0x7fff84fd0ffd com.apple.CommonAuth (4.0 - 2.0) <BD720379-757B-305C-A7BE-E00E680F8218> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth
0x7fff85019000 - 0x7fff85022ffb libsystem_notify.dylib (121.20.1) <9B34B4FE-F5AD-3F09-A5F0-46AFF3571323> /usr/lib/system/libsystem_notify.dylib
0x7fff85023000 - 0x7fff85026fff com.apple.TCC (1.0 - 1) <32A075D9-47FD-3E71-95BC-BFB0D583F41C> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC
0x7fff8504b000 - 0x7fff85070ff7 com.apple.CoreVideo (1.8 - 117.2) <4674339E-26D0-35FA-9958-422832B39B12> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
0x7fff85071000 - 0x7fff850a1fff com.apple.IconServices (25 - 25.17) <4751127E-FBD5-3ED5-8510-08D4E4166EFE> /System/Library/PrivateFrameworks/IconServices.framework/Versions/A/IconServices
0x7fff850b4000 - 0x7fff850b5fff com.apple.TrustEvaluationAgent (2.0 - 25) <334A82F4-4AE4-3719-A511-86D0B0723E2B> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
0x7fff850b6000 - 0x7fff85111ffb com.apple.AE (665.5 - 665.6) <9B17E7B7-D493-346A-827E-6DF1474E4977> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
0x7fff85112000 - 0x7fff85137ff7 com.apple.ChunkingLibrary (2.0 - 155.1) <B845DC7A-D1EA-31E2-967C-D1FE0C628036> /System/Library/PrivateFrameworks/ChunkingLibrary.framework/Versions/A/ChunkingLibrary
0x7fff85138000 - 0x7fff851affff com.apple.CoreServices.OSServices (600.4 - 600.4) <6BC86B46-AFD3-3F06-8659-2C954CBEBD43> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
0x7fff851ba000 - 0x7fff8548bff4 com.apple.CoreImage (9.4.0) <2C636ECD-0F1A-357C-9EFF-0452476FDDF5> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/CoreImage.framework/Versions/A/CoreImage
0x7fff854fd000 - 0x7fff857d1fc7 com.apple.vImage (7.0 - 7.0) <D241DBFA-AC49-31E2-893D-EAAC31890C90> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
0x7fff85809000 - 0x7fff85825fff libresolv.9.dylib (54) <11C2C826-F1C6-39C6-B4E8-6E0C41D4FA95> /usr/lib/libresolv.9.dylib
0x7fff85826000 - 0x7fff85827fff libunc.dylib (28) <62682455-1862-36FE-8A04-7A6B91256438> /usr/lib/system/libunc.dylib
0x7fff85874000 - 0x7fff85938ff7 com.apple.backup.framework (1.5.5 - 1.5.5) <CA77A4FC-7B76-30C7-94BE-FF4B8140D05A> /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup
0x7fff85c9d000 - 0x7fff85cd2fff libssl.0.9.8.dylib (52.8.4) <3F8ADCC3-AE3F-371C-A4D5-FF219D33E507> /usr/lib/libssl.0.9.8.dylib
0x7fff85dd0000 - 0x7fff85debff7 libCRFSuite.dylib (34) <FFAE75FA-C54E-398B-AA97-18164CD9789D> /usr/lib/libCRFSuite.dylib
0x7fff85dec000 - 0x7fff861cdffe libLAPACK.dylib (1094.5) <7E7A9B8D-1638-3914-BAE0-663B69865986> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
0x7fff8631e000 - 0x7fff8632bff7 libxar.1.dylib (202) <5572AA71-E98D-3FE1-9402-BB4A84E0E71E> /usr/lib/libxar.1.dylib
0x7fff8632c000 - 0x7fff86336ff7 libcsfde.dylib (380.70.2) <3ACB87D7-A81C-3C45-B648-AD27F1B9D841> /usr/lib/libcsfde.dylib
0x7fff86337000 - 0x7fff86337fff com.apple.Accelerate (1.9 - Accelerate 1.9) <509BB27A-AE62-366D-86D8-0B06D217CF56> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
0x7fff86338000 - 0x7fff86376ff7 libGLImage.dylib (9.6.5) <C242B319-6F4B-3FB3-8FCE-0B77424F0BED> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
0x7fff86536000 - 0x7fff86536fff com.apple.Accelerate.vecLib (3.9 - vecLib 3.9) <F8D0CC77-98AC-3B58-9FE6-0C25421827B6> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
0x7fff86537000 - 0x7fff866d3ff3 com.apple.QuartzCore (1.8 - 332.4) <CFB972D1-FA37-380C-9A47-2A67A84B7442> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
0x7fff866e4000 - 0x7fff866e4ff7 libkeymgr.dylib (28) <3AA8D85D-CF00-3BD3-A5A0-E28E1A32A6D8> /usr/lib/system/libkeymgr.dylib
0x7fff86944000 - 0x7fff86996fff libc++.1.dylib (120) <4F68DFC5-2077-39A8-A449-CAC5FDEE7BDE> /usr/lib/libc++.1.dylib
0x7fff86997000 - 0x7fff872c028f com.apple.CoreGraphics (1.600.0 - 599.35.12) <050E2450-9F5F-3B6A-8C34-414D094EAF9B> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
0x7fff872c1000 - 0x7fff87427fff libGLProgrammability.dylib (9.6.5) <53BCF254-3014-33DC-94EF-72C7270F14F2> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib
0x7fff87428000 - 0x7fff87429ffb libremovefile.dylib (33) <3543F917-928E-3DB2-A2F4-7AB73B4970EF> /usr/lib/system/libremovefile.dylib
0x7fff8742a000 - 0x7fff874e2ff7 com.apple.DiscRecording (8.0 - 8000.4.6) <CDAAAD04-A1D0-3C67-ABCC-EFC9E8D44E7E> /System/Library/Frameworks/DiscRecording.framework/Versions/A/DiscRecording
0x7fff874e3000 - 0x7fff874ebfff libsystem_dnssd.dylib (522.92.3) <1418DF66-01BE-3A87-8553-09EAA945F4FE> /usr/lib/system/libsystem_dnssd.dylib
0x7fff874ec000 - 0x7fff874ecfff com.apple.CoreServices (59 - 59) <7A697B5E-F179-30DF-93F2-8B503CEEEFD5> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
0x7fff874ed000 - 0x7fff874f9ffb com.apple.AppleFSCompression (56.92.2 - 1.0) <16542F97-9D21-317D-8A50-4C34AAD35F41> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression
0x7fff87909000 - 0x7fff8790bfff libCVMSPluginSupport.dylib (9.6.5) <9DE29AD9-5F59-3B9B-899C-4DED190CB817> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib
0x7fff87924000 - 0x7fff88778ff7 com.apple.WebCore (9537 - 9537.78.1) <56C3D4BF-2495-3FD2-8212-91AF7DF693B8> /System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebCore.framework/Versions/A/WebCore
0x7fff88ac5000 - 0x7fff88ad7fff com.apple.ImageCapture (9.0 - 9.0) <BE0B65DA-3031-359B-8BBA-B9803D4ADBF4> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
0x7fff88ad8000 - 0x7fff88d20ff7 com.apple.CoreData (107 - 481.3) <E78734AA-E3D0-33CB-A014-620BBCAB2E96> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
0x7fff88d38000 - 0x7fff88dc4ff7 com.apple.ink.framework (10.9 - 207) <8A50B893-AD03-3826-8555-A54FEAF08F47> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
0x7fff890b8000 - 0x7fff89141fff com.apple.ColorSync (4.9.0 - 4.9.0) <B756B908-9AD1-3F5D-83F9-7A0B068387D2> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync
0x7fff89142000 - 0x7fff89144fff libRadiance.dylib (1048) <5D66AE6D-1B0B-33CC-91F0-D93AE7016C7B> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
0x7fff8949e000 - 0x7fff894a5ff8 liblaunch.dylib (842.92.1) <A40A0C7B-3216-39B4-8AE0-B5D3BAF1DA8A> /usr/lib/system/liblaunch.dylib
0x7fff894ac000 - 0x7fff8971cffd com.apple.security (7.0 - 55471.14.40) <58F50B4A-FC1E-3AE0-A5DB-DD737E50AC17> /System/Library/Frameworks/Security.framework/Versions/A/Security
0x7fff89725000 - 0x7fff89a9cff6 com.apple.JavaScriptCore (9537 - 9537.78.1) <8623A109-9E9D-3E3B-A8E1-6EE447C0110C> /System/Library/Frameworks/JavaScriptCore.framework/Versions/A/JavaScriptCore
0x7fff89a9d000 - 0x7fff89aa9ff7 com.apple.OpenDirectory (10.9 - 173.90.1) <383F96FF-1DF3-37E8-8540-03A697C873F6> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
0x7fff89aaa000 - 0x7fff89ad9fff com.apple.DebugSymbols (106 - 106) <E1BDED08-523A-36F4-B2DA-9D5C712F0AC7> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols
0x7fff89aed000 - 0x7fff89bb8fff libvDSP.dylib (423.32) <3BF732BE-DDE0-38EB-8C54-E4E3C64F77A7> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
0x7fff89bb9000 - 0x7fff89c26ff1 com.apple.ApplicationServices.ATS (360 - 363.6) <828C2711-4577-3F75-B436-3BDF328DFB11> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
0x7fff89c27000 - 0x7fff89c32ff7 com.apple.DirectoryService.Framework (10.9 - 173.90.1) <22A0C230-CF1E-38F5-A947-5ACDAEEE0DB6> /System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService
0x7fff8a38a000 - 0x7fff8a525ff8 com.apple.CFNetwork (673.6 - 673.6) <CAA196FE-BF5A-384F-975E-E0F81359805B> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
0x7fff8a526000 - 0x7fff8a52cff7 libsystem_platform.dylib (24.90.1) <3C3D3DA8-32B9-3243-98EC-D89B9A1670B3> /usr/lib/system/libsystem_platform.dylib
0x7fff8a9f1000 - 0x7fff8aad8fff libxml2.2.dylib (26.2) <FFA6BCAE-6D2F-3B1E-B4D1-939939924708> /usr/lib/libxml2.2.dylib
0x7fff8abfc000 - 0x7fff8ac23ff7 libsystem_network.dylib (241.4) <0D630D53-C772-3EC5-8257-EFB0ACCE3153> /usr/lib/system/libsystem_network.dylib
0x7fff8acf1000 - 0x7fff8ad36ff6 com.apple.HIServices (1.23 - 468) <A4E9E28B-95C3-3654-85C6-E6A1C53CACFE> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
0x7fff8ad37000 - 0x7fff8ad39fff com.apple.EFILogin (2.0 - 2) <8D651894-B7AD-3F23-9B93-472EEA3D292F> /System/Library/PrivateFrameworks/EFILogin.framework/Versions/A/EFILogin
0x7fff8ad3a000 - 0x7fff8ad42ff7 com.apple.speech.recognition.framework (4.2.4 - 4.2.4) <98BBB3E4-6239-3EF1-90B2-84EA0D3B8D61> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
0x7fff8ad43000 - 0x7fff8ad50ff4 com.apple.Librarian (1.2 - 1) <F1A2744D-8536-32C7-8218-9972C6300DAE> /System/Library/PrivateFrameworks/Librarian.framework/Versions/A/Librarian
0x7fff8ad51000 - 0x7fff8ad52ff7 libDiagnosticMessagesClient.dylib (100) <4CDB0F7B-C0AF-3424-BC39-495696F0DB1E> /usr/lib/libDiagnosticMessagesClient.dylib
0x7fff8aee5000 - 0x7fff8aefeff7 com.apple.Kerberos (3.0 - 1) <F108AFEB-198A-3BAF-BCA5-9DFCE55EFF92> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
0x7fff8af0e000 - 0x7fff8af55ff7 libcups.2.dylib (372.6) <CBD2F0CF-FA10-36E1-A1D5-1B946B45B3B3> /usr/lib/libcups.2.dylib
0x7fff8af56000 - 0x7fff8af87ff7 libtidy.A.dylib (15.12) <BF757E3C-733A-3B6B-809A-A3949D46466E> /usr/lib/libtidy.A.dylib
0x7fff8af9b000 - 0x7fff8b07fff7 com.apple.coreui (2.2 - 231.1) <187DF89C-8A64-366D-8782-F90315FA3CD7> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
0x7fff8b081000 - 0x7fff8b10cff7 libCoreStorage.dylib (380.70.2) <BD993BC8-ED54-3DC1-B28B-3B6AC77E8E5C> /usr/lib/libCoreStorage.dylib
0x7fff8b10d000 - 0x7fff8b136ff7 libc++abi.dylib (49.1) <21A807D3-6732-3455-B77F-743E9F916DF0> /usr/lib/libc++abi.dylib
0x7fff8b137000 - 0x7fff8b13bff7 libheimdal-asn1.dylib (323.92.2) <979AEAA0-59B3-3E99-94B1-9BB9C6C45273> /usr/lib/libheimdal-asn1.dylib
0x7fff8b13c000 - 0x7fff8b1feffd com.apple.CoreText (367.23 - 367.23) <C799261E-2E19-3D69-8A8D-098B7DD8D31D> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText
0x7fff8b510000 - 0x7fff8b53fff9 com.apple.GSS (4.0 - 2.0) <27FCA2B4-0767-3002-8755-862B19B5CF92> /System/Library/Frameworks/GSS.framework/Versions/A/GSS
0x7fff8b569000 - 0x7fff8b573fff libcommonCrypto.dylib (60049) <8C4F0CA0-389C-3EDC-B155-E62DD2187E1D> /usr/lib/system/libcommonCrypto.dylib
0x7fff8be38000 - 0x7fff8be3cff7 libcache.dylib (62) <BDC1E65B-72A1-3DA3-A57C-B23159CAAD0B> /usr/lib/system/libcache.dylib
0x7fff8be47000 - 0x7fff8be62ff7 libPng.dylib (1048) <C14F8741-9F67-32DA-896A-F873705B3EC6> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
0x7fff8be63000 - 0x7fff8bec6ffb com.apple.SystemConfiguration (1.13.1 - 1.13.1) <339A2A90-DA25-33AF-88E5-2FB38A758FEE> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
0x7fff8c1a8000 - 0x7fff8c1a8ffd libOpenScriptingUtil.dylib (157.1) <D3B6E577-3CDB-3139-9B94-19496DFA7318> /usr/lib/libOpenScriptingUtil.dylib
0x7fff8c483000 - 0x7fff8c48efff libGL.dylib (9.6.5) <A5F36623-33E8-379D-A423-8F873018CD79> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
0x7fff8c504000 - 0x7fff8c50eff7 com.apple.CrashReporterSupport (10.9 - 539) <B25A09EC-A021-32EC-86F8-05B4837E0EDE> /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport
0x7fff8c50f000 - 0x7fff8c527fff com.apple.openscripting (1.4.1 - 157.1) <2C6C6498-D88E-3D9B-B933-9873890F382E> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
0x7fff8c5b5000 - 0x7fff8c5edff7 com.apple.RemoteViewServices (2.0 - 94) <3F34D630-3DDB-3411-BC28-A56A9B55EBDA> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices
0x7fff8c71d000 - 0x7fff8c71dfff com.apple.ApplicationServices (48 - 48) <3E3F01A8-314D-378F-835E-9CC4F8820031> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
0x7fff8c7b6000 - 0x7fff8c7dffff com.apple.DictionaryServices (1.2 - 208) <A539A058-BA57-35EE-AA08-D0B0E835127D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
0x7fff8cc29000 - 0x7fff8cc40ff7 com.apple.CFOpenDirectory (10.9 - 173.90.1) <D7F2E159-CF6B-3EB1-9806-3BC59E63D24F> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
0x7fff8cc78000 - 0x7fff8ccbaff7 libauto.dylib (185.5) <F45C36E8-B606-3886-B5B1-B6745E757CA8> /usr/lib/libauto.dylib
0x7fff8ccbb000 - 0x7fff8ccbcfff libsystem_sandbox.dylib (278.11.2) <0C93EB23-7364-3670-B511-212A7A524695> /usr/lib/system/libsystem_sandbox.dylib
0x7fff8ccd1000 - 0x7fff8ccf9ffb libxslt.1.dylib (13.9) <DA7092EA-0D65-3723-9CDA-A31B2E05D643> /usr/lib/libxslt.1.dylib
0x7fff8ccfa000 - 0x7fff8cd41ffb libFontRegistry.dylib (127.0.1) <F267F500-6E4A-3BE3-97C1-08AAA649E02E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib
0x7fff8cd42000 - 0x7fff8cd45fff com.apple.help (1.3.3 - 46) <AE763646-D07A-3F9A-ACD4-F5CBD734EE36> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
0x7fff8cd46000 - 0x7fff8cd85fff libGLU.dylib (9.6.5) <7463B411-2DB0-3338-BC8D-403293E2CA34> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
0x7fff8cd86000 - 0x7fff8cf3effb libicucore.A.dylib (511.36) <9AAC5980-2C1F-3B86-8A16-DB533F5E7C84> /usr/lib/libicucore.A.dylib
0x7fff8cf3f000 - 0x7fff8cf4cff0 libbz2.1.0.dylib (29) <0B98AC35-B138-349C-8063-2B987A75D24C> /usr/lib/libbz2.1.0.dylib
0x7fff8cf4d000 - 0x7fff8cfbafff com.apple.SearchKit (1.4.0 - 1.4.0) <B9B8D510-A27E-36B0-93E9-17146D9E9045> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
0x7fff8cfbe000 - 0x7fff8cfc5fff libcompiler_rt.dylib (35) <4CD916B2-1B17-362A-B403-EF24A1DAC141> /usr/lib/system/libcompiler_rt.dylib
0x7fff8cfdb000 - 0x7fff8d007ff7 com.apple.framework.SystemAdministration (1.0 - 1.0) <E4CEA45A-A2D7-356F-BEC9-E7CB84487918> /System/Library/PrivateFrameworks/SystemAdministration.framework/Versions/A/SystemAdministration
0x7fff8d008000 - 0x7fff8d091fff libsystem_c.dylib (997.90.4) <EA812F03-8AD2-3776-AD50-6BEBC90F1F5F> /usr/lib/system/libsystem_c.dylib
0x7fff8d092000 - 0x7fff8d099fff com.apple.NetFS (6.0 - 4.0) <8E26C099-CE9D-3819-91A2-64EA929C6137> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
0x7fff8d09a000 - 0x7fff8d0f2ff7 com.apple.Symbolication (1.4 - 129.0.2) <78AE8B21-BF15-373F-88C6-73BF740BFFFB> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication
0x7fff8d0f3000 - 0x7fff8d10fff7 libsystem_kernel.dylib (2422.115.14) <8116098D-B3F1-3E50-A934-576DD6369234> /usr/lib/system/libsystem_kernel.dylib
0x7fff8d1cc000 - 0x7fff8d1cfffc com.apple.IOSurface (91.3 - 91.3) <E93485CC-12B1-318E-BAE3-AB532B264935> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
0x7fff8d763000 - 0x7fff8d763fff com.apple.Carbon (154 - 157) <EFC1A1C0-CB07-395A-B038-CFA2E71D3E69> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
0x7fff8d764000 - 0x7fff8d766ffb libutil.dylib (34) <DAC4A6CF-A1BB-3874-9569-A919316D30E8> /usr/lib/libutil.dylib
0x7fff8d767000 - 0x7fff8d771ff7 com.apple.bsd.ServiceManagement (2.0 - 2.0) <2D27B498-BB9C-3D88-B05A-76908A8A26F3> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
0x7fff8d772000 - 0x7fff8d860fff libJP2.dylib (1048) <19B37CB6-C864-3830-87FE-BB53F8542FB0> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib
0x7fff8d899000 - 0x7fff8d8cafff com.apple.MediaKit (15 - 709) <23E33409-5C39-3F93-9E73-2B0E9EE8883E> /System/Library/PrivateFrameworks/MediaKit.framework/Versions/A/MediaKit
0x7fff8d9b7000 - 0x7fff8d9b7fff com.apple.Cocoa (6.8 - 20) <E90E99D7-A425-3301-A025-D9E0CD11918E> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
0x7fff8d9b8000 - 0x7fff8d9c6fff com.apple.CommerceCore (1.0 - 42) <24C71143-C5D7-363D-A875-87FA5F185CD1> /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore
0x7fff8da5e000 - 0x7fff8da65ffb libcopyfile.dylib (103.92.1) <CF29DFF6-0589-3590-834C-82E2316612E8> /usr/lib/system/libcopyfile.dylib
0x7fff8daa0000 - 0x7fff8daa3ff7 com.apple.LoginUICore (3.0 - 3.0) <1ECBDA90-D6ED-3333-83EB-9C8232DFAD7C> /System/Library/PrivateFrameworks/LoginUIKit.framework/Versions/A/Frameworks/LoginUICore.framework/Versions/A/LoginUICore
0x7fff8daa4000 - 0x7fff8dd8efff com.apple.CoreServices.CarbonCore (1077.17 - 1077.17) <3A2E92FD-DEE2-3D45-9619-11500801A61C> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
0x7fff8dd8f000 - 0x7fff8de59ff7 com.apple.LaunchServices (572.32 - 572.32) <A4699DED-5101-3068-94F8-8D0B7A84BC79> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
0x7fff8de6d000 - 0x7fff8de6eff7 libsystem_blocks.dylib (63) <FB856CD1-2AEA-3907-8E9B-1E54B6827F82> /usr/lib/system/libsystem_blocks.dylib
0x7fff8de8b000 - 0x7fff8ea01ff7 com.apple.AppKit (6.9 - 1265.21) <9DC13B27-841D-3839-93B2-3EDE66157BDE> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
0x7fff8ec4c000 - 0x7fff8ec59fff com.apple.Sharing (132.2 - 132.2) <F983394A-226D-3244-B511-FA51FDB6ADDA> /System/Library/PrivateFrameworks/Sharing.framework/Versions/A/Sharing
0x7fff8eff3000 - 0x7fff8f041ff7 com.apple.opencl (2.3.59 - 2.3.59) <9F43F471-C3C3-352D-889D-EC418DC1F5B2> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
0x7fff8f042000 - 0x7fff8f04affc libGFXShared.dylib (9.6.5) <FCCD0CD3-02FD-3A79-B048-A14745D76CC8> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
0x7fff8f089000 - 0x7fff8f08aff7 libSystem.B.dylib (1197.1.1) <70B235FC-BCED-367B-BA6C-67C299BAE7D9> /usr/lib/libSystem.B.dylib
0x7fff8f08b000 - 0x7fff8f13bff7 libvMisc.dylib (423.32) <049C0735-1808-39B9-943F-76CB8021744F> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
0x7fff8f159000 - 0x7fff8f1beffb com.apple.Heimdal (4.0 - 2.0) <C28DBCAE-01AC-363A-9046-3BD33F225526> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal
0x7fff8f1d0000 - 0x7fff8f1d5fff libmacho.dylib (845) <1D2910DF-C036-3A82-A3FD-44FF73B5FF9B> /usr/lib/system/libmacho.dylib
0x7fff8f26a000 - 0x7fff8f35bff9 libiconv.2.dylib (41) <BB44B115-AC32-3877-A0ED-AEC6232A4563> /usr/lib/libiconv.2.dylib
0x7fff8f4fd000 - 0x7fff8f508ff7 com.apple.NetAuth (5.0 - 5.0) <C811E662-9EC3-3B74-808A-A75D624F326B> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth
0x7fff8f509000 - 0x7fff8f538fd2 libsystem_m.dylib (3047.16) <B7F0E2E4-2777-33FC-A787-D6430B630D54> /usr/lib/system/libsystem_m.dylib
0x7fff8f539000 - 0x7fff8f5a5fff com.apple.framework.IOKit (2.0.1 - 907.100.14) <10932113-9F7E-38A0-A158-A019A555CAC3> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x7fff8f5a6000 - 0x7fff8f5b1fff libkxld.dylib (2422.115.14) <1317F07F-AD7C-397A-9935-26413D641F08> /usr/lib/system/libkxld.dylib
0x7fff8f5b2000 - 0x7fff8f5b5fff libCoreVMClient.dylib (58.1) <EBC36C69-C896-3C3D-8589-3E9023E7E56F> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
0x7fff8f5b6000 - 0x7fff8f70aff3 com.apple.audio.toolbox.AudioToolbox (1.10 - 1.10) <69B273E8-5A8E-3FC7-B807-C16B657662FE> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
0x7fff8f732000 - 0x7fff8f862ff7 com.apple.desktopservices (1.8.3 - 1.8.3) <225BEC20-F8E0-3F22-9560-890A1A5B9050> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
0x7fff8fe31000 - 0x7fff8fec1ff7 com.apple.Metadata (10.7.0 - 800.30) <E107CE36-FBC3-35A5-84E0-864B4178FC5D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
0x7fff8ff05000 - 0x7fff8ffe2fff libcrypto.0.9.8.dylib (52.8.4) <E03DB1E7-4CC6-3338-B67D-F69BE2FB28FC> /usr/lib/libcrypto.0.9.8.dylib
0x7fff8fffd000 - 0x7fff9000eff7 libsystem_asl.dylib (217.1.4) <655FB343-52CF-3E2F-B14D-BEBF5AAEF94D> /usr/lib/system/libsystem_asl.dylib
0x7fff90010000 - 0x7fff90020ffb libsasl2.2.dylib (170) <C8E25710-68B6-368A-BF3E-48EC7273177B> /usr/lib/libsasl2.2.dylib
0x7fff90021000 - 0x7fff90074fff com.apple.ScalableUserInterface (1.0 - 1) <CF745298-7373-38D2-B3B1-727D5A569E48> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/ScalableUserInterface.framework/Versions/A/ScalableUserInterface
0x7fff90075000 - 0x7fff9007eff7 libcldcpuengine.dylib (2.3.58) <645ABD2F-C93B-3943-8B07-BBC08B904253> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libcldcpuengine.dylib
0x7fff9008a000 - 0x7fff900bfffc com.apple.LDAPFramework (2.4.28 - 194.5) <5E501783-06E8-390C-AF34-A7FAD402F3E6> /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP
0x7fff900c0000 - 0x7fff901aafff libsqlite3.dylib (158) <00269BF9-43BE-39E0-9C85-24585B9923C8> /usr/lib/libsqlite3.dylib
0x7fff901ab000 - 0x7fff905deffb com.apple.vision.FaceCore (3.0.0 - 3.0.0) <F42BFC9C-0B16-35EF-9A07-91B7FDAB7FC5> /System/Library/PrivateFrameworks/FaceCore.framework/Versions/A/FaceCore
0x7fff905f4000 - 0x7fff907a1f27 libobjc.A.dylib (551.1) <AD7FD984-271E-30F4-A361-6B20319EC73B> /usr/lib/libobjc.A.dylib
0x7fff907a2000 - 0x7fff907ddfff com.apple.bom (14.0 - 193.1) <EF24A562-6D3C-379E-8B9B-FAE0E4A0EF7C> /System/Library/PrivateFrameworks/Bom.framework/Versions/A/Bom
0x7fff907de000 - 0x7fff907e2ff7 libGIF.dylib (1048) <53A30C22-410C-3DFF-9236-0CC56D2E64A5> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
0x7fff907e3000 - 0x7fff908eaff7 com.apple.ImageIO.framework (3.3.0 - 1048) <FDFAFDEA-3559-330F-9578-40F4F62F51B3> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
0x7fff908eb000 - 0x7fff9093cff7 com.apple.audio.CoreAudio (4.2.1 - 4.2.1) <07F2B103-AE29-3118-BBC4-9A72E13B013B> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
0x7fff9093d000 - 0x7fff9098aff2 com.apple.print.framework.PrintCore (9.0 - 428) <8D8253E3-302F-3DB2-9C5C-572CB974E8B3> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
0x7fff90b5e000 - 0x7fff90b97ff7 com.apple.QD (3.50 - 298) <C1F20764-DEF0-34CF-B3AB-AB5480D64E66> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
0x7fff90b98000 - 0x7fff90b99ff7 com.apple.print.framework.Print (9.0 - 260) <EE00FAE1-DA03-3EC2-8571-562518C46994> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
0x7fff91016000 - 0x7fff91026fff libbsm.0.dylib (33) <2CAC00A2-1352-302A-88FA-C567D4D69179> /usr/lib/libbsm.0.dylib
0x7fff91039000 - 0x7fff91051ff7 com.apple.GenerationalStorage (2.0 - 160.3) <64749B08-0212-3AC8-9B49-73D662B09304> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage
0x7fff91052000 - 0x7fff91076ff7 libJPEG.dylib (1048) <3C999DC3-8A51-3CA9-9AB8-7F9DBA278FE6> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
0x7fff91077000 - 0x7fff9107aff7 libdyld.dylib (239.4) <41077DD7-F909-3B8A-863E-72AE304EDE13> /usr/lib/system/libdyld.dylib
0x7fff9131a000 - 0x7fff91334fff libdispatch.dylib (339.92.1) <C4E4A18D-3C3B-3C9C-8709-A4270D998DE7> /usr/lib/system/libdispatch.dylib
0x7fff91434000 - 0x7fff91436ff3 libsystem_configuration.dylib (596.15) <4998CB6A-9D54-390A-9F57-5D1AC53C135C> /usr/lib/system/libsystem_configuration.dylib
0x7fff91437000 - 0x7fff91445fff com.apple.opengl (9.6.5 - 9.6.5) <4FAEADD8-EEB3-3FD9-ADC6-BA65806228CC> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
0x7fff91448000 - 0x7fff914bbfff com.apple.securityfoundation (6.0 - 55122.3) <0AFCF575-97C3-3458-A72E-39DA07804EB9> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
0x7fff91542000 - 0x7fff91569ffb libsystem_info.dylib (449.1.4) <12CD9E42-8CEE-3A8D-B006-F8A6EB98804D> /usr/lib/system/libsystem_info.dylib
0x7fff915ca000 - 0x7fff915dcff7 com.apple.MultitouchSupport.framework (245.13.1 - 245.13.1) <38262B92-C63F-35A0-997D-AD2EBF2F8338> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
0x7fff91633000 - 0x7fff91637fff com.apple.CommonPanels (1.2.6 - 96) <6B434AFD-50F8-37C7-9A56-162C17E375B3> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
0x7fff91638000 - 0x7fff9163aff7 com.apple.securityhi (9.0 - 55005) <9985032A-0EE1-3760-8D23-ADD3965A4D18> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
0x7fff9163b000 - 0x7fff918e5ff5 com.apple.HIToolbox (2.1.1 - 698) <26FF0E2C-1CD7-311F-ACF0-84F3D5273AD6> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
0x7fff918e6000 - 0x7fff91934ff9 libstdc++.6.dylib (60) <0241E6A4-1368-33BE-950B-D0A175C41F54> /usr/lib/libstdc++.6.dylib
0x7fff91977000 - 0x7fff9197bff7 libsystem_stats.dylib (93.90.3) <C588E082-D94B-3510-9F9A-7AD83B3402DE> /usr/lib/system/libsystem_stats.dylib
0x7fff9197c000 - 0x7fff91ab2ff5 com.apple.WebKit (9537 - 9537.78.2) <EB8D3D78-92E7-3B67-8AAF-B51A181461E0> /System/Library/Frameworks/WebKit.framework/Versions/A/WebKit
0x7fff91b31000 - 0x7fff91b58ff7 com.apple.shortcut (2.6 - 2.6) <A62BC973-6782-3893-B014-EC6503AB7EAD> /System/Library/PrivateFrameworks/Shortcut.framework/Versions/A/Shortcut
0x7fff91bb8000 - 0x7fff91cb2fff libFontParser.dylib (111.1.6) <77253632-B3F6-3151-ABA0-C1EF458668A8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
0x7fff91cb3000 - 0x7fff91cd7fff libxpc.dylib (300.90.2) <AB40CD57-F454-3FD4-B415-63B3C0D5C624> /usr/lib/system/libxpc.dylib
0x7fff91cd8000 - 0x7fff91d1dfff libcurl.4.dylib (78.94.1) <88F27F9B-052E-3375-938D-2603E90D8AD5> /usr/lib/libcurl.4.dylib
0x7fff91d1e000 - 0x7fff91d24fff com.apple.AOSNotification (1.7.0 - 760.4) <8F042A51-E0A9-37E6-A601-0DD6A58A0AC8> /System/Library/PrivateFrameworks/AOSNotification.framework/Versions/A/AOSNotification
0x7fff91d25000 - 0x7fff91e93ff7 libBLAS.dylib (1094.5) <DE93A590-5FA5-32A2-A16C-5D7D7361769F> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
0x7fff91e94000 - 0x7fff91ea5ff7 libz.1.dylib (53) <42E0C8C6-CA38-3CA4-8619-D24ED5DD492E> /usr/lib/libz.1.dylib
0x7fff91ebe000 - 0x7fff91ec7fff com.apple.speech.synthesis.framework (4.7.1 - 4.7.1) <383FB557-E88E-3239-82B8-15F9F885B702> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
0x7fff91ec8000 - 0x7fff91ecaff7 libquarantine.dylib (71) <7A1A2BCB-C03D-3A25-BFA4-3E569B2D2C38> /usr/lib/system/libquarantine.dylib
0x7fff91ecb000 - 0x7fff91eccff7 libodfde.dylib (20) <C00A4EBA-44BC-3C53-BFD0-819B03FFD462> /usr/lib/libodfde.dylib
0x7fff91f3a000 - 0x7fff91f46ff7 com.apple.HelpData (2.1.4 - 90) <BEA1C549-40D3-35BF-9204-CB679FCB0648> /System/Library/PrivateFrameworks/HelpData.framework/Versions/A/HelpData
0x7fff91f47000 - 0x7fff91f60ff7 com.apple.Ubiquity (1.3 - 289) <C7F1B734-CE81-334D-BE41-8B20D95A1F9B> /System/Library/PrivateFrameworks/Ubiquity.framework/Versions/A/Ubiquity
0x7fff91fea000 - 0x7fff92043ff7 libTIFF.dylib (1048) <923096A6-02CC-311D-9596-1961430C0EF7> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
0x7fff92044000 - 0x7fff920a8fff com.apple.datadetectorscore (5.0 - 354.5) <C9FAB401-3FE2-3221-B60C-E4F1841CA5F1> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore
0x7fff920ac000 - 0x7fff920cefff com.apple.framework.familycontrols (4.1 - 410) <5D2414D4-D418-327F-9E3B-0B0889150828> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls
0x7fff920cf000 - 0x7fff923cfff7 com.apple.Foundation (6.9 - 1056.17) <E0B0FAF6-5CA8-3EEB-8BF2-104C0AEEF925> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x7fff925ff000 - 0x7fff92604fff com.apple.DiskArbitration (2.6 - 2.6) <A4165553-770E-3D27-B217-01FC1F852B87> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
0x7fff9262d000 - 0x7fff92659fff com.apple.CoreServicesInternal (184.9 - 184.9) <4DEA54F9-81D6-3EDB-AA3C-1F9C497B3379> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal
0x7fff9265a000 - 0x7fff9272bff1 com.apple.DiskImagesFramework (10.9.6 - 373) <4EA5A3C8-13E2-309C-8FAB-C21A4C316802> /System/Library/PrivateFrameworks/DiskImages.framework/Versions/A/DiskImages
0x7fff92748000 - 0x7fff92796fff libcorecrypto.dylib (161.1) <F3973C28-14B6-3006-BB2B-00DD7F09ABC7> /usr/lib/system/libcorecrypto.dylib
0x7fff92869000 - 0x7fff928aafff com.apple.PerformanceAnalysis (1.47 - 47) <DBC7349E-8440-3FE0-B5E4-B6A8EF3017E9> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis
0x7fff928ab000 - 0x7fff928b0ff7 libunwind.dylib (35.3) <78DCC358-2FC1-302E-B395-0155B47CB547> /usr/lib/system/libunwind.dylib
0x7fff92911000 - 0x7fff92920ff8 com.apple.LangAnalysis (1.7.0 - 1.7.0) <8FE131B6-1180-3892-98F5-C9C9B79072D4> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis


External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 2
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 1046389
thread_create: 0
thread_set_state: 0


VM Region Summary:
ReadOnly portion of Libraries: Total=205.4M resident=96.7M(47%) swapped_out_or_unallocated=108.7M(53%)
Writable regions: Total=107.0M written=1172K(1%) resident=47.6M(44%) swapped_out=11.0M(10%) unallocated=59.4M(56%)

REGION TYPE VIRTUAL
=========== =======
CG backing stores 2660K
CG image 12K
CG raster data 24K
CG shared images 212K
CoreGraphics 8K
CoreImage 4K
Dispatch continuations 4096K
IOKit 36.2M
IOKit (reserved) 4K reserved VM address space (unallocated)
Kernel Alloc Once 8K
MALLOC 37.1M
MALLOC (admin) 32K
Memory Tag 242 12K
OpenCL 8K
STACK GUARD 56.0M
Stack 10.1M
VM_ALLOCATE 16.4M
__DATA 42.1M
__IMAGE 528K
__LINKEDIT 68.7M
__TEXT 136.8M
__UNICODE 544K
mapped file 49.3M
shared memory 4K
=========== =======
TOTAL 460.6M
TOTAL, minus reserved VM space 460.6M

johnnyfp
03-17-2016, 02:14 AM
Hi,

I think my Gyro is Half dead on my Prop Shield!

So after pointing out about the discrepancy of the NXPMotionSense.cpp library in post #171 (https://forum.pjrc.com/threads/33328-Prop-Shield-Beta-Test?p=99445&viewfull=1#post99445) and then seeing that the code hadn't been updated but other people where still getting the IMURead GUI working without my change I begun to wonder how everyone is getting it to work but I need to hack the library to make it work, to get the Mag calibrated.

Then upon inspection, I can see in this code that the newdata update is only done on a gyro event or change of data, so if you move the unit then the Gyro would report the move and an newdata flag would be set. Now if My Gyro is only ever reporting back 0, and the code only sets this flag on the gyro cycle then I would never get any changes.

Updating the Initialization code so that the Gyro is now put into Self-Test mode, I'm still getting no data. It seems that the I2C Controller part of the Gyro chip is working, because the read reg and write reg are reporting, but the actual sensor part is not working. I'm also not getting any Gyro Temperature reading.

A few days ago the gyro was working with OneHorses Library, but it too is now reporting no data from the Gyro.

Any Ideas on how I should approach and find the fault?

Wozzy
03-17-2016, 03:29 AM
using orientation sketch to output Yaw indication to APA102 leds using FastLED on pins 11 and 13 (I believe that the choice of pins 11 and 13 should cause FastLED to select Hardware SPI - but not sure on this)
(hardware covered)

Are you using Pins 11 and 13 on the Teensy, or the 5,D,C,G pins on the PropShield?

I just got my APA102 LEDS (a 1 m, 144LED/m strip)
I am able to run them from the Teensy 3.1 pins directly , but not from the 5,D,C,G pins on the PropShield.
I get similar results with either your program above or with the FastLED Firstlight sketch.

Edit: I should have mentioned that I'm powering the APA102 strip with an external 5V supply, with the ground tied to the Teensy ground.
I was only trying to tie into the Clock and Data outputs on the PropShield.

defragster
03-17-2016, 03:33 AM
APA102 aren't 'Dotstar' SPI bus are they? That is what the PropShield is looking for as I saw it. I just ordered some Dotstar.

<edit>: Yes - those are the same

Wozzy
03-17-2016, 03:38 AM
I tried the new GUI.exe program on my Windows 10 PC
The program window now re-sizes properly, and is able to go full screen.
The quality and performance of the graphics display still seems good even at full screen resolution (1920x1080)

Wozzy
03-17-2016, 03:44 AM
APA102 aren't 'Dotstar' SPI bus are they? That is what the PropShield is looking for as I saw it. I just ordered some Dotstar.

I was under the impression that Dotstar and APA102 were the same.

KurtE
03-17-2016, 04:43 AM
I meant to try dot star today, but got sidetracked, I was going to check to see if library was doing anything with io pin 7 which looks like enable for them

JBeale
03-17-2016, 05:26 AM
I did the calibration twice and the numbers seem somewhat close, at least. Would be cool to have the option for the Cal GUI to display this.

Hard Iron Offset
-0.51
15.25
70.61

Soft Iron Mapping
0.9821 -0.0104 -0.0133
-0.0104 0.9797 0.0035
-0.0133 0.0035 1.0396

Hard Iron Offset
-0.70
16.40
71.02

Soft Iron Mapping
0.9770 -0.0141 -0.0154
-0.0141 0.9824 0.0042
-0.0154 0.0042 1.0424


Plot of NXP Orientation sketch moving around, and then sitting still on desk, using default 8 Hz update rate
6710

below plot shows about 15 minutes of data with sensor stuck down on the desk; not much drift after the initial oscillation damps out.
EDIT: I then continued the test for 8 hours, and the data looks about the same as the 15 minutes (no significant drift).
6712

Snippet of 8 Hz raw data at end of above graph:


2.529,0.044,-0.123
2.529,0.044,-0.123
2.528,0.044,-0.123
2.528,0.044,-0.123
2.528,0.044,-0.123
2.528,0.044,-0.124
2.527,0.043,-0.124
2.527,0.043,-0.124
2.527,0.043,-0.124
2.526,0.043,-0.124
2.526,0.043,-0.124
2.526,0.043,-0.124
2.526,0.043,-0.124
2.526,0.043,-0.124
2.527,0.043,-0.124
2.527,0.043,-0.124
2.527,0.043,-0.124
2.527,0.043,-0.124
2.528,0.043,-0.124
2.528,0.043,-0.124
2.528,0.043,-0.124
2.528,0.043,-0.124
2.527,0.043,-0.124
2.528,0.043,-0.124
2.527,0.043,-0.124
2.528,0.043,-0.124
2.527,0.043,-0.124
2.528,0.043,-0.124
2.528,0.043,-0.124
2.528,0.043,-0.124
2.527,0.043,-0.124
2.527,0.043,-0.124
2.527,0.043,-0.125
2.527,0.043,-0.124
2.527,0.043,-0.124
2.527,0.043,-0.124
2.527,0.043,-0.124
2.527,0.043,-0.125
2.526,0.043,-0.125
2.526,0.042,-0.124
2.527,0.043,-0.125
2.527,0.043,-0.125
2.527,0.042,-0.125

defragster
03-17-2016, 06:09 AM
I was under the impression that Dotstar and APA102 were the same.

opps - Hadn't looked beyond Adafruit named Dotstar . . . I found this on Adafruit - it seems they should be the same .vs. the 1 wire WS2812:

The manufacturer of the APA102C smart LED used in this strip used to be GRB order, and has changed in 2015 to have BRG color order. This means if you are using our DotStar library (https://www.adafruit.com/products/2241)

apa102/ (https://cpldcpu.wordpress.com/2014/08/27/apa102/)
understanding-the-apa102-superled/ (https://cpldcpu.wordpress.com/2014/11/30/understanding-the-apa102-superled/)

mortonkopf
03-17-2016, 08:07 AM
@Wozzy - Initial test was to see if SPI based leds work with shield at the same time. just hooked up to pins 11 and 13, will look at using the shield pins either tonight, or tomorrow.

@defragster - dotstar is just the name that Adafruit gives to APA102, just like calling ws2811 leds Neopixels, very annoying that AdaF cause this confusion. RGB order can be defined in FastLED library usually, or pixel data can easily be restructured in a colour function in the sketch. They are MUCH cheaper from a china source, even with taxes added. These are four wire leds very different to ws2811, they have a dedicated clock line. I have ordered from a number of china suppliers, including Greeled and from alibaba.

Ben
03-17-2016, 08:38 AM
Remember to set Teensy Pin 7 high to use the shields 5V buffers.:)

mortonkopf
03-17-2016, 09:03 AM
@Ben -
Remember to set Teensy Pin 7 high to use the shields 5V buffers.:)
Good call. I would have struggled with wondering why 11 and 13 were not working on 5DCG shield pins.

defragster
03-17-2016, 10:32 AM
Remember to set Teensy Pin 7 high to use the shields 5V buffers.:)

Good to know - I got as far as setting pin 5 output HIGH to enable the audio amp output, but had not looked into the 5DCG shield pins.

@mortonkopf - Thx - I saw that dotstar==APA102 for my post #217, but 7 hours earlier when I saw I could get a $5 Pi Zero I got that and the a dotstar strip shipped without reading ... while they still had stock - they lasted 2 more hours.

@Wozzy - is this your problem from post #211? <edit>

(Paul?): Hopefully the Prop Shield will come with a COOL PJRC CARD - the Audio Shield could use one - to know and understand such pin details

PaulStoffregen
03-17-2016, 11:39 AM
[Update: Also crashes without the LC plugged in. Can make it crash by running it and quitting without doing anything. Haven't been able to make the display show anything other than labels and blank content panes.]


Looks like the Mac version is pretty unstable. :(

I've had it crash here a few time as well. I'm going to rewrite the port menu stuff soon, so hopefully whatever I did wrong there will soon be replaced with something better.



I think my Gyro is Half dead on my Prop Shield!
....
Any Ideas on how I should approach and find the fault?

Can you run the I2C scanner. If using Teensyduino 1.28-beta1, it's in File > Examples > Wire > Scanner. Would be good to know if the chip totally died, or is still alive but not working properly.



(Paul?): Hopefully the Prop Shield will come with a COOL PJRC CARD - the Audio Shield could use one - to know and understand such pin details

There no way new printed cards will happen in time for the first release. But remind me of this later....

manitou
03-17-2016, 11:52 AM
I've seriously considered doing something like this. The W25Q64 flash chip does have a 256 byte area which can be used for serial numbers or other stuff. I believe those 256 bytes survive the normal chip erase, but I haven't tested.


The flash chip has 3 256-byte "security registers". There are SPI instructions to erase/program/read these 3 registers. I confirmed that data written survives the eraseeverything example, so registers could be used to store calibration data. Takes about 10ms to erase a security register.

The hack used to read/program


void read_secreg() {
int i;
uint8_t v[4];
SPI.beginTransaction(SPICONFIG);
CSASSERT();
SPI.transfer(0x48); // read
SPI.transfer(0); SPI.transfer(0x10); SPI.transfer(0); // address
SPI.transfer(0); // dummy
SPI.transfer(v,sizeof(v));
CSRELEASE();
SPI.endTransaction();
for(i=0;i<sizeof(v);i++) {Serial.print(v[i]); Serial.print(" ");}
Serial.println();
}

void write_secreg() {
// erase and write a security register
SPI.beginTransaction(SPICONFIG);
CSASSERT();
SPI.transfer(0x06); // write enable
CSRELEASE();
delayMicroseconds(1);
CSASSERT();
SPI.transfer(0x44); // erase
SPI.transfer(0); SPI.transfer(0x10); SPI.transfer(0); // address
CSRELEASE();
SPI.endTransaction();
uint32_t t =micros();
SerialFlash.wait();
t=micros()-t;
SPI.beginTransaction(SPICONFIG);
CSASSERT();
SPI.transfer(0x06); // write enable
CSRELEASE();
delayMicroseconds(1);
CSASSERT();
SPI.transfer(0x42); // write
SPI.transfer(0); SPI.transfer(0x10); SPI.transfer(0); // address
for(int i=0;i<64;i++)SPI.transfer(i+4);
CSRELEASE();
SPI.endTransaction();
SerialFlash.wait();
Serial.print(t); Serial.println(" us");
}

benscammell
03-17-2016, 12:11 PM
Internally, we're called these "wit" and "witout", named after the Philly Cheesesteak ordering protocol (www.cheesesteaks.co.uk/orderingcheesesteaks/). That's why the label on this bin says "WIT".

Thanks Paul... I'm now hungry for, and a significant distance from, a Philly Cheesesteak! :-)

Ben
03-17-2016, 12:28 PM
There no way new printed cards will happen in time for the first release. But remind me of this later....
Maybe just create the PDF version and include a small piece of paper with the link might suffice for the first batch? I think it's pretty important to convey information such as the "enable" pins and how to hook up the speaker (no gnd connection) and how many LEDs maximum with USB-power...

Wozzy
03-17-2016, 01:14 PM
@Wozzy - is this your problem from post #211?

Yes... I definitely missed that (setting Pin 7 high to enable the shields 5V buffers) when looking at the diagram.
I can't wait to get home to try it out.

KurtE
03-17-2016, 01:15 PM
Maybe just create the PDF version and include a small piece of paper with the link might suffice for the first batch? I think it's pretty important to convey information such as the "enable" pins and how to hook up the speaker (no gnd connection) and how many LEDs maximum with USB-power...
There is lots of good information and ideas scattered through this thread, it might be helpful, if there was some summary like posting, like updates to posting #1, which gives hints, like:

Download the following libraries...

To try out Speaker, connect ... And test programs for speaker are at ...

How to use the APA102...

Again great stuff!

mortonkopf
03-17-2016, 02:09 PM
+1 KurtE - perhaps best saved for a shield released thread, with first post holding this info (in lieu of a wiki). I imagine, however, that this would actually be all in the shield webpage when it goes up, with all of the gotcha captured from this thread and nicely distilled in a single coherent 'how to get this shield working' page.

PaulStoffregen
03-17-2016, 04:06 PM
... that this would actually be all in the shield webpage when it goes up, with all of the gotcha captured from this thread and nicely distilled in a single coherent 'how to get this shield working' page.

Yes, exactly. I was planning to start the page this weekend, after another round or two of improvements to the calibration app.

mortonkopf
03-17-2016, 05:17 PM
So yes, just ran the previous APA102 orientation sketch with pinmode(7, OUTPUT) and digitalWrite(7,HIGH) in setup, and 5DCG connections work (of course they do!). They are useable as expected with declaring pins 11 and 13. the sketch below uses the orientation sketch and outputs direction indicator. I left pin 7 high for the whole program.

#include <NXPMotionSense.h>
#include <Wire.h>
#include <EEPROM.h>
#include <FastLED.h>

#define NUM_LEDS 11 //number of leds in strip length on one side
#define DATA_PIN 11
#define CLOCK_PIN 13
CRGB leds[NUM_LEDS];


NXPMotionSense imu;
NXPSensorFusion filter;

void setup() {
Serial.begin(9600);
imu.begin();
filter.begin();
// FastLED.addLeds<APA102, DATA_PIN, CLOCK_PIN>(leds, NUM_LEDS);
FastLED.addLeds<APA102, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
pinMode(7, OUTPUT);
digitalWrite(7, HIGH);
}

void loop() {
float ax, ay, az;
float gx, gy, gz;
float mx, my, mz;
float roll, pitch, heading;

if (imu.available()) {
// Read the motion sensors
imu.readMotionSensor(ax, ay, az, gx, gy, gz, mx, my, mz);

// Update the SensorFusion filter
filter.update(gx, gy, gz, ax, ay, az, mx, my, mz);
}

// roll = filter.getRoll();
// pitch = filter.getPitch();
heading = filter.getYaw();

if(heading<(-1)){
for (int x=0;x<4;x++){
leds[x]=CRGB(0,55,255);
FastLED.show();
}
}
if(heading>(1)){
for (int x=7;x<11;x++){
leds[x]=CRGB(200,155,0);
FastLED.show();
}
}
if(heading>(-1)&& heading<1){
for (int x=5;x<7;x++){
leds[x]=CRGB(0,155,0);
FastLED.show();
}
}

for (int x=0;x<NUM_LEDS;x++){
leds[x]=CRGB(0,0,0);
FastLED.show();
}
}


// Decide when to print
bool readyToPrint() {
static unsigned long nowMillis;
static unsigned long thenMillis;

// If the Processing visualization sketch is sending "s"
// then send new data each time it wants to redraw
while (Serial.available()) {
int val = Serial.read();
if (val == 's') {
thenMillis = millis();
return true;
}
}
// Otherwise, print 8 times per second, for viewing as
// scrolling numbers in the Arduino Serial Monitor
nowMillis = millis();
if (nowMillis - thenMillis > 125) {
thenMillis = nowMillis;
return true;
}
return false;
}

mortonkopf
03-17-2016, 05:53 PM
BUT.... prop shield does NOT fit on octows2811 adapter board on top side using standard female header adapters. Its about 3mm too long - i have my shield bottom mounted. oh no..

Wozzy
03-17-2016, 06:59 PM
Does anyone know the maximum current @ 5V the PropShield can pass through to the 5DCG APA102 port?
I've been using an external 5V power supply, with the ground tied to the Propshield/Teensy3.1, to power the LED strip, but I'm guessing that the idea is to connect directly to the 5DCG APA102 port.
Thanx

johnnyfp
03-17-2016, 07:18 PM
@Paul

The I2C part of the Gyro is working just not the sensor part. Your library checks that anyway. But in any case here is the output of the Scanner as requested.


Scanning...
Device found at address 0x1E (LSM303D,HMC5883L,FXOS8700,LIS3DSH)
Device found at address 0x20 (MCP23017,MCP23008,FXAS21002)
Device found at address 0x60 (MPL3115,MCP4725,MCP4728,TEA5767,Si5351)
done



The fact that the AMP was never working on arrival, and the gyro was working but then stopped, makes me wonder if something happened to it during transit, or I just got unlucky with a duff board.

KurtE
03-17-2016, 07:28 PM
Just tried out my strand of 60 APA102s... First test failed... My strand came with connectors on one side, so I tried using them,

Problem was, the connector was on the Output side not input side :o, so it failed. So added connection to other end, now it is working.

Also side note: the 4 pin connector on the shield does not have the same order of signals (VCC, DATA, CLOCK, GND) that is on the APA strand (VCC, CI, DI, GND).

The Strand test now works (after telling IO Pin 7 to go high). Morton's program does something, not sure yet what, but does change as I move the board


Kurt

onehorse
03-17-2016, 07:41 PM
The fact that the AMP was never working on arrival, and the gyro was working but then stopped

My amp doesn't work either, or rather is makes buzzing and popping noises but no talkie sound out.

At least my gyro works... so far.

PaulStoffregen
03-17-2016, 08:06 PM
My amp doesn't work either, or rather is makes buzzing and popping noises but no talkie sound out.


I want to get your hardware ASAP for testing, so I can figure out what went wrong! Robin will contact you later today.

defragster
03-17-2016, 08:46 PM
FWIW - Mine works.
I've put hours on my AMP and it is working well from +/- 0.5W speaker and headphone. it is fully socketed to a T_3.2. I have not used the APA102 pins. Just did flash erase and hardware test and reprinted the same calibration data. Also my GYRO is giving good data to IMU with Calibrate, and the here is my just updated Calibration print - followed by Flash erase,test.

<edit>: Only minor Oddity is the IMU app won't pick up Serial sometimes. I can select, unselect, see data on TYQT then disable TYQT Monitor and IMU won't get data until I reset the unit and reconnect IMU app. And when IMU won't show data it does have the port because TYQT cannot get it (Winodws10).


Magnetic Calibration
Hard Iron Offset
37.12
14.83
117.04

Soft Iron Mapping
1.0112 -0.0082 -0.0173
-0.0082 0.9917 0.0323
-0.0173 0.0323 0.9986

Flash Memory has 8388608 bytes.
Erasing ALL Flash Memory:
estimated wait: 20 seconds.
Yes, full chip erase is SLOW!
...................
Erase completed
actual wait: 19 seconds.

Raw SerialFlash Hardware Test

Read Chip Identification:
JEDEC ID: EF 40 17
Part Nummber: W25Q64FV
Memory Size: 8388608 bytes
Block Size: 65536 bytes

Reading Chip...

Writing 4096 signatures

Double Checking All Signatures:
all 4096 signatures read ok

Checking Signature Pairs
all 2047 signature pairs read ok

Checking Read-While-Write (Program Suspend)
write 256 bytes at 256
write time was 441 microseconds.
read-while-writing: 00 00 00 00 15 F5 95 4B
test passed, good read while writing

Checking Read-While-Erase (Erase Suspend)
erase time was 166322 microseconds.
erase correctly erased 65536 bytes
read-while-erasing: 00 00 00 00 15 F5 95 4B
test passed, good read while erasing

All Tests Passed :-)

Test data was written to your chip. You must run
EraseEverything before using this chip for files.

Ben
03-17-2016, 11:53 PM
I tried to investigate why my Prop Shield shows drift and had a look at the raw gyro output provided by

void readMotionSensor(float& ax, float& ay, float& az, float& gx, float& gy, float& gz)
and wrote this to get a moving average to see the offset:


#include <NXPMotionSense.h>

NXPMotionSense imu;
const int ledPin = 13;
int ledState = LOW;
elapsedMillis ledMillis = 0;
elapsedMillis serialMillis = 0;

void setup() {
Serial.begin(115200);
while (!Serial) ; // wait for serial port open
imu.begin();
pinMode(ledPin, OUTPUT);
}

float movingAverage[3];
void loop() {
float gyro[3]; //gyro data in order x y z
float dummy; //a dummy int where readMotionSensor can dump the accel data


// get data
if (imu.available()) {
imu.readMotionSensor(dummy, dummy, dummy, gyro[0], gyro[1], gyro[2]);
//recalculate averages
for (int i=0 ; i<3 ; i++) {
movingAverage[i] = movingAverage[i]*0.999f + gyro[i]*0.001f;
}
}
//print to serial
if (serialMillis >= 500) {
serialMillis -= 500;
Serial.print(movingAverage[0], 5);
Serial.print(", ");
Serial.print(movingAverage[1], 5);
Serial.print(", ");
Serial.print(movingAverage[2], 5);
Serial.println("");
}

//blink LED
if (ledMillis >= 1000) {
ledMillis -= 1000;
if (ledState == LOW) digitalWrite(ledPin, ledState = HIGH);
else digitalWrite(ledPin, ledState = LOW);
}
}

my output after some time:

-0.84893, 0.86430, -0.09326
-0.84667, 0.86420, -0.09219
-0.84867, 0.86518, -0.09173
-0.84748, 0.86680, -0.09283
-0.84604, 0.86525, -0.09367
-0.84852, 0.86463, -0.09165
-0.84878, 0.86428, -0.09439
-0.85037, 0.86443, -0.09540
-0.85026, 0.86683, -0.09417
-0.85017, 0.86826, -0.09538
-0.85107, 0.86773, -0.09533
-0.85257, 0.86840, -0.09655
-0.85200, 0.86745, -0.09800
-0.85093, 0.86623, -0.09696
-0.85047, 0.86623, -0.09711

Then after shaking it and letting it settle again for a couple minutes:


-1.34035, 0.90906, -0.11356
-1.33845, 0.91073, -0.11148
-1.33725, 0.91161, -0.11435
-1.33792, 0.91184, -0.11460
-1.34183, 0.91223, -0.11400
-1.34252, 0.91236, -0.11414
-1.34392, 0.91208, -0.11436
-1.34487, 0.91015, -0.11354
-1.34541, 0.91029, -0.11263
-1.34278, 0.91131, -0.11257
-1.34313, 0.91252, -0.11180
-1.34338, 0.91340, -0.11340
-1.34475, 0.91323, -0.11154
-1.34332, 0.91596, -0.11416
-1.34294, 0.91321, -0.11297
-1.34327, 0.91095, -0.11272
-1.34219, 0.91169, -0.11136

so the offset changed :confused:

Notice I use floats, so this is in degrees per second, not an average of the raw integer values.

If some of you would be so kind to run this code for some minutes and post results? Do your Prop Shields behave the same?

-Ben

Edit: Code's also here: https://github.com/Ben-Rheinland/NXPMotionSense/tree/master/examples/TestGyroscope

PaulStoffregen
03-18-2016, 12:18 AM
I'm seeing this, with the one that's on my desk right now (same as the one I logged yesterday with the plotter)



-0.05944, -0.16238, -0.14935
-0.05749, -0.16098, -0.14897
-0.05449, -0.16069, -0.14927
-0.05210, -0.15898, -0.15031
-0.05385, -0.15895, -0.15127
-0.05415, -0.15820, -0.14912
-0.05351, -0.15895, -0.15041
-0.05318, -0.15829, -0.15199
-0.05139, -0.15831, -0.15188
-0.05335, -0.15680, -0.15171
-0.05411, -0.15773, -0.15200
-0.05561, -0.15742, -0.15084

PaulStoffregen
03-18-2016, 12:25 AM
I gave my board a very vigorous shake for several seconds, then let it settle. Now I'm seeing this:



-0.03475, -0.14212, -0.12813
-0.03416, -0.14235, -0.12915
-0.03388, -0.14054, -0.12969
-0.03787, -0.14303, -0.12819
-0.03777, -0.14283, -0.12675
-0.03887, -0.14247, -0.12647
-0.03645, -0.14157, -0.12542
-0.03870, -0.14204, -0.12572
-0.04091, -0.14277, -0.12654
-0.04022, -0.14199, -0.12671
-0.04048, -0.14185, -0.12665
-0.04136, -0.14095, -0.12530

pictographer
03-18-2016, 12:26 AM
We're not measuring the rotation of the earth, are we? If you flip the orientation 180, do the readings drift in a different direction?

http://www.wired.co.uk/news/archive/2011-02/23/playstation-move-hack

Or maybe this is relate to ITAR? The sensor is intentionally crippled to avoid arms trafficking regulations?

Ben
03-18-2016, 12:43 AM
@Paul your offset looks much better than mine and seems to recover better from shaking. I will investigate further on the weekend.

defragster
03-18-2016, 01:06 AM
I ran the code above for a bit and got this - it seemed to return when going back to my wooden desktop and shaken in free air. You can see iif it shows what you are looking for.



start . . . .
-0.04247, -0.10901, 0.02902
-0.06639, -0.18005, 0.04410
-0.11375, -0.24709, 0.06488
-0.13281, -0.31292, 0.08098

5:46 PM 3/17/2016 << SHAKEN ------

-0.59318, -1.51788, 0.42819
-0.58274, -1.51893, 0.42942
-0.58738, -1.51972, 0.42839
-0.57681, -1.52116, 0.42955
-0.59812, -1.50247, 0.42839
-0.65898, -1.38084, 0.43402
-0.25908, -1.63214, 1.44146
0.14189, 0.06166, 8.98632
3.02387, 2.91671, 14.67131
0.66231, -2.42216, 8.66873
-1.31853, -2.32576, 6.60831
-1.17767, -7.79408, 5.01112
-3.46747, -8.11082, 2.89802
-5.42296, -6.96765, 4.24515
-6.10721, -2.44790, 6.41113
-14.44281, -4.94015, 0.33017
2.65920, -0.94411, 1.12840
1.31437, 0.33808, -0.58399
-2.00174, 1.72423, 4.66322
-10.22663, -4.30171, 2.26541
-3.60680, -4.13442, 15.68208
-10.63062, -7.40791, 16.42157
-3.90650, -11.72521, 26.51940
-10.97616, -16.72645, 27.21338
-23.27667, -20.32959, 26.55439
-9.62276, -32.31821, 38.67164
-21.80443, -28.03357, 38.99112
-28.18420, -23.33231, 36.39219
-15.59743, -20.68818, 35.60229
-15.64517, -20.55730, 31.66413
-15.28123, -20.39620, 31.36851
-13.62677, -19.14669, 30.07308
-12.73997, -18.11305, 28.78445
-12.28807, -17.02123, 27.35917
-11.72452, -16.24940, 26.02020
-11.21889, -15.43207, 24.69112
-10.69281, -14.75488, 23.50751
-10.19556, -14.11033, 22.38184
-9.72129, -13.49634, 21.30986
-9.27108, -12.91413, 20.29208
-8.84080, -12.35932, 19.32423
-8.43734, -11.83174, 18.40151

.....

5:47 PM 3/17/2016

-0.48299, -1.55495, 0.44116
-0.48422, -1.55546, 0.44034
-0.48626, -1.55626, 0.43960
-0.48260, -1.55343, 0.43997
-0.48470, -1.55185, 0.43926
-0.48321, -1.55095, 0.43906
-0.48041, -1.55131, 0.44045
-0.47650, -1.55069, 0.43943
-0.47687, -1.54943, 0.43912
-0.47565, -1.54971, 0.43813
-0.47556, -1.54871, 0.43860

...


5:50 PM 3/17/2016

-0.50408, -1.56597, 0.43822
-0.50244, -1.56552, 0.43693
-0.50187, -1.56409, 0.43657
-0.49845, -1.56345, 0.43589
-0.49353, -1.56108, 0.43424
-0.48901, -1.56221, 0.43391
-0.48772, -1.56082, 0.43308

...

5:53 PM 3/17/2016

-0.48281, -1.54704, 0.42940
-0.48391, -1.54445, 0.42945
-0.48389, -1.54641, 0.43032
-0.48273, -1.54937, 0.42987
-0.48642, -1.55147, 0.43049
-0.48792, -1.55275, 0.43046

...

5:54 PM 3/17/2016 SHAKEN -----------

-0.49586, -1.55172, 0.43597
-0.50018, -1.54983, 0.43538
-0.50000, -1.55112, 0.43399
-0.49940, -1.54848, 0.43287
-0.49826, -1.54931, 0.43223
-0.49491, -1.59703, 0.43003
-0.49002, -1.57563, 0.43150
1.28545, -2.61965, 1.63388
6.46129, 3.88872, 10.08814
8.22576, 7.54464, 11.63682
4.93702, 3.75111, 0.01044
5.35784, -19.14593, -4.40086
9.40530, -18.00746, 5.93152
4.47634, -21.19606, 4.80288
3.85115, -22.13147, 4.60667
2.13024, -12.96994, 7.73207
4.80907, -15.34549, 8.33710
5.28452, -16.29916, 7.15517
6.85971, -13.02245, 8.16220
3.80305, -11.93313, 3.55960
5.15795, -9.09268, 1.02516
11.93230, -16.75019, 4.95976
12.76663, -16.15040, 5.06468
7.54164, -4.99982, -1.33484
8.11709, -6.08714, 0.14008
12.11487, -16.91682, 3.41119
7.58032, -16.25744, 3.28042
3.48484, -16.52768, 2.05204
3.53077, -16.89972, 3.21459
2.02319, -15.30025, 2.63088
1.90327, -14.76658, 2.53200
2.47600, -14.14725, 2.36687
2.32917, -13.53267, 2.27178
2.18840, -12.94291, 2.17907
2.06383, -12.38399, 2.09223
1.93189, -11.85363, 2.01160


...

5:56 PM 3/17/2016

-0.58058, -1.50875, 0.42752
-0.57788, -1.50825, 0.42826
-0.58097, -1.50870, 0.42810


...

5:58 PM 3/17/2016

-0.59716, -1.52556, 0.42761
-0.59407, -1.52492, 0.42695
-0.59543, -1.52583, 0.42655
-0.59634, -1.52402, 0.42593


...

6:04 PM 3/17/2016

-0.60611, -1.50448, 0.42727
-0.60418, -1.50658, 0.42704
-0.60132, -1.50609, 0.42868
-0.60488, -1.50792, 0.42989
-0.60348, -1.50779, 0.43117
-0.60405, -1.50784, 0.43032
-0.60153, -1.50988, 0.43049
-0.60123, -1.51133, 0.43034
-0.60304, -1.50955, 0.42771

Note : I ran IMU with calibration. When I went to set it down it went near my 'MSFT BAND watch' ( running cortex in it that messes up AM radio held in that hand ) and it BLURB'd my IMU image - I left it sit and here is the odd Egg shaped collection I got later with outlier SPEW that I think was the watch proximity - if you have any outside influence you might be seeing this effect?

6730

PaulStoffregen
03-18-2016, 01:22 AM
There's a known issue with mechanical stress, which is common to all MEMS-based sensors. If you bend or twist the PCB, it can create significant offsets due to the mechanical stress placed on the chip's plastic package.

This is something we probably need to mention well on the product page.

Almost everyone else is doing a calibration process to measure and subtract these gyro and accelerometer offsets. Looks like we probably should too. In Freescale's huge algorithm (https://github.com/PaulStoffregen/NXPMotionSense/blob/master/SensorFusion.cpp#L220), there seems to be code which tries to learn the gyroscope offsets, but I must confess I don't fully understand everything they're doing in that code.

3D Joy
03-18-2016, 02:48 AM
Well Paul if you don't fully understand something I'm really out of this loop.
Thanks for all that are participating in the developpement of the prop shield.

Seriously all I need to do is make APA102 LEDs work with the teensy so should I wait or use the OCTOWS2811 shield? I don't need the gyro or the sound amplifier.

PaulStoffregen
03-18-2016, 02:59 AM
Many APA102s work with 3.3V signals, so you might just try wiring pins 11 and 13 to the data and clock lines and see if it works.

Of course, if you have any other SPI chips connected, the APA102s will hear that communication. The prop shield has gates to prevent the APA102s from responding to the communication with other chips. It has a SPI flash chip, which eventually we'll use for images. So much code to write.....

3D Joy
03-18-2016, 03:28 AM
Sorry to derail too much.

Yeah they work at 3.3V here too but not after 24'' of 144/m APA102. I'd like to get more than double that and I know I can use the level shifters mentioned everywhere here on this forum but I'm lazy and frankly not very smart so I need something more plug and play LOL.
So its either the OCTO WS2811 with a hacked code (I think?) or I wait for the prop shield to happen.

Still its very interesting to see this new product being tested and libraries being created.
Good job everyone and thanks for your efforts.

MichaelMeissner
03-18-2016, 03:35 AM
Oh well, live and learn.

Be careful when de-soldering the APA102 connection, since it is near something with the NXPMotion sensors. I had soldered a right angle female header to the 4 pins, and decided I really wanted 4 cables instead. So I tried to de-solder the header. I got 3 of the pins removed, but the fourth one was stuck. Other than the LEDs, it was working fine.

I went to the local electronics guy, asking if he had anything in the shop smaller than the picks I had (which would not fit in the holes), and he tried his hand at removing the solder. Evidently he damaged something, and the i2cscanner gives errors when it runs. If I plug another i2c device into the bus (the Adafruit 8x8 i2c backpack), it can find that device, but none of the 3 devices on the chip. Once when I removed the Adafruit device, it was able to find the other 3 devices, but every other time I've tried to replicate it, it fails.

Hopefully, it will appear in the retail shop soon, so I can buy another one to play with the sensors. The sound amplifier does work. I haven't tried the flash memory yet. I can blink normal LEDs if I attach wires to the APA102 lights, but without soldering the wires down, neopixels didn't run (I'm not sure it was do to my using bare wires, or something is corrupting the data stream).

PaulStoffregen
03-18-2016, 04:38 AM
For long APA102 strips, you'll probably need to use 12 MHz SPI. 24 MHz usually only works between 100 to 200 LEDs.

mortonkopf
03-18-2016, 10:31 AM
Be careful when de-soldering the APA102 connection,
Michael, do you mean the 5DCG pin area when you say APA102 connection?
Regarding your test on 'neopixels', was this from the 5DCG pins?