GPS NAV

Hypermobile · Post by **Hypermobile** » Wed Jan 15, 2014 8:24 pm

I found a little bug.

Today i added a Sonar SRF08, but on the Nav Code i get a compilation error.
I don't get this error on the MW2.3.

error message:
Sensors.cpp: In function 'uint16_t i2c_readReg16(int8_t, int8_t)':
Sensors.cpp:1664: error: cannot convert 'uint8_t (*)[2]' to 'uint8_t*' for argument '3' to 'void i2c_read_reg_to_buf(uint8_t, uint8_t, uint8_t*, uint8_t)'

I Also Think...that For a Better autoland...
Sonar could be very usefull. since the Height is measured Relative to the ground/landing spot..And is not relative to the take-off point like Baro

thanks anyway :-)

The new Wingui is great and is again compatible with the 'old' MW2.3 regular.

turkawa · Post by **turkawa** » Thu Jan 16, 2014 6:35 pm

With B5 my gps finds 6-7 sats but cant initiate gps hold or gps home.
I set it up at rc and check multiple times. sat are there but no gps modes..
am i doing something wrong??

EOSBandi · Post by **EOSBandi** » Thu Jan 16, 2014 7:40 pm

I found a nasty bug in the baro code (it was recently updated in _shared and merged to the B5 code.) Under 20degree Celsius the baro will go haywire. I'll post a fix to the B5 code later tonight.

Please note that it is also important to let your copter sit in the cold before you start flying. Since most of the sensors are temperature sensitive, and even they are compensated, the larger the difference between the startup temperature and actual one, the larger the error will be.

EOSBandi · Post by **EOSBandi** » Thu Jan 16, 2014 7:42 pm

turkawa wrote:With B5 my gps finds 6-7 sats but cant initiate gps hold or gps home.
I set it up at rc and check multiple times. sat are there but no gps modes..
am i doing something wrong??

And with those sats you also have 3D fix ?
Check your gps alone, connected to a PC.

wareck · Post by **wareck** » Thu Jan 16, 2014 7:54 pm

Hi
And very good job for this pre-release...

I found a little bug Inside MW-GUI.
When I go on "mission" pannel, context menu box open..
Not realy a problem but this afternoon, I click somewhere I doesn't want

Olivier

wareck · Post by **wareck** » Thu Jan 16, 2014 7:54 pm

Hi
And very good job for this pre-release...

I found a little bug Inside MW-GUI.
When I go on "mission" pannel, context menu box open..
Not realy a problem but this afternoon, I click somewhere I doesn't want

Olivier

EOSBandi · Post by **EOSBandi** » Thu Jan 16, 2014 7:57 pm

wareck wrote:Hi
And very good job for this pre-release...

I found a little bug Inside MW-GUI.
When I go on "mission" pannel, context menu box open..
Not realy a problem but this afternoon, I click somewhere I doesn't want

Olivier

Yes, I'm aware of it.. already fixed in the source, it will be included in the next release..
Thanks for noticing.
EOS

Hypermobile · Post by **Hypermobile** » Thu Jan 16, 2014 8:02 pm

EOSBandi wrote:I found a nasty bug in the baro code (it was recently updated in _shared and merged to the B5 code.) Under 20degree Celsius the baro will go haywire. I'll post a fix to the B5 code later tonight.

Please note that it is also important to let your copter sit in the cold before you start flying. Since most of the sensors are temperature sensitive, and even they are compensated, the larger the difference between the startup temperature and actual one, the larger the error will be.

You found that after looking for that Sonar Compilation issue?

turkawa · Post by **turkawa** » Thu Jan 16, 2014 8:06 pm

EOSBandi wrote:And with those sats you also have 3D fix ?
Check your gps alone, connected to a PC.

in wingui, at gps window, upper right pkt light blinks green and red, and satellite is green.
in standart multiwii gui, 3dfix is green.
I have 8 sats connected at the moment.
cannot activate gps home , gps hold...

