MultiWii 1.9

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
mr.rc-cam
Posts: 457
Joined: Wed Jul 27, 2011 11:36 pm

Re: MultiWii 1.9

Post by mr.rc-cam »

Stalk wrote:I added an external pullups 2k2. WMP and BMA020 are supplied directly from 5V.
In v1.8p2: WMP and BMA020 work, errors are about 600 in 5 minutes.
In v1.9.: Both work debug2 = 0 for 5 minutes.
Good job, thank you very much.

You are welcome. With the I2C problems solved, you will now find that your PID's can be further optimized for much more precise flight behavior. So you did the right thing to fix the hardware rather than solve it with software tricks.

As a general comment to all, the use of the software defined internal pullups has shown to be a poor solution. These internal pullups are very high value (20K-50K ohms). To add to the frustration, pullup resistors on many of the sensor BOB and LLC boards are 10K ohms. But from what I have seen, for good I2C communication many WiiCopter installations need something closer to 2.2K ohms. Some shields already have these installed for you (may require jumpers to enable them). The point is that if you have built your own shield, and have I2C issues (as reported by GUI's V1.9 debug2), then first thing on the list is to review your use of SDA and SCL pullups.

Reflex wrote:Hi. not sure if this is useful here but I find BMP085 Baro won't work in 1.8 or 1.9 (tried 2 baro's) they do however work in 1.7

That is interesting. When you say it doesn't work do you mean that the baro data is 0? If you are sure the BMP085 is still working in V1.7 (check it again), and does not work in 1.8-1.9, then that is unexpected. But as you may have learned here, it helps to use the I2C error counter test to verify if your installation has I2C problems. If the I2C communication is not reliable then anything is possible.
Last edited by mr.rc-cam on Thu Nov 17, 2011 6:09 pm, edited 1 time in total.

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: MultiWii 1.9

Post by shikra »

Update...

I just had quick test. To small an area to fly around, but it was enough to tell ..... :D

So I can confirm....
It works! Damned well too.

Calibrated the multi level, took off, flicked switch and it returned to perfect level and locked there real firm....
No additional acc calibration trim needed...
It was windy too....

I tried rocking and invoking a wobble of death with no issues.
Flew it in the angle mode using sticks and it seemed pretty good, but I only had an area 6m*6m to test and didn't try any tuning...

Using the same settings before where the tri would drift terrible....

AND BEST OF ALL !
This is with same copter / settings that drifts terrible on previous versions

I think you guys will like :D :D

I'll create a thread later and write up the details so Alex can take a look to see if it's suitable to integrate.

I have another idea too - I think it will work very well for baro alt hold too.....

Reflex
Posts: 12
Joined: Sat Sep 10, 2011 3:54 pm

Re: MultiWii 1.9

Post by Reflex »

Hi. Yes Baro data is 0 , lots of I2C errors showing in 1.9
WM+ works fine in 1.7 , 1.8 and 1.9

Almost seems 1.9 is not looking in the right place for Baro data in 1.8 and 1.9
Anyone else tried the BMP085 ?

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

Re: MultiWii 1.9

Post by mr.rc-cam »

Reflex wrote:Hi. Yes Baro data is 0 , lots of I2C errors showing in 1.9
WM+ works fine in 1.7 , 1.8 and 1.9
Almost seems 1.9 is not looking in the right place for Baro data in 1.8 and 1.9
Anyone else tried the BMP085 ?

I have a BMP085 and data is present in V1.7 - V1.9. There have been no significant code changes to the BMP085 sensor R/W functions that would explain your missing data problem. One important thing is that V1.7 only had one baro sensor choice in it; In version 1.8-1.9 there is more than one baro sensor choice to select from. So check your sketch for accurate sensor defines.

It would best to start a new thread about your issue since it does not seem to be a V1.9 related bug. But some things to help get you started:
1. Disable the BMP085 in the sketch. If you still have I2C errors then you have I2C problems.
2. Ensure your ACC sensor is working. The ACC data is needed to use the ALT feature.
3. Ignore the ALT data window for now. If you see any moving data in the V1.8 or V1.9 GUI's debug1 window then the BMP085 is active.

- Thomas

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

Re: MultiWii 1.9

Post by jevermeister »

mr.rc-cam wrote:
Reflex wrote:Hi. Yes Baro data is 0 , lots of I2C errors showing in 1.9
WM+ works fine in 1.7 , 1.8 and 1.9
Almost seems 1.9 is not looking in the right place for Baro data in 1.8 and 1.9
Anyone else tried the BMP085 ?

I have a BMP085 and data is present in V1.7 - V1.9. There have been no significant code changes to the BMP085 sensor R/W functions that would explain your missing data problem. One important thing is that V1.7 only had one baro sensor choice in it; In version 1.8-1.9 there is more than one baro sensor choice to select from. So check your sketch for accurate sensor defines.

It would best to start a new thread about your issue since it does not seem to be a V1.9 related bug. But some things to help get you started:
1. Disable the BMP085 in the sketch. If you still have I2C errors then you have I2C problems.
2. Ensure your ACC sensor is working. The ACC data is needed to use the ALT feature.
3. Ignore the ALT data window for now. If you see any moving data in the V1.8 or V1.9 GUI's debug1 window then the BMP085 is active.

- Thomas





+1 on on working bmp, had no problems with sensor reading throughout all versions. I use BMP085

Reflex
Posts: 12
Joined: Sat Sep 10, 2011 3:54 pm

Re: MultiWii 1.9

Post by Reflex »

Thanks for the feedback

I should say. I'm not going to use the BMP085 on a Wii copter
I'm hoping to build a Visual Variometer for model gliders

If the Baro is tied to the ACC in the 1.9 code
this explains why I'm getting no readings (No ACC)

Thanks again

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

Re: MultiWii 1.9

Post by mr.rc-cam »

Reflex wrote:If the Baro is tied to the ACC in the 1.9 code this explains why I'm getting no readings (No ACC)

That is correct. In V1.8 and V1.9, if the ACC sensor is not working then ALT data window will report 0 and the ALT graph data will be flat-lined. In other words, the V1.8 & V1.9 Alt-Hold feature requires a Baro sensor *and* a ACC sensor. However, even without the ACC sensor the GUI's debug1 window will show the baro data if the BMP085 is working.

However, you mentioned you have I2C errors that are reported in V1.9. These errors are not reported by the GUI in the earlier versions (pre V1.9) but it is likely they are occurring there too. So keep in mind that you have I2C problems that need investigation.

Reflex
Posts: 12
Joined: Sat Sep 10, 2011 3:54 pm

Re: MultiWii 1.9

Post by Reflex »

Cheers I'll 'scope the data lines and adjust pull-up values if needed.

I added a thread about the Visual Variometer
viewtopic.php?f=7&t=904

User avatar
UndCon
Posts: 293
Joined: Mon Feb 21, 2011 2:10 pm

Re: MultiWii 1.9

Post by UndCon »

I have a board with a BMP085 - this image shows the board(paris 4.0) lying on my desk running the latest version of 1.9 (downloaded today)

Image

spagoziak
Posts: 171
Joined: Thu Jan 20, 2011 1:18 am

Re: MultiWii 1.9

Post by spagoziak »

mr.rc-cam wrote:
I use genuine Wmp and bma020 without problems but I also use baro and mag.

Additional homework items for Stalk, Spagoziak, and jevermeister:
1. On the BMA020 schematic is a pair of I/O wire connection areas labeled ST1 and ST2. Please post the details to where you have connected each of their five pins/pads.
2. There is a PCB jumper pad labeled J1. Is yours open (no solder short) or closed (solder shorted)?

- Thomas


While I was searching the thread for some clue about what you mean by ST1 and 2, I found Alex's code (below) and figured I'd give it a shot... Went' from 50,000 errors in 30 seconds to 0 in 10 minutes, according to debug2 on the GUI @ version 1.9!

I haven't had a chance to fly it... everyone is asleep here and this thing makes far too much noise to fly tonight. Tomorrow is another story, wish me luck! This is tremendous, by the way--Alex & Thomas, your help on such a deep level is greatly appreciated! This is something I doubt I'd ever figure out :oops:

spag

Here is a pic of the GUI after 10 minutes of sitting here on the table:
0 errors on debug2 after 10 minutes of sitting still
0 errors on debug2 after 10 minutes of sitting still


Here is the code chunk from Alex I stumbled upon, linked here:

Code: Select all

// ************************************************************************************************************
// board orientation and setup
// ************************************************************************************************************
//default board orientation
#if !defined(ACC_ORIENTATION)
  #define ACC_ORIENTATION(X, Y, Z)  {accADC[ROLL]  = X; accADC[PITCH]  = Y; accADC[YAW]  = Z;}
#endif
#if !defined(GYRO_ORIENTATION)
  #define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = X; gyroADC[PITCH] = Y; gyroADC[YAW] = Z;}
#endif
#if !defined(MAG_ORIENTATION)
  #define MAG_ORIENTATION(X, Y, Z)  {magADC[ROLL]  = X; magADC[PITCH]  = Y; magADC[YAW]  = Z;}
#endif

/*** I2C address ***/
#if !defined(ADXL345_ADDRESS)
  #define ADXL345_ADDRESS 0x3A
  //#define ADXL345_ADDRESS 0xA6   //WARNING: Conflicts with a Wii Motion plus!
#endif

#if !defined(BMA180_ADDRESS)
  #define BMA180_ADDRESS 0x80
  //#define BMA180_ADDRESS 0x82
#endif

#if !defined(ITG3200_ADDRESS)
  #define ITG3200_ADDRESS 0XD0
  //#define ITG3200_ADDRESS 0XD2
#endif

