This sentence about HMC5883L worries me: "but no problem to solder it on the original pads from the BMP085 baro !"
So how could I have both sensors connected?

You're reading it wrong.
But after all, it's just i2c bus so you can connect many things to it at once. You can solder BMP085 breakout to BMP pads, and compass breakout to the C/D/GND pads on the bottom of the board.

Originally Posted by snapper1234

it works, I think the BMP085 also required EOC and XCLR lines, VCC 3.3V !

http://www.rcgroups.com/forums/showp...postcount=1751
http://www.rcgroups.com/forums/showp...postcount=1756

This sentence about HMC5883L worries me: "but no problem to solder it on the original pads from the BMP085 baro !"

He's talking about soldering BMP085.. not HMC5883...

Originally Posted by timecop

You're reading it wrong.
But after all, it's just i2c bus so you can connect many things to it at once. You can solder BMP085 breakout to BMP pads, and compass breakout to the C/D/GND pads on the bottom of the board.

I am a real newbie, so sorry if I ask a lot of explanation.
Soldering BMP085 to FF is OK (in theory …)
If I add HMC5883L breakout, I read I should connect it in this way: SCL (C), SDA (D), GND, and 3V pads. But where is the 3V pad?

Either as I said before (middle pad under PWM outputs on top of PCB) or the one circled here.

Thanks TC, perfectly clear.

Originally Posted by Tom Frank

I'm doing calibration of my white 1.2/1.3 version of the FF controller. I have v1.24 firmware in the FF board and am using v1.0.7 of the ZN Upper Machine configuration program guided by the User Guide dated 02-26-2012 from post #1, so I think I have all the latest version of everything.

The basic settings all went well and system settings all looked to set as they should, and so did the IMU calibration, up to a point.

I have the board sitting level on my slate pool table. The FF board boots up with the designated sequence of LED flashes and beeps and the IMU calibration process triggers by moving both sticks up and outward as the manual states, but it's also triggered by both stick up and inward, which is not mentioned. I figured this might be similar to the controller arming process, which works with both sticks down and either in together or out together, so I didn't get concerned (yet). I let the IMU alibration go to completion with both methods, and it appeared to complete OK, ending with the specified single buzzer beep and extinction of the Green LED.

BUT, in both methods, right after the GREEN LED goes out, I get another buzzer beep followed by three flashes of the RED LED, which then goes out. SO... is this another undocumented feature or error alert. I can find nothing here that explains this, or did I miss it?

<EDIT> If it makes a difference, I don't have my motors hooked up during any of this... didn't think it should matter for calibrating the sticks and setting level reference for the controller board. <EDIT>

Just keeping your post up front so someone can help or have you resolved your problem.

I had the similar or the same problems but magically I seemed to get over them when I played with the board more.

Which TX have you got a Futaba 9C/10C or another brand? (as you would know Futaba throttle stuff is upside down to others)

EDIT: May be not totally magically but also with help of the blokes from here. jesolins spot on with the comments in the following post. That should help.

Hi Tom,
Yes there are undocumented stick movements that will also arm the FF as it was noted noted in the FF Arming 101. Note that there are different arming procedures in the pre FF v1.4 firmware too.
--FF arming 101
--FF Tx channel reversal and camera pitch control 101
--ESC calibration using FF
Cheers,
Jim
Quadrocopter and Tricopter Mega Link Index

Originally Posted by Tom Frank

I'm doing calibration of my white 1.2/1.3 version of the FF controller. I have v1.24 firmware in the FF board and am using v1.0.7 of the ZN Upper Machine configuration program guided by the User Guide dated 02-26-2012 from post #1, so I think I have all the latest version of everything.

The basic settings all went well and system settings all looked to set as they should, and so did the IMU calibration, up to a point.

I have the board sitting level on my slate pool table. The FF board boots up with the designated sequence of LED flashes and beeps and the IMU calibration process triggers by moving both sticks up and outward as the manual states, but it's also triggered by both stick up and inward, which is not mentioned. I figured this might be similar to the controller arming process, which works with both sticks down and either in together or out together, so I didn't get concerned (yet). I let the IMU alibration go to completion with both methods, and it appeared to complete OK, ending with the specified single buzzer beep and extinction of the Green LED.

BUT, in both methods, right after the GREEN LED goes out, I get another buzzer beep followed by three flashes of the RED LED, which then goes out. SO... is this another undocumented feature or error alert. I can find nothing here that explains this, or did I miss it?

<EDIT> If it makes a difference, I don't have my motors hooked up during any of this... didn't think it should matter for calibrating the sticks and setting level reference for the controller board. <EDIT>

Originally Posted by Firepower

Just keeping your post up front so someone can help or have you resolved your problem.

I had the similar or the same problems but magically I seemed to get over them when I played with the board more.

Which TX have you got a Futaba 9C/10C or another brand? (as you would know Futaba throttle stuff is upside down to others)

EDIT: May be not totally magically but also with help of the blokes from here. jesolins spot on with the comments in the following post. That should help.

Originally Posted by jesolins

Hi Tom,
Yes there are undocumented stick movements that will also arm the FF as it was noted noted in the FF Arming 101. Note that there are different arming procedures in the pre FF v1.4 firmware too.
--FF arming 101
--FF Tx channel reversal and camera pitch control 101
--ESC calibration using FF
Cheers,
Jim
Quadrocopter and Tricopter Mega Link Index

