Release v2.3 is coming soon... prepare

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
Stars112
Posts: 36
Joined: Wed Jan 30, 2013 9:29 pm

Re: Release v2.3 is coming soon... prepare

Post by Stars112 »

in "Config.h" is a little typing error:

#define LCD_TELEMETRY_AUTO_FREQ 1967// to step to next telemetry page 967 <=> 3s

to

#define LCD_TELEMETRY_AUTO_FREQ 967// to step to next telemetry page 967 <=> 3s

Stars112
Posts: 36
Joined: Wed Jan 30, 2013 9:29 pm

Re: Release v2.3 is coming soon... prepare

Post by Stars112 »

In the Config.h the section:

/*********************** Cam Stabilisation ***********************/
/* The following lines apply only for a pitch/roll tilt stabilization system. Uncomment the first or second line to activate it */
//#define SERVO_MIX_TILT
#define SERVO_TILT

Don't work with Poti on Radio.
Only the Automatik Camstab is ready.
In previous Versions you can change with Poti (AUX3) the Gimbal position. it is dosent work in 1573.

Mis
Posts: 203
Joined: Fri Apr 01, 2011 12:23 am

Re: Release v2.3 is coming soon... prepare

Post by Mis »

Don't work with Poti on Radio.

Start GUI, go to settibgs tab and assign AUX channel for SERVO1 middle position.

Stars112
Posts: 36
Joined: Wed Jan 30, 2013 9:29 pm

Re: Release v2.3 is coming soon... prepare

Post by Stars112 »

Mis wrote:Start GUI, go to settibgs tab and assign AUX channel for SERVO1 middle position.

OK, that works!
Thanks Mis...

BUT that is definite not intuitive!!! ;)
A minimum is a description near the scalebox.
A Dropbox would be much better.

ttcorse
Posts: 17
Joined: Sun Feb 03, 2013 7:53 am

Re: Release v2.3 is coming soon... prepare

Post by ttcorse »

I discovered the solution to the problem of the fix for FC CRIUS aio.
Need to be reset after the first power in practice as it had done before EOSBandi not alter the gps.ino sending a session string to the GPS turned on.
I wonder will lost it ported?
EOSBandi help!

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

Re: Release v2.3 is coming soon... prepare

Post by Alexinparis »

rbirdie001 wrote:Hi,
today I tested r1573 in 328 (Crius SE) with I2C_GPS_NAV_v2_2 loaded in Arduino Promini and ALWAYS after powering ON I see three I2C errors in GUI. Then it works normally and number of errors remains on 3, but previously it wasn't like this. Probably just bad timing during bootup, but doesn't look nice because we, ordinary users, were taught that I2C errors are bad and shouldn't be there ;) .

I see also the 3 errors when I use a I2C_GPS_NAV. I suppose it will be corrected with EOS GPS update.

Another strange thing is that when I change some values (like PID) over GUI and press "WRITE" button, FC reboots. It also started happenning after connecting I2C GPS.
Can someone verify this before 2.3 release?
Thanks!
Roman

I can't reproduce it.

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

Re: Release v2.3 is coming soon... prepare

Post by Alexinparis »

jevermeister wrote:Hi,
I did a small overview with the new PRE Code and I stumbled upon a small thing I'd like to adress:

I like to start action style with the copter in my hand tilted and then start engines and throttle up in acro and let it loose,

I need to fly with my Camera below the copter and becuase of vibration feedback I do not use a Skit, so I need to start from my hand.
The copter checks if being tilted ons tartup and this prevents me from starting like this. Same goes to starting on uneven ground.

I like to suggest the following (I use this by myself successfully):
Introduce a parameter that disables this security feature for advanced users.

Code: Select all

void go_arm() {
  if(calibratingG == 0
  #if defined(ONLYARMWHENFLAT)
    && f.ACC_CALIBRATED
  #endif


ONLYARMWHENFLAT is activated per default, so new users have the security of not making mistakes and those that are interested can change that.


Ok, why not.
But note staying below 25 deg is quite achievable even by hands ;)

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

Re: Release v2.3 is coming soon... prepare

Post by jevermeister »

Alexinparis wrote:Ok, why not.
But note staying below 25 deg is quite achievable even by hands ;)



Thanks, :-)

But I like to start 45° and give full throttle. That impresses the ladies ;-).