#if !defined(MS561101BA_ADDRESS)
  #define MS561101BA_ADDRESS 0xEE //CBR=0 0xEE I2C address when pin CSB is connected to LOW (GND)
  //#define MS561101BA_ADDRESS 0xEF //CBR=1 0xEF I2C address when pin CSB is connected to HIGH (VCC)
#endif

//ITG3200 and ITG3205 Gyro LPF setting
#if defined(ITG3200_LPF_256HZ) || defined(ITG3200_LPF_188HZ) || defined(ITG3200_LPF_98HZ) || defined(ITG3200_LPF_42HZ) || defined(ITG3200_LPF_20HZ) || defined(ITG3200_LPF_10HZ)
  #if defined(ITG3200_LPF_256HZ)
    #define ITG3200_SMPLRT_DIV 0  //8000Hz
    #define ITG3200_DLPF_CFG   0
  #endif
  #if defined(ITG3200_LPF_188HZ)
    #define ITG3200_SMPLRT_DIV 0  //1000Hz
    #define ITG3200_DLPF_CFG   1
  #endif
  #if defined(ITG3200_LPF_98HZ)
    #define ITG3200_SMPLRT_DIV 0
    #define ITG3200_DLPF_CFG   2
  #endif
  #if defined(ITG3200_LPF_42HZ)
    #define ITG3200_SMPLRT_DIV 0
    #define ITG3200_DLPF_CFG   3
  #endif
  #if defined(ITG3200_LPF_20HZ)
    #define ITG3200_SMPLRT_DIV 0
    #define ITG3200_DLPF_CFG   4
  #endif
  #if defined(ITG3200_LPF_10HZ)
    #define ITG3200_SMPLRT_DIV 0
    #define ITG3200_DLPF_CFG   5
  #endif
#else
    //Default settings LPF 256Hz/8000Hz sample
    #define ITG3200_SMPLRT_DIV 0  //8000Hz
    #define ITG3200_DLPF_CFG   0
#endif

uint8_t rawADC[6];
static uint32_t neutralizeTime = 0;
 
// ************************************************************************************************************
// I2C general functions
// ************************************************************************************************************

// Mask prescaler bits : only 5 bits of TWSR defines the status of each I2C request
#define TW_STATUS_MASK   (1<<TWS7) | (1<<TWS6) | (1<<TWS5) | (1<<TWS4) | (1<<TWS3)
#define TW_STATUS       (TWSR & TW_STATUS_MASK)

void i2c_init(void) {
  #if defined(INTERNAL_I2C_PULLUPS)
    I2C_PULLUPS_ENABLE
  #else
    I2C_PULLUPS_DISABLE
  #endif
  TWSR = 0;                                    // no prescaler => prescaler = 1
  TWBR = ((16000000L / I2C_SPEED) - 16) / 2;   // change the I2C clock rate
  TWCR = 1<<TWEN;                              // enable twi module, no interrupt
}

void i2c_rep_start(uint8_t address) {
  TWCR = (1<<TWINT) | (1<<TWSTA) | (1<<TWEN) ; // send REPEAT START condition
  waitTransmissionI2C();                       // wait until transmission completed
  TWDR = address;                              // send device address
  TWCR = (1<<TWINT) | (1<<TWEN);
  waitTransmissionI2C();                       // wail until transmission completed
}

void i2c_stop(void) {
  TWCR = (1 << TWINT) | (1 << TWEN) | (1 << TWSTO);
  //  while(TWCR & (1<<TWSTO));                <- can produce a blocking state with some WMP clones
}

void i2c_write(uint8_t data ) {   
  TWDR = data;                                 // send data to the previously addressed device
  TWCR = (1<<TWINT) | (1<<TWEN);
  waitTransmissionI2C();
}

uint8_t i2c_readAck() {
  TWCR = (1<<TWINT) | (1<<TWEN) | (1<<TWEA);
  waitTransmissionI2C();
  return TWDR;
}

uint8_t i2c_readNak(void) {
  TWCR = (1<<TWINT) | (1<<TWEN);
  waitTransmissionI2C();
  i2c_stop();
  return TWDR;
}

void waitTransmissionI2C() {
  uint16_t count = 255;
  while (!(TWCR & (1<<TWINT))) {
    count--;
    if (count==0) {              //we are in a blocking state => we don't insist
      TWCR = 0;                  //and we force a reset on TWINT register
      neutralizeTime = micros(); //we take a timestamp here to neutralize the value during a short delay
      #ifdef LOG_VALUES
        i2c_errors_count++;
      #endif
      break;
    }
  }
}

void i2c_getSixRawADC(uint8_t add, uint8_t reg) {
  i2c_rep_start(add);
  i2c_write(reg);         // Start multiple read at the reg register
  i2c_rep_start(add +1);  // I2C read direction => I2C address + 1
  for(uint8_t i = 0; i < 5; i++)
    rawADC[i]=i2c_readAck();
  rawADC[5]= i2c_readNak();
}

void i2c_writeReg(uint8_t add, uint8_t reg, uint8_t val) {
  i2c_rep_start(add+0);  // I2C write direction
  i2c_write(reg);        // register selection
  i2c_write(val);        // value to write in register
  i2c_stop();
}

uint8_t i2c_readReg(uint8_t add, uint8_t reg) {
  i2c_rep_start(add+0);  // I2C write direction
  i2c_write(reg);        // register selection
  i2c_rep_start(add+1);  // I2C read direction
  return i2c_readNak();  // Read single register and return value
}

// ****************
// GYRO common part
// ****************
void GYRO_Common() {
  static int16_t previousGyroADC[3] = {0,0,0};
  static int32_t g[3];
  uint8_t axis;
 
  if (calibratingG>0) {
    for (axis = 0; axis < 3; axis++) {
      // Reset g[axis] at start of calibration
      if (calibratingG == 400) g[axis]=0;
      // Sum up 400 readings
      g[axis] +=gyroADC[axis];
      // Clear global variables for next reading
      gyroADC[axis]=0;
      gyroZero[axis]=0;
      if (calibratingG == 1) {
        gyroZero[axis]=g[axis]/400;
        blinkLED(10,15,1+3*nunchuk);
      }
    }
    calibratingG--;
  }
  for (axis = 0; axis < 3; axis++) {
    gyroADC[axis]  -= gyroZero[axis];
    //anti gyro glitch, limit the variation between two consecutive readings
    gyroADC[axis] = constrain(gyroADC[axis],previousGyroADC[axis]-800,previousGyroADC[axis]+800);
    previousGyroADC[axis] = gyroADC[axis];
  }
}

// ****************
// ACC common part
// ****************
void ACC_Common() {
  static int32_t a[3];
 
  if (calibratingA>0) {
    for (uint8_t axis = 0; axis < 3; axis++) {
      // Reset a[axis] at start of calibration
      if (calibratingA == 400) a[axis]=0;
      // Sum up 400 readings
      a[axis] +=accADC[axis];
      // Clear global variables for next reading
      accADC[axis]=0;
      accZero[axis]=0;
    }
    // Calculate average, shift Z down by acc_1G and store values in EEPROM at end of calibration
    if (calibratingA == 1) {
      accZero[ROLL]  = a[ROLL]/400;
      accZero[PITCH] = a[PITCH]/400;
      accZero[YAW]   = a[YAW]/400-acc_1G; // for nunchuk 200=1G
      accTrim[ROLL]   = 0;
      accTrim[PITCH]  = 0;
      writeParams(); // write accZero in EEPROM
    }
    calibratingA--;
  }
  accADC[ROLL]  -=  accZero[ROLL] ;
  accADC[PITCH] -=  accZero[PITCH];
  accADC[YAW]   -=  accZero[YAW] ;
}


// ************************************************************************************************************
// I2C Barometer BOSCH BMP085
// ************************************************************************************************************
// I2C adress: 0xEE (8bit)   0x77 (7bit)
// principle:
//  1) read the calibration register (only once at the initialization)
//  2) read uncompensated temperature (not mandatory at every cycle)
//  3) read uncompensated pressure
//  4) raw temp + raw pressure => calculation of the adjusted pressure
//  the following code uses the maximum precision setting (oversampling setting 3)
// ************************************************************************************************************

#if defined(BMP085)
#define BMP085_ADDRESS 0xEE
static struct {
  // sensor registers from the BOSCH BMP085 datasheet
  int16_t  ac1, ac2, ac3, b1, b2, mb, mc, md;
  uint16_t ac4, ac5, ac6;
  union {uint16_t val; uint8_t raw[2]; } ut; //uncompensated T
  union {uint32_t val; uint8_t raw[4]; } up; //uncompensated P
  uint8_t  state;
  uint32_t deadline;
} bmp085_ctx; 
#define OSS 3

void i2c_BMP085_readCalibration(){
  delay(10);
  bmp085_ctx.ac1 = i2c_BMP085_readIntRegister(0xAA);
  bmp085_ctx.ac2 = i2c_BMP085_readIntRegister(0xAC);
  bmp085_ctx.ac3 = i2c_BMP085_readIntRegister(0xAE);
  bmp085_ctx.ac4 = i2c_BMP085_readIntRegister(0xB0);
  bmp085_ctx.ac5 = i2c_BMP085_readIntRegister(0xB2);
  bmp085_ctx.ac6 = i2c_BMP085_readIntRegister(0xB4);
  bmp085_ctx.b1  = i2c_BMP085_readIntRegister(0xB6);
  bmp085_ctx.b2  = i2c_BMP085_readIntRegister(0xB8);
  bmp085_ctx.mb  = i2c_BMP085_readIntRegister(0xBA);
  bmp085_ctx.mc  = i2c_BMP085_readIntRegister(0xBC);
  bmp085_ctx.md  = i2c_BMP085_readIntRegister(0xBE);
}

