dev 20120618 and dev 20129616

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
Post Reply
bill516
Posts: 334
Joined: Sun Aug 07, 2011 12:27 pm

dev 20120618 and dev 20129616

Post by bill516 »

Just tried both of these devs and both give the same result and that is no GYRO data or movement in the GUI. Sketch is set up for GY_80 IMU and all other sensors are reading except the GYRO.

Tried with dev 20120522 same settings and the IMU works as it should, only thing I have found that is different is the address for the gyro has changed in the dev 616 and 618 versions.

Also with the 3 dev version I dont get a green led flickering when you press write in the GUI that I get with the V2.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: dev 20120618 and dev 20129616

Post by Alexinparis »

Also with the 3 dev version I dont get a green led flickering when you press write in the GUI that I get with the V2.


This is normal, it was removed to not freeze the GUI during the write eeprom processs.
you can anyway check the right conf with a READ command just after

bill516
Posts: 334
Joined: Sun Aug 07, 2011 12:27 pm

Re: dev 20120618 and dev 20129616

Post by bill516 »

Thanks Alex but have you any explanation of why the GYRO isnt responding in the 616 and 618 dev.

I have had a play around with the addresses in def.h for the ADXL345 but to no avail.

I have found that the green led on my FTDI stops flashing for a short while during the write process so I know its writing.

mr.rc-cam
Posts: 457
Joined: Wed Jul 27, 2011 11:36 pm

Re: dev 20120618 and dev 20129616

Post by mr.rc-cam »

Tried with dev 20120522 same settings and the IMU works as it should, only thing I have found that is different is the address for the gyro has changed in the dev 616 and 618 versions.

The I2C address changes to the sensors got me too when I loaded up MultiWii_dev_20120606. These little code tweaks really can cause some headaches for us that are out of the loop!

It appears that in the most recent dev releases the I2C addresses have been converted to a 7-bit format (an 8-bit format had previously been used). So that is why you see that the I2C address has been rotated right 1-bit. But if you are using the correct sensor defines provided in the new release then your sensor should work the same as before. So double check your defines and prepare to report the bug if all your config choices are correct.

And just for curiosity sake, what is the old I2C address you used (that worked in the old code) and what is the latest one (that does not work in the latest dev code)?
Do you see any errors reported in the GUI's I2C Error counter ?

- Thomas

bill516
Posts: 334
Joined: Sun Aug 07, 2011 12:27 pm

Re: dev 20120618 and dev 20129616

Post by bill516 »

The only define of any consequence is GY_80 in config.h but I have had to add a code rework into the sensor tab for the L3G4200D

// ************************************************************************************************************
// contribution from Ciskje, corrected by wektorx
// I2C Gyroscope L3G4200D
// ************************************************************************************************************
#if defined(L3G4200D)
void Gyro_init() {
delay(100);
delay(5); i2c_writeReg(0XD2+0 ,0x20 ,0b01001111 ); // CTRL_REG1 DR 200Hz BW 20Hz
delay(5); i2c_writeReg(0XD2+0 ,0x21 ,0b00101001 ); // CTRL_REG2
delay(5); i2c_writeReg(0XD2+0 ,0x22 ,0b00000000 ); // CTRL_REG3 all disable
delay(5); i2c_writeReg(0XD2+0 ,0x23 ,0b00110000 ); // CTRL_REG4 2000dps
delay(5); i2c_writeReg(0XD2+0 ,0x24 ,0b00000000 ); // CTRL_REG5
delay(5); i2c_writeReg(0XD2+0 ,0x2E ,0b00000000 ); //
}

void Gyro_getADC () {
TWBR = ((16000000L / 400000L) - 16) / 2; // change the I2C clock rate to 400kHz
i2c_getSixRawADC(0XD2,0x80|0x28);

GYRO_ORIENTATION( ((rawADC[1]<<8) | rawADC[0])/4 ,
((rawADC[3]<<8) | rawADC[2])/4 ,
((rawADC[5]<<8) | rawADC[4])/4 );
GYRO_Common();
}
#endif

With the above code included the board works OK in V2 and DEV 20120522 the ADXL Address in V2 and DEV522 is 0xA6
in the 616 and 618 DEV's the ADXL 345 address is 0x53 in def.h and in the sensor tab it is 0x1D with the 0x53 address commented out underneath.