My TX is a Futaba 7C.

But maybe I wasn't clear on my question. Arming the FF board is not really the question... I've read and undestood the stick motions for that with FW 1.24, and did see this in the latest User Guide from post #1. I only mentioned the dual ways of arming the board because I found the same applies to starting the IMU calibration using the TX. So this was mainly an observation possibly for a Used Guide revision.

My question was in regard to the IMU calibration itself. I've done this both via the ZN setup program and via the TX using the documented (sticks up and out) motion. In both cases, I get an additional buzzer beep followed by three flashes of the RED right (ending with the LED off) immediatedly after the IMU calibration ends with the documented beep and green LED turning off. So I was asking if the additional beep and flashing of the red LED at the end of the IMU calibration is normal or an error indication of some kind? If it's an error, what does it mean?

After posting, I forgot to mention that I also have installed a baro chip on the boards reserved pads, and based on the ZN output, it looks to be successfully installed and working (see my recent post on this). Perhaps the extra beep and flashing red LED after the IMU calibration completes is related to the presence of the baro chip?

I was hoping someone could could confirm they have gotten the same extra beep and red LED flashes at the end of the IMU calibration, with or without a baro chip on the board. And if so, does the FF board work properly? I'm hesitant to attempt to fly it until I know what is going on... still waiting for motors to arrive before I can even do a tethtered test.

To repeat, I have:

1. white FF board with v1.2 on one side and 1.3 on the other
2. FF version 1.24 installed
3. using ZN v1.7.0
4. BMP085 baro chip installed on the FF board (functioning properly, I believe)

Originally Posted by Tom Frank

4. BMP085 baro chip installed on the FF board (functioning properly, I believe)

With original firmware it only shows altitude, but no other functions - useless for flight.
Works with MultiWii firmware, in case You want to try.

And... Attach motors and test, will be better than just try to understand somehow mixed LED's, working in Chinese logic :P

Originally Posted by Tom Frank

I'm doing calibration of my white 1.2/1.3 version of the FF controller. I have v1.24 firmware in the FF board and am using v1.0.7 of the ZN Upper Machine configuration program guided by the User Guide dated 02-26-2012 from post #1, so I think I have all the latest version of everything.

The basic settings all went well and system settings all looked to set as they should, and so did the IMU calibration, up to a point.

I have the board sitting level on my slate pool table. The FF board boots up with the designated sequence of LED flashes and beeps and the IMU calibration process triggers by moving both sticks up and outward as the manual states, but it's also triggered by both stick up and inward, which is not mentioned. I figured this might be similar to the controller arming process, which works with both sticks down and either in together or out together, so I didn't get concerned (yet). I let the IMU alibration go to completion with both methods, and it appeared to complete OK, ending with the specified single buzzer beep and extinction of the Green LED.

BUT, in both methods, right after the GREEN LED goes out, I get another buzzer beep followed by three flashes of the RED LED, which then goes out. SO... is this another undocumented feature or error alert. I can find nothing here that explains this, or did I miss it?

Tom, I'm a newbie, but I have a FF 1.3/1.2 AND a 1.3/1.3 and they do the same as yours. It's puzzling. But, 24 hrs ago I had never hovered anything, and today I got a stable hover at eyeball level. Sweet. OK, there were also broken props and frightened people during the 1st attempts, but that was my bad, not the FF. If I can fly it, even a caveman can. Great board with no mods.......yet.

Originally Posted by ABLomas

With original firmware it only shows altitude, but no other functions - useless for flight.
Works with MultiWii firmware, in case You want to try.
...

Thank you... yes, I'm aware the baro will do nothing right now with the current FF firmware, but I am planning ahead for later firmware when I will have a need for that function. I will go to MW if FF doesn't implement a new firmware for it (which would be unusual since they provide a space on theri board for one!)

Originally Posted by Crash Testing

Tom, I'm a newbie, but I have a FF 1.3/1.2 AND a 1.3/1.3 and they do the same as yours. It's puzzling. But, 24 hrs ago I had never hovered anything, and today I got a stable hover at eyeball level. Sweet. OK, there were also broken props and frightened people during the 1st attempts, but that was my bad, not the FF. If I can fly it, even a caveman can. Great board with no mods.......yet.

THANK YOU! Exactly what I wanted to hear. This should be added to the User Guide. I just bought and receive my board a few days ago.. and already my board is "obsolete" (just kidding, I hope)! Can you tell any noticeable difference in the boards other than they probably just corrected the obsolete "v1.2" labelling on one side of the board?

Hello again TIME COP... you da man, I mean you are the man, after installing aux and activating the level and acc in multi wii config or multiwiiwin config, the auto function works great...BUT the aux channel MUST be connected from the receiver to the proper position in the FF board. It only took me a day and a half to realize that I didn't have the receiver aux ports connected. (I was in the bathroom (loo to some)and had an eppifinay, just a small one ) and noted to self I need to connect aux to FF board. Now as aloong time rc'er I should have known this. but I didn't, just took it for granted all was connected. Remember to always double check or ask, I could have been flying alot sooner if I had asked. Thank you again Time Cop for your kind pateince and prompt assistance with my tri copter FF board questions. I will continue to follow the progress of the free flight multiwii project.

Your Fellow Multi Rotor Builder and Pilot,
Eddie

Edmack