Naze32Pro STMF3 help thread

Gaijin · Post by **Gaijin** » Mon Jul 14, 2014 6:25 pm

Maybe we should start a NazePro thread

Good idea treym so thats what I have done ...

Hopefully this thread can become a useful resource for all the Naze32Pro early adopters

To Kick things off I will link to the baseflight github repo and some of the forked firmware that supports the hardware,also below you will find a link to the page of Naze32 Hardware discussion thread containing the helpful advice treym and TC have offered to date

https://github.com/multiwii/baseflight
https://github.com/treymarc/FF32mini
https://github.com/hydra/cleanflight
http://www.multiwii.com/forum/viewtopic.php?f=23&t=5149

http://www.multiwii.com/forum/viewtopic.php?f=22&t=2387&start=2400#p53281

Now a request...

Can someone break down the requirements / tools a little more for flashing newer versions of Cleanflight / Baseflight / FF32Mini to a Naze32Pro for me to experiment with, I'm quite used to using Flash Loader, hercules, Arduino and other hombrew type projects but outside of the OpenTx Projects Companion9X have little experience with DFU files and the type of STM chips that need them, the configurator(s) apparently won't work for this yet?

I'll be using one of the pre-compiled binaries and would like to backup the baseflight firmware installed too if possible as I have yet to manage to compile anything from source without seriously messing it up, I'm rather more of a tester / hardware experimenter and would really appreciate the help.

********************************************EDITED***************************************************
***Edited for clarity as requested, quote replaced with a link to the thread in question***

treym · Post by **treym** » Tue Jul 15, 2014 12:19 am

source : https://bitbucket.org/treymarc/baseflight
doc : NazePro Pinout/Wiring
firmware : hex/dfu

Other source that you may want to look at :
https://github.com/multiwii/baseflight
https://github.com/jihlein/FF32mini
https://github.com/hydra/cleanflight

to backup the firmware :

short answer

- linux/mac will use dfu-util
- windows will use dfu tools from st electronic

- enter bootloader mode by typing "R" in the cli or by shorting the boot pin (see picture below)
- the device will now appears as a usb device in dfu mode
- download the firmware using the above mentioned tool
- save the firmware into a file

long answer
- this need proper documentation and screenshoot, ie : code need to be moved to github for that to happen
- soon™

some tests :

scrat · Post by **scrat** » Tue Jul 15, 2014 9:35 am

What is the difference between AfroFlight32 rev5 and Pro version? Thx!

fiendie · Post by **fiendie** » Tue Jul 15, 2014 9:48 am

scrat wrote:What is the difference between AfroFlight32 rev5 and Pro version? Thx!

Different MCU (with on-chip USB instead of a USB-Serial chip), sensors connected to SPI instead of i2c.

scrat · Post by **scrat** » Tue Jul 15, 2014 9:53 am

How much and where can I buy this fc?

fiendie · Post by **fiendie** » Tue Jul 15, 2014 9:57 am

scrat wrote:How much and where can I buy this fc?

The real question is if it would be worth it. There are no real-world benefits compared to the regular naze at the moment. The code is far from finished and large parts are untested. treym even changed the default settings to go with his Spektrum gear (imagine that...).

scrat · Post by **scrat** » Tue Jul 15, 2014 10:00 am

Uf. Then not for me. Thx!

timecop · Post by **timecop** » Tue Jul 15, 2014 11:07 am

spektrum gear is amazing

Gaijin · Post by **Gaijin** » Tue Jul 15, 2014 12:34 pm

Sorry to keep flogging this one TC but did you use the 16v regs on the last batch, I think you did but would rather check

timecop · Post by **timecop** » Tue Jul 15, 2014 1:00 pm

Should be - if it says |L3xx on the top then yes.

treym · Post by **treym** » Tue Jul 15, 2014 7:55 pm

scrat wrote:What is the difference between AfroFlight32 rev5 and Pro version? Thx!

Real FPU and code change for a better attitude estimation.
No need for soft serial
More output .. if you need them .. want to build a 14 motors model ?

fiendie wrote:treym even changed the default settings to go with his Spektrum gear (imagine that...).

yes , it was either spektrum or pwm or ppm or sumd .. had to chose one .

ps project is make/gcc ... keil project file is there for convenience , so it will spit warning .