void  Baro_init() {
  delay(10);
  i2c_BMP085_readCalibration();
  i2c_BMP085_UT_Start();
  delay(5);
  i2c_BMP085_UT_Read();
}

// read a 16 bit register
int16_t i2c_BMP085_readIntRegister(uint8_t r) {
  union {int16_t val; uint8_t raw[2]; } data;
  i2c_rep_start(BMP085_ADDRESS + 0);
  i2c_write(r);
  i2c_rep_start(BMP085_ADDRESS + 1);//I2C read direction => 1
  data.raw[1] = i2c_readAck();
  data.raw[0] = i2c_readNak();
  return data.val;
}

// read uncompensated temperature value: send command first
void i2c_BMP085_UT_Start() {
  i2c_writeReg(BMP085_ADDRESS,0xf4,0x2e);
  i2c_rep_start(BMP085_ADDRESS + 0);
  i2c_write(0xF6);
  i2c_stop();
}

// read uncompensated pressure value: send command first
void i2c_BMP085_UP_Start () {
  i2c_writeReg(BMP085_ADDRESS,0xf4,0x34+(OSS<<6)); // control register value for oversampling setting 3
  i2c_rep_start(BMP085_ADDRESS + 0); //I2C write direction => 0
  i2c_write(0xF6);
  i2c_stop();
}

// read uncompensated pressure value: read result bytes
// the datasheet suggests a delay of 25.5 ms (oversampling settings 3) after the send command
void i2c_BMP085_UP_Read () {
  i2c_rep_start(BMP085_ADDRESS + 1);//I2C read direction => 1
  bmp085_ctx.up.raw[2] = i2c_readAck();
  bmp085_ctx.up.raw[1] = i2c_readAck();
  bmp085_ctx.up.raw[0] = i2c_readNak();
}

// read uncompensated temperature value: read result bytes
// the datasheet suggests a delay of 4.5 ms after the send command
void i2c_BMP085_UT_Read() {
  i2c_rep_start(BMP085_ADDRESS + 1);//I2C read direction => 1
  bmp085_ctx.ut.raw[1] = i2c_readAck();
  bmp085_ctx.ut.raw[0] = i2c_readNak();
}

void i2c_BMP085_Calculate() {
  int32_t  x1, x2, x3, b3, b5, b6, p, tmp;
  uint32_t b4, b7;
  // Temperature calculations
  x1 = ((int32_t)bmp085_ctx.ut.val - bmp085_ctx.ac6) * bmp085_ctx.ac5 >> 15;
  x2 = ((int32_t)bmp085_ctx.mc << 11) / (x1 + bmp085_ctx.md);
  b5 = x1 + x2;
  // Pressure calculations
  b6 = b5 - 4000;
  x1 = (bmp085_ctx.b2 * (b6 * b6 >> 12)) >> 11;
  x2 = bmp085_ctx.ac2 * b6 >> 11;
  x3 = x1 + x2;
  tmp = bmp085_ctx.ac1;
  tmp = (tmp*4 + x3) << OSS;
  b3 = (tmp+2)/4;
  x1 = bmp085_ctx.ac3 * b6 >> 13;
  x2 = (bmp085_ctx.b1 * (b6 * b6 >> 12)) >> 16;
  x3 = ((x1 + x2) + 2) >> 2;
  b4 = (bmp085_ctx.ac4 * (uint32_t)(x3 + 32768)) >> 15;
  b7 = ((uint32_t) (bmp085_ctx.up.val >> (8-OSS)) - b3) * (50000 >> OSS);
  p = b7 < 0x80000000 ? (b7 * 2) / b4 : (b7 / b4) * 2;
  x1 = (p >> 8) * (p >> 8);
  x1 = (x1 * 3038) >> 16;
  x2 = (-7357 * p) >> 16;
  pressure = p + ((x1 + x2 + 3791) >> 4);
}

void Baro_update() {
  if (currentTime < bmp085_ctx.deadline) return;
  bmp085_ctx.deadline = currentTime;
  TWBR = ((16000000L / 400000L) - 16) / 2; // change the I2C clock rate to 400kHz, BMP085 is ok with this speed
  switch (bmp085_ctx.state) {
    case 0:
      i2c_BMP085_UT_Start();
      bmp085_ctx.state++; bmp085_ctx.deadline += 4600;
      break;
    case 1:
      i2c_BMP085_UT_Read();
      bmp085_ctx.state++;
      break;
    case 2:
      i2c_BMP085_UP_Start();
      bmp085_ctx.state++; bmp085_ctx.deadline += 26000;
      break;
    case 3:
      i2c_BMP085_UP_Read();
      i2c_BMP085_Calculate();
      BaroAlt = (1.0f - pow(pressure/101325.0f, 0.190295f)) * 4433000.0f;
      bmp085_ctx.state = 0; bmp085_ctx.deadline += 20000;
      break;
  }
}
#endif

// ************************************************************************************************************
// I2C Barometer MS561101BA
// ************************************************************************************************************
// first contribution from Fabio
// modification from Alex (September 2011)
//
// specs are here: http://www.meas-spec.com/downloads/MS5611-01BA03.pdf
// useful info on pages 7 -> 12
#if defined(MS561101BA)

// registers of the device
#define MS561101BA_PRESSURE    0x40
#define MS561101BA_TEMPERATURE 0x50
#define MS561101BA_RESET       0x1E

// OSR (Over Sampling Ratio) constants
#define MS561101BA_OSR_256  0x00
#define MS561101BA_OSR_512  0x02
#define MS561101BA_OSR_1024 0x04
#define MS561101BA_OSR_2048 0x06
#define MS561101BA_OSR_4096 0x08

#define OSR MS561101BA_OSR_4096

static struct {
  // sensor registers from the MS561101BA datasheet
  uint16_t c[7];
  union {uint32_t val; uint8_t raw[4]; } ut; //uncompensated T
  union {uint32_t val; uint8_t raw[4]; } up; //uncompensated P
  uint8_t  state;
  uint32_t deadline;
} ms561101ba_ctx;

void i2c_MS561101BA_reset(){
  i2c_writeReg(MS561101BA_ADDRESS, MS561101BA_RESET, 0);
}

void i2c_MS561101BA_readCalibration(){
  union {uint16_t val; uint8_t raw[2]; } data;
  delay(10);
  for(uint8_t i=0;i<6;i++) {
    i2c_rep_start(MS561101BA_ADDRESS + 0);
    i2c_write(0xA2+2*i);
    i2c_rep_start(MS561101BA_ADDRESS + 1);//I2C read direction => 1
    data.raw[1] = i2c_readAck();  // read a 16 bit register
    data.raw[0] = i2c_readNak();
    ms561101ba_ctx.c[i+1] = data.val;
  }
}

void  Baro_init() {
  delay(10);
  i2c_MS561101BA_reset();
  delay(10);
  i2c_MS561101BA_readCalibration();
}

// read uncompensated temperature value: send command first
void i2c_MS561101BA_UT_Start() {
  i2c_rep_start(MS561101BA_ADDRESS+0);      // I2C write direction
  i2c_write(MS561101BA_TEMPERATURE + OSR);  // register selection
  i2c_stop();
}

// read uncompensated pressure value: send command first
void i2c_MS561101BA_UP_Start () {
  i2c_rep_start(MS561101BA_ADDRESS+0);      // I2C write direction
  i2c_write(MS561101BA_PRESSURE + OSR);     // register selection
  i2c_stop();
}

// read uncompensated pressure value: read result bytes
void i2c_MS561101BA_UP_Read () {
  i2c_rep_start(MS561101BA_ADDRESS + 0);
  i2c_write(0);
  i2c_rep_start(MS561101BA_ADDRESS + 1);
  ms561101ba_ctx.up.raw[2] = i2c_readAck();
  ms561101ba_ctx.up.raw[1] = i2c_readAck();
  ms561101ba_ctx.up.raw[0] = i2c_readNak();
}

// read uncompensated temperature value: read result bytes
void i2c_MS561101BA_UT_Read() {
  i2c_rep_start(MS561101BA_ADDRESS + 0);
  i2c_write(0);
  i2c_rep_start(MS561101BA_ADDRESS + 1);
  ms561101ba_ctx.ut.raw[2] = i2c_readAck();
  ms561101ba_ctx.ut.raw[1] = i2c_readAck();
  ms561101ba_ctx.ut.raw[0] = i2c_readNak();
}

void i2c_MS561101BA_Calculate() {
  int64_t dT   = ms561101ba_ctx.ut.val - ((uint32_t)ms561101ba_ctx.c[5] << 8);  //int32_t according to the spec, but int64_t here to avoid cast after
  int64_t off  = ((uint32_t)ms561101ba_ctx.c[2] <<16) + ((dT * ms561101ba_ctx.c[4]) >> 7);
  int64_t sens = ((uint32_t)ms561101ba_ctx.c[1] <<15) + ((dT * ms561101ba_ctx.c[3]) >> 8);
  pressure     = (( (ms561101ba_ctx.up.val * sens ) >> 21) - off) >> 15;
}

void Baro_update() {
  if (currentTime < ms561101ba_ctx.deadline) return;
  ms561101ba_ctx.deadline = currentTime;
  TWBR = ((16000000L / 400000L) - 16) / 2; // change the I2C clock rate to 400kHz, MS5611 is ok with this speed
  switch (ms561101ba_ctx.state) {
    case 0:
      i2c_MS561101BA_UT_Start();
      ms561101ba_ctx.state++; ms561101ba_ctx.deadline += 15000; //according to the specs, the pause should be at least 8.22ms
      break;
    case 1:
      i2c_MS561101BA_UT_Read();
      ms561101ba_ctx.state++;
      break;
    case 2:
      i2c_MS561101BA_UP_Start();
      ms561101ba_ctx.state++; ms561101ba_ctx.deadline += 15000; //according to the specs, the pause should be at least 8.22ms
      break;
    case 3:
      i2c_MS561101BA_UP_Read();
      i2c_MS561101BA_Calculate();
      BaroAlt = (1.0f - pow(pressure/101325.0f, 0.190295f)) * 4433000.0f;
      ms561101ba_ctx.state = 0; ms561101ba_ctx.deadline += 30000;
      break;
  }
}
#endif


