MultiWii

Posted: **Mon Apr 01, 2013 11:09 am**

Hi, Kataventos!

Concerning the Frsky RSSI PWM there is a simple method i use with minimosd and my apm by using the Miso Pin ( http://diydrones.com/xn/detail/705844:Comment:970255 ). So no extra hardware is required, the signal is already digitally encoded. No need to make it analog and than resample it.

Code: Select all

  
    #define RSSIPIN 12              // Miso Pin
Setup:                pinMode(RSSIPIN, INPUT);
    
Readout with timeout: pulseIn(RSSIPIN, HIGH,500)

I am planning to use minimosd as well for mwii. Is it really neccessary with your software to connect RX and TX of minimosd? Minimosd on apm only needs RX because it is not supposed to send stuff. So if i just want the osd to display mwii data (and not configure mwii with osd) the RX line should be sufficient as well?

Cheers
Kraut Rob

Posted: **Mon Apr 01, 2013 11:49 am**

Crashpilot1000 wrote: Is it really neccessary with your software to connect RX and TX of minimosd? Minimosd on apm only needs RX because it is not supposed to send stuff. So if i just want the osd to display mwii data (and not configure mwii with osd) the RX line should be sufficient as well?
Kraut Rob

OSD uses MSP for communication with main controller and since MSP is meant to be challenge/response like you really need to send query to controller to get data back.

Regards Andrej

Posted: **Mon Apr 01, 2013 12:28 pm**

Thanks crashlander, you are right!

Posted: **Mon Apr 01, 2013 8:39 pm**

MinimOSD 0.345 on long range mission 2200m MWC 2.2 tricopter. I need the fix for HOME arrow Bug. Thanks.

http://www.youtube.com/watch?v=8QNTsWyZ6xo

Using FrSky RSSI with LPF filter R=100K, C=4u7. I don't like the latency of RSSI filter, way too smooth to reflect reality and also has abnormal behaviour on lost signal- it jumps to 100% suddenly then go to 0.

Posted: **Mon Apr 01, 2013 9:17 pm**

dramida wrote:MinimOSD 0.345 on long range mission 2200m MWC 2.2 tricopter. I need the fix for HOME arrow Bug. Thanks.

http://www.youtube.com/watch?v=8QNTsWyZ6xo

Using FrSky RSSI with LPF filter R=100K, C=4u7. I don't like the latency of RSSI filter, way too smooth to reflect reality and also has abnormal behaviour on lost signal- it jumps to 100% suddenly then go to 0.

Good flight,
This is important for KV team OSD,
IMHO:
The climb rate indication it's very accurate.
Speed, distance and altitude seems working good.
In Statistics page after disarming, all data seems Ok, only the trip appear a little bit not accurate 2200mt x 2= must be 4400 mt, the trip calculation give about 4700 mt (not so bad), this is due to integration of GPS speed. I can confirm that in case of trip done with almost constant speed the calcs are accurate, but in case of a fast changes in speed (acro flight) the trip calcs are completely bad. This is due to the latency of speed informations received on OSD.

About Home arrow, I saw a not bad indication, please explain better.

Thanks very much
Carlo

Posted: **Mon Apr 01, 2013 9:39 pm**

Crashpilot1000 wrote:Hi, Kataventos!

Concerning the Frsky RSSI PWM there is a simple method i use with minimosd and my apm by using the Miso Pin ( http://diydrones.com/xn/detail/705844:Comment:970255 ). So no extra hardware is required, the signal is already digitally encoded. No need to make it analog and than resample it.

Yep, I have already wrote about that on other topic here in forum, no problem, we can implement that easy for next release using PWM

Cheers,
KV

Posted: **Mon Apr 01, 2013 9:40 pm**

Crashpilot1000 wrote:Thanks crashlander, you are right!

Yep... Crashlander is right, no way to work around that :ugeek:

Posted: **Mon Apr 01, 2013 9:51 pm**

dramida wrote:MinimOSD 0.345 on long range mission 2200m MWC 2.2 tricopter. I need the fix for HOME arrow Bug. Thanks.

Using FrSky RSSI with LPF filter R=100K, C=4u7. I don't like the latency of RSSI filter, way too smooth to reflect reality and also has abnormal behaviour on lost signal- it jumps to 100% suddenly then go to 0.

Hi Dramida,

I did not saw your video but I will later, the thing is that for an "electronic´s" man you should already have seen what is causing that and not blame on the code...
Get your multimeter and take a look to what happens to the values when measuring more then one analogue reading... that and to what happens when you turn off your TX, I have talked about that on other topic (I will edit and link it here later).

Anyway this is already fixed on latest development of Multiwii, go check, update and you will be OK

KV

Posted: **Mon Apr 01, 2013 10:05 pm**

carlonb wrote:This is important for KV team OSD,
IMHO:
The climb rate indication it's very accurate.
Speed, distance and altitude seems working good.
In Statistics page after disarming, all data seems Ok, only the trip appear a little bit not accurate 2200mt x 2= must be 4400 mt, the trip calculation give about 4700 mt (not so bad), this is due to integration of GPS speed. I can confirm that in case of trip done with almost constant speed the calcs are accurate, but in case of a fast changes in speed (acro flight) the trip calcs are completely bad. This is due to the latency of speed informations received on OSD.

About Home arrow, I saw a not bad indication, please explain better.

Thanks very much
Carlo

Hi Carlo,

no need to change your previous work on the statistics TRIP, it is the most accurate we can using the GPS Speed I have made plenty of test´s before this last release.

Test consisted in going far as 800m one (or two times) come right back and disarm, normally I see a difference of 9m to 15m or so... We can not have a more accurate reading using this method but, it is damn good I should say

Cheers,
KV

PS: I have some new ideas that will dicuss with you tomorrow (no way to chat today) about this matter using "distance to home".

Posted: **Mon Apr 01, 2013 11:15 pm**

Hi Guys,
First of all i would like to thank you, im really happy that the development of the OSD is still alive :-)

really great work from all of you!

To give you a quick update on the "OSD shows nothing after the update" problem reported by KasparsL and KoekieMonster, the clear EEPROM solution mentioned below solved it.
Running a Rushduino OSD v1.2, i did the update to dev345 from KV 2.1. As it was not working, i reloaded KV 2.1 again and i had a picture on video out. Update to dev345 and again no Gui response and no video output. :cry:

So i decided uploaded the eeprom_clear.ino and then the dev345. After the OSD booted i had an picture straight away.

howardhb wrote:Maybe the Atmega's EEPROM needs to be cleared completely first. (this is a known issue, reported before)

To do this, up-load the Arduino sketch: Arduino\Files\Examples\EEPROM\eeprom_clear.ino

Then re-load KV_Team_OSD sketch.

H.

Cheers
Stéphane

Posted: **Tue Apr 02, 2013 12:10 am**

Great to hear Stéphane

as the KV Team OSD evolves, we are adding and moving the settings around in the eeprom. for some reason, we are having issues with some boards having the wrong settings in the eeprom addresses. When ever there is an issue users should perform the eeprom clear function.

We will see what I can do in the next release to add the same function as the clear ino to the core of the KV OSD firmware. This should solve the issues that some people are having.

Thanks for using the OSD and we hope you have a great time with it.

Ross

Posted: **Wed Apr 03, 2013 8:58 am**

Hi,
I have nearly everything up running. Only the current will not show up. the accumulated current is counting up and the vbat is shown correctly, but the currently used amps are always at 0.0mAh.

Here is a "schematic" of my setup (I still have to tweak the powermeter settings):

Am I missing something? Do I have to config something in the GUI?

Thanks in advance for any help!

Posted: **Wed Apr 03, 2013 2:36 pm**

shackfu wrote:Hi,
I have nearly everything up running. Only the current will not show up. the accumulated current is counting up and the vbat is shown correctly, but the currently used amps are always at 0.0mAh.
Am I missing something? Do I have to config something in the GUI?

Thanks in advance for any help!

Hi shackfu,

great draw you have here

No you are not missing anything, instant consumption will only be shown if you had the current sensor connected to your OSD using the wiki mods and enabling the OSD ADC on OSD GUI.
I should advise you to connect your OSD on other serial then zero, because that way you will need to unplug it every-time you need to upload new MW code or to connect the FC to the MW GUI.
(e.g) I have OSD on Serial 1, GPS on Serial 2, and "other" on Serial 3.

Cheers,
KV

Posted: **Wed Apr 03, 2013 2:46 pm**

kataventos wrote:(e.g) I have OSD on Serial 1, GPS on Serial 2, and "other" on Serial 3.

Sorry, to jump in. I'm currently trying to do just that myself with my Crius AIOP v2 with no success so far. Is there some multiwii (I'm on 2.2) config that needs to be set or are all serials active on a mega by default?