ArrogantDuck · Post by **ArrogantDuck** » Tue Jul 15, 2014 11:40 pm

Yes, where would one get one of these to test?
Somewhere, read that it has gps built in, too.
Quite curious.
Thanks.

theailer · Post by **theailer** » Wed Jul 16, 2014 7:28 am

Hehe. It will most likely never have GPS built in

treym · Post by **treym** » Wed Jul 16, 2014 12:41 pm

ArrogantDuck wrote:Yes, where would one get one of these to test?

the nazePro is not listed you must explicitly ask for one by using the contact form on http://abusemark.com/store/ or join #multiwii

as far as i know : board is provide without support, your are on your own , "hell no support".. etc .. for early adopters or dev

Gaijin · Post by **Gaijin** » Wed Jul 16, 2014 5:39 pm

theailer wrote:Hehe. It will most likely never have GPS built in

Not if it still wants to fit on a 36 x 36mm PCB :lol:

that said I wouldn't bet Tc couldn't do it if he wanted to, look at how much he packed into the AfroMini

Yeah this board is currently for for Devs and the adventurous only, if you aren't ready to work at it I'd give it a miss for the time being.

I chose it as I've used various generations of Naze boards in my other multis over the years and wanted to try something new in a 250 H quad build, that said only a few years ago the Naze32 itself was in similar uncharted territory until it became more established, I enjoy the challenge of trying something new and seeing what the community can do with it.

The next question then, I assume the 5v / 3.3v / ground pins are useful voltage supply points from the boards regs?

timecop · Post by **timecop** » Thu Jul 17, 2014 1:22 am

yes, 5V is from esc power, 3.3V is from mcu reg. don't draw much more than 100mA from it tho

Gaijin · Post by **Gaijin** » Fri Jul 18, 2014 7:39 am

So then,

Still working out how to flash the Pro, think I have the toolset now but don't have a dfu (or Hex) image, any of the devs with a free moment feel like compiling the latest version?
I realise I can "theoretically" do it myself, but, TBH I suck at it

Although my board doesn't show in the StM Dfuse App at all and I'm not convinced it is entering DFU mode, I send R via Hercules and the board flashes and reboots, Hercules will no longer open the serial port but device manager still shows it as STMicroelectronics Virtual COM Port (COM47) not a DFU aware STM device as listed in the DFuse manual , I flash OpenTx to a Taranis all the time via Companion9x so I assume everything is in place driverwise .

When I have the process cracked and have more free time (renovating a new house before moving in ATM) I will document and add the flashing process to the Wiki, scouts honour

jihlein · Post by **jihlein** » Wed Jul 23, 2014 1:15 pm

Curious as to how well some of you are seeing the MPU6000 accels work on Naze32Pro Rev2 boards.

I have a Naze32Pro Rev1 and the MPU6000 is usable without applying any calibration routines. I have 2 Naze32Pro Rev2 boards that are really bad, they measure better than 11.5 MPS^2 just sitting on the bench, and don't perform well at all even after calibration, the accelerometer data wanders all over, even with temp compensation. The two Rev2 boards exhibit really poor bias and scale factor values.

I have 4 AQ32 boards of various revision, and the MPU6000s on those boards works fine too.

So either there is an issue with the Naze32Pro Rev2 (highly doubtful), or an issue with the MPU6000 chips (more likely). Anyone hear of production issues from Invensense?

I'm going to work on some more sophisticated calibration algorithms to see if I can make these boards useable.

On the software front, I've been experimenting with designing the controls in Matlab and Simulink, automatically generating the flight control parts of the code. Also have added support for an external I2C magnetometer, which I'm currently debugging. None of this has hit the FF32mini GIT repo yet,

timecop · Post by **timecop** » Wed Jul 23, 2014 3:31 pm

The MPU6000's are from the same bag I've had for nearly 2 years now - I bought 100 and have been (very) slowly using them.
brm also mentioned this - one board he got needed almost no calibration - and he was surprised, asked me if I got a new batch of MPU6k or something... Unfortunately, I have no idea how such variations are possible from a single reel...

jihlein · Post by **jihlein** » Wed Jul 23, 2014 5:07 pm

Unfortunately, I have no idea how such variations are possible from a single reel...

Me neither.....

brm · Post by **brm** » Thu Jul 24, 2014 7:50 am