Someone volunteers to code that? I have no access to svn anymore!

Nils

Stars112
Posts: 36
Joined: Wed Jan 30, 2013 9:29 pm

Re: Release v2.3 is coming soon... prepare

Post by Stars112 »

Hi,
i tested today 3 Akkus with 1573 on my own PCB.
After new PID Setting (R/P 4.0) YAW D =120 (can this be ok? The Jump at YAW is so mostly ok) and YAWRate =0,5 (before 0,8) the Copter is in a new league :shock:

Verry Cool! Thank You...
I think the Flighttime is now longer (subjective-no measurement).

User avatar
linuxslate
Posts: 91
Joined: Mon May 13, 2013 3:55 pm

Re: Release v2.3 is coming soon... prepare

Post by linuxslate »

Comment on ONLYARMWHENFLAT:

When we fly the toy mini's and micro's, one test we do is the upsidedown hand-toss.

Starting with motors off, and holding the Quad upsidedown, toss it out in front of you, then give it some throttle.

A mini or micro with good flight control system should right itself, and fly on happily.

While this is not something I'd try with my 450 Brushless FPV system, I do realize that there are people working on mini and even micro MultiWii 'copters.

Perhaps just so that MultiWii can "Check all the boxes" - i.e. pass the upsidedown hand-toss, we should implement something like this. (With adequate warnings).

--- Just my $0.02

rbirdie001
Posts: 178
Joined: Fri Apr 01, 2011 10:32 pm
Location: Czech Republic, Prague

Re: Release v2.3 is coming soon... prepare

Post by rbirdie001 »

Alexinparis wrote:
rbirdie001 wrote:Hi,
today I tested r1573 in 328 (Crius SE) with I2C_GPS_NAV_v2_2 loaded in Arduino Promini and ALWAYS after powering ON I see three I2C errors in GUI. Then it works normally and number of errors remains on 3, but previously it wasn't like this. Probably just bad timing during bootup, but doesn't look nice because we, ordinary users, were taught that I2C errors are bad and shouldn't be there ;) .

I see also the 3 errors when I use a I2C_GPS_NAV. I suppose it will be corrected with EOS GPS update.

Another strange thing is that when I change some values (like PID) over GUI and press "WRITE" button, FC reboots. It also started happenning after connecting I2C GPS.
Can someone verify this before 2.3 release?
Thanks!
Roman

I can't reproduce it.

Hi Alex,
I again tried to get rid of reboot after writing data to FC so I again cleared its EEPROM and reloaded r1573. I have Crius SE board with connected I2C GPS in Promini. Behavior is exactly the same - three I2C errors from the beginning and reboot when writing settings to EEPROM. See this video:
http://www.youtube.com/watch?v=5r_KaEdLsfI
Note, that after unwanted reboot I2C errors are not there anymore (it confirms reboot?).
I'm attaching my actual config.h, no other file was altered. You can try to reproduce the fault...
When I disconected I2C GPS and disabled it in config.h, writing to EEPROM worked perfectly without reboot, as it should.
Sorry, I'm used that what works for everyone, it usually doesn't work for me. At least I should be good as a beta tester ;)
Roman
Attachments
config.zip
My actual config.h with activated I2C GPS
(19.36 KiB) Downloaded 300 times

sismeiro
Posts: 173
Joined: Tue Feb 21, 2012 12:33 pm

Re: Release v2.3 is coming soon... prepare

Post by sismeiro »

Hi to all,

Just giving my feedback regarding the pre v2.3. I tested it with my Xcopter that has a Crius SE FC and didn't found any problem. My rig is nothing fancy, just a X525 with ANGLE and MAG activated.

I still have to tune the PIDs since I felt the Xcopter too loose when flying with defaults. I used the LCD via Blueterm in Android to increase the roll and pitch P to 5.4 just to test. It flew better but now I think I need to change the PID for the LEVEL because it seems to take too long to return to horizontal. Any suggestions?

It's looking good to be released sometime soon. Excellent work from the developers and off course, Alex.

Regards,
Luis Sismeiro

Ringo42
Posts: 11
Joined: Thu Jun 13, 2013 8:50 pm

Re: Release v2.3 is coming soon... prepare

Post by Ringo42 »

