KV Team Multiwii OSD

mysku82 · Post by **mysku82** » Wed Mar 13, 2013 10:38 am

Hello
I have a problem with the video voltage, voltage not show me, on MinimOSD
I respected exactly "hardware mods".
It's a software bug?

Thanks

KasparsL · Post by **KasparsL** » Wed Mar 13, 2013 6:09 pm

kataventos wrote:Question: What had you installed on them before KVTeam firmware?
Cheers,
KV

The first was Rushduino v2.1 firmware. But as mentioned, I did not realize, that this minimOSD board had bootloader form factory pre-installed. So first time I programmed it with ARVISP programmer - deleting the bootloader and, probably, clearing the eeprom.

dramida · Post by **dramida** » Fri Mar 15, 2013 12:35 am

I fley with MinimOSD 345 and i am not happy with Home Arrow. I took off from gas station near the road. Please observe the offset of the home arow at 4:53. The gas station is in left, near the road and the home arrow points right. This behaviour happen only when moving, if i stand still in PH, the Home arrow is good. See the GPS pos Hold and the good arrow, and when ai disengage the GPS PH, the arrow shifts to right guiding me in a wrong way.

The video with the minute specified is here: http://youtu.be/doEWDyIfp1I?t=4m53s

p.s.
Battery voltage works fine if is read from MWC, no need to mood your osd hardware, Mysku call me to debug your setup.

kataventos · Post by **kataventos** » Fri Mar 15, 2013 12:48 am

dramida wrote:I fley with MinimOSD 345 and i am not happy with Home Arrow...

Hi, as I said before the arrow was not good but, I have already fixed it for the next release.

KV

kataventos · Post by **kataventos** » Fri Mar 15, 2013 12:51 am

mysku82 wrote:Hello
I have a problem with the video voltage, voltage not show me, on MinimOSD
I respected exactly "hardware mods".
It's a software bug?

Thanks

Hi,
what is your problem? Please describe in detail... not shown can be lots of stuff

Software was tested for analogue inputs and no bug found.

KV

kataventos · Post by **kataventos** » Fri Mar 15, 2013 12:53 am

KasparsL wrote:The first was Rushduino v2.1 firmware. But as mentioned, I did not realize, that this minimOSD board had bootloader form factory pre-installed. So first time I programmed it with ARVISP programmer - deleting the bootloader and, probably, clearing the eeprom.

...

kataventos · Post by **kataventos** » Fri Mar 15, 2013 1:11 am

To all,

it was "discussed" here before about the RSSI on MINIM OSD and now on MW_FC board using the FRSky receivers that only output PWM signal (Pulse with modulation).
The analogue inputs from both boards need a constant voltage reading, and for this you need a low pass filter.

I modified the available FRSky.com draw to the correct R and C values.

From the receivers RSSI output feed it to a 10KOhm resistor. At the other end of the resistor, connect it it a 47uF capacitor whose other end goes to GND.
From resistor/capacitor joint, add an 1kOhm resistor and from that go to the analog input on you MW FC. Some site´s explaining the usage of the low pass filter do not add the 1k resistor but, it prevents the capacitor from emptying its charge into your flight control or OSD port too fast when the system is powered off.

Hope this help you guys.

Cheers,
KV

dramida · Post by **dramida** » Fri Mar 15, 2013 1:18 am

kataventos wrote:
dramida wrote:I fley with MinimOSD 345 and i am not happy with Home Arrow...

Hi, as I said before the arrow was not good but, I have already fixed it for the next release.

KV

Thanks alot Kata, this OSD is Awsome!

I didn't saw your previous post.

You should also double check the vertical speed indicator as i have footage in which the baro altitude stays constant on the left but the vertical speed is -3m/s for a while.
And BTW, R2 is not needed as the input impedance of analog ports of atmega is much higher (MegaOhm) so R2 is neglijable.
For R-C filter i am using 4u7 with 100k SMD, all wraped in a shrink tube. The 47 uF is a little bit larger and takes more space so i preferred the 4.7 capacitor.

kataventos · Post by **kataventos** » Fri Mar 15, 2013 1:37 am

dramida wrote:R2 is not needed as the input impedance of analog ports of atmega is much higher (tens of MegaOhm) so R2 is neglijable.
For R-C filter i am using 4u7 with 100k SMD, all wraped in a shrink tube. The 47 uF is a little bit larger and takes more space so i preferred the 4.7 capacitor.

Well, both ways should work just fine anyway, some of the guy´s do not find such parts in regular electronic stores neither the skills to solder them together, and with the ones above they should have no problem on both, they too fit in a heat shrink small tube, just not so small as yours