maybe just a variation of the init sequence:
https://www.google.ch/search?q=multiwii+Signal+Path+Reset&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:de:official&client=firefox-a&channel=np&source=hp&gfe_rd=cr&ei=mqvQU7LoD82-_QazwYHQDw
resetting the signal path is on my list.
will measure the variance of the accel unit and see how much it differs.

treym · Post by **treym** » Thu Jul 24, 2014 9:03 am

this is what is used in the baseflight port

https://bitbucket.org/treymarc/baseflig ... ter#cl-176

Code: Select all

    ENABLE_MPU6000;
    spiTransferByte(MPU6000_PWR_MGMT_1);          // Device Reset
    spiTransferByte(BIT_H_RESET);
    DISABLE_MPU6000;

    delay(150);

    ENABLE_MPU6000;
    spiTransferByte(MPU6000_SIGNAL_PATH_RESET);          // Device Reset
    spiTransferByte(BIT_GYRO | BIT_ACC | BIT_TEMP);
    DISABLE_MPU6000;

i dont have noticed any issue with nazePro rev1 and rev2

jihlein · Post by **jihlein** » Thu Jul 24, 2014 1:16 pm

Thanks, I'll give it a try tonight and report back!

But this leads me to wonder about Register 106, User Control. Bit 0, SIG_COND_RESET, is defined as follows:

When set to 1, this bit resets the signal paths for all sensors (gyroscopes, accelerometers, and temperature sensor). This operation will also clear the sensor registers. This bit automatically clears to 0 after the reset has been triggered.
When resetting only the signal path (and not the sensor registers), please use Register 104, SIGNAL_PATH_RESET.

I Wonder if there is any benefit to clearing the sensor registers too?? Need to experiment some........

jihlein · Post by **jihlein** » Fri Jul 25, 2014 1:11 pm

Unfortunately, the modified reset sequences on startup had no effect on the poor bias/scale factor accuracy issue. These two MPU6000 chips may be on the outer edge of the specs, plain and simple.

brm · Post by **brm** » Sat Jul 26, 2014 4:52 pm

jihlein wrote:Unfortunately, the modified reset sequences on startup had no effect on the poor bias/scale factor accuracy issue. These two MPU6000 chips may be on the outer edge of the specs, plain and simple.

ok, i got 3 more boards - 2 ok with baseflight and one doesn't boot at all.
seems to be a sad issue.

intially i thought the mpu-6000 would be ok - but now ...

timecop · Post by **timecop** » Sun Jul 27, 2014 4:49 am

All of those were loaded with treym's baseflight which did work - but I'm not sure if he touches SPI flash in his code.

brm · Post by **brm** » Sun Jul 27, 2014 9:37 am

timecop wrote:All of those were loaded with treym's baseflight which did work - but I'm not sure if he touches SPI flash in his code.

yes, the access to the spi flash fails.
it does respond to the read ID comand. but not much more ...

timecop · Post by **timecop** » Sun Jul 27, 2014 9:43 am

Then it works.
This is the flash chip used:
M25P16-VMN6TP

Pretty sure this is ds:
http://www.micron.com/-/media/Documents ... M25P16.pdf

brm · Post by **brm** » Sun Jul 27, 2014 4:35 pm

timecop wrote:Then it works.
This is the flash chip used:
M25P16-VMN6TP

Pretty sure this is ds:
http://www.micron.com/-/media/Documents ... M25P16.pdf

yes, i can read the id.
but not the uid bytes.
which is possible with the 'previous' version.

timecop · Post by **timecop** » Sun Jul 27, 2014 4:45 pm

So look at datasheet and make sure command IDs match. Read ID command is always same, but read/write block/etc stuff could be different.
like 2 years ago I had 4mbit flash chips that I used, which have different commands from 16mbit ones. Compare what's on the label, and if that's the case, specialcase the new chip. Then again, jihlein has the same hardware as you do, and is probably flying, so I guess there's something else that's wrong, probably software.

brm · Post by **brm** » Sun Jul 27, 2014 5:27 pm

timecop wrote:So look at datasheet and make sure command IDs match. Read ID command is always same, but read/write block/etc stuff could be different.
like 2 years ago I had 4mbit flash chips that I used, which have different commands from 16mbit ones. Compare what's on the label, and if that's the case, specialcase the new chip. Then again, jihlein has the same hardware as you do, and is probably flying, so I guess there's something else that's wrong, probably software.