I'm new to multiwii. My board has 2.2 on it. where do I get 2.3 when it comes out? Will it be posted here? I've got an issue where the rear left motor doesn't power up correctly and I'm hoping 2.3 will fix it.
Thanks

PatrikE
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: Release v2.3 is coming soon... prepare

Post by PatrikE »


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

Re: Release v2.3 is coming soon... prepare

Post by Hamburger »

info on
- servos pins and setup
- private defaults
- new powermeter setup
updated in wiki and links put into config.h

Please read and enhance.

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

Re: Release v2.3 is coming soon... prepare

Post by Hamburger »

I seem to remember we moved some servo pins for some coptertypes. In case this would collide with former motor pins it could easily fry a servo fast. So a warning notice would be good. Anyone remember which coptertype(s) was affected beyond TRI on mega with hardware.pwm?

PatrikE
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: Release v2.3 is coming soon... prepare

Post by PatrikE »

Plans, FlyingWing and BI Servos was also changed.

User avatar
city_kid
Posts: 64
Joined: Wed Apr 03, 2013 8:09 pm
Location: Birmingham UK

Re: Release v2.3 is coming soon... prepare

Post by city_kid »

@Hamburger

Where is the "updated wiki" for v2.3....?

Many thanks!

city_kid

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

Re: Release v2.3 is coming soon... prepare

Post by Hamburger »

from trunk/Readme.txt:

Documentation for releases should be in the official wiki at
http://www.multiwii.com/wiki

Dunno know how it was spelled in last release notes.
Have fun.

obor
Posts: 26
Joined: Sun Mar 17, 2013 11:58 pm

Re: Release v2.3 is coming soon... prepare

Post by obor »

Hi,
One question: do you plan to integrate changing pids with POT value and Ziegler-Nichols algorythm as described here:
viewtopic.php?f=7&t=1701
?
Thanks

teslahed
Posts: 84
Joined: Wed Jun 27, 2012 2:51 pm

Re: Release v2.3 is coming soon... prepare

Post by teslahed »

It would be great to have a potentiometer you could use to alter one or more PID values on the fly. I would start my PID tuning by linking it to P on pitch and roll and go from there. You'd need the multiwii software to output the PID setting in real time so that you could read it over bluetooth or whatever and note down the best value. Then after tuning you'd turn the potentiometer off and set the PID setting to the best value previously discovered using the GUI.

tovrin
Posts: 705
Joined: Tue Sep 20, 2011 4:08 pm

Re: Release v2.3 is coming soon... prepare

Post by tovrin »

if you have bluetooth, why not just use the android app and make changes via the app? thats hwo i do it, thoguh i dont recommend making changes in flight, as i heard it can bug out for a full second.

BarneyG
Posts: 39
Joined: Tue May 07, 2013 4:42 pm

Post by BarneyG »

Teslahed look at this thread ... viewtopic.php?t=1701

Also look at my thread in mruk about this feature ... I think I'll be adding it into my build at some point soon if you'd like a copy

sismeiro
Posts: 173
Joined: Tue Feb 21, 2012 12:33 pm

Re: Release v2.3 is coming soon... prepare

Post by sismeiro »

Hi,

Following the topic to say that I am prepared for 2.3 final. :)

I have being using the latest shared from SVN with my configurations like Crius SE, LCD config, LCD telemetry, etc. and all ok for my Xcopter. The test flights didn't show any problem and for me that was using 2.1 for a long time, it flies very well, only needed to increase the default P for roll and pitch.

Regards,
Luis Sismeiro

teslahed
Posts: 84
Joined: Wed Jun 27, 2012 2:51 pm

Re:

Post by teslahed »

BarneyG wrote:Teslahed look at this thread ... viewtopic.php?t=1701

Also look at my thread in mruk about this feature ... I think I'll be adding it into my build at some point soon if you'd like a copy


Thanks Barney. If they are not adding this to the main 2.3 release then i would indeed appreciate a copy of your modified version. Especially if it's exactly the same as 2.3 except with that one mod - that would be really handy!

I have used the bluetooth aps to PID tune on the fly before, it works well. A potentiometer would give better results i think - easier and quicker to make small precise changes in real time.

iosonologio
Posts: 13
Joined: Sun Sep 22, 2013 5:46 pm

Re: Release v2.3 is coming soon... prepare

Post by iosonologio »