mr.rc-cam
Posts: 457
Joined: Wed Jul 27, 2011 11:36 pm

Re: dev 20120618 and dev 20129616

Post by mr.rc-cam »

With the above code included the board works OK in V2 and DEV 20120522 the ADXL Address in V2 and DEV522 is 0xA6
in the 616 and 618 DEV's the ADXL 345 address is 0x53 in def.h and in the sensor tab it is 0x1D with the 0x53 address commented out underneath.

An 8bit address of 0xA6 would be 0x53 in 7-bit lingo, so the dev's address seems sane.

The unanswered questions is if the I2C error counter is showing errors (which would confirm there is an address choice problem or something else). So what does the error register report in the GUI when run the latest dev with its GY_80 defines?

BTW, I see a suspicious value in my dev_20120606 code, which may be in yours too. It sets the acc_1G to 265, which seems odd to me. But this means nothing if you are having I2C errors. So first things first.

- Thomas

bill516
Posts: 334
Joined: Sun Aug 07, 2011 12:27 pm

Re: dev 20120618 and dev 20129616

Post by bill516 »

Oh yes I have i2c errors, like they are going out of fashion, they start off as negative numbers then go positive. I thought maybe the i2c errors were due to the fact I did not have any pull resistors so I added some 2K2 to the SDA and SCL lines but the errors still remain, and I even remembered to comment out use internal pullups. I tried the PIPO IMU to see if it had any difference as that was the IMU my supplier told me to use but its still the same, I attempted to try using the default L3G4200D code but my little linux machine decided it did not like the code and spat out errors for me, it compiles under windows no problem, I will have a try on my pc tomorrow even though that gives me grief with the GUI crashing.

mr.rc-cam
Posts: 457
Joined: Wed Jul 27, 2011 11:36 pm

Re: dev 20120618 and dev 20129616

Post by mr.rc-cam »

Comment out the ADXL defines so that this sensor is disabled/ignored. If you still have I2C errors reported in the GUI then the problem is affecting more than just the ADXL. But if no errors are seen with the ADXL removed from the code then you will at least have narrowed down the issue to either an incorrect ADXL address choice or code bug.

Also, go back and recheck the I2C error count while running the old V2.0 version that "works." If it is zero (with all the sensors working) then that would help indicate that the hardware is not part of your problem. If you have errors there too, but have been ignoring them, then it is time to fix the hardware.

- Thomas

bill516
Posts: 334
Joined: Sun Aug 07, 2011 12:27 pm

Re: dev 20120618 and dev 20129616

Post by bill516 »

Well a move forward, commented out ADXL345 no change, so I commented everything out in the GY_80 define and uploaded ran GUI no i2c errors. Put back the sensors one by one and the culprit is the L3G4200D GYRO. Tried with the L3G4200D code that comes with DEV no joy still errors, tried with the code that was re-worked by WEKTORX still errors, but at least I know its in that section but what it is I'm stumped.

mr.rc-cam
Posts: 457
Joined: Wed Jul 27, 2011 11:36 pm

Re: dev 20120618 and dev 20129616

Post by mr.rc-cam »

Load the old MWC V2 version that was "working" well for you. Confirm that all the sensors are running in the GUI. If you still see I2C errors then you may have a sensor problem or the I2C pullups need attention. Typically such problems are due to incorrect pullups.

- Thomas

bill516
Posts: 334
Joined: Sun Aug 07, 2011 12:27 pm

Re: dev 20120618 and dev 20129616

Post by bill516 »

Dev 20120522 loaded and working as it should 0 i2c errors. That is with the 2K2 pullups on the board and the modified code inserted.

Reloaded dev 20102522 with the code that comes with the dev for the L3G4200D and it throws i2c errors. The modified code is the one to use but when put into the 616 618 dev's it doesn't work.

mr.rc-cam
Posts: 457
Joined: Wed Jul 27, 2011 11:36 pm

Re: dev 20120618 and dev 20129616

Post by mr.rc-cam »