entering the bootloader with 'R' doesn't do anything good (using baseflight from marc).
It does not activate the internal DFU routines.

all works on the prev. flight controller.
I changed from normal to fast read mode but it doesn't help.

timecop · Post by **timecop** » Mon Jul 28, 2014 1:26 am

Unless someone actually spent the time to read reference manual and/or do some debugging to find entry point for ROM bootloader, I wouldn't expect R to reboot to work. With DFU devices, it should be different anyway - it should provide a "dfu capable" descriptor on the VCP device, so that DFU-util can automatically enter in firmware update mode.

treym · Post by **treym** » Mon Jul 28, 2014 4:52 am

brm wrote:entering the bootloader with 'R' doesn't do anything good (using baseflight from marc).

true , this is an known issue, please refere to the fixme/testme list

startup.s will reboot to dfu with gcc , keil startup.s will reset/reboot

With keil compiled firmware , just short the boot pin , so your are sure it get into dfu

ps : https://bitbucket.org/treymarc/baseflig ... ?at=master

brm · Post by **brm** » Mon Jul 28, 2014 9:50 am

timecop wrote:Unless someone actually spent the time to read reference manual and/or do some debugging to find entry point for ROM bootloader, I wouldn't expect R to reboot to work. With DFU devices, it should be different anyway - it should provide a "dfu capable" descriptor on the VCP device, so that DFU-util can automatically enter in firmware update mode.

yes, i know - RTFM

but from 3 boards i tested one - which has a faulti flash chip.
the other two boards do work.

just a matter of testing.
the driver is ok

and from the past i know they do fly ...

and there is no need to provide some sort of dfu capable bits.
the chip from the factory without any use code can enter the dfu mode just by 'using' the boot0 pin.

treym · Post by **treym** » Mon Jul 28, 2014 12:00 pm

Gaijin wrote: but don't have a dfu (or Hex) image, any of the devs with a free moment feel like compiling the latest version?

done, you can find them in the second post

i did not test the baseflight configurator but you may want to try -> 'load the dev version and uncomment"
https://github.com/multiwii/baseflight- ... ault.js#L7

danhouldsworth · Post by **danhouldsworth** » Wed Aug 20, 2014 10:49 am

timecop wrote:The MPU6000's are from the same bag I've had for nearly 2 years now - I bought 100 and have been (very) slowly using them.
brm also mentioned this - one board he got needed almost no calibration - and he was surprised, asked me if I got a new batch of MPU6k or something... Unfortunately, I have no idea how such variations are possible from a single reel...

Apologies if this is a stupid question - but do you assemble / solder the Naze boards yourself? I'd always assumed a fab house was used even for prototype boards. If not, looks like I need to up my game with soldering :oops:

Back on track, if I contact you through the abusemark store, would I be able to get hold of a few of these Pro boards?
I've currently got 5 of your Naze32Acro and 2 Naze32 mainly on Armattan and WarpQuads, and now want to tinker with custom set ups.

The aspects I'm really interested in are the SPI access of the MPU as I know from the datasheets this enables me a theoretical 8000hz read rate, and also the DSM / FPU instructions of the CortexM4.

Ps. For what its worth I'd be *really* interested (and would happily pre-order a handful) if you did a lite/acro version - Ie STMF3 + MPU6000 + Serial (for Spektrum Sat) + On board regulator for direct 3s/4s lipo power. No I2C hassle, no external FTDI, no magnometer to read due north from my 80amp power lines, no altimeter to drop when the wind is blowing, no need for anything else. I could have a lot of fun tinkering with that :mrgreen:

treym · Post by **treym** » Wed Aug 20, 2014 10:09 pm

danhouldsworth wrote:The aspects I'm really interested in are the SPI access of the MPU as I know from the datasheets this enables me a theoretical 8000hz read rate

Hello,

Short answer , you would need something faster than a stm32f3@72mhz , code can be made faster but i dont think it can be made as fast as : 1/8000 - 125 , a stm32f4@168mhz will meet the required speed ( ~73 ) i can say not much but it is believed that the next NazePro version will aslo meet the required speed :p

While the Naze32Pro is to be viewed as a intermediate prototype the next gen flight controller is being polished they are 100% awesome.