P

Posted: **Wed Apr 03, 2013 3:03 pm**

trufy wrote:
To give you a quick update ... the clear EEPROM solution mentioned below solved it.
So i decided uploaded the eeprom_clear.ino and then the dev345. After the OSD booted i had an picture straight away.

howardhb wrote:Maybe the Atmega's EEPROM needs to be cleared completely first. (this is a known issue, reported before)

To do this, up-load the Arduino sketch: Arduino\Files\Examples\EEPROM\eeprom_clear.ino

Then re-load KV_Team_OSD sketch.

H.

Cheers
Stéphane

Hi Stéphane and welcome

after reading your post and taking the other post´s in extreme account, decided to upload the EEPROM clear.ino to the repo and add a note on the wiki page for future user´s.
Now, a big thank you for you appreciation/consideration

Cheers,
KV

Posted: **Wed Apr 03, 2013 3:13 pm**

TextZombie wrote:... Is there some multiwii (I'm on 2.2) config that needs to be set or are all serials active on a mega by default?

P

Hi,
they are enabled by default

Code: Select all

 /******                Serial com speed    *********************************/
    /* This is the speed of the serial interfaces */
    #define SERIAL0_COM_SPEED 115200
    #define SERIAL1_COM_SPEED 115200
    #define SERIAL2_COM_SPEED 115200
    #define SERIAL3_COM_SPEED 115200

What is the problem you have? Do not forget TX to RX and vice versa...

Cheers,
KV

Posted: **Wed Apr 03, 2013 4:03 pm**

Why do You guys think, that writing '0' (0x00) to the EEPROM is erasing it??? If the empty erased EEPROM contains "255" (0xFF) at each address! :evil:

Actually program memory also is "0xFF" when erased by programmer!

Posted: **Wed Apr 03, 2013 5:10 pm**

Thank you KasparsL for your input. We are not erasing the memory, we are "clearing" it. as denoted by the name of the Arduino example file, eeprom_clear.ino. It does not erase the epprom, it simply clears, or sets all addresses to 0. Then the OSD code can see that it needs to "reinstall" the default settings.

Posted: **Wed Apr 03, 2013 5:40 pm**

power67 wrote:Thank you KasparsL for your input. We are not erasing the memory, we are "clearing" it. as denoted by the name of the Arduino example file, eeprom_clear.ino. It does not erase the epprom, it simply clears, or sets all addresses to 0. Then the OSD code can see that it needs to "reinstall" the default settings.

Don't get me wrong - I am Trying to explain that there is default values for AVR microcontrollers memories (and others) and which is 0xFF. So why to make other sketch to "adapt" the EEPROM for firmware, if the firmware can be made right and check for default empty 0xFF value.

Posted: **Wed Apr 03, 2013 5:52 pm**

kataventos wrote: they are enabled by default

Just knowing that allowed me to work it out thank you.

Looks like I had my serial port numbers confused and had the wrong baud rate configured, but kept ignoring it because I didn't think it was the one I was connected to. So instead of checking the simple stuff I set about deciphering the serial code to try and work out what config option I'd missed to turn it on! Ah well, another 4 hours sacrificed on the altar of schoolboy errors

Thanks again.

KasparsL wrote:Don't get me wrong - I am Trying to explain that there is default values for AVR microcontrollers memories (and others) and which is 0xFF. So why to make other sketch to "adapt" the EEPROM for firmware, if the firmware can be made right and check for default empty 0xFF value.

I think the point is that these devices tend to ship with some other software on them already rather than as blank (mine did), and variables stored in eeprom when shipped could potentially cause problems therefore clearing is a good idea.

P

Posted: **Fri Apr 12, 2013 11:03 am**

Hi guys , quick question here.

By looking at your scheme here: http://code.google.com/p/rush-osd-devel ... dware_Mods

I see you send the 3.3v sensor/rssi range to the adc input trought just a 1kohm resistor.

This is not supposed to drop down voltage under 1.1v isn't it ?

By checking the code you use the Internal 1.1v Aref voltage. This looks a bit suspicious to me, do you consider sensors already output 1.1v range on your scheme ?

Thanks.

Posted: **Fri Apr 12, 2013 2:15 pm**

Impossible to cover all scenrios with good resolution.

It is same for monitoring bat voltage. Max is 1.1v, but my boards drop it to about 3.3v - so have to amend the code.

Actaully - KV team

could you put a #define in config or add to GUI?
option to coose:
analogReference(INTERNAL);
analogReference(DEFAULT);

I'm happy to change mine each time , but I know some others are less comfortable.

Posted: **Fri Apr 12, 2013 3:15 pm**

shikra wrote:Impossible to cover all scenrios with good resolution.

It is same for monitoring bat voltage. Max is 1.1v, but my boards drop it to about 3.3v - so have to amend the code.

Actaully - KV team

could you put a #define in config or add to GUI?
option to coose:
analogReference(INTERNAL);
analogReference(DEFAULT);

I'm happy to change mine each time , but I know some others are less comfortable.

Hi Shikra,

OK, no problem with that. 2.2 will be out soon with that option, PWM option for RSSI and some more stuff!

Cheers,
KV

PS: Check out: http://www.youtube.com/watch?v=RK-wNWUgqfk

Posted: **Fri Apr 12, 2013 3:33 pm**

Yes I think using Default ( 5v) analogReference is far sufficient for 3.3v output range considering the resolution loss is not really problematic with the informations we needs.

Perhaps it would be more secure to default it to Default and not Internal. Some peoples will plug their 3.3v following the Wiki scheme without understanding what they're doing, and burn their ADC input.

Posted: **Sun Apr 14, 2013 1:40 am**

Hi kipkool,

thanks, the option will be on GUI but it does not need to be default, user must know what he is using, besides you "will" only burn your ATmel with voltages higher then 5v.
I do not see any document on the WIKI pointing to failure of the user´s hardware.

Cheers,
KV

Posted: **Tue Apr 16, 2013 4:30 pm**

Hi Kv_Team.

When can i test another version of KV-osd? Actually i use dev_R345 from google repository.

I have all sensors onboard plus RSSI, Vbat and Curent. I usually fly long distance in fpv so OSD will be tested in real life situations.

Posted: **Tue Apr 16, 2013 10:09 pm**

dramida wrote:... I usually fly long distance in fpv so OSD will be tested in real life situations.

Ohhh... in that case, it will be much sooner :shock:

because everybody else here does not fly in real life situation, we call it other thing... But we really try to go "real life" when we fly!

Posted: **Tue Apr 16, 2013 10:49 pm**

Hi Guys,
Great project :!:

I'm new owner of that OSD board and now I'm learning how to configure it. I think I already understand most of features and more-less everything works as I want to, but I have one problem:
I'm using r345 and with my copter with MWi 2.2 the OSD doesn't show flying modes (triangle signs by ACC,BARO,MAG,GPS HOLD...) ARMED state and throttle value. The rest (main voltage and RSSI from MW, height, artifical horizont...) seems to work OK.
From the GUI simulator when "use boxnames" is active are working all features (even after OSD reboot) but with the same config with real copter flying modes again doesn't show up.
Can you tell me what I'm missing :?:

Thanks!
Roman

Posted: **Tue Apr 16, 2013 10:55 pm**

Hey Dramida...

an FPV pilot does not need to fly long range to lost him self, he just need to fly for the first time in one place go as high as 20m far as 200m and spin two times...
Well... I´m afraid that is why we all fly "real life situations" :lol:

Cheers,
KV

Posted: **Tue Apr 16, 2013 11:07 pm**

rbirdie001 wrote:...
From the GUI simulator when "use boxnames" is active are working all features (even after OSD reboot) but with the same config with real copter flying modes again doesn't show up.
Can you tell me what I'm missing
Thanks!
Roman

Hi rbirdie001,

use BOX ID´s, that does not suppose to happen anymore... did you checked box ID´s as well?

Cheers,
KV

Posted: **Wed Apr 17, 2013 1:45 pm**

Hi,

I have a question about MwRssi variable.
In Serial.ino in serialMSPCheck() function there is

Code: Select all

void serialMSPCheck(){
...
  if (cmdMSP==MSP_ANALOG)
  {
    MwVBat    = read8();
    pMeterSum = read16();
    MwRssi    = read16();
   
  }
...
}

but on GlobalVarialbes.h MwRssi is only 8 bit

Code: Select all

   uint8_t  MwRssi=0;

this can cause overflow ?

Thanks.

Posted: **Wed Apr 17, 2013 2:31 pm**

Hi EmmeDi8,

hey... thanks for pointing that

yes it can, don´t know how that happened :oops:

but it will be fixed for 2.2 release.

Have fun.
Cheers,
KV

Posted: **Wed Apr 17, 2013 9:27 pm**

kataventos wrote: use BOX ID´s, that does not suppose to happen anymore... did you checked box ID´s as well?
KV

Dear kataventos,
as I wrote, I'm quite new in Minim OSD and I don't understand difference between BOX ID's and BOXNAMES so I resume situation once more:
In my config, there is as default commented:

Code: Select all

 //#define USE_BOXNAMES              // Comment this line to use BOXIDS

In the GUI I have Use BoxNames active because without it the mode info ISN'T shown even with simulator.
My settings are here:

I first cleared EEPROM, then reflashed r345, configured like this, wrote and rebooted.

With the simulator my screen looks like this:

When connected to real MWi running 2.2 while MWi is ARMED and ACC+MAG+BARO are active, it still looks like this:

I didn't test GPS yet.
Do you have any idea, what I'm doing wrong?

P.S. I noticed one more strange thing:
I'm using RSSI via MWi. It works, but when the MWi gets into failsafe state, RSSI starts showing fluctuating crazy values. I think that it's known problem which is going to be solved, this is just to inform you!
Thank you!
Roman

Posted: **Wed Apr 17, 2013 9:39 pm**

Same questions here also , +1. I don't understand the difference between BoxID and BoxName

Posted: **Wed Apr 17, 2013 9:58 pm**

rbirdie001 wrote:In the GUI I have Use BoxNames active because without it the mode info ISN'T shown even with simulator.

Please turn Box Names off and save (simulator is one thing and the FC other)

After doing so, you will be OK.
I know that it creates some confusion , we will fix that for r 2.2 and explain it better on the WIKI.

rbirdie001 wrote:P.S. I noticed one more strange thing:
I'm using RSSI via MWi. It works, but when the MWi gets into failsafe state, RSSI starts showing fluctuating crazy values. I think that it's known problem which is going to be solved, this is just to inform you!
Thank you!
Roman

Yes, I have reproduced a similar issue and part of the problem was on MW code with simultaneous readings like VBAT, RSSI, and CURRENT. Hamburger started a thread about it for some time now and it is already fixed on Multiwii shared code, now the analogue readings are one channel per Multiwii main loop cycle and the ADCSRA speedup of the analog reads is disabled.

Tested and working just fine now.

Cheers,
KV

Posted: **Wed Apr 17, 2013 10:27 pm**

dramida wrote:Same questions here also , +1. I don't understand the difference between BoxID and BoxName

Box Names is no longer used and it will be removed.

Posted: **Wed Apr 17, 2013 10:38 pm**

kataventos wrote:Please turn Box Names off and save (simulator is one thing and the FC other) After doing so, you will be OK.
I know that it creates some confusion , we will fix that for r 2.2 and explain it better on the WIKI.

Yes, thanks, I did so and it works now!

I guess that BOX NAMES is the an old protocol and BOX ID's is the a new protocol. Simulator uses the old one and MWi 2.2 the new one so each of them needs different setting.
Do I understand it OK?
Roman

Posted: **Wed Apr 17, 2013 11:16 pm**

rbirdie001 wrote:Yes, thanks, I did so and it works now!
I guess that BOX NAMES is the an old protocol and BOX ID's is the a new protocol. Simulator uses the old one and MWi 2.2 the new one so each of them needs different setting.
Do I understand it OK?
Roman

Have fun,
KV

Posted: **Thu Apr 18, 2013 2:30 am**

Hi all,

I updated/edited the initial post of this topic to inform you and mostly new arrived guys of relevant information.

I just hope that it still make sense for the followed post´s made by you all, thank you for your collaboration and understanding, don´t forget to keep tuned :mrgreen:

Cheers,
KV

Please check: viewtopic.php?f=8&t=2918&p=28940#p28940

Posted: **Thu Apr 18, 2013 11:30 am**

a quicky... why does the board type keeps switching back to rush after "write"

it's he one called jumbo osd v 0.1 minim osd clone i believe
thx

Posted: **Thu Apr 18, 2013 2:08 pm**

a quicky... why does the board type keeps switching back to rush after "write"

This has been reported before....

Try first uploading Arduino example, eeprom_clear.ino
Then re-load KV_Team_MinimOSD.ino

Also, your board is not 100% compatible.....

On most MinimOSD clones, the MAX7456 has its own RESET line wired from Atmega PortB, Bit2 (Arduino Digital Pin 10)
The "Jumbo" board does not have its own RESET line, it simply shares the Atmega's RESET line, which is also connected to FTDI connectors DTR pin (Data Terminal Ready) via a capacitor.
I'm not sure if this is a problem because that RESET line is only ever driven HIGH once, during MAX7456Setup(), called once from setup().
In MAX7456Setup() you could try increasing delay(250) to delay(500).

So, pressing RESET in the GUI will not reset your MAX chip, only your Atmega will reset. This might cause problems, especially Uploading a new character map.....
I suggest that you power your OSD down/up after uploading....
(You could edit the GUI (in Processing) and make the DTR line toggle when the RESET button is pressed..... )

Oh, and your board does not have an LED connected to Digital pin 7. Not serious though.....

H.

Posted: **Fri Apr 19, 2013 2:31 am**

thanks for the help
it was from long time ago... dont even remember how did i get it... just wanna try to do some fpv recently... so I thought why not just use it... i'll try it out and see how it eventually works out

thanks again

Posted: **Mon Apr 22, 2013 4:33 pm**

Hello,

i use multwii with serial GPS on a promini. Can i use minimosd with kvteam firmware also with serial GPS ?

Kayle

Posted: **Mon Apr 22, 2013 4:36 pm**

No - sorry.
Buy cheap I2C/serial converter from RCt or similar. Seems to run a bit better in my early tests too...

Posted: **Mon Apr 22, 2013 5:09 pm**

Hi,

Thanks for your answer. The Problem with the i2c GPS is that rth doesn't work over 650m distance. :sad:

Kayle

Posted: **Mon Apr 22, 2013 6:49 pm**

Ah - not many go that far with a copter. I recall the posts. what happen s- doe sit work, but misreport? Might be worth a look.
Tested mine at 500m they other day. Worked great - came home straight, level and under control, but it did not hold the copter direction - forward was pointing the wrong direction by the time it came home - but still the RTH worked perfect. Maybe it selects heading only at start and does not keep. Must ask EOSB.

Posted: **Tue Apr 23, 2013 10:04 pm**

@Shikra

That is a known problem unfortunately, the copter direction accuracy but more the arrow pointing home. Note: I do not have 45º problems like some are having, just small difference and just sometimes.
I spent many time scratching my head with that, changed the code for 3 times now and it seems better but... always with doubts (why do I have to change what is notorious correct?)
and (why do I only see a problem from time to time and in such particular conditions?) like when tilting (not in all directions heading).

Well, started trying to figure about it on MWii code and a better way to calibrate my MAG witch is a (HMC5883L). Got even better result using a slightly different routine because this sensor in particular have a difference of about 7% on Z axis so... after all this and still not seeing what I wanted to, found this post : viewtopic.php?f=8&t=3451#p35149 Paulmann pointed exactly what the problem is

Anyway the heading code on KVT r345 will be the same on next release (2.2), we just hope that Alex fix the problem on MW code soon as well.

NOTE to all: If you are having this heading problem and decide to use the code on the post, be aware of cycletime when using a 328 based board.

Have fun and fly safe!
KV

Edit: And please make sure that your MAG is clear of ESC´s and other magnetic fields eventually... because this will really mess with accuracy!

Posted: **Tue Apr 23, 2013 11:48 pm**

Actually OSD is good... points correct for me. Now I have mag sensor orientation correct !
It is just that the copter gradually yawed around maybe 120 degrees during the RTH by time it arrived. Slightly unnerving.
Try calibrating around inclination axis.. I find that makes mine much more accurate....Someone posted about it previously and I saw significant improvement when tried.

Posted: **Wed Apr 24, 2013 12:40 am**

@Shikra,

about the Mag... yep, you probably have read the same post as I...
I am in Europe so normally I calibrate with the copter facing the ground 45º. Z and Y axis start/pointing North then point East for X.

Great that you have no problems with the OSD what version are you using? r345 or my last changes on repo?
And about the MW code, 2.2 or recent?

Posted: **Wed Apr 24, 2013 9:20 am**

Cheers KV
yep - thats how I do it to! Funny - I thought you were in US for some reason. Its about 40 deg here in Wales
r345 with 2.2. working great. Only change I made is to only leave volts, flight time and an arrow only on bottom line when osd switch is on. Absoloutely perfect for me...!
Sometimes I want to see all the info, but twice I missed the low volts.... never happened in long long time until started flying with all the stuff on the screen so was thinking maybe I'm not noticing it with all the moving info.

MultiWii

KV Team Multiwii OSD

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

AW: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd

Re: SW Development on Minim Osd