The R2 was thinking on more then just MEGA Boards...
I will inclusive add this to the repository wiki for some guys that like the MINIM mods and others with DIY OSD´s running with same type of connections as the ones we support at this time (Minim and Rush).

Cheers,
KV

kataventos · Post by **kataventos** » Fri Mar 15, 2013 1:55 am

dramida wrote:
You should also double check the vertical speed indicator...

OK, I will pay attention to that on next flight´s :roll:

KV

dramida · Post by **dramida** » Fri Mar 15, 2013 10:19 pm

I rewatched the flight and here you can see abnormal behaviour shown on OSD, regarding vertical speed in relation to barometric altitude:

http://youtu.be/doEWDyIfp1I?t=1m32s ( from min1.32 on left altitude is rapidly increasing from 133 to 140m but the vertical speed shows 0) :!:

http://youtu.be/doEWDyIfp1I?t=1m58s ( from min 1.58 to 2.07 the altitude stays constant but vertical speed shows -1 or -2m/s) :shock:

http://youtu.be/doEWDyIfp1I?t=2m11s (from min 2.11 to 2.15 the vertical speed is negative but altitude increases from 137 to 140m) :shock:

etc.....

carlonb · Post by **carlonb** » Fri Mar 15, 2013 11:06 pm

dramida wrote:I rewatched the flight and here you can see abnormal behaviour shown on OSD, regarding vertical speed in relation to barometric altitude:

http://youtu.be/doEWDyIfp1I?t=1m32s ( from min1.32 on left altitude is rapidly increasing from 133 to 140m but the vertical speed shows 0)

http://youtu.be/doEWDyIfp1I?t=1m58s ( from min 1.58 to 2.07 the altitude stays constant but vertical speed shows -1 or -2m/s)

http://youtu.be/doEWDyIfp1I?t=2m11s (from min 2.11 to 2.15 the vertical speed is negative but altitude increases from 137 to 140m)

etc.....

Hi Dragu,
Yes, I saw the issue, but looking at OSD code I really do not understand...the code only convert with the selected units (Metric/Ipmerial) the vertical speed (vario) received from MWii serial port and show it on screen.
My opinion is that the vario speed is not correctly calculated as I saw also that the vertical speed is strongly influenced if the copter is fliyng flat at high speed (I've not yet tested last MWii vers. 2.2).
I think that the vario calcs must involve all acc axis, may be with last MWii vers. 2.2 it's solved, I need to verify this.
Ciao
Carlo

KasparsL · Post by **KasparsL** » Sat Mar 16, 2013 2:27 pm

I have noticed one closing bracket, before ''displayCursor();", missing in latest "screen.ino" file (rev: r08b3574de1f5, 12.03.2013). Without it, the code will not compile.

Code: Select all

    MAX7456_WriteString(itoa(temperMAX,screenBuffer,10),MAGD-3);
  }
  displayCursor();
}

kataventos · Post by **kataventos** » Tue Mar 19, 2013 1:06 pm

@ KasparsL

Yep

I have made some cleaning to the code and accidently deleted it! Sorry for not replying earlier but I am with lot´s of work and preparing myself for the vacations starting tomorrow :mrgreen:

Carlo have already fixed it on the repo.

To all,

does anyone use temperature meter? if yes, are the readings correct?

Thanks.
Cheers,
KV

kataventos · Post by **kataventos** » Tue Mar 19, 2013 1:16 pm

dramida wrote:you can see abnormal behaviour shown on OSD, regarding vertical speed in relation to barometric altitude...

Hi,

already checked and there is nothing wrong with the OSD code regarding this supposed "issue". The OSD only displays what MW FC sends.
I was not able to reproduce it until now! I will make a dev demo video during this vacations week.

KV

carlonb · Post by **carlonb** » Tue Mar 19, 2013 6:05 pm

kataventos wrote:@ KasparsL

..... preparing myself for the vacations starting tomorrow
....
Cheers,
KV

Hi Enrique,
Have a nice vacation,

, hope you came back soon :mrgreen:

Ciao

kataventos · Post by **kataventos** » Thu Mar 21, 2013 4:17 pm

Hi,

this is the test video description:

"Just a flight test with r345 and MW 2.2. Sorry for the vibes but it needs to be better tuned, as well as some ball bearing change also!

There are issues that need to be figured and they are not with the OSD code, I found the out almost the same problem with the home arrow indicator even after I coded a new formula, the only way to see if this is what I think it is, is to downgrade MW version to r1240 used for first developments because the issue was not there, the other way is to when I see this coming (wrong home indication) make a return home and see the drone and arrow behavior, this is the way to start debugging because the simulator does not lie if you know what I mean... The tool is there, you just need to use it