danhouldsworth · Post by **danhouldsworth** » Thu Aug 21, 2014 11:52 am

Thanks treym

I'll look forward to getting my hands on the next gen versions :mrgreen:

I've only just started looking through your code, but are you able to point to where you read / filter the MPU?

Theres a technique of integrate and dump http://diydrones.com/profiles/blogs/measuring-tilt-dynamics-of-multicoptersI'm keen to experiment with (hence my interest in super high read rates) to see if we can get better positional estimates from 2nd integral of accels, without needing baro or gps. Of course, it will always drift over time, but if its possible to improve the accuracy by 1 or 2 orders of magnitude - I would definitely settle for a Loiter that held within a metre for ~30secs if I could forgoe the extra sensor overhead / cost / weight.

ps. On the hardware serial vs software serial. Forgive my ignorance, but is this basically so the chip itself if listening to the rise and fall of the signal voltage and clock and so can process the byte stream in the background, vs our flight controller having to schedule regular time to doing this task? If so, this is a serious plus for me, as I like to avoid spending processor time or my time

on sorting out interfaces and drivers...

timecop · Post by **timecop** » Tue Aug 26, 2014 1:17 am

Yeah you can send a message and get some. I do assemble them myself, tho not hand-placed (I do have a machine for it).

Regarding 8000Hz sampling, MPU has fifo, you don't need to read it on each loop (that would be silly actually), so I don't see a problem with that. Running gyro at 8kHz ODR and filtering it even at 1kHz is perfectly doable even on F1/72MHz.

re: lite, I do have something w/mpu6500 on SPI and F1, but I'm still waiting for PCBs for that to show up and then will need some coding to make it work w/current baseflight.

danhouldsworth · Post by **danhouldsworth** » Fri Sep 05, 2014 10:40 am

Excellent! Thanks - I'll wait for the lite versions. Should give me enough time to bootstrap myself up the STM / ARM learning curve, as only recently got the build environment set up as had gone back to playing with AVRs.

Do you assemble the production boards or just the protoypes? Any pointers / links to surface mount component placing machines - I'm already invested in this hobby so if its reasonable (in regards to size as much as cost!) I'd be open to having a play. It's all learning for me.
Good move with HK now supplying your Naze board. Hope they're playing nice on the royalties....

timecop · Post by **timecop** » Fri Sep 05, 2014 10:54 am

if you've seen recent commits to baseflight, you probably noticed mpu6500 support is in.

yes I assemble the boards and no I don't think you can afford the $60k+ I've invested in my pick and place so far. but it's also very useless for prototypes, unless a board is very complex, it would take longer to program in a job + update parts on feeders etc than it would take to hand place one.

brm · Post by **brm** » Sat Sep 06, 2014 11:09 am

danhouldsworth wrote:Thanks treym

I'll look forward to getting my hands on the next gen versions

I've only just started looking through your code, but are you able to point to where you read / filter the MPU?

Theres a technique of integrate and dump http://diydrones.com/profiles/blogs/measuring-tilt-dynamics-of-multicoptersI'm keen to experiment with (hence my interest in super high read rates) to see if we can get better positional estimates from 2nd integral of accels, without needing baro or gps. Of course, it will always drift over time, but if its possible to improve the accuracy by 1 or 2 orders of magnitude - I would definitely settle for a Loiter that held within a metre for ~30secs if I could forgoe the extra sensor overhead / cost / weight.

ps. On the hardware serial vs software serial. Forgive my ignorance, but is this basically so the chip itself if listening to the rise and fall of the signal voltage and clock and so can process the byte stream in the background, vs our flight controller having to schedule regular time to doing this task? If so, this is a serious plus for me, as I like to avoid spending processor time or my time on sorting out interfaces and drivers...

on the spi bus it needs 55us to go thorugh a complete read cycle for the mpu-6000.
from bills blog post you can destilate a simple to do.
you need to sample mems data at ten times of the imu rate - then you make shure you get rid of noise.
filter the samples with lp filter.
the interesting apsect is the reduced effect on high frequency noise.
you can also enable the fifo buffer and issue a mems device read at 4khz for example.
from my experience it can tell you it helps.
the marg sensor fusion need a little less than 190us.

maybe i can recap a sentence from bill nesbitt: having a clean view on the data.
but the real kicker comes when the pelican has landed.
then you run the sensor fusion also at the data rate