// ************************************************************************************************************
// I2C Accelerometer ADXL345
// ************************************************************************************************************
// I2C adress: 0x3A (8bit)    0x1D (7bit)
// Resolution: 10bit (Full range - 14bit, but this is autoscaling 10bit ADC to the range +- 16g)
// principle:
//  1) CS PIN must be linked to VCC to select the I2C mode
//  2) SD0 PIN must be linked to VCC to select the right I2C adress
//  3) bit  b00000100 must be set on register 0x2D to read data (only once at the initialization)
//  4) bits b00001011 must be set on register 0x31 to select the data format (only once at the initialization)
// ************************************************************************************************************
#if defined(ADXL345)
void ACC_init () {
  delay(10);
  i2c_writeReg(ADXL345_ADDRESS,0x2D,1<<3); //  register: Power CTRL  -- value: Set measure bit 3 on
  i2c_writeReg(ADXL345_ADDRESS,0x31,0x0B); //  register: DATA_FORMAT -- value: Set bits 3(full range) and 1 0 on (+/- 16g-range)
  i2c_writeReg(ADXL345_ADDRESS,0x2C,8+2+1); // register: BW_RATE     -- value: 200Hz sampling (see table 5 of the spec)
  acc_1G = 256;
}

void ACC_getADC () {
  TWBR = ((16000000L / 400000L) - 16) / 2; // change the I2C clock rate to 400kHz, ADXL435 is ok with this speed
  i2c_getSixRawADC(ADXL345_ADDRESS,0x32);

  ACC_ORIENTATION( - ((rawADC[3]<<8) | rawADC[2]) ,
                     ((rawADC[1]<<8) | rawADC[0]) ,
                     ((rawADC[5]<<8) | rawADC[4]) );
  ACC_Common();
}
#endif

// ************************************************************************************************************
// contribution initially from opie11 (rc-groups)
// adaptation from C2po (may 2011)
// contribution from ziss_dm (June 2011)
// contribution from ToLuSe (Jully 2011)
// I2C Accelerometer BMA180
// ************************************************************************************************************
// I2C adress: 0x80 (8bit)    0x40 (7bit) (SDO connection to VCC)
// I2C adress: 0x82 (8bit)    0x41 (7bit) (SDO connection to VDDIO)
// Resolution: 14bit
//
// Control registers:
//
// 0x20    bw_tcs:   |                                           bw<3:0> |                        tcs<3:0> |
//                   |                                             150Hz |                 !!Calibration!! |
// ************************************************************************************************************
#if defined(BMA180)
void ACC_init () {
  delay(10);
  //default range 2G: 1G = 4096 unit.
  i2c_writeReg(BMA180_ADDRESS,0x0D,1<<4); // register: ctrl_reg0  -- value: set bit ee_w to 1 to enable writing
  delay(5);
  uint8_t control = i2c_readReg(BMA180_ADDRESS, 0x20);
  control = control & 0x0F; // register: bw_tcs reg: bits 4-7 to set bw -- value: set low pass filter to 10Hz (bits value = 0000xxxx)
  control = control | 0x00;
  i2c_writeReg(BMA180_ADDRESS, 0x20, control);
  delay(5);
  control = i2c_readReg(BMA180_ADDRESS, 0x30);
  control = control & 0xFC;
  control = control | 0x02;
  i2c_writeReg(BMA180_ADDRESS, 0x30, control);
  delay(5);
  acc_1G = 512;
}

void ACC_getADC () {
  TWBR = ((16000000L / 400000L) - 16) / 2;  // Optional line.  Sensor is good for it in the spec.
  i2c_getSixRawADC(BMA180_ADDRESS,0x02);
  //usefull info is on the 14 bits  [2-15] bits  /4 => [0-13] bits  /8 => 11 bit resolution
  ACC_ORIENTATION(  - ((rawADC[1]<<8) | rawADC[0])/32 ,
                    - ((rawADC[3]<<8) | rawADC[2])/32 ,
                      ((rawADC[5]<<8) | rawADC[4])/32 );
  ACC_Common();
}
#endif

// ************************************************************************************************************
// contribution from Point65 and mgros (rc-groups)
// contribution from ziss_dm (June 2011)
// contribution from ToLuSe (Jully 2011)
// I2C Accelerometer BMA020
// ************************************************************************************************************
// I2C adress: 0x70 (8bit)
// Resolution: 10bit
// Control registers:
//
// Datasheet: After power on reset or soft reset it is recommended to set the SPI4-bit to the correct value.
//            0x80 = SPI four-wire = Default setting
// | 0x15: | SPI4 | enable_adv_INT | new_data_INT | latch_INT | shadow_dis | wake_up_pause<1:0> | wake_up |
// |       |    1 |              0 |            0 |         0 |          0 |                 00 |       0 |
//
// | 0x14: |                       reserved <2:0> |            range <1:0> |               bandwith <2:0> |
// |       |                      !!Calibration!! |                     2g |                         25Hz |
//
// ************************************************************************************************************
#if defined(BMA020)
void ACC_init(){
  i2c_writeReg(0x70,0x15,0x80);
  uint8_t control = i2c_readReg(0x70, 0x14);
  control = control & 0xE0;
  control = control | (0x00 << 3); //Range 2G 00
  control = control | 0x00;        //Bandwidth 25 Hz 000
  i2c_writeReg(0x70,0x14,control);
  acc_1G = 255;
}

void ACC_getADC(){
  TWBR = ((16000000L / 400000L) - 16) / 2;
  i2c_getSixRawADC(0x70,0x02);
  ACC_ORIENTATION(    ((rawADC[1]<<8) | rawADC[0])/64 ,
                      ((rawADC[3]<<8) | rawADC[2])/64 ,
                      ((rawADC[5]<<8) | rawADC[4])/64 );
  ACC_Common();
}
#endif

// ************************************************************************************************************
// standalone I2C Nunchuk
// ************************************************************************************************************
#if defined(NUNCHACK)
void ACC_init() {
  i2c_writeReg(0xA4 ,0xF0 ,0x55 );
  i2c_writeReg(0xA4 ,0xFB ,0x00 );
  delay(250);
  acc_1G = 200;
}

void ACC_getADC() {
  TWBR = ((16000000L / I2C_SPEED) - 16) / 2; // change the I2C clock rate. !! you must check if the nunchuk is ok with this freq
  i2c_getSixRawADC(0xA4,0x00);

  ACC_ORIENTATION(  ( (rawADC[3]<<2)        + ((rawADC[5]>>4)&0x2) ) ,
                  - ( (rawADC[2]<<2)        + ((rawADC[5]>>3)&0x2) ) ,
                    ( ((rawADC[4]&0xFE)<<2) + ((rawADC[5]>>5)&0x6) ));
  ACC_Common();
}
#endif

// ************************************************************************
// LIS3LV02 I2C Accelerometer
//contribution from adver (http://multiwii.com/forum/viewtopic.php?f=8&t=451)
// ************************************************************************
#if defined(LIS3LV02)
#define LIS3A  0x3A // I2C adress: 0x3A (8bit)

void i2c_ACC_init(){
  i2c_writeReg(LIS3A ,0x20 ,0xD7 ); // CTRL_REG1   1101 0111 Pwr on, 160Hz
  i2c_writeReg(LIS3A ,0x21 ,0x50 ); // CTRL_REG2   0100 0000 Littl endian, 12 Bit, Boot
  acc_1G = 256;
}

void i2c_ACC_getADC(){
  TWBR = ((16000000L / 400000L) - 16) / 2; // change the I2C clock rate to 400kHz
  i2c_getSixRawADC(LIS3A,0x28+0x80);
  ACC_ORIENTATION(  (rawADC[3]<<8 | rawADC[2])/4 ,
                   -(rawADC[1]<<8 | rawADC[0])/4 ,
                   -(rawADC[5]<<8 | rawADC[4])/4);
  ACC_Common();
}
#endif

// ************************************************************************************************************
// I2C Accelerometer LSM303DLx
// contribution from wektorx (http://www.multiwii.com/forum/viewtopic.php?f=8&t=863)
// ************************************************************************************************************
#if defined(LSM303DLx_ACC)
void ACC_init () {
  delay(10);
  i2c_writeReg(0x30,0x20,0x27);
  i2c_writeReg(0x30,0x23,0x30);
  i2c_writeReg(0x30,0x21,0x00);

  acc_1G = 256;
}

  void ACC_getADC () {
  TWBR = ((16000000L / 400000L) - 16) / 2;
  i2c_getSixRawADC(0x30,0xA8);

  ACC_ORIENTATION( - ((rawADC[3]<<8) | rawADC[2])/16 ,
                     ((rawADC[1]<<8) | rawADC[0])/16 ,
                     ((rawADC[5]<<8) | rawADC[4])/16 );
  ACC_Common();
}
#endif

// ************************************************************************************************************
// ADC ACC
// ************************************************************************************************************
#if defined(ADCACC)
void ACC_init(){
  pinMode(A1,INPUT);
  pinMode(A2,INPUT);
  pinMode(A3,INPUT);
  acc_1G = 75;
}