What about MultiWii conf. The Mac version has some troubles with the bluetooth, it is extremely slow. I know nothing about processing, so it would be better if somebody else tackles the issue.

Second problem, i have noticed some issues in the baro signal on Multiwii conf:

Baro signal has some aliasing (i.e.: two successive points with the same value), that happens really often (every 3-5 points). Since the signal in Multiwii (when on cable) is updated at around 3Hz, i think there might be a bigger underlying problem. Please notice that only baro seems to have this issue, while gyro signals are smooth.
I will need to dig into this deeper, anybody else noticed this?

BarneyG
Posts: 39
Joined: Tue May 07, 2013 4:42 pm

Re: Release v2.3 is coming soon... prepare

Post by BarneyG »

to be honest I've kinda given up on Baro on my Crius AIOP v2 board ... I got down to -12m (and still descending) the other night while my quad was sat on the floor for about 20 mins for some testing of the latest pre release version.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Release v2.3 is coming soon... prepare

Post by timecop »

The baro / board probably heated up.

BarneyG
Posts: 39
Joined: Tue May 07, 2013 4:42 pm

Re: Release v2.3 is coming soon... prepare

Post by BarneyG »

timecop wrote:The baro / board probably heated up.


Oh I don't disagree ... I removed the foam I had covering it and it gradually returned to a reasonably correct value but the point is if I don't cover it it is affected by prop wash & light and if I do cover it is affected by heat ... either way the data it provides isn't correct and my quad isn't going to be doing what I want of it :)

Edit ... Don't get me wrong not dissing MultiWii really it is the limitations of the hardware ... putting the Baro on a separate board that wasn't in the propwash would address a number of issues, same goes for the Compass too
Last edited by BarneyG on Tue Oct 15, 2013 3:07 pm, edited 1 time in total.

Ringo42
Posts: 11
Joined: Thu Jun 13, 2013 8:50 pm

Re: Release v2.3 is coming soon... prepare

Post by Ringo42 »

I've got the readytoflyquads pro board and the baro on it is bad too. I've seen it as low as -20m with the motors never turning on, just as It was sitting there on the table.

obor
Posts: 26
Joined: Sun Mar 17, 2013 11:58 pm

Re: Release v2.3 is coming soon... prepare

Post by obor »

BarneyG wrote:to be honest I've kinda given up on Baro on my Crius AIOP v2 board ... I got down to -12m (and still descending) the other night while my quad was sat on the floor for about 20 mins for some testing of the latest pre release version.

Same for me, I never got good results on altitude with my AIOP V2 also. Simply not usable.
Another thing also which did not worked well is angle or stable mode. The Copter always drift quickly on one side or the other. It does not hold any position at all. It made me feel just like the accelero are not acurate enough to keep a perfect zero level...

iosonologio
Posts: 13
Joined: Sun Sep 22, 2013 5:46 pm

Re: Release v2.3 is coming soon... prepare

Post by iosonologio »

Those are board related problems (or warming up, or simply weather change on a 20 min timescale). My was an issue about software.
I repeat the question.

Baro signal has some aliasing (i.e.: two successive points with the same value), that happens really often (every 3-5 points). Since the signal in Multiwii (when on cable) is updated at around 3Hz, i think there might be a bigger underlying problem. Please notice that only baro seems to have this issue, while gyro signals are smooth.

Did anybody see the same?

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

Re: Release v2.3 is coming soon... prepare

Post by crashlander »

Long standing feature in MWII is its I term zeroing function when TH is below some value.
That is necessary feature in multi-copter world but can be considered bug for FIXEDWINGS since pilots are gliding with zero TH all the time (often) and there this feature is actually a bug!
I prpose to enclose that part of code in #ifdefs for FIXEDWING (allready described in Airplane RTH thread viewtopic.php?f=7&t=2456&start=330#p42355).

Regards
Andrej

mabaka
Posts: 21
Joined: Thu Oct 17, 2013 12:03 pm

Re: Release v2.3 is coming soon... prepare -> parameters...

Post by mabaka »

F_CPU and I2C_SPEED usage.

I2C_SPEED parameter usage.
It is defined in config.h; its default value is for slow I2C (100 KHz), and is rarely used.
On most TWBR (TWI Bit Rate Register) register writes appears explicitly 400000L (for 400 KHz).
So something like this would be more elegant:
#define I2C_SPEED_SLOW 100000L
#define I2C_SPEED_FAST 400000L
and use one or the other in TWBR writes.