Reloaded dev 20102522 with the code that comes with the dev for the L3G4200D and it throws i2c errors. The modified code is the one to use but when put into the 616 618 dev's it doesn't work.

It seems odd that the stock dev code is causing I2C errors only on the gyro. The address it uses looks good. But your modified code is using the old 8-bit address (0xD2). Your mod needs to be updated for the latest dev versions since the 7-bit format (0x69) is required now. For example:

Code: Select all

// ************************************************************************************************************
// contribution from Ciskje, corrected by wektorx
// I2C Gyroscope L3G4200D
// Modified I2C address for 7-bit access (V2 dev)
// ************************************************************************************************************
#if defined(L3G4200D)
#define L3G4200D_ADDRESS 0x69
void Gyro_init() {
  delay(100);
  i2c_writeReg(L3G4200D_ADDRESS ,0x20 ,0b01001111 ); // CTRL_REG1 DR 200Hz BW 20Hz
  delay(5);
  i2c_writeReg(L3G4200D_ADDRESS ,0x21 ,0b00101001 ); // CTRL_REG2
  delay(5);
  i2c_writeReg(L3G4200D_ADDRESS,0x22 ,0b00000000 ); // CTRL_REG3 all disable
  delay(5);
  i2c_writeReg(L3G4200D_ADDRESS,0x23 ,0b00110000 ); // CTRL_REG4 2000dps
  delay(5);
  i2c_writeReg(L3G4200D_ADDRESS,0x24 ,0b00000000 ); // CTRL_REG5
  delay(5);
  i2c_writeReg(L3G4200D_ADDRESS,0x2E ,0b00000000 ); //
  delay(5);
}

void Gyro_getADC () {
  TWBR = ((16000000L / 400000L) - 16) / 2; // change the I2C clock rate to 400kHz
  i2c_getSixRawADC(L3G4200D_ADDRESS,0x80|0x28);

  GYRO_ORIENTATION( ((rawADC[1]<<8) | rawADC[0])/4 ,
  ((rawADC[3]<<8) | rawADC[2])/4 ,
  ((rawADC[5]<<8) | rawADC[4])/4 );
  GYRO_Common();
}
#endif


After the gyro's I2C errors are fixed you will be in a better situation to solve the original problem (the missing ACC data). That said, I recommend that you disable all the other sensors while you work on the gyro code. After the gyro is working error free, enable the other sensors one by one and check for correct data and error-free I2C at each step before adding the next sensor. This will ensure you're not fighting multiple fires.

- Thomas

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: dev 20120618 and dev 20129616

Post by jevermeister »

@Alex: you can let the led blink without freezing the software, just don't use the delay command ;-)


Nils

bill516
Posts: 334
Joined: Sun Aug 07, 2011 12:27 pm

Re: dev 20120618 and dev 20129616

Post by bill516 »

Help I'm drowning, well I'm in over my head. Copied that code into the 618 dev and still i2c errors. I have the data sheet for the L3G4200D for all the good its doing me as none of it seems to tally with the code.

mr.rc-cam
Posts: 457
Joined: Wed Jul 27, 2011 11:36 pm

Re: dev 20120618 and dev 20129616

Post by mr.rc-cam »

I don't have access to dev618 but I looked at dev606 and dev622. I can't see anything in them that would explain the L3G4200D's I2C errors. I don't have this sensor so I am not able to do much more.

Some general comments:
1. Until you solve the I2C errors, troubleshoot with the stock (unmodified code). Using the #defines, disable all the sensors except the L3G4200D.
2. Find someone else that has your GY-80 sensor board and confirm that they have success on the dev release you are using.
3. You mentioned you added the 2.2K pullups. These are the ideal values for the Arduino's 5V I2C buss. However, are you sure that are no other pullups hiding in your sensor board or Arduino shield? Are the 3V sensors using proper LLC's? It would be grand if posted a schematic of the GY-80.
4. For extra credit, Re-read the first post in this I2C white paper discussion many times until EVERYTHING about I2C is clear to you: viewtopic.php?f=8&t=986

Please keep in mind that the dev releases are **experimental** code. Bugs are expected. So it might be best to go back to the formal release and use it while the dev version branches mature a bit more.

- Thomas

bill516
Posts: 334
Joined: Sun Aug 07, 2011 12:27 pm