As for AH (because of temperature I think, need to calibrate all sensors on the field on next flight) is not correct with the real movements after some time flying and in some "rare" conditions. If you experience this issue, it is too, coming from the flight control board and have nothing to do with the OSD code because, if you drop the sticks the drone will drift and AH is correct and leveled so, "it thinks that is leveled".

This can sound strange but, the direction facing will influence on this too as well as the home direction arrow.
(e.g) depending on the direction they can change behavior!?

This issues were acquired during this first flight test with both latest developments and they need to be reproduced again by me and the entire KV Team so we can confirm them.

Fly safe.
Cheers,
KV "

Video: http://www.youtube.com/watch?v=KkMsvyXO ... e=youtu.be

Peter · Post by **Peter** » Fri Mar 22, 2013 10:28 pm

Testing r345 I noticed that my voltage is 0.3volt higher than the voltage in the multiwii GUI. Do I also need to tune the voltage display in the osd?
Is it possible to read main and video voltage from mw?
Why is there a GPS alt field? Can it be disabled?
It would be nice to have a percentage for main battery.

Don't get me wrong, I really like the software, thanks!

dramida · Post by **dramida** » Fri Mar 22, 2013 11:25 pm

I'll activate RTH when i will notice wrong arrow direction. Until now i observed that when stationary, home arrow is good.

Here is MinimOSD V0.345put to the test over the city in a photo shooting FPV session:

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

I have some doubts about RSSI indicator, some times when i shut down the transmitter, RSSI gows unexpectedly for a second to 100% then drops to 0. (using Frsky receiver with latest D8R-XP software)

Best regards,
Mihai

carlonb · Post by **carlonb** » Sat Mar 23, 2013 5:33 pm

dramida wrote:I'll activate RTH when i will notice wrong arrow direction. Until now i observed that when stationary, home arrow is good.

Here is MinimOSD V0.345put to the test over the city in a photo shooting FPV session:

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

I have some doubts about RSSI indicator, some times when i shut down the transmitter, RSSI gows unexpectedly for a second to 100% then drops to 0. (using Frsky receiver with latest D8R-XP software)

Best regards,
Mihai

Hi Mihai,
Thanks for your vid, is very useful for KV team OSD.
I saw almost all data are shown correctly.
Climb rate appear very good, when the copter is in alt-hold, this show 0mt/sec, when is rising or descending show almost good values related to altitude indicator (baro, not GPS alt).
Only a big dubt is about trip on statistics after land, 1507 mt appear too big, I don't think you run 1500mt, may be the actual calculation of trip it's not so accurate (integration of MWii GPS speed). We need to find a new algorithm to calc it.

Ciao, Carlo

power67 · Post by **power67** » Wed Mar 27, 2013 7:33 am

Wow, over 300 downloads and not a single donation...... you guys are a tough to please.
We realy want to make this the best OSD out there for the MultiWii, so if you like it, throw a dog a bone. with your help, it will be.

shikra · Post by **shikra** » Wed Mar 27, 2013 10:13 am

A million thanks and have a beer on me.... hopefully a few others will follow

howardhb · Post by **howardhb** » Wed Mar 27, 2013 10:57 am

Dunno how much your beer costs, but I just donated a couple... :!:

KoekieMonster · Post by **KoekieMonster** » Wed Mar 27, 2013 11:28 am

Would like to donate you a few beers if I get it going.
can get these ones going: http://code.google.com/p/rushduino-osd/
But KV_team_osd just outputs black screen (no cam connected). I have made my board like this: osd-multiwii using this schematic: schematic

Can anyone point me in the direction of where it is going wrong?

rotary65 · Post by **rotary65** » Wed Mar 27, 2013 11:34 am

Gesture of appreciation sent!

I am very encouraged by your progress and hope you continue your good work!

I removed an Eagle Tree OSD and a Dragon V2 OSD out of my two FPV multicopters to replace them with RCT minimOSDs running this firmware. One is on a Naze32/baseflight, the other on an AIO Pro1.0 running MWC. I'm still tweaking the power function on both (direct on the OSD on the Naze32 setup because Powermeter doesn't pass through on the MSP serial protocol implementation in baseflight yet).

I'm still waiting for the snow to melt here, but I should be able to do flight tests soon.

howardhb · Post by **howardhb** » Wed Mar 27, 2013 1:58 pm