F_CPU parameter usage.
If I am not wrong, this parameter comes from:
(board used).build.f_cpu=16000000L
on boards.txt file.
It seems to be used in TWBR writes and baudrate calculations, but not in pulse width calculations.

So I understand that F_CPU must be 16 MHz, and usage on 3.3V arduinos or using the internal 8 MHz chip clock would require a massive code change.
Please, correct me if I am wrong in these assumptions.

So suppose you want to try the internal 8 MHz chip clock such on a gimbal only Multiwii usage.
Would changing in output.cpp:
map(servo[i], 1020, 2000...
to
map(servo[i], 510, 1000...
be enough, or is there a less horrible way?

(BTW, explicit 1020 and 2000 is ugly).

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Release v2.3 is coming soon... prepare

Post by e_lm_70 »

crashlander wrote:Long standing feature in MWII is its I term zeroing function when TH is below some value.
That is necessary feature in multi-copter world but can be considered bug for FIXEDWINGS since pilots are gliding with zero TH all the time (often) and there this feature is actually a bug!
I prpose to enclose that part of code in #ifdefs for FIXEDWING (allready described in Airplane RTH thread viewtopic.php?f=7&t=2456&start=330#p42355).

Regards
Andrej


Good point.

On my hacked MultiWii 2.1 for airplane it is one of the hack that I did.

When the throttle is zero, actually I make the error for the I term softly declining (using some destructing filtering, average like I = (I*0.9)+Error) , while in the with throttle over zero I don't make any filtering.

For instance if I want to do hand launch of an airplane, after arming, I don't want it keep the control surfaces for force to go back to the position that was at arm time, still I want the error go away in few seconds, and still I want to have some I support when gliding at zero power.

These are easy hack that can be add on MultiWii in no time ... I guess being specific airplane mode, maybe in name of a clean code these little tuning has not been done on the main stream

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

Re: Release v2.3 is coming soon... prepare

Post by crashlander »

e_lm_70 wrote:For instance if I want to do hand launch of an airplane, after arming, I don't want it keep the control surfaces for force to go back to the position that was at arm time, still I want the error go away in few seconds, and still I want to have some I support when gliding at zero power.

In my yesterdays tests I did not noticed any issues with completely disabled I term zeroing. Usually I hand launch my wing in HORIZON mod, and glide with zero TH is really smooth and stable that way.
Your solution sounds same as TPA but for zero TH. Right?

Regards
Andrej

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

Re: Release v2.3 is coming soon... prepare

Post by Alexinparis »

iosonologio wrote:Baro signal has some aliasing (i.e.: two successive points with the same value), that happens really often (every 3-5 points). Since the signal in Multiwii (when on cable) is updated at around 3Hz, i think there might be a bigger underlying problem. Please notice that only baro seems to have this issue, while gyro signals are smooth.

Did anybody see the same?


because baro signal is not updated internally so fast.
See Baro_update() function and you will see you can't expect a new value sooner than 20ms after the previous one.

iosonologio
Posts: 13
Joined: Sun Sep 22, 2013 5:46 pm

Re: Release v2.3 is coming soon... prepare

Post by iosonologio »

Alexinparis wrote:because baro signal is not updated internally so fast.
See Baro_update() function and you will see you can't expect a new value sooner than 20ms after the previous one.


I agree on Baro being updated every 20ms.
But signal in multiwii config is received only every 300ms or so (please correct me here). It should not see any aliasing unless the baro signal is updated slower than that. (I noticed that also while sampling baro values from matlab, at really precise reading times ~500ms).
I might have some time today to dig deeper.

quadflyer8
Posts: 7
Joined: Tue Jun 26, 2012 8:57 am

eeprom save in "GUI Settings" page problem

Post by quadflyer8 »

have tested in R1573 and right now in R1604 to save in the GUI "Settings page" some values.

First, i found VBATscale was not saved, but then tried other "green" values in this page:
Mintrottle / vbatscale / MAG DECL and none of them was sucessfully saved with write after changed.

After a powerdown and repower, the old values are shown in this page.
All other stuff on first multiwii GUI Page were sucessfully saved.

Have done a complete eeprom clean with Arduino sketch to verify...

using Arduino IDE 1.05 / R1604 / Promini / 328p...
cu, Michael

ttcorse
Posts: 17
Joined: Sun Feb 03, 2013 7:53 am

Re: Release v2.3 is coming soon... prepare

Post by ttcorse »

still not solved the problem with Crius aiop v1.1 and CN-06 GPS Receiver V2.0, does not recognize the GPS and the LED remains fixed access only after resetting "card powered" recognizes and executes the GPS fix .

scrat
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

Re: Release v2.3 is coming soon... prepare

Post by scrat »

ttcorse wrote:still not solved the problem with Crius aiop v1.1 and CN-06 GPS Receiver V2.0, does not recognize the GPS and the LED remains fixed access only after resetting "card powered" recognizes and executes the GPS fix .


I have had the same config like you. MWii 2.2 GPS was working every time.

ttcorse
Posts: 17
Joined: Sun Feb 03, 2013 7:53 am

Re: Release v2.3 is coming soon... prepare

Post by ttcorse »

scrat wrote:
ttcorse wrote:still not solved the problem with Crius aiop v1.1 and CN-06 GPS Receiver V2.0, does not recognize the GPS and the LED remains fixed access only after resetting "card powered" recognizes and executes the GPS fix .


I have had the same config like you. MWii 2.2 GPS was working every time.


With 2.2 I had no problems, now is a bit uncomfortable reset every time because I also the canopy to protect all the eletrônica and every time I have to take it apart.

User avatar
haydent
Posts: 583
Joined: Sun Jun 17, 2012 1:35 am
Location: NSW, AU

Re: Release v2.3 is coming soon... prepare

Post by haydent »

hope its not too late to squeeze this into 2.3, but here is a patch to add amperage display to the GUI

viewtopic.php?p=42892#p42892

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

Re: eeprom save in "GUI Settings" page problem

Post by Alexinparis »

quadflyer8 wrote:have tested in R1573 and right now in R1604 to save in the GUI "Settings page" some values.

First, i found VBATscale was not saved, but then tried other "green" values in this page:
Mintrottle / vbatscale / MAG DECL and none of them was sucessfully saved with write after changed.

After a powerdown and repower, the old values are shown in this page.
All other stuff on first multiwii GUI Page were sucessfully saved.

Have done a complete eeprom clean with Arduino sketch to verify...

using Arduino IDE 1.05 / R1604 / Promini / 328p...
cu, Michael


Hi,
I also have this problem on some of my 328p boards (not all).
there is apparently a problem with NO_FLASH_CHECK
activate #define NO_FLASH_CHECK and it should be good after a proper reset.

PatrikE
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: Release v2.3 is coming soon... prepare

Post by PatrikE »

Code: Select all

#define OPENLRSv2MULTI  // OpenLRS v2 Multi Rc Receiver board including ITG3205 and ADXL345

Don't compile after .cpp/.h change.

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

Re: eeprom save in "GUI Settings" page problem

Post by Hamburger »

Alexinparis wrote:I also have this problem on some of my 328p boards (not all).
there is apparently a problem with NO_FLASH_CHECK
activate #define NO_FLASH_CHECK and it should be good after a proper reset.


my test case:
compile & upload,
run gui,
reconnect,
read,
change pid value to 17,
write,
read (pid value should be 17),
exit gui,
run gui,
reconnect,
read - observe pid value: should be 17, not default value <-- this fails

this works:

Code: Select all

//#define NO_FLASH_CHECK
//#define MULTIPLE_CONFIGURATION_PROFILES


this does not work: (after power cycle/board reset the pid value is back to default)

Code: Select all

//#define NO_FLASH_CHECK
#define MULTIPLE_CONFIGURATION_PROFILES

quadflyer8
Posts: 7
Joined: Tue Jun 26, 2012 8:57 am

Re: eeprom save in "GUI Settings" page problem

Post by quadflyer8 »

Hamburger wrote:
Alexinparis wrote:I also have this problem on some of my 328p boards (not all).
there is apparently a problem with NO_FLASH_CHECK
activate #define NO_FLASH_CHECK and it should be good after a proper reset.

this works:

Code: Select all

//#define NO_FLASH_CHECK
//#define MULTIPLE_CONFIGURATION_PROFILES

Thanks Alexinparis and Hamburger, I will try this #defines.
cu,
Michael

Post Reply