Re: dev 20120618 and dev 20129616

Post by bill516 »

This is the thing, it works as it should with V2 and dev 20120522, its when we move to the next devs 616, 618 and now 622 that the problem appears. I don know about pullups on the sensor board but I know the only pullups on my shield are the ones I fitted the other day, but even without those pullups I was getting this problem. I would love to have a schematic for this board but the only inof I got from the supplier was define as PIPO in config .h until Katch came along with his updates for the Chinese IMU's. I'll read that thread tomorrow but in the mean time I was looking at the 7 bit code you posted and while comparing to the data sheet, I think I am begining to understand it a bit.

If we take address 0x20 , 0b01001111 as an example, that is refering to control reg 1 and the first 0100 are setting the Data Rate 200 Hz and Band Width to 20Hz. The 1111 are for the PD, power down mode, ZEN, z axis mode, YEN, y axis mode and XEN, x axis mode with a value 1 being normal or enabled. I havn't been through the others yet but am I right in my interpretation so far. Its getting late my head hurts and my eyes hurt even more I@m going to bed.

mr.rc-cam
Posts: 457
Joined: Wed Jul 27, 2011 11:36 pm

Re: dev 20120618 and dev 20129616

Post by mr.rc-cam »

This is the thing, it works as it should with V2 and dev 20120522, its when we move to the next devs 616, 618 and now 622 that the problem appears.

This kind of observation has caused confusion many times before. An I2C buss that has a poor pullup configuration can become unreliable with improvements to the code. For example, things like minor changes to how often the I2C is accessed can affect it. So although it is comforting to know everything works well on the prior versions, that in itself does not guarantee that the I2C is robust. Just something to keep in mind.

I looked at the recent dev code again to see if anything jarring would pop out. The only notable thing I can report is that I2C clock calculations now use the compiler variable called F_CPU. Earlier MWC code had this hardcoded as 16000000L because the most common Osc speed is 16MHz. F_CPU is a compiler directed value that is tied to the board you selected in the IDE's tools menu, so it automatically uses the correct Osc value for the target hardware. If the board that is chosen {in the menu} is not the correct one then the I2C clock speed would be wrong. For example, if an 8MHz board was chosen, but the target is actually a 16MHz board, then the I2C clock would be too fast and I2C errors would occur.

In the Arduino IDE, select Tools->Board and reconfirm you have the correct board selected. That is to say, your Arduino's CPU name should be in the list and it should be 16MHz. Be sure it is the one that is selected.

If the board choice correctly matches your installed Arduino then maybe it would be worth your time to edit the L3G4200D code and replace all instances of F_CPU with 16000000L. At this point that's all I got to offer.

- Thomas

bill516
Posts: 334
Joined: Sun Aug 07, 2011 12:27 pm

Re: dev 20120618 and dev 20129616

Post by bill516 »

What's that saying give a thousand monkeys a fish in a barrel or something, well give an old Airframe tech a hammer and he'll make it fit. I made it fit, GYRO now reads as well as all the other sensors on my IMU GY_80 board. The trick was really a shot in the dark I changed the address from 0x69 to 0x68 and it works, but whether it has any impact on anything else I dont know. Changed the 69 for 68 in the 606, 628 and 622 devs and they all work as expected, although I have come up with a new error in 618 and 622 dev sensors, togglebeep =2 is not defined in the section, comment it out and it compiles and runs same as if you do not un-comment inflight calibration in config.h.

mr.rc-cam
Posts: 457
Joined: Wed Jul 27, 2011 11:36 pm

Re: dev 20120618 and dev 20129616

Post by mr.rc-cam »

Congrats! That is the alternate I2C address for the sensor based on the how the board was designed (a pin on the chip is soldered to logic low or high to determine the address). I had thought about the alternate address, but since it was working error free in the old code it did not make sense you would need to use the other address with the new code. It might be wise to report this GY-80 config issue so the alternate address is in the board's define.

- Thomas

bill516
Posts: 334
Joined: Sun Aug 07, 2011 12:27 pm

Re: dev 20120618 and dev 20129616

Post by bill516 »

I agree on reporting but who too and how, BTW it was pure luck that I tried 68 I was thinking 70.