KoekieMonster wrote:Would like to donate you a few beers if I get it going.
can get these ones going: http://code.google.com/p/rushduino-osd/
But KV_team_osd just outputs black screen (no cam connected). I have made my board like this: osd-multiwii using this schematic: schematic

Can anyone point me in the direction of where it is going wrong?

That schematic looks like a Rushduino.
Make sure you select RUSH in the GUI. Also, what type of camera, PAL or NTSC ?

Also, your schematic shows the LED connected to arduino digital pin 5, but in MinimOSD it is connected arduino digital pin 7.
So you will have to edit the Setup() function in KV_Team_OSD.ino

Code: Select all

void setup()
{
. 
.
.
  //Led output
  //pinMode(7,OUTPUT);
  pinMode(5,OUTPUT);
.
.
.

and in loop()

Code: Select all

  
.
.
// Blink Basic Sanity Test Led at 1hz
  if(tenthSec>10)
    digitalWrite(5,HIGH);
  else
    digitalWrite(5,LOW);
.
.

And another thing, your schematic shows a buzzer in the circuit.
KV_Team MinimOSD does not (at this time) support a buzzer, but you could hack the original buzzer code from:
https://code.google.com/p/osd-max7456-multiwii/downloads/detail?name=osd_max7456_multiwii_V1_1.zip&can=2&q=

Oh, and you MUST also upload the character map.

Hope this helps.

Howard.

KoekieMonster · Post by **KoekieMonster** » Wed Mar 27, 2013 3:59 pm

I believe it is a rushduino indeed, and I am very sorry, but I have allready tried the above things(I did not use the buzzer since my multiwii has one, I did move the LED to the right pin in the software) but, unfortunately there is something going wrong in the GUI connection I think, when I write the new settings and then read them again they reset to their default, what could cause this? the serial port is working fine when I upload the new character map(not through the GUI but by using this sketch: character upload sketch).
I am using a PAL camera btw.

Thanks for your help

howardhb · Post by **howardhb** » Wed Mar 27, 2013 4:12 pm

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.

power67 · Post by **power67** » Wed Mar 27, 2013 5:27 pm

KoekieMonster

I think it is great that you wish to implement the KV_Team_OSD on a custom board.

now let's see if we can get it to work for you.

a few things first.

1. If this hardware setup is correct and is a "clone" of the Rushuino, have you uploaded the original Rushduino code and been able to see anything?

2. Are you getting any default values when you perform a read in the GUI? other then all off and 0s ?

3. try the above suggestion, we have seen some none rush/minim Atmega EEPROMs have some strange data causing some issues.

4. The default values in the OSD code are for the rushduino board, you should not need to have to change anything through the gui to get something on the screen.
(unless something is different from the original rush hardware. in that case some code modification will be required, and that would be very difficult on our end as we do not have your custom board.)

5. Triple check your board for matching the schematic, it is easy to miswire a custom board like this. I even print the schematic out and highlight every trace on the page after checking. check the component values again as well. But, if your answer to question 1 is yes it works with the original Rush firmware, then we know you have the board hardware setup correct.

Let us know the above, and post a screen cap of the gui after a read. and a picture of your actual board.

Thanks
Ross

power67 · Post by **power67** » Wed Mar 27, 2013 5:37 pm

Thank You to those that have donated, we now have 4 donations, if you dont mind, I would like to add your names to our Supporters page I will use the names provided by paypal.

The above post and hardware issues is exactly why donations will help make it the best, if we have the resources to get,build and test projects like that board, we can make sure our system works well with it.

Thank you again.

Ross

shikra · Post by **shikra** » Wed Mar 27, 2013 5:54 pm

I had this last night - I had uploaded a different sketch previously. SImply forgot to re-upload the kvosd sketches. Re-uploaded and off it went.

KoekieMonster wrote:I believe it is a rushduino indeed, and I am very sorry, but I have allready tried the above things(I did not use the buzzer since my multiwii has one, I did move the LED to the right pin in the software) but, unfortunately there is something going wrong in the GUI connection I think, when I write the new settings and then read them again they reset to their default, what could cause this? the serial port is working fine when I upload the new character map(not through the GUI but by using this sketch: character upload sketch).
I am using a PAL camera btw.

Thanks for your help

howardhb · Post by **howardhb** » Wed Mar 27, 2013 6:12 pm

if you dont mind, I would like to add your names to our Supporters page I will use the names provided by paypal.

No worries!
I just love this hobby - it keeps me out of the Pub!

H.

rotary65 · Post by **rotary65** » Wed Mar 27, 2013 8:19 pm

@power67: Sure, fine by me. If it will help encourage others, then it's a good idea.

KoekieMonster · Post by **KoekieMonster** » Wed Mar 27, 2013 9:02 pm

thank you for your help, this is what I tried:
1. Yes, I have attached a .zip file which contains a working project.
2. Nope, no data from GUI (this is a problem, I know, I just don't know what's causing it. I made an echo program and it works (at 115200) so the connections are right.
3. tried, no improvement.
4. when I boot, I see an image for the camera for a few sec's and after that I get a blue screen.
5. I have checked it, and since it is working with the other firmware I don't think this is where the problem is.

Attachments:
board backside
board frontside
screencap of GUI after read

carlonb · Post by **carlonb** » Wed Mar 27, 2013 10:15 pm

KoekieMonster wrote:thank you for your help, this is what I tried:
1. Yes, I have attached a .zip file which contains a working project.
2. Nope, no data from GUI (this is a problem, I know, I just don't know what's causing it. I made an echo program and it works (at 115200) so the connections are right.
3. tried, no improvement.
4. when I boot, I see an image for the camera for a few sec's and after that I get a blue screen.
5. I have checked it, and since it is working with the other firmware I don't think this is where the problem is.

Attachments:
board backside
board frontside
screencap of GUI after read

Hi KoekieMonster,
I saw the top view of your OSD, it's not so easy to check in detail your components assembly, but if I'm not wrong, I don't see the two cap of about 18 or 22pF that must be connected to the cristal (16MHz) and ground.
Is the cristal connected at the 2 terminals outside of the picture on lower side?
Hope to correctly saw as I don't have this kind of printed circuit.
Bye
Carlo

kataventos · Post by **kataventos** » Thu Mar 28, 2013 8:55 am

Thank you all for your "appreciation" sure made us very happy!

@KoekieMonster,

the "verified" firmware is the KV Team 2.1 and if it works, the latest developments should work as well.

Simple question: What changes did you made to the original (KV Team 2.1) for it to work, if any :?:

Cheers,
KV

KoekieMonster · Post by **KoekieMonster** » Thu Mar 28, 2013 10:22 am

Hi, The SMD crystals just came in, so I'll solder them tonight(GMT+1), together with the caps. didn't think it would make a problem since the 2.1 version does work.
will report my findings after that.

changes I made to 2.1:
#define RUSHDUINO
#define VideoSignalType_PAL
const char videoSignalType=1
#define BST 5 //LED moved from pin 7 to pin 5

so nothing fancy, just the PAL and rushduino actually.

thanks for your help.

kataventos · Post by **kataventos** » Thu Mar 28, 2013 11:04 am

KoekieMonster wrote:Hi, The SMD crystals just came in, so I'll solder them tonight(GMT+1), together with the caps. didn't think it would make a problem since the 2.1 version does work.
will report my findings after that.

changes I made to 2.1:
#define RUSHDUINO
#define VideoSignalType_PAL
const char videoSignalType=1
#define BST 5 //LED moved from pin 7 to pin 5

so nothing fancy, just the PAL and rushduino actually.

thanks for your help.

OK so, just the LED sanity test pin, because everything else is default even on latest developments.

Code: Select all

0,   // S_BOARDTYPE
1,   // S_VIDEOSIGNALTYPE

Good luck and don´t forget to report.
Cheers,
KV

power67 · Post by **power67** » Fri Mar 29, 2013 4:40 am

I have added 5 people to the Supporters list on the Google Code site. Thank you for your donations and as Rotory65 said, we hope it encourages others to follow their lead and be part of the growing KV OSD Team.

We are working on some exciting enhancements for the next release.

Ross

KoekieMonster · Post by **KoekieMonster** » Fri Mar 29, 2013 9:38 am

Like I said I soldered the caps, unfortunately the crystals I ordered are the wrong footprint so the big 16 MHz is still there.
I have been unable to test it yet, will try this evening and then report.
(to be honest, I dont think it will work now, any other ideas of what changes might affect my results?)

Crashpilot1000 · Post by **Crashpilot1000** » 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

crashlander · Post by **crashlander** » 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

Crashpilot1000 · Post by **Crashpilot1000** » Mon Apr 01, 2013 12:28 pm

Thanks crashlander, you are right!

dramida · Post by **dramida** » 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.

carlonb · Post by **carlonb** » 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

kataventos · Post by **kataventos** » 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

kataventos · Post by **kataventos** » 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:

kataventos · Post by **kataventos** » 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

kataventos · Post by **kataventos** » 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".

trufy · Post by **trufy** » 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