EOSBandi · Post by **EOSBandi** » Thu Jan 16, 2014 8:13 pm

turkawa wrote:
EOSBandi wrote:And with those sats you also have 3D fix ?
Check your gps alone, connected to a PC.

in wingui, at gps window, upper right pkt light blinks green and red, and satellite is green.
in standart multiwii gui, 3dfix is green.
I have 8 sats connected at the moment.
cannot activate gps home , gps hold...

Did you ARMED your copter first ?
(when unarmed, you cannot activate any gps assisted mode)

EOSBandi · Post by **EOSBandi** » Thu Jan 16, 2014 8:20 pm

Hypermobile wrote:
EOSBandi wrote:I found a nasty bug in the baro code (it was recently updated in _shared and merged to the B5 code.) Under 20degree Celsius the baro will go haywire. I'll post a fix to the B5 code later tonight.

Please note that it is also important to let your copter sit in the cold before you start flying. Since most of the sensors are temperature sensitive, and even they are compensated, the larger the difference between the startup temperature and actual one, the larger the error will be.

You found that after looking for that Sonar Compilation issue?

Nope, I tried to fly it out in -1C and althold was unusable...
I did not checked sonar issues yet...

EOSBandi · Post by **EOSBandi** » Thu Jan 16, 2014 8:26 pm

Hypermobile wrote:I found a little bug.

Today i added a Sonar SRF08, but on the Nav Code i get a compilation error.
I don't get this error on the MW2.3.

error message:
Sensors.cpp: In function 'uint16_t i2c_readReg16(int8_t, int8_t)':
Sensors.cpp:1664: error: cannot convert 'uint8_t (*)[2]' to 'uint8_t*' for argument '3' to 'void i2c_read_reg_to_buf(uint8_t, uint8_t, uint8_t*, uint8_t)'

I Also Think...that For a Better autoland...
Sonar could be very usefull. since the Height is measured Relative to the ground/landing spot..And is not relative to the take-off point like Baro

thanks anyway
The new Wingui is great and is again compatible with the 'old' MW2.3 regular.

Autoland does not use baro altitude at all. It uses the vario. Initiates a constant speed sink, and when no changes in altitude for a certain amount of time it thinks that land is completed.
I don't own the sonar code, but currently it is not used anywhere in the code to compensate altitude.
The error above is easy... it should be
i2c_read_reg_to_buf(addr, reg, b, sizeof(b));
or
i2c_read_reg_to_buf(addr, reg, &b[0], sizeof(b));

Apparently nobody used this part of the code since the rehaul of the i2c handler routines.

turkawa · Post by **turkawa** » Thu Jan 16, 2014 8:32 pm

EOSBandi wrote:
turkawa wrote:
EOSBandi wrote:And with those sats you also have 3D fix ?
Check your gps alone, connected to a PC.

in wingui, at gps window, upper right pkt light blinks green and red, and satellite is green.
in standart multiwii gui, 3dfix is green.
I have 8 sats connected at the moment.
cannot activate gps home , gps hold...

Did you ARMED your copter first ?
(when unarmed, you cannot activate any gps assisted mode)

Feel like stupid now...
Was it always like that? I remember like when gps fix achieved you could switch to gps mode..
so i was trying like that....
It works when armed...

Hypermobile · Post by **Hypermobile** » Thu Jan 16, 2014 8:39 pm

EOSBandi wrote:
Hypermobile wrote:I found a little bug.

Today i added a Sonar SRF08, but on the Nav Code i get a compilation error.
I don't get this error on the MW2.3.

error message:
Sensors.cpp: In function 'uint16_t i2c_readReg16(int8_t, int8_t)':
Sensors.cpp:1664: error: cannot convert 'uint8_t (*)[2]' to 'uint8_t*' for argument '3' to 'void i2c_read_reg_to_buf(uint8_t, uint8_t, uint8_t*, uint8_t)'