mr.rc-cam
Posts: 457
Joined: Wed Jul 27, 2011 11:36 pm

Re: dev 20120618 and dev 20129616

Post by mr.rc-cam »

I agree on reporting but who too and how,

In the old days, when things were at a slow {and perhaps at a more controlled} pace, a MWC bug would be reported in the thread that announced the formal release. But these experimental dev releases occur often and without an announcement. So this is a question you should pose to Alex; It would be good to know how he would like bugs to be formally reported now.

And as a generally comment, the dev releases are wild cards. Anyone that intends to use them should understand that bugs are expected. So proceed at your own risk and be prepared to spend more time tinkering than flying. :)

- Thomas

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: dev 20120618 and dev 20129616

Post by Alexinparis »

mr.rc-cam wrote:
I agree on reporting but who too and how,

In the old days, when things were at a slow {and perhaps at a more controlled} pace, a MWC bug would be reported in the thread that announced the formal release. But these experimental dev releases occur often and without an announcement. So this is a question you should pose to Alex; It would be good to know how he would like bugs to be formally reported now.

And as a generally comment, the dev releases are wild cards. Anyone that intends to use them should understand that bugs are expected. So proceed at your own risk and be prepared to spend more time tinkering than flying. :)

- Thomas


Hi Thomas,

In fews days, I will "freeze" features (I'm still waiting 2 3 addons).
After, there will be some "pre" or "rc" version in order to be able to release a clean 2.1

mr.rc-cam
Posts: 457
Joined: Wed Jul 27, 2011 11:36 pm

Re: dev 20120618 and dev 20129616

Post by mr.rc-cam »

After, there will be some "pre" or "rc" version in order to be able to release a clean 2.1

A clean V2.1 would be fantastic. Thanks! :)
- Thomas

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: dev 20120618 and dev 20129616

Post by Hamburger »

anyone succeed in compiling either LED FLASHER or Landing Lights?
Both produce compiler errors for me like
error: 'PB4' was not declared in this scope

Several postings suggest same or similar errors with both features.
As it seems it never worked to begin with (Alex mentioned same effect earlier) for regular Arduino IDE users, should it be removed as we are getting closer to release?

As it stands v2.1 will come with a load of new features and has the chance to be more stable than earlier releases. So we might limit the features to choose from in config.h to those that stand a chance to work?

crashlander
Posts: 506
Joined: Thu May 05, 2011 8:13 am
Location: Slovenia

Re: dev 20120618 and dev 20129616

Post by crashlander »

Define for MMA7455 is still wrong in latest shared:

Code: Select all

 //#define MMA745

should be

Code: Select all

 //#define MMA7455


And since Led flasher (inside LED.ino) says...

Code: Select all

  LED_FLASHER_DDR |= (1<<LED_FLASHER_BIT);

it is probably enough to change (config.h)

Code: Select all

#define LED_FLASHER_BIT PB4

into

Code: Select all

#define LED_FLASHER_BIT 4
?

Regards
Andrej

fiendie
Posts: 151
Joined: Fri Apr 20, 2012 4:22 pm

Re: dev 20120618 and dev 20129616

Post by fiendie »

Hamburger wrote:anyone succeed in compiling either LED FLASHER or Landing Lights?
Both produce compiler errors for me like
error: 'PB4' was not declared in this scope

Several postings suggest same or similar errors with both features.
As it seems it never worked to begin with (Alex mentioned same effect earlier) for regular Arduino IDE users, should it be removed as we are getting closer to release?

As it stands v2.1 will come with a load of new features and has the chance to be more stable than earlier releases. So we might limit the features to choose from in config.h to those that stand a chance to work?


It depends on which board you are using.
Just try renaming PB4 to PORTB4 and it will most likely work. I don't really know why AVR pins were used but it's trivial to fix.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: dev 20120618 and dev 20129616

Post by Tommie »

I just checked, PB4 is defined as an alias to PORTB4 - and it is defined in <avr/portpins.h> which is always included by <avr/io.h>; this is what happens with my Arduino IDE as well - it might be a version issue. If changing PB4 to PORTB4 fixes the issue, I'm fine with it.

Post Reply