void ACC_getADC() {
  ACC_ORIENTATION( -analogRead(A1) ,
                   -analogRead(A2) ,
                    analogRead(A3) );
  ACC_Common();
}
#endif

// ************************************************************************************************************
// contribution from Ciskje
// I2C Gyroscope L3G4200D
// ************************************************************************************************************
#if defined(L3G4200D)
void Gyro_init() {
  delay(100);
  i2c_writeReg(0XD2+0 ,0x20 ,0x8F ); // CTRL_REG1   400Hz ODR, 20hz filter, run!
  delay(5);
  i2c_writeReg(0XD2+0 ,0x24 ,0x02 ); // CTRL_REG5   low pass filter enable
}

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])/20  ,
                     ((rawADC[3]<<8) | rawADC[2])/20  ,
                    -((rawADC[5]<<8) | rawADC[4])/20  );
  GYRO_Common();
}
#endif

// ************************************************************************************************************
// I2C Gyroscope ITG3200
// ************************************************************************************************************
// I2C adress: 0xD2 (8bit)   0x69 (7bit)
// I2C adress: 0xD0 (8bit)   0x68 (7bit)
// principle:
// 1) VIO is connected to VDD
// 2) I2C adress is set to 0x69 (AD0 PIN connected to VDD)
// or 2) I2C adress is set to 0x68 (AD0 PIN connected to GND)
// 3) sample rate = 1000Hz ( 1kHz/(div+1) )
// ************************************************************************************************************
#if defined(ITG3200)
void Gyro_init() {
  delay(100);
  i2c_writeReg(ITG3200_ADDRESS, 0x3E, 0x80); //register: Power Management  --  value: reset device
//  delay(5);
//  i2c_writeReg(ITG3200_ADDRESS, 0x15, ITG3200_SMPLRT_DIV); //register: Sample Rate Divider  -- default value = 0: OK
  delay(5);
  i2c_writeReg(ITG3200_ADDRESS, 0x16, 0x18 + ITG3200_DLPF_CFG); //register: DLPF_CFG - low pass filter configuration
  delay(5);
  i2c_writeReg(ITG3200_ADDRESS, 0x3E, 0x03); //register: Power Management  --  value: PLL with Z Gyro reference
  delay(100);
}

void Gyro_getADC () {
  TWBR = ((16000000L / 400000L) - 16) / 2; // change the I2C clock rate to 400kHz
  i2c_getSixRawADC(ITG3200_ADDRESS,0X1D);
  GYRO_ORIENTATION(  + ( ((rawADC[2]<<8) | rawADC[3])/4) , // range: +/- 8192; +/- 2000 deg/sec
                     - ( ((rawADC[0]<<8) | rawADC[1])/4 ) ,
                     - ( ((rawADC[4]<<8) | rawADC[5])/4 ) );
  GYRO_Common();
}
#endif



// ************************************************************************************************************
// I2C Compass common function
// ************************************************************************************************************
#if MAG
void Mag_getADC() {
  static uint32_t t,tCal = 0;
  static int16_t magZeroTempMin[3];
  static int16_t magZeroTempMax[3];
  uint8_t axis;
  if ( currentTime < t ) return; //each read is spaced by 100ms
  t = currentTime + 100000;
  TWBR = ((16000000L / 400000L) - 16) / 2; // change the I2C clock rate to 400kHz
  Device_Mag_getADC();
  if (calibratingM == 1) {
    tCal = t;
    for(axis=0;axis<3;axis++) {magZero[axis] = 0;magZeroTempMin[axis] = 0; magZeroTempMax[axis] = 0;}
    calibratingM = 0;
  }
  magADC[ROLL]  -= magZero[ROLL];
  magADC[PITCH] -= magZero[PITCH];
  magADC[YAW]   -= magZero[YAW];
  if (tCal != 0) {
    if ((t - tCal) < 30000000) { // 30s: you have 30s to turn the multi in all directions
      LEDPIN_TOGGLE;
      for(axis=0;axis<3;axis++) {
        if (magADC[axis] < magZeroTempMin[axis]) magZeroTempMin[axis] = magADC[axis];
        if (magADC[axis] > magZeroTempMax[axis]) magZeroTempMax[axis] = magADC[axis];
      }
    } else {
      tCal = 0;
      for(axis=0;axis<3;axis++)
        magZero[axis] = (magZeroTempMin[axis] + magZeroTempMax[axis])/2;
      writeParams();
    }
  }
}
#endif

// ************************************************************************************************************
// I2C Compass HMC5843 & HMC5883
// ************************************************************************************************************
// I2C adress: 0x3C (8bit)   0x1E (7bit)
// ************************************************************************************************************
#if defined(HMC5843) || defined(HMC5883)
void Mag_init() {
  delay(100);
  i2c_writeReg(0X3C ,0x02 ,0x00 ); //register: Mode register  --  value: Continuous-Conversion Mode
}

void Device_Mag_getADC() {
  i2c_getSixRawADC(0X3C,0X03);
  #if defined(HMC5843)
    MAG_ORIENTATION( ((rawADC[0]<<8) | rawADC[1]) ,
                     ((rawADC[2]<<8) | rawADC[3]) ,
                    -((rawADC[4]<<8) | rawADC[5]) );
  #endif
  #if defined (HMC5883)
    MAG_ORIENTATION( ((rawADC[4]<<8) | rawADC[5]) ,
                    -((rawADC[0]<<8) | rawADC[1]) ,
                    -((rawADC[2]<<8) | rawADC[3]) );
  #endif
}
#endif

// ************************************************************************************************************
// I2C Compass AK8975 (Contribution by EOSBandi)
// ************************************************************************************************************
// I2C adress: 0x18 (8bit)   0x0C (7bit)
// ************************************************************************************************************
#if defined(AK8975)
void Mag_init() {
  delay(100);
  i2c_writeReg(0x18,0x0a,0x01);  //Start the first conversion
  delay(100);
}

void Device_Mag_getADC() {
  i2c_getSixRawADC(0x18,0x03);
  MAG_ORIENTATION( ((rawADC[3]<<8) | rawADC[2]) ,         
                   ((rawADC[1]<<8) | rawADC[0]) ,     
                  -((rawADC[5]<<8) | rawADC[4]) );
  //Start another meassurement
  i2c_writeReg(0x18,0x0a,0x01);
}
#endif

#if !GYRO
// ************************************************************************************************************
// I2C Wii Motion Plus + optional Nunchuk
// ************************************************************************************************************
// I2C adress 1: 0xA6 (8bit)    0x53 (7bit)
// I2C adress 2: 0xA4 (8bit)    0x52 (7bit)
// ************************************************************************************************************
void WMP_init() {
  delay(250);
  i2c_writeReg(0xA6, 0xF0, 0x55); // Initialize Extension
  delay(250);
  i2c_writeReg(0xA6, 0xFE, 0x05); // Activate Nunchuck pass-through mode
  delay(250);

  // We need to set acc_1G for the Nunchuk beforehand; It's used in WMP_getRawADC() and ACC_Common()
  // If a different accelerometer is used, it will be overwritten by its ACC_init() later.
  acc_1G = 200;
  acc_25deg = acc_1G * 0.423;
  uint8_t numberAccRead = 0;
  // Read from WMP 100 times, this should return alternating WMP and Nunchuk data
  for(uint8_t i=0;i<100;i++) {
    delay(4);
    if (WMP_getRawADC() == 0) numberAccRead++; // Count number of times we read from the Nunchuk extension
  }
  // If we got at least 25 Nunchuck reads, we assume the Nunchuk is present
  if (numberAccRead>25)
    nunchuk = 1;
  delay(10);
}

uint8_t WMP_getRawADC() {
  uint8_t axis;
  TWBR = ((16000000L / I2C_SPEED) - 16) / 2; // change the I2C clock rate
  i2c_getSixRawADC(0xA4,0x00);

  if (micros() < (neutralizeTime + NEUTRALIZE_DELAY)) {//we neutralize data in case of blocking+hard reset state
    for (axis = 0; axis < 3; axis++) {gyroADC[axis]=0;accADC[axis]=0;}
    accADC[YAW] = acc_1G;
    return 1;
  }

  // Wii Motion Plus Data
  if ( (rawADC[5]&0x03) == 0x02 ) {
    // Assemble 14bit data
    gyroADC[ROLL]  = - ( ((rawADC[5]>>2)<<8) | rawADC[2] ); //range: +/- 8192
    gyroADC[PITCH] = - ( ((rawADC[4]>>2)<<8) | rawADC[1] );
    gyroADC[YAW]  =  - ( ((rawADC[3]>>2)<<8) | rawADC[0] );
    GYRO_Common();
    // Check if slow bit is set and normalize to fast mode range
    gyroADC[ROLL]  = (rawADC[3]&0x01)     ? gyroADC[ROLL]/5  : gyroADC[ROLL];  //the ratio 1/5 is not exactly the IDG600 or ISZ650 specification
    gyroADC[PITCH] = (rawADC[4]&0x02)>>1  ? gyroADC[PITCH]/5 : gyroADC[PITCH]; //we detect here the slow of fast mode WMP gyros values (see wiibrew for more details)
    gyroADC[YAW]   = (rawADC[3]&0x02)>>1  ? gyroADC[YAW]/5   : gyroADC[YAW];   // this step must be done after zero compensation   
    return 1;
  } else if ( (rawADC[5]&0x03) == 0x00 ) { // Nunchuk Data
    ACC_ORIENTATION(  ( (rawADC[3]<<2)      | ((rawADC[5]>>4)&0x02) ) ,
                    - ( (rawADC[2]<<2)      | ((rawADC[5]>>3)&0x02) ) ,
                      ( ((rawADC[4]>>1)<<3) | ((rawADC[5]>>5)&0x06) ) );
    ACC_Common();
    return 0;
  } else
    return 2;
}
#endif

void initSensors() {
  delay(200);
  POWERPIN_ON
  delay(100);
  i2c_init();
  delay(100);
  if (GYRO) Gyro_init();
  else WMP_init();
  if (BARO) Baro_init();
  if (ACC) {ACC_init();acc_25deg = acc_1G * 0.423;}
  if (MAG) Mag_init();
}

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

Re: MultiWii 1.9

Post by mr.rc-cam »

While I was searching the thread for some clue about what you mean by ST1 and 2, I found Alex's code (below) and figured I'd give it a shot... Went' from 50,000 errors in 30 seconds to 0 in 10 minutes, according to debug2 on the GUI @ version 1.9!

If you fixed this without any hardware changes then it sounds suspicious. There is a chance you don't have his debug variable's name assigned to debug2 (serial.pde). Also, that patch's I2C error counter is disabled by default and requires intervention to turn it on. The latest V1.9 download has all this stuff already setup for you and is ready to use.

So instead using that patch in your V1.9, I highly recommend that you start with a fresh new V1.9 download (which has this patch correctly configured for reporting the I2C problems). This will ensure that you can see any I2C error counts in the GUI. In other words, if the latest V1.9 release has 0 in the GUI's debug2 window (remains zero for several minutes), and your sensors are all working, then go out and fly it! I hope I am wrong, but my gut feeling is that you will see errors until you work on the hardware.

BTW, ST1 and ST2 are solder pads on the BMA020 board. You can see them here (lower left corner):
download/file.php?id=536&mode=view

Noctaro
Posts: 280
Joined: Thu Sep 08, 2011 11:15 am
Contact:

Re: MultiWii 1.9

Post by Noctaro »

Hi again,
today i did some further testflights, with a new frame i constructed. It is much more precise then my last one. Acro need nearly no trim. But i had some strange behaviour.
Both level and acro mode work great as long as my 4000mah akku has enough power. But if voltage drops, i start to drift as ever, after around 12 minutes of flight. I could capture a good scene where we can definatly see it starting to drift. I hope i am able to upload it soon. Btw. at one of my flights, i think i had an gyro drift at low power, because it seems even acro mode started to drift. I ll keep on testing these days, to give a better review.

greetz noc

spagoziak
Posts: 171
Joined: Thu Jan 20, 2011 1:18 am

Re: MultiWii 1.9

Post by spagoziak »

mr.rc-cam wrote:
While I was searching the thread for some clue about what you mean by ST1 and 2, I found Alex's code (below) and figured I'd give it a shot... Went' from 50,000 errors in 30 seconds to 0 in 10 minutes, according to debug2 on the GUI @ version 1.9!

If you fixed this without any hardware changes then it sounds suspicious. There is a chance you don't have his debug variable's name assigned to debug2 (serial.pde). Also, that patch's I2C error counter is disabled by default and requires intervention to turn it on. The latest V1.9 download has all this stuff already setup for you and is ready to use.

So instead using that patch in your V1.9, I highly recommend that you start with a fresh new V1.9 download (which has this patch correctly configured for reporting the I2C problems). This will ensure that you can see any I2C error counts in the GUI. In other words, if the latest V1.9 release has 0 in the GUI's debug2 window (remains zero for several minutes), and your sensors are all working, then go out and fly it! I hope I am wrong, but my gut feeling is that you will see errors until you work on the hardware.

BTW, ST1 and ST2 are solder pads on the BMA020 board. You can see them here (lower left corner):
download/file.php?id=536&mode=view


I'm suspicious too, but the darn thing just flew around in the yard for a few minutes (before I realized I was flying on a nearly empty battery without my lipo alarm plugged in). I did make a hardware change though...I commented out and unplugged the BMP025. I have a feeling this fellow may have been the culprit, because it's the one thing I hadn't done yet.

Here's a pic of me harassing the gyro lines.. you can see debug2 is still 0 after 5 ish minutes as well.
proof i2c is alive and well.JPG


Here's what's different:
[list=]
[*]I downloaded 1.9 fresh from the repository.
[*]I replaced the included sensors.pde with the one Alex posted here
[*]I //commented out and disconnected my BMP025...
[/list]

Now for some PID tuning... glad to finally have 1.9 on board :)

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

Re: MultiWii 1.9

Post by mr.rc-cam »

Here's what's different:
[*]I downloaded 1.9 fresh from the repository.
[*]I replaced the included sensors.pde with the one Alex posted here
[*]I //commented out and disconnected my BMP025...

If you "updated" the latest V1.9 code with that particular patch from Alex then you will NOT see the I2C errors. Because the I2C error counter is disabled in that patch, debug2 will remain 0 and will not help you identify I2C problems.

However, the latest V1.9 code will show the I2C errors *and* it has Alex's I2C improvements from that earlier patch. So I recommend you use the latest code as-is and observe the GUI's debug2 so that you can be assured you don't have any I2C issues. If you find it shows errors then we can work together and fix it.

So, before you do anything, get the latest V1.9 loaded. Configure it for your sensors, but otherwise use it as-is (no patches!). Then report what debug2 says and we will go from there.

spagoziak
Posts: 171
Joined: Thu Jan 20, 2011 1:18 am

Re: MultiWii 1.9

Post by spagoziak »

mr.rc-cam wrote:
Here's what's different:
[*]I downloaded 1.9 fresh from the repository.
[*]I replaced the included sensors.pde with the one Alex posted here
[*]I //commented out and disconnected my BMP025...

If you "updated" the latest V1.9 code with that particular patch from Alex then you will NOT see the I2C errors. Because the I2C error counter is disabled in that patch, debug2 will remain 0 and will not help you identify I2C problems.

However, the latest V1.9 code will show the I2C errors *and* it has Alex's I2C improvements from that earlier patch. So I recommend you use the latest code as-is and observe the GUI's debug2 so that you can be assured you don't have any I2C issues. If you find it shows errors then we can work together and fix it.

So, before you do anything, get the latest V1.9 loaded. Configure it for your sensors, but otherwise use it as-is (no patches!). Then report what debug2 says and we will go from there.


Alrighty! I downloaded another fresh copy, reversed acc roll, gyro pitch (stuff I've been doing since forever), disabled internal pullups, enabled motor_stop, moved midrc to 1505, changed mincommand to 950, enabled servo tilt for the camera stabilization gimbal and uploaded it.

After a just-in-case hand test, I lifted it off in the living room, only 8x8 feet of room. Solid as a stone :)

While I was bench testing the code, I noticed something interesting: tilting the mwc past 90 degrees stopped the gyro from working. The graph wouldn't update changes and the I2C error count in debug2 roared to life, counting as fast as it could. Once I returned the mwc to an attitude of less than 90 degrees to level, everything resumed as normal.

Here's a video showing what I'm trying to describe.

Odd, or intentional?

spag

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

Re: MultiWii 1.9

Post by mr.rc-cam »

After a just-in-case hand test, I lifted it off in the living room, only 8x8 feet of room. Solid as a stone

That is excellent.

While I was bench testing the code, I noticed something interesting: tilting the mwc past 90 degrees stopped the gyro from working. The graph wouldn't update changes and the I2C error count in debug2 roared to life, counting as fast as it could. Once I returned the mwc to an attitude of less than 90 degrees to level, everything resumed as normal.

The I2C errors are a problem that needs to be fixed. I would start the troubleshooting by gently tugging, pulling, and tapping all the electrical parts and wires (while you watched the debug2 data). Hopefully you learn something from that exercise.

User avatar
UndCon
Posts: 293
Joined: Mon Feb 21, 2011 2:10 pm

Re: MultiWii 1.9

Post by UndCon »

How many times have 1.9 been fixed and reuploaded without any obvious changes to the naked eye?

I have 1.9 on all my Arduinos (5 in total) but I have no clue at all WHICH version of 1.9 they are running...

I suggest start naming them accordingly

1.9 (release)
1.9.1 (bug fixes)
1.9.2 (bug fixes)
2.0 (release)
Last edited by UndCon on Wed Nov 23, 2011 8:54 am, edited 1 time in total.

spagoziak
Posts: 171
Joined: Thu Jan 20, 2011 1:18 am

Re: MultiWii 1.9

Post by spagoziak »

UndCon wrote:How many times have 1.9 been fixed and reuploaded without any obvious changes to the naked eye?

I have 1.9 on all my Arduinos (5 in total) but I have no clue at all WHICH version of 1.9 they are running...

I suggest start naming them accordingly

1.9 (release)
1.9.1 (bug fixes)
1.9.2 (bugfixes)
2.0 (release)


The way software at my employer is versioned goes like this:
major.minor.patch.customer-specific.firmware

This sort of numbering would work well for MWC, too I think. 1.9.3.remzibi.mega or 1.8.2.fixedwing, for example.

It's really easy for us to keep track of what we're dealing with when handling support issues :)

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: MultiWii 1.9

Post by shikra »

+1 - keep it simple...

UndCon wrote:How many times have 1.9 been fixed and reuploaded without any obvious changes to the naked eye?

I have 1.9 on all my Arduinos (5 in total) but I have no clue at all WHICH version of 1.9 they are running...

I suggest start naming them accordingly

1.9 (release)
1.9.1 (bug fixes)
1.9.2 (bug fixes)
2.0 (release)

KaiK
Posts: 58
Joined: Thu Jul 28, 2011 8:32 pm
Contact:

Re: MultiWii 1.9

Post by KaiK »

Yeah +1

User avatar
Th0rsten
Posts: 65
Joined: Mon Oct 31, 2011 10:28 am

Re: MultiWii 1.9

Post by Th0rsten »

+1

mon_lolo_fr
Posts: 40
Joined: Tue Nov 15, 2011 9:50 am

Re: MultiWii 1.9

Post by mon_lolo_fr »

mr.rc-cam wrote:The I2C errors are a problem that needs to be fixed. I would start the troubleshooting by gently tugging, pulling, and tapping all the electrical parts and wires (while you watched the debug2 data). Hopefully you learn something from that exercise.


I agree with that, it'll be a good exercise to find out what's going on. I'm thinking of a wire or an electrical part that can come next to a component/cable and that'll make an electrical contact between some pins or something like that.

spagoziak
Posts: 171
Joined: Thu Jan 20, 2011 1:18 am

Re: MultiWii 1.9

Post by spagoziak »

mr.rc-cam wrote:
After a just-in-case hand test, I lifted it off in the living room, only 8x8 feet of room. Solid as a stone

That is excellent.

While I was bench testing the code, I noticed something interesting: tilting the mwc past 90 degrees stopped the gyro from working. The graph wouldn't update changes and the I2C error count in debug2 roared to life, counting as fast as it could. Once I returned the mwc to an attitude of less than 90 degrees to level, everything resumed as normal.

The I2C errors are a problem that needs to be fixed. I would start the troubleshooting by gently tugging, pulling, and tapping all the electrical parts and wires (while you watched the debug2 data). Hopefully you learn something from that exercise.


The problem is related to the BMA020! I uncommented it and unplugged it, and the MWC reads gyro data no matter what attitude it's at.

Could this be related to the trusted Z axis definition? I tried it with that define enabled and not, both returned the same result, except that when enabled,the copter graphic flipped upright again when I was 100% inverted. And the attitude graphics pertaining to level were much slower and much less accurate (while holding in hand). There was visible drift while holding the MWC at an angle.

So maybe it's how I have my BMA020 wired?
Mine is wired as described in berkley's blog.
bma020.JPG
(18.33 KiB) Not downloaded yet


spag

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

Re: MultiWii 1.9

Post by mr.rc-cam »

The problem is related to the BMA020! I uncommented it and unplugged it, and the MWC reads gyro data no matter what attitude it's at.

I am surprised that the tugging, pulling, and tapping tests did not show any problems with the BMA020 board since this sounds like a "mechanical" issue. If a close visual inspection of the BMA020 and all related wiring does not disclose any problems then your BMA020 may need replacement.

Could this be related to the trusted Z axis definition?

Doubtful since Debug2's I2C error counter involves the I2C communication at a primitive hardware level. But if you can find another BMA020 user that reports I2C errors when the model is at a steep attitude then that would be helpful.

So maybe it's how I have my BMA020 wired? Mine is wired as described in berkley's blog.

From what I saw, the only BMA wiring schematic there is for an ATMEGA1280 installation. If your setup isn't exactly as shown on that schematic then please post an accurate drawing.

Use your voltmeter and confirm 5.0V at the power inputs of the WMP and BMA020. I recommend with V1.9 to power the two sensors direct from the 5V supply rather than from the POWERPIN on the Arduino. This will provide ideal voltage to the 5V powered sensors and will free up a CPU I/O pin for future use.

BTW, what are you using for pullup resistors? If you are using the Arduino's internal pullups then disable them and use external 2.2K ohm pullups. If doing this does not help, and you are sure the BMA020 wires/connections/soldering is perfect, then I think that sensor replacement is next on the list.

- Thomas

KeesvR
Posts: 194
Joined: Fri May 27, 2011 6:51 pm
Location: The Netherlands

Re: MultiWii 1.9

Post by KeesvR »

I've done the 90 degrees rotation test and the I2C debug value stays at 0.
So I think thomas is right about your BMA020.

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

Re: MultiWii 1.9

Post by jevermeister »

KeesvR wrote:I've done the 90 degrees rotation test and the I2C debug value stays at 0.
So I think thomas is right about your BMA020.


Same here! No problems tilting past 90°.
Gyros are still submitting date and no debug counter running skywards.

Sorry Mate!

kataventos
Posts: 702
Joined: Sun Aug 28, 2011 8:14 pm
Contact:

Re: MultiWii 1.9

Post by kataventos »

Hi Alex,

in the dev before 1.9 release I posted a video with my quad where I mencioned that the accumulative drift was forever gone! In the day after when I mounted my FPV equipment (total flight weight 1,455kg) the drift came back, from then to today I tried to find (in silence) :) the reason to that and how to solve it. After reading many post´s I made some simple changes that finaly stoped the drift and other problems relative to ACC (NK).

In the IMU

Code: Select all

#define ACC_LPF_FACTOR 64

Code: Select all

#define GYR_CMPF_FACTOR 350.0f

Code: Select all

accTemp[axis] = (accTemp[axis] - (accTemp[axis] >>6)) + accADC[axis];
      accSmooth[axis] = accTemp[axis]>>6;


In the code

Code: Select all

// 50 degrees max inclination
      errorAngle = constrain(2*rcCommand[axis],-250,+250) - angle[axis] + accTrim[axis]; //16 bits is ok here


Please tell me if this changes I made, make sence! one thing I´m sure, just calibrate GYROS and ACC once and I have now something like 15 flight´s in two diferent days, everything is like in the first one... Perfect! :) The most significant diference is that the stable is lazy (normal thing because of the delay in the output of the filter, that occurs when increasing the value on LPF) but realy stable, I just fly in stable when I want to be precise on the object that I´m filming, the sticks get to soft (in stable mode) with this changes but that´s good to! so at this time I´m ready to add a baro and the most important, an OSD with AH.

Cheers,
Henrique

Lapino
Posts: 84
Joined: Tue Aug 16, 2011 10:01 am

Re: MultiWii 1.9

Post by Lapino »

jevermeister wrote:
KeesvR wrote:I've done the 90 degrees rotation test and the I2C debug value stays at 0.
So I think thomas is right about your BMA020.


Same here! No problems tilting past 90°.
Gyros are still submitting date and no debug counter running skywards.

Sorry Mate!


+1 no debug errors after tilting 90°s and gyro working after this

Tri with original wmp, bma020, no specific board, internal pullups enabled

spagoziak
Posts: 171
Joined: Thu Jan 20, 2011 1:18 am

Re: MultiWii 1.9

Post by spagoziak »

Great to have so many folks verify this! That really narrows it down to my BMA. I actually have another one on a friend's controller... I'll push my 1.9 config there and see if I get a different result.

mahowik
Posts: 332
Joined: Sun Apr 10, 2011 6:26 pm

Re: MultiWii 1.9

Post by mahowik »

kataventos wrote:Please tell me if this changes I made, make sence!


As I'm also Alex and I have posted that changes. So I will reply to you :)
You increased the LPF factor and increased the GYRO value for complimentary filter... And yes, these changes helps to reduce the drift but not resolve this issues at all unfortunately...

As for FPV you can apply one more patch from Shikra. It helps to lock the force (particularly the speed of rotation) in Level mode. I tried this and my quadX was more smooth in flight:

Code: Select all

PTerm =constrain((int32_t)errorAngle,-P8[PIDLEVEL],+P8[PIDLEVEL]);


viewtopic.php?f=7&t=905

thx-
Alex

mahowik
Posts: 332
Joined: Sun Apr 10, 2011 6:26 pm

Re: MultiWii 1.9

Post by mahowik »

@to all: Also I'm just wanna to promote new mode if not all aware about this. :)
It's already initially tested by some guys and have a good feedbacks.

viewtopic.php?f=7&t=925

russian version: http://forum.rcdesign.ru/f123/thread221 ... ost2970794

kataventos
Posts: 702
Joined: Sun Aug 28, 2011 8:14 pm
Contact:

Re: MultiWii 1.9

Post by kataventos »

mahowik wrote:
kataventos wrote:Please tell me if this changes I made, make sence!


As I'm also Alex and I have posted that changes. So I will reply to you :)
You increased the LPF factor and increased the GYRO value for complimentary filter... And yes, these changes helps to reduce the drift but not resolve this issues at all unfortunately...


Hi Alex Mahowik :),

thanks for you reply, Alex "the first" :lol: have already reply me because I sent him a PM, I can ensure you that my drift and other problem´s with ACC are gone. I thought that they were gone flying without my FPV gear, but when I tryed the stable mode with 1.455kg it came back, then I realise that the weight made force a litle bit my motors and consequently the vibes from the motors. Then I made this changes and GUI show much better values with my motors full throttle (never tried before a bench full throttle), so at this time it is perfect with no drift at all, as I said before in my last post, after the changes I calibrate GYRO and ACC 1 time until today and I have now more then 20 flight´s with no problem, everything is perfect. My doubt was if the changes could afect something else and if I could use them in future releases, (note that I´m no coder at all just a pilot playing with fire, because the stuff you all make is unbelievable!) Alex told me that no problem at all!So at this time my only main worry is with the GPS on a Promini!

Cheers,
Henrique

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

Re: MultiWii 1.9

Post by Alexinparis »

mahowik wrote:@to all: Also I'm just wanna to promote new mode if not all aware about this. :)
It's already initially tested by some guys and have a good feedbacks.

viewtopic.php?f=7&t=925

russian version: http://forum.rcdesign.ru/f123/thread221 ... ost2970794


Hi,
I've just included it in the last dev ;)
I named this mode HEAD FREE (more versatile than beginner mode)
+ ability to use AUX3 AUX4 like AUX1 and AUX2

mahowik
Posts: 332
Joined: Sun Apr 10, 2011 6:26 pm

Re: MultiWii 1.9

Post by mahowik »

Alexinparis wrote:I've just included it in the last dev ;)

Cool!!! :)

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

Re: MultiWii 1.9

Post by jevermeister »

Alexinparis wrote:ability to use AUX3 AUX4 like AUX1 and AUX2



Wellw ell well,
seems I do have to get a turnigy 9x after all :-/.

;-) hmmmm

Can someone please press on my Donate Button n ncopters.blogspot.com ;-)

User avatar
SoundMTB
Posts: 37
Joined: Tue Jul 26, 2011 8:17 am
Location: Germany Osnabrueck
Contact:

Re: MultiWii 1.9

Post by SoundMTB »

Hi

Can someone tell me witch Version of 1.9 is working, I found many files at http://code.google.com/p/multiwii/source/browse/#svn%2Ftrunk%2FMultiWii_shared

Witch Version I have to use to get my QuadX working?

Oliver

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

Re: MultiWii 1.9

Post by mr.rc-cam »

SoundMTB wrote:Can someone tell me witch Version of 1.9 is working, I found many files at http://code.google.com/p/multiwii/source/browse/#svn%2Ftrunk%2FMultiWii_shared


V1.9 is here: http://code.google.com/p/multiwii/downloads/list

- Thomas

kiliam
Posts: 14
Joined: Mon Feb 14, 2011 11:06 pm

Re: MultiWii 1.9

Post by kiliam »

Hello guys.
I am finishing rebuildin my quadx. i just received a bma020 and connected it to my wmp, but i read the problems at first with this combination of sensors and i added external pullups of 2.2k to the wmp, like this:
Image

After soldering just the pullups and the wmp i tested it without the bma020 and the problem appeared then, the gui is extremely slow, i had loading problems with the gui beause i have very com ports and it would just take longer to load but then worked fine but this time its is always slow, in minutes the lines in the graph dont even get to the end of the graph.

I use this max232 to connect to the pc with a usb to rs232, but i use this many times without problems:

Image

I then thought it could be just the bma020 missing and i soldered it to the wmp but still the problem continues.
I will try to make a movie of it. And then test without the pullups probably. Oh, in the code i tested with pullups enabled and disabled and same thing...
Dont have much to do, waiting for props to test Alex new 1.9 firmware and Simonk new firmware in my hobbyking supersimple 25/30A escs, and the bma020.



My bad :oops: ... I unsoldered the pullups ando the same... Then i remembered to restart the pc... After it it works fine. But i made a movie before i will post the link later, the problem is i restart this pc few times a year...
Just have to wait for props now to test v1.9 :mrgreen: ...

Thank you very much Alex

kiliam
Posts: 14
Joined: Mon Feb 14, 2011 11:06 pm

Re: MultiWii 1.9

Post by kiliam »

Here i am again...
I am still bench testing my new bma020 and 1.9. With v1.9 i have oscillations from acc that disappear with v1.9 but with 1.7 acc code, and the problem i have is when i arm the quad the acc reading goes nuts and in the graph the acc blue line drops. I have wmp and bma020 connected to 5v directly and not by pin d12 and 2.2k pullup resistors in i2c. Better to see the movie please:

http://www.youtube.com/watch?v=_7aEPRu1_yE

Thanks you for any help.

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

Re: MultiWii 1.9

Post by mr.rc-cam »

the problem i have is when i arm the quad the acc reading goes nuts and in the graph the acc blue line drops.

Your GUI noise looks normal to me considering your test methods. I see the quad sitting on a glass table top with motors running. This is not a valid way to test since the vibrations from the hard surface will be detected by the sensor.

BTW, I'm not a big fan of using the heavy wires to connect the sensors. And they look like solid (not stranded) wires. Their stiffness and mass will couple vibrations to the sensor board. I recommend smaller gauge wires that are stranded. Light weight wires and soft mounted sensors will reduce sensor vibrations. So if you feel you are having performance problems due to vibration then the sensor's "mechanical" installation will require more attention.

What flight performance problem are you trying to solve?

kiliam
Posts: 14
Joined: Mon Feb 14, 2011 11:06 pm

Re: MultiWii 1.9

Post by kiliam »

I just connected the bma020 but i dont think it is normal that the acc line would drop so much just by powering the motors.
These are stranded wires but i made them short, i will try to find some more light.

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: MultiWii 1.9

Post by shikra »

Is anyone using LCD screen on 1.9 ?

I thought it always used to run at 9600 for LCD, but mine is not working on 1.9 Seems to think its 115k

Or could just be it doesn't like the cold weather this week. Like me...

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

Re: MultiWii 1.9

Post by mr.rc-cam »

Is anyone using LCD screen on 1.9 ?
I thought it always used to run at 9600 for LCD, but mine is not working on 1.9 Seems to think its 115k


I'm not using a LCD, but a quick glance at the V1.9 code revealed that it defaults to 115.2K baud. Easy to change though (#define SERIAL_COM_SPEED, config.h).

oddcopter
Posts: 4
Joined: Tue Dec 06, 2011 6:37 am

Re: MultiWii 1.9

Post by oddcopter »

Hi,
I've just included it in the last dev
I named this mode HEAD FREE (more versatile than beginner mode)
+ ability to use AUX3 AUX4 like AUX1 and AUX2Alexinparis

Posts: 487
Joined: Wed Jan 19, 2011 3:07 pm
Private message


Alex,

jevermeister mentioned having to order a 9ch Turnigy. Does the HEAD FREE mode require more than a 6 channel TX/RX?

As a beginner (waiting on my board) I am very interested in this mode, but only have a 6ch TX/RX.

Thanks for all of your and others work on this project. It is amazing! Sorry if this is the wrong place to ask this question.

Thanks,
Britt

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: MultiWii 1.9

Post by shikra »

Thanks!
I thoughty GUI is at SERIAL_COM_SPEED, but the LCD should be softserial @9600. And it looks like that at first glance to me

Or maybe I am thinking back to early dev code.

mmmm strange as my LCD is set to 9600 and doesn't support 115k and GUI is set at 115k. It always worked...

Now to find out why!

mr.rc-cam wrote:
Is anyone using LCD screen on 1.9 ?
I thought it always used to run at 9600 for LCD, but mine is not working on 1.9 Seems to think its 115k


I'm not using a LCD, but a quick glance at the V1.9 code revealed that it defaults to 115.2K baud. Easy to change though (#define SERIAL_COM_SPEED, config.h).

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

Re: MultiWii 1.9

Post by Hamburger »

for original (3 wire serial) LCD a special reprogramming of pin _and_ sending at 9600 is done.
afaik only for Textstar LCD a 4 wire serial is used _and_ it is driven at 115k (thus needs no reprogramming of serial IF (same as with GUI)

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: MultiWii 1.9

Post by shikra »

Yep - bit banging soft serial. It all looks right.
Just in case, I set com speed to 9600 and hey presto it started working. But now has stopped. Same garbage on display.
I must have issue with my LCD. I tried on another multiwii board and it's the same. :(

Crap - always something not working

wilco1967
Posts: 156
Joined: Thu Aug 18, 2011 6:04 pm
Location: Winterswijk, Netherlands

Re: MultiWii 1.9

Post by wilco1967 »

No, you don't need anything more than a 6 channel for Head Free....

However..... you will only be able to use Aux1 and Aux2 (not the new Aux3 and 4, as they represent channels 7 & 8).
You can simply put Head Free on either aux1 or aux2, but that leaves little options for Level mode / heading (compass) mode / Baro mode etc.

An 8(+) Channel transmitter gives you more options....
If you want to upgrade at some point, the Turnigy / Eurgle / IMax / whatever 9X transmitter, with ER9X firmware upgrade is highly recommended.
As much fun to do the upgrade / modify on the 9X as the MultiWii project...
http://code.google.com/p/er9x/

BTW: I've tried the new head free mode, and it seems to work just fine.... however, once you're used to 'normal' quad flying, this new mode becomes highly confusing again :roll: ..... you're still trying to control, as if standing behind the model....
I think it is especially usefull in a situation where you've lost orientation, and you're not sure anymore what is the 'front'. I guess this could have saved my last quad (flew away, after lost orientation.... never found it back :( ).
You could put LEVEL mode + HEAD FREE on the same switch.... if you loose orientation, hit that switch... than slowly bring it back towards you.



oddcopter wrote:
Hi,
I've just included it in the last dev
I named this mode HEAD FREE (more versatile than beginner mode)
+ ability to use AUX3 AUX4 like AUX1 and AUX2Alexinparis

Posts: 487
Joined: Wed Jan 19, 2011 3:07 pm
Private message


Alex,

jevermeister mentioned having to order a 9ch Turnigy. Does the HEAD FREE mode require more than a 6 channel TX/RX?

As a beginner (waiting on my board) I am very interested in this mode, but only have a 6ch TX/RX.

Thanks for all of your and others work on this project. It is amazing! Sorry if this is the wrong place to ask this question.

Thanks,
Britt

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

Re: MultiWii 1.9

Post by mr.rc-cam »

Yep - bit banging soft serial. It all looks right.

Oops/Sorry, I completely forgot about the hard coded 9600 soft serial. Out of sight, out of mind!

Just in case, I set com speed to 9600 and hey presto it started working. But now has stopped. Same garbage on display.
I must have issue with my LCD. I tried on another multiwii board and it's the same. Crap - always something not working

More reason to cherish the times when everything is working. :)

Wayne
Posts: 86
Joined: Sun Jul 31, 2011 10:44 pm

Re: MultiWii 1.9

Post by Wayne »

I would like to try the new HeadFree option on my Paris V4 quad and have a question.
What are the hardware requirements? Do I need to have GPS working and a Mag or will Mag only work.
I have downloaded and have working Arduino 1.0. I have also un-zipped the latest dev but do not see a change file.
Thanks for the info.

Post Reply