using the sensor fusion as the lp filter.

forget anything about a 328p ...

treym · Post by **treym** » Tue Sep 09, 2014 11:55 pm

hum..

thanks to an accurate reader, it has been pointed out that there is a typo in the code ...

https://bitbucket.org/treymarc/baseflig ... ter#cl-134

my bad, this inadvertly deactivate the onboard mag

Gaijin · Post by **Gaijin** » Fri Sep 26, 2014 8:11 pm

Treym,

I can't get my Pro to go into flashing mode, nothing shows in DFuse even if I power on with the bootloader shorted, it's driving me crazy!

timecop · Post by **timecop** » Sat Sep 27, 2014 1:10 pm

Did it work before?

Gaijin · Post by **Gaijin** » Sat Sep 27, 2014 7:09 pm

No I've never managed it, it has been waiting for me to develop some extra free time and fit it into my development quad, but as I seem to have cooked the Naze32 I fitted to a 250 sized quad it's gone in there (I don't make a habit of this but I messed up while wiring a MWOSD and released some magic smoke from an unspecified place, it still flew fine but yesterday after a flight I disarmed and when I tried to fly again it was kaput) , functionally the pro is fine but I lagging behind in improvements.

The correct flashing app is the STM DFuse app right?

Normally if I get stuck it's just something stupid (for example touching the bootloader pins after power up) that I can solve myself with a bit of research but as the Pro is the road less travelled I have gone nowhere.

All help appreciated

jihlein · Post by **jihlein** » Sun Sep 28, 2014 5:51 pm

1)Short BOOT0 pin
2)Power up board
3)Start DFUse application

If a DFU compatible device does not show up in the upper left corner of the DFUse window, I can only think of 1 or 2 things that would cause that.

1)Board is dead. I don't think this is your issue, because it sounds like your board is operational with the old software.
2)You don't have the proper drivers loaded on the computer running DFUse. On my Win7 laptop, these drivers loaded the first time I hooked up the board while it was in DFUse mode (powered up after BOOT0 was shorted), FWIW.

jihlein · Post by **jihlein** » Tue Oct 07, 2014 12:13 am

Has anyone successfully gotten I2C working over the STM32F3 PB6/PB7 pins on the Naze32Pro? I'm trying to talk to an external HMC5883 with no success.

I've tried both hard and soft I2C routines, each with different, non working results.

Hardware I2C does not respond at all. The start SCL and SDA waveforms look correct though, properly clocking out the address at with a 400 kHz rate. But there is no ACK from the HMC5883.

Software I2C ACKs the start command, and all the initialization commands are accepted, but all reads return 0xFF, as verified in both the software and via the logic analyzer. This at least tells me the breakout board is hooked up correctly.

It's got to be something silly, but I can't for the life of me figure it out. It's most like due to improper timing setup, but I've tried various timing register configs with no success, although SCL is clocking at 400 kHz as desired. I know from some of my other experiments the HMC5883 is sensitive to clockspeeds, it does not like to be overclocked.

I also know the HMC5883 is good as I tried it on the F4 I2C bus and it works fine. I also have used this I2C driver on the STM32F3 Discivery board and successfully taked to the I2C device on that board. Stumped for the moment........

Guess I should load the STM32F3 Discovery board software and modify it to talk to the HMC5883 and see if it works there.......

jihlein · Post by **jihlein** » Tue Oct 07, 2014 12:14 am

Double post deleted.......

treym · Post by **treym** » Tue Oct 07, 2014 10:09 pm

jihlein wrote:Has anyone successfully gotten I2C working over the STM32F3 PB6/PB7 pins on the Naze32Pro? I'm trying to talk to an external HMC5883 with no success.

Yes , work for me [1], I decided to use PB8/9 [2] to keep it aligned within the greater scheme of dog [3] cause i am just a lolcat ..

I did look at your code and yes .. cant tell you the specific lines , .. but the issue is related to the clock/init part.

edit : since i also changed to use the default lib layout , and i also redownloaded from ti web sit .. your comment are still to be found in the code, do a grep with your login and do a quick diff

1: https://bitbucket.org/treymarc/baseflight/overview
2 : https://docs.google.com/spreadsheets/d/ ... edit#gid=0
3 : http://askdongs.com/CatIHazBadPinout?