I Also Think...that For a Better autoland...
Sonar could be very usefull. since the Height is measured Relative to the ground/landing spot..And is not relative to the take-off point like Baro

thanks anyway
The new Wingui is great and is again compatible with the 'old' MW2.3 regular.

Autoland does not use baro altitude at all. It uses the vario. Initiates a constant speed sink, and when no changes in altitude for a certain amount of time it thinks that land is completed.
I don't own the sonar code, but currently it is not used anywhere in the code to compensate altitude.
The error above is easy... it should be
i2c_read_reg_to_buf(addr, reg, b, sizeof(b));
or
i2c_read_reg_to_buf(addr, reg, &b[0], sizeof(b));

Apparently nobody used this part of the code since the rehaul of the i2c handler routines.

`

i'm not a programmer ;-)

But if you change it to this: it does indeed compile.
i2c_read_reg_to_buf(addr, reg, &b[0], sizeof(b));

the code will compile like the regular MW2.3.

turkawa · Post by **turkawa** » Thu Jan 16, 2014 8:46 pm

is it normal to not being able to activate gps hold with less than 6 sat??
the normal sat number to lock is around 5 here.. 6 and above is a good day....

EOSBandi · Post by **EOSBandi** » Thu Jan 16, 2014 8:50 pm

turkawa wrote:is it normal to not being able to activate gps hold with less than 6 sat??
the normal sat number to lock is around 5 here.. 6 and above is a good day....

Yes, with 5 sat you will have SOME position information but not precise enough to hold position or navigate

happyusers · Post by **happyusers** » Sat Jan 18, 2014 1:25 pm

Thank you EOS for that great work.
I had a very old Multiwii board with a Mega as FC and tried to renew it. I uploaded your firmware 2.3 navi b4, updated my PC (net 4.0 and so on) and tried to connect but without success. I got the message "check you have choosen the right com port". I tried alternatively with 115000 baud and 57600 (I read in source that tx0 was configured at such a speed) but no luck.
I was not sure of my board and connexion so I downgraded to 2.0. The connexion was OK and my sensors showed immediately.
Would you have any clue to diagnose the problem with new Config programm? Formerly, I remember that you could test the connexion through a simple terminal on the right port with the right speed ; is it any longer possible or is there another test procedure?
I would be very pleased if you could give me an advice in order to progress and use your nav tools.
Thank you.

szakacs · Post by **szakacs** » Sun Jan 19, 2014 12:22 am

EOSBandi wrote:
szakacs wrote:Would it be possible to show trim values in the GUI ?

It is a good idea, plus perhaps you can change them from gui... it could be faster than changing trim with stick controls

Is it possible to extract the values using a terminal program like MultiWiiCL ?

EOSBandi · Post by **EOSBandi** » Sun Jan 19, 2014 9:28 am

Not without changing the code, since these values are not communicated to the config programs.

Imen · Post by **Imen** » Sun Jan 19, 2014 3:57 pm

HI EOSBandi,

Just test the 2.3 b-5, testing with SET_HEADING command and I think it had reversed by 180 degree.
trying to fix with wrap angle 180. it's OK now

zidlov · Post by **zidlov** » Sun Jan 19, 2014 10:54 pm

After having abandoned MultiWii for a while in favour of Megapirate, I flashed MW2.3-nav yesterday (thanks to EOSBandi) on my AIOP, because I finally wanted the responsiveness and pure awesome control of MW back to my Dex Mini Quad. After about two minutes of pid tuning it felt already much better than everything I could get with Megapirate.
But, anyways, just wanted to chime in here. Tried my first mission, although my alt-hold and gps-hold is not yet tuned ok, but like Imen I noticed that the heading somehow was wrong.
When I tried a RTH, the copter didn't come in heads first, although this is what is defined in config.h (1 and true/0 and false are interchangeable, right?)
The mission I aborted prematurely because of not yet good-enough pids, but it seemed that it wasn't heading to the next waypoint, but was slightly off...
Just wanted to share my observation.

Imen · Post by **Imen** » Mon Jan 20, 2014 3:36 am

zidlov wrote:After having abandoned MultiWii for a while in favour of Megapirate, I flashed MW2.3-nav yesterday (thanks to EOSBandi) on my AIOP, because I finally wanted the responsiveness and pure awesome control of MW back to my Dex Mini Quad. After about two minutes of pid tuning it felt already much better than everything I could get with Megapirate.
But, anyways, just wanted to chime in here. Tried my first mission, although my alt-hold and gps-hold is not yet tuned ok, but like Imen I noticed that the heading somehow was wrong.
When I tried a RTH, the copter didn't come in heads first, although this is what is defined in config.h (1 and true/0 and false are interchangeable, right?)
The mission I aborted prematurely because of not yet good-enough pids, but it seemed that it wasn't heading to the next waypoint, but was slightly off...
Just wanted to share my observation.

Hi Zidlov, heading to waypoint is OK include RTH, I think

. You could choose an option, changeable on GUI whether tail / head first while copter go to some waypoint.
The issue I found is only in set heading command, so if I command heading of copter to the west then actual copter would heading to the east when I perform mission mode.

happyusers · Post by **happyusers** » Mon Jan 20, 2014 12:55 pm

I am stuck with the GUI.
Is there a reason why I cannot get my FC connected? The GUI tells me to check the port number. Could it be because I have not yet wired my GPS (FMP04)?

EOSBandi · Post by **EOSBandi** » Mon Jan 20, 2014 1:07 pm

happyusers wrote:I am stuck with the GUI.
Is there a reason why I cannot get my FC connected? The GUI tells me to check the port number. Could it be because I have not yet wired my GPS (FMP04)?

1. can you connect with MultiWiiConf ?
2. Which opsys ?
3. What FC and GUI version and which board?

4. FMP04 will be problematic, it is very likely that it wont work with MTK1.9 GPS firmware, and NMEA mode has resolution issues

EOSBandi · Post by **EOSBandi** » Mon Jan 20, 2014 1:09 pm

Imen wrote:HI EOSBandi,

Just test the 2.3 b-5, testing with SET_HEADING command and I think it had reversed by 180 degree.
trying to fix with wrap angle 180. it's OK now

Thanks, i'll include this fix..

happyusers · Post by **happyusers** » Mon Jan 20, 2014 1:29 pm

EOSBandi wrote:
happyusers wrote:I am stuck with the GUI.
Is there a reason why I cannot get my FC connected? The GUI tells me to check the port number. Could it be because I have not yet wired my GPS (FMP04)?

1. can you connect with MultiWiiConf ?
2. Which opsys ?
3. What FC and GUI version and which board?

4. FMP04 will be problematic, it is very likely that it wont work with MTK1.9 GPS firmware, and NMEA mode has resolution issues

I can connect with MultiwiiConf 2.3 GUI on serial 0.
I am on a XP machine.
I have a Arduino Mega 2560, a FFIMU and it seems to be well tuned.
The GUI version is 2.3 pre8.

I have forgotten to mention that my FMP04/BLOB work OK with miniGPS. I got 5 sat fix last night from home.

EOSBandi · Post by **EOSBandi** » Mon Jan 20, 2014 1:39 pm

You said you did not connected your gps. Did you configured it ? (I mean you defined USE_MSP_WP?)
If not, please do so, since MSP_NAV_CONF works only with the above define.

EOSBandi · Post by **EOSBandi** » Mon Jan 20, 2014 3:57 pm

felixrising wrote:Interesting stuff... especially with piksi kickstarter successfully funded, and being oss and oshw... They're also actively talking to various flight controller teams

I checked their github, the latest checkin was three months ago. The current code is quite rudimentary and no sign of any RTK implementation.
(however, If they successfully implement RTK on an STM32 proc, that would be interesting, since NV08-CSM modules are capable to output raw phase data, which can be processed then. So instead of getting piksi for 500usd per piece, you need two NV08 and and two STM32 discovery boards, total cost - around 100usd)
(However I'm in serious doubt, STM32F4 does not have enough horsepower, neither double precision FPU that is necessary for RTK (or at least to port RTKLIB)

happyusers · Post by **happyusers** » Mon Jan 20, 2014 6:21 pm

Yes the line #define USE_MSP_WP is uncommented.
I tryed another time and I have the same message "please check if you have selected the right com port".
Furthermore, when I launch the GUI, a message appears "no internet connexion available".
I left the serial0 baud rate to 57600 as was but I tried the two possible rates 115200 and 57600.
When using plain 2.3 the board gets to the GUI without problem. I am puzzled.

ttcorse · Post by **ttcorse** » Mon Jan 20, 2014 7:26 pm

a question:
because in psh if I move the stick with the quad when I leave the stick back to the point where I had activated the psh?
It should not change the psh if I leave the stick?

EOSBandi · Post by **EOSBandi** » Mon Jan 20, 2014 8:15 pm

ttcorse wrote:a question:
because in psh if I move the stick with the quad when I leave the stick back to the point where I had activated the psh?
It should not change the psh if I leave the stick?

Not yet, this function is temporary disabled (for code testing reasons)

EOSBandi · Post by **EOSBandi** » Mon Jan 20, 2014 8:16 pm

happyusers wrote:Yes the line #define USE_MSP_WP is uncommented.
I tryed another time and I have the same message "please check if you have selected the right com port".
Furthermore, when I launch the GUI, a message appears "no internet connexion available".
I left the serial0 baud rate to 57600 as was but I tried the two possible rates 115200 and 57600.
When using plain 2.3 the board gets to the GUI without problem. I am puzzled.

It is weird. Please send me your config.h I'll test it on my test board...

happyusers · Post by **happyusers** » Mon Jan 20, 2014 11:18 pm

It is weird. Please send me your config.h I'll test it on my test board...

Here it is. I was obliged to zip it for forum regulation.
Thank you for checking.

EOSBandi · Post by **EOSBandi** » Mon Jan 20, 2014 11:32 pm

happyusers wrote:
It is weird. Please send me your config.h I'll test it on my test board...

Here it is. I was obliged to zip it for forum regulation.
Thank you for checking.

It is quite outdated. Please download the Beta5 code from http://code.google.com/p/mw-wingui/downloads/list alongside with the pre8(b5) WinGUI.

happyusers · Post by **happyusers** » Tue Jan 21, 2014 12:39 am

EOSBandi wrote:It is quite outdated. Please download the Beta5 code from http://code.google.com/p/mw-wingui/downloads/list alongside with the pre8(b5) WinGUI.

I tried with beta 5 and pre8 (b5) but no success. It reacts as before. "check port number".
Furthermore, it says I have no internet connexion.

EOSBandi · Post by **EOSBandi** » Tue Jan 21, 2014 11:09 am

happyusers wrote:
EOSBandi wrote:It is quite outdated. Please download the Beta5 code from http://code.google.com/p/mw-wingui/downloads/list alongside with the pre8(b5) WinGUI.

I tried with beta 5 and pre8 (b5) but no success. It reacts as before. "check port number".
Furthermore, it says I have no internet connexion.

Strange. Could you please check it on another machine (preferably not XP). Just want to determine is it a FC problem or a WinGUI.
(You can also try update FTDI drivers from http://www.ftdichip.com/FTDrivers.htm)

happyusers · Post by **happyusers** » Wed Jan 22, 2014 10:41 am

I tried on a Vista machine. It's the same except that the software no longer complains with the internet connexion (wired connexion to the modem).
I have tested the arduino port (com4) at two speed rates 57600 and 115200. It seems that navB5 is configured to exchange at 57600? So no significant progress!

-ralf- · Post by **-ralf-** » Wed Jan 22, 2014 4:08 pm

Hi András,

can you please integrate r1651 in next beta?
Thanks

EOSBandi · Post by **EOSBandi** » Thu Jan 23, 2014 2:50 pm

-ralf- wrote:Hi András,

can you please integrate r1651 in next beta?
Thanks

HI,
Next release will be merged into _shared.

EOSBandi · Post by **EOSBandi** » Thu Jan 23, 2014 2:52 pm

happyusers wrote:I tried on a Vista machine. It's the same except that the software no longer complains with the internet connexion (wired connexion to the modem).
I have tested the arduino port (com4) at two speed rates 57600 and 115200. It seems that navB5 is configured to exchange at 57600? So no significant progress!

I'm stuck. It must be some very basic problem, but I ran out of ideas. Anyone else ?

happyusers · Post by **happyusers** » Thu Jan 23, 2014 6:05 pm

Andras, would you know a means to listen at FC - a very basic tool like serial sniffer or terminal - I could use to debug that situation? I remember that in the former versions of multiwii, if you send a character (a) to the FC using a terminal, it sends all the variables in serial mode. Is there a way to do something like that now?

happyusers · Post by **happyusers** » Fri Jan 24, 2014 9:35 am

Hi Andras,
I dig in the setup code. I was surprised, I expected to find initialisation for port 0 as link to GUI. What I find is the following code (line582):

Code: Select all

void setup() {
  #if !defined(GPS_PROMINI)
    SerialOpen(0,SERIAL0_COM_SPEED);
    #if defined(PROMICRO)
      SerialOpen(1,SERIAL1_COM_SPEED);
    #endif
    #if defined(MEGA)
      SerialOpen(1,SERIAL1_COM_SPEED);
      SerialOpen(2,SERIAL2_COM_SPEED);
      SerialOpen(3,SERIAL3_COM_SPEED);
    #endif
  #endif

Fo a Mega board which is my case, all ports except 0 are open.
A little bit further, I find that piece of code (line 682):

Code: Select all

  #if defined(GPS_SERIAL)
    GPS_SerialInit();
    for(uint8_t j=0;j<=5;j++){
      GPS_NewData();
      LEDPIN_ON
      delay(20);
      LEDPIN_OFF
      delay(80);
    }
    if(!GPS_Present){
      SerialEnd(GPS_SERIAL);
      SerialOpen(0,SERIAL0_COM_SPEED);
    }

It seems that port 0 is allocated to serial GPS. It could be a reason of trouble connecting board to GUI as far as I expect to exchange data through port 0 (USB). What do you think?
[Edit 19:45]
Apparently I have read code too quickly. Port 0 is open especially when GPS not present. Anyhow, I dont know why port 0 is associated with GSP. For me its devoted to serial communication through USB!
Would you know, by chance, where communication is checked inside main loop? I have not found any function looking like byteAvailable..
[Edit 25/01]
I have wired again the FC to USB port. The activity of port is showing on rx LED. When I press 'connect', the LED is bright 7 times with interval of 8 or 10 seconds, then it flashes 7 times and immediately after that, the GUI tells that I have to check the port number.
The first point is that it is the right port number (activity is obvious on LED)
The second point is the firmware does not answer the GUI. Why?
Some idea to progress into diagnostic?
[Edit 20:26]
Some news : I have used a port sniffer and I can say the GUI sends packets on port 4 which FC is supposed to listen. I see commands like $M>dd sent through the port. No answer from FC.
[Edit 26/01]
I tried to use navi GUI with 2.3 Alex firmware. Everything is OK. The communication established a first and I can read parameters and sensors.
I think the problem is inside navi firmware. I shall dig deeper to find the reason my FC does not links to GUI.

-ralf- · Post by **-ralf-** » Sat Jan 25, 2014 5:19 pm

Hi András,

I just gave Beta5 a first chance .... all seems to work fine :mrgreen:

But there is another big problem ..... not enough AUX-channels. Is there a
chance to enable AUX5 to AUX6 or AUX8?

mopedcrosser · Post by **mopedcrosser** » Sun Jan 26, 2014 1:58 pm

Hi Eos,

I just tested the b5 version and found a possible bug that occurs frequently.. I am not sure wether my baro is defective after flashing ( why should it ?) but my altitude goes after a couple of seconds to 4m and then jumps to 175XX meters and stays in that region. So there is a 17.5km offset. Anybody else with that issue ? Was using the 2.3 release before on my crius aiop V1.1 before and baro worked fine.

Then threre are 2 things I can´t figure out...

1. How to enable the other Aux channels in WINGui ? Using sumppm with Graupner MX20

2. Where can I set a servo and map it to an Aux channel... I need this for gimbal control and always defined it in config.h in MW2.2. Since 2.3 its gone and I cant find out how to set it....

Best regards

Seb

EOSBandi · Post by **EOSBandi** » Sun Jan 26, 2014 2:07 pm

-ralf- wrote:Hi András,

I just gave Beta5 a first chance .... all seems to work fine

But there is another big problem ..... not enough AUX-channels. Is there a
chance to enable AUX5 to AUX6 or AUX8?

what about having six states per aux channel instead of three ?

EOSBandi · Post by **EOSBandi** » Sun Jan 26, 2014 2:10 pm

mopedcrosser wrote:Hi Eos,

I just tested the b5 version and found a possible bug that occurs frequently.. I am not sure wether my baro is defective after flashing ( why should it ?) but my altitude goes after a couple of seconds to 4m and then jumps to 175XX meters and stays in that region. So there is a 17.5km offset. Anybody else with that issue ? Was using the 2.3 release before on my crius aiop V1.1 before and baro worked fine.

Then threre are 2 things I can´t figure out...

1. How to enable the other Aux channels in WINGui ? Using sumppm with Graupner MX20

2. Where can I set a servo and map it to an Aux channel... I need this for gimbal control and always defined it in config.h in MW2.2. Since 2.3 its gone and I cant find out how to set it....

Best regards

Seb

Did you tried the b5-barofix (it is the latest that you can download)?
at the moment only four aux channels are used in multiwii code for function setting.
servo settings are not finished yet, but it will be there in the next release.

-ralf- · Post by **-ralf-** » Sun Jan 26, 2014 3:14 pm

EOSBandi wrote:
-ralf- wrote:Hi András,

I just gave Beta5 a first chance .... all seems to work fine

But there is another big problem ..... not enough AUX-channels. Is there a
chance to enable AUX5 to AUX6 or AUX8?

what about having six states per aux channel instead of three ?

This may be a solution

mopedcrosser · Post by **mopedcrosser** » Sun Jan 26, 2014 3:33 pm

Hi Eos,

nope didnt see that.. sorry / will report my findings on the fixed version ! Any plans for the next release ? I wont be able to got to fly this weekend anyways, so i´d probably wait for the next release.

Thanks for your support / great work

Seb

dm571 · Post by **dm571** » Sun Jan 26, 2014 4:29 pm

Uploaded baro fix version. Still issue with althold. Very unstable baro mode, climbing. QC trying to loss height all the time. Temp is -15 celcium.

EOSBandi · Post by **EOSBandi** » Sun Jan 26, 2014 4:37 pm

dm571 wrote:Uploaded baro fix version. Still issue with althold. Very unstable baro mode, climbing. QC trying to loss height all the time. Temp is -15 celcium.

is alt stable when copter is on the ground ? (and cooled down)
did you wait about 10 minute to let sensors cool down ?