KV Team Multiwii OSD

[subaru4wd]

I have it connected, worked before on MPNG but since I switched to MWII 2.3 all I got is awaiting heartbeats message... So I guess I must enable or define it, but not really sure how ...
Any help is appreciated.
Thanks

Florin,
MPNG & ArduCopter use the MAVLink protocol.
MultiWii uses the MSP (Multiwii Serial Protocol).

The KV_OSD firmware expects to see MSP and not MavLink, so you must update the firmware on your OSD board. As it is now, you do not have KV_OSD at all... just a MinimOSD board ready for arducopter.

Its not difficult at all, you'll need a FTDI controller to accomplish it. Just follow these steps and you'll get yourself setup: https://code.google.com/p/rush-osd-deve ... stallation

[cofl1001]

Hi Brian,
Surprised to see your answer here
I figured it out...basically I need a new firmware otherwise the osd will not be recognized by the multiwii...
By the way, I love the way Mwii flies...been testing it last week-end...glad I left MPNG and joined the mwii community. thanks for that tip.
Enjoy this week-end flying

[Free_Bird]

Just had an idea... wanted to see it it was possible or not. I don't have the hardware to test it out.

If I get one of these OSDs:http://witespyquad.gostorego.com/flight-controllers/minimosd.html

Would this OSD function as a standalone unit?

What I would like to do is install this into a small FPV wing with only RSSI, Battery Voltage, and Time displayed. It makes sense that this would be possible as the data/telemetry that I want displayed is coming from the inputs on the OSD, but I am unsure if there is something in the inner workings of the code that will prevent the board from functioning without an APM/MW flight controller hooked up.

[carlonb]

Just had an idea... wanted to see it it was possible or not. I don't have the hardware to test it out.

If I get one of these OSDs:http://witespyquad.gostorego.com/flight-controllers/minimosd.html

Would this OSD function as a standalone unit?

What I would like to do is install this into a small FPV wing with only RSSI, Battery Voltage, and Time displayed. It makes sense that this would be possible as the data/telemetry that I want displayed is coming from the inputs on the OSD, but I am unsure if there is something in the inner workings of the code that will prevent the board from functioning without an APM/MW flight controller hooked up.

Hi Free_Bird, welcome to our KV_Team_OSD.

Yes, this OSD with KV_Team s/w can be used as stand alone OSD device, only need 5Vdc supply and all analogic device you want connect to it (Main Batt, Video Batt, RSSI, Current sensor).
Actually the time on KV OSD has double functions: "OSD ON time" and "Fly time", in stand alone use you will have only OSD ON time.
The only negative think is that you can't have acces to OSD menu' as this can only be done with FC serial connection, but you can work around this in two ways:
1) Use the KV GUI for setting up some functions.
2) Changing some of setups in globalvariables.h file in order to enable/hide all you need (be carefull with this operation).

Cheers
Carlo

[jevermeister]

Hi,
I accidently deleted the bootloader when I uplaoded the eeprom clean sketch.

A friend of mien amnaged to reburn the bootloader.

Sketches like blink etc. are working.

I uplaoded the KVteam sketch but when I connect via the GUI I cannot save any data, when I hit read after I pressed write everything resets to default.

WTF?

Nils

[scrat]

Hi. I need an info about fonts. Where can I find file for KV-OSD FW with bigger fonts?
And another question. What could be wrong with my minim osd v1.1. from hk and latest kv osd v2.2 I see text on my goggles but all around text are white patches...Is there any info what should I do to make this patches disappear?

Thanks.

[kataventos]

...
I uplaoded the KVteam sketch but when I connect via the GUI I cannot save any data, when I hit read after I pressed write everything resets to default.
Nils

Hey Nils, to be honest I can´t figure what´s happening no clue sorry... How did that happen? I mean how can that happen by uploading the clear EEPROM sketch!

Hi. I need an info about fonts. Where can I find file for KV-OSD FW with bigger fonts?
... What could be wrong with my minim osd v1.1. from hk and latest kv osd v2.2 I see text on my goggles but all around text are white patches...Is there any info what should I do to make this patches disappear?

Thanks.

Hi Scrat, I will make a new "alternative" font map with next release (2.3) we are almost ready for it . It will have two character maps inside the GUI data folder, the one from r2.2 (updated) and a new one for who wants bigger fonts. Also... maybe a third one with the kind of chars used on some other OSD´s for who likes them better (eg, three diagonal letters for "icons"). I am fan of different and original stuff, but I understand that some like this kind of chars. No Problem I can make that happen and of course fully compatible with the current code (2.3).

About the "patches" you see around the text?? can you explain better or post a pic? I do not understand what you mean!

[scrat]

Thanks for info about fonts I'm waiting

About the "patches"...I have found the problem. I'm powering minimosd with 5V form Naze32 board. Board gives me 5.02V output. And yesterday, I've connected minimosd to FTDI and have live video and there was no white patches. So i have mesured power from ftdi and see that ftdi gives me 5.09V. Problem solved. I have bought stepdown regulator from 12V to 5V and V can be adjusted with pot.

[int77]

Hi,
I’m playing with new MAX7456 video output (VSYNC interrupt etc., dev. version from 3rd of January) and found a conflict of this implementation with current font map.
In fact, this dev. version includes auto-increment mode for faster video output. This mode allows transmitting only character address, and offset in video buffer is incremented automatically. According to datasheet, this mode is disabled by writing 0xFF to MAX. As a result, there is a conflict with current font map implementation: SYM_G_HOME character address is defined as 0xFF, so activating “Go Home” mode and sending this character to MAX results in a freeze of the screen until “Go Home” mode is switched off.
So in fast auto-increment video output mode, last character address (0xFF) has to be avoided. In my case quick solution was to change SYM_G_HOME from 0xFF to 0xFE and update corresponding character using font editor.

[kataventos]

Hi Int77,

correct and not... I found it this bug this weekend and had hard time to catch it... you can go back to rev417 and still see it (prior to new MAX sketch implementation).

Please update your clone to rev 417 and confirm/report back, if you catch the exact cause it would be much appreciated, since I was unable to determine exactly Anyway, because it got stuck during flight with return home engaged (crashed with the char on the left side of the screen) I figured it by calling another char address just in case after some serious reading on every bit changed on that revision

I have more work going before upload it to the repo but the GO_HOME char will travel to 0XC0, the char map is being completely renewed

[int77]

Please update your clone to rev 417 and confirm/report back, if you catch the exact cause it would be much appreciated, since I was unable to determine exactly Anyway, because it got stuck during flight with return home engaged (crashed with the char on the left side of the screen) I figured it by calling another char address just in case after some serious reading on every bit changed on that revision

I've just rolled back to dev. revision 058e2219686d (version just before new MAX output implementation) and on my setup there is no issue with screen freeze in go home mode

It's really looks like the root cause is auto-increment mode output desactivation by 0xFF character. Below is the citation from max datasheet:
"When performing the auto-increment write for the display memory, the 8-bit address is internally generated, and
therefore only 8-bit data is required by the SPI-compatible interface (Figure 21). The content is to
be interpreted as a Character Address byte if DMAH[1] = 0 or a Character Attribute byte if
DMAH[1] = 1. This mode is disabled by writing the escape character 1111 1111."

[scrat]

Hey kataventos. Master

Could you be so kind and tell me how to lower the rush-osd font brightness - http://www.rcgroups.com/forums/showpost ... nt=942...I have read that is set to 120% and must be at 90%. Because of that I have white smearing around fonts.

Thanks.

edit: maybe here?

From:

Code: Select all

  uint8_t x;
  for(x = 0; x < MAX_screen_rows; x++) {
    MAX7456_Send(MAX7456ADD_RB0+x, WHITE_level_120);
  }

To:

Code: Select all

  uint8_t x;
  for(x = 0; x < MAX_screen_rows; x++) {
    MAX7456_Send(MAX7456ADD_RB0+x, WHITE_level_90);
  }

[kataventos]

Hey Int77,

OK, I still did not had the chance to roll back again for a second go after seeing this post. Anyway, issue solved.

I have been working on a new screen layout more simple to use and less confusing.
Chars are bigger specially symbols. Because the pilot knows he´s unit and configured it on GUI at first, it should not be a problem for anyone.
Added new functions and a new screen routine while the FC is acquiring the GPS. Also added a slide for the throttle and an "AUTOPILOT" message when the copter is on HOLD, HOME or WP.
FLIGHT MODE is separated from the SENSORS function and can now be set for position. Home indicator now have double "3D Arrows" etc, etc... some more stuff that I do not remember at this moment

Will post some stuff tomorrow (slow work )

Cheers and thanks,
-KV

[kataventos]

Hey Scrat,

yes, that´s it. You can go as low as 80. I never had that kind of issue... what hardware do you have?

See the Max sketch for previous defines:

Code: Select all

#define WHITE_level_80 0x03
#define WHITE_level_90 0x02
#define WHITE_level_100 0x01
#define WHITE_level_120 0x00

Cheers,
-KV

[scrat]

Hey Scrat,

yes, that´s it. You can go as low as 80. I never had that kind of issue... what hardware do you have?

See the Max sketch for previous defines:

Code: Select all

#define WHITE_level_80 0x03
#define WHITE_level_90 0x02
#define WHITE_level_100 0x01
#define WHITE_level_120 0x00

Cheers,
-KV

Thanks kataventos. I'll change white level later today and see if it works. I have hobbyking minimosd v1.1.

[scrat]

I found this on fpvlab about rssi...can I do that with FrSky D4R-II receiver?

KVteam osd + Naze32 + a receiver that outputs RSSI in the PPM stream, and your connection is done.

In naze change rssi_aux_channel=X where auxchannel is the RSSI channel in PPM stream, set kv-osd to grab RSSI from multiwii controller, and you are done. No additional wires.

Example: Naze32 control map is AETR1234, rssi is on PPM channel 8, set rssi_aux_channel=4

If abowe doesn't work...see below?

Using Naze32 and baseflight FW - FrSky D4R-II receiver and have 3rd and 4th channel signal connected and get CPPM on CH1 and RSSI on CH2. Do I need to connect just rssi signal wire with 1kOHM resistor to minimosd or I need to connect GND wire to somewhere?

I have made my cable for rssi exactly like on this picture: http://api.ning.com/files/qgybvJa4VHiv6 ... analog.jpg

Thanks for info.

[scrat]

Hey Scrat,

yes, that´s it. You can go as low as 80. I never had that kind of issue... what hardware do you have?

See the Max sketch for previous defines:

Code: Select all

#define WHITE_level_80 0x03
#define WHITE_level_90 0x02
#define WHITE_level_100 0x01
#define WHITE_level_120 0x00

Cheers,
-KV

Thanks kataventos. I'll change white level later today and see if it works. I have hobbyking minimosd v1.1.

Ok. I've set WHITE_level to 80 MAX sketch and it's perfect.

[turkawa]

I do not reccomend that mod anymore because you can have it with much clean mod using the Multiwii VBat, and now the RSSI is available either if you have a Mega board.

Anyway :

http://code.google.com/p/rush-osd-devel ... dware_Mods

I made this mod you see on the picture, but I do not use it anymore, do not reccomend it either if you are not used to solder small stuff. Your soldering Iron should be 20W max, and you should not give heat for long.




Cheers,
KV

Hi Kata..
I have made the mode you have showed there but i cant get a voltage reading..
Is there a setting i am missing here in multiwii or rush osd setup?

I also activated vbat. As far as i understand vbat does not actually looks at the voltage. It starts from predefined voltage and calculates right?
And my rx does not have RSSI output(optima 7) i set rssi minim osd but my rssi still shows 0..
Everything is working except these 2..
I dont have any hope on RSSI but not being able to see live voltage is killing me..
I didnt soldered the hack. I have gone to a professional and payed him to do.
So it is a good as it can be. So any bad solder or short shouldnt be an issue.
Besides, i checked the connections and shorts with multimeter..All ok..

[kataventos]

Ok. I've set WHITE_level to 80 MAX sketch and it's perfect.

Great

Hi Kata..
I have made the mode you have showed there but i cant get a voltage reading..
Is there a setting i am missing here in multiwii or rush osd setup?

I also activated vbat. As far as i understand vbat does not actually looks at the voltage. It starts from predefined voltage and calculates right?

Vbat is via MSP...

And my rx does not have RSSI output(optima 7) i set rssi minim osd but my rssi still shows 0...

Don´t understand your point if you do not have RSSI why does it must show anything else but zero? unless you want to take it off screen, is that it?

I dont have any hope on RSSI but not being able to see live voltage is killing me..
I didnt soldered the hack. I have gone to a professional and payed him to do.
So it is a good as it can be. So any bad solder or short shouldnt be an issue.
Besides, i checked the connections and shorts with multimeter..All ok..

Still don´t understand the RSSI issue... voltage should work just fine and RSSI also.

Before more explanations I would like to ask you what version of KVTeam work are you using!!?

Cheers,
-KV

[kataventos]

This is just a small teaser on the next version 2.3 coming soon...

The default screen suffered major changes and it is more simple to read for everyone. The aspect is more "PRO" and new gadgets were programmed...
Volume flight can now be set via GUI, autopilot warning, sensors are now detached from flight mode (flight mode is also moveable as all other functions), double 3D arrows for home indication, acquiring sats routine on the sensors field until it get´s a 3D fix, etc. There will be two character maps inside the GUI data folder, the default and one with bigger main chars (letters and numbers)... and more...

Have fun,
-KV

[scrat]

Great! Can't wait. Could you be so kind and check this post of mine: viewtopic.php?f=8&t=2918&start=810#p45578 thanks!

[turkawa]

Still don´t understand the RSSI issue... voltage should work just fine and RSSI also.

Before more explanations I would like to ask you what version of KVTeam work are you using!!?

Cheers,
-KV

What i meant was,
From what i have read, i had the idea that rush osd have a way of calculating rssi without the actual rssi connection from crius AIOP board. I was wrong i guess.
About the voltage, I made the needed soldering but didn't know where to go from there. I connected the wires to the battery but bat was still 0%.
I was confused about what to define from MW code, what to choose from rush odd gui. But all ok now, managed to make voltage work properly.
Cant wait for v2.3
Thanks for this beautiful software

[kataventos]

Great! Can't wait. Could you be so kind and check this post of mine: viewtopic.php?f=8&t=2918&start=810#p45578 thanks!

Hey Scrat,

I see... already posted a lot of times about the RC Filter on this topic and the last time was in December viewtopic.php?f=8&t=2918&start=770#p44864 the RC filter is the best way to get the RSSI readings on PWM output RX´s but you can also wait for KVT 2.3 to use the PWM
I use the RC Filter since almost ever (as far as I remember) and since 2.2 I use it on the MWii FC with perfect values since they were smoothed by Hamburger. Anyway, either way (FC or OSD) you should be just fine with it.

What i meant was,
From what i have read, i had the idea that rush osd have a way of calculating rssi without the actual rssi connection from crius AIOP board. I was wrong i guess.
About the voltage, I made the needed soldering but didn't know where to go from there. I connected the wires to the battery but bat was still 0%.
I was confused about what to define from MW code, what to choose from rush odd gui. But all ok now, managed to make voltage work properly.
Cant wait for v2.3
Thanks for this beautiful software

OK I see. No, the only way for you to get RSSI reading is with a RX actually is capable of outputting that data. No other way to calculate it using both (OSD analogue input) or (FC board analogue input) hope you understand this.

Great you managed to get voltage running on screen, now go on and have some fun

Cheers,
-KV

[kataventos]

I am playing with the implementation of a pitch ladder which I think that looks fine but with not much use on our case (hardware limitations)

In this case I would like to ask if this have "legs to go":

- "Pitch ladder" will follow AH for (Pitch) all the way with (degrees=x)
- " " " stay straight until roll reaches (degrees=x) eg 25º ... then it will follow the AH this way we have a sort of mix between PL and Bank Angle...

[turkawa]

please stick to dots… pretty please with sugar on top..
as a graphics man, i hate those super lowres boxy lines..
they look like they come out from those really old sinclair spectrum games…
dots look way smoother…

[kataventos]

Of course, these pics were just to make my point about the implementation... I like "dots" better for a long time now for the exact same reason
Ohhh and no side bars also...




Anyway, almost done... 2.3 will be out soon. Just need to see some more points with Carlo and we are good to go and pack the stuff.


EDIT: This will be the alternative Char map:

[int77]

Waiting with interest 2.3 version, and thanks again to KV team for active work.

Regarding “pitch ladder” - why not, but in my opinion it will not add a lot of useful information taking into account hardware limitations. Fast evolutions of pitch ladder lines around roll angle=25 deg (switching between horizontal lines and following AH) might be visually perturbing for some pilots, it will be nice to have a possibility to de-activate this feature.

One of the points that might be improved is too slow video update cycle time (100ms). 10Hz screen update frequency is clearly too slow, resulting in perceptible lags. Any chance to look on this point and make faster loop? Will be nice to have at least 30Hz. It should be possible with faster video output implementation from vvk.

[kataventos]

We are already close to the limits on memory...

Regarding the pitch ladder OK it will be exactly like the AH to avoid confusion and will be possible to deactivate it on config.h until we are able to free up some Mem.
As for the time cycle is 50ms for Hi and 100ms for Low. It is 20hz actually.

This will be probably the default layout... (still updating)

[scrat]

Great! Can't wait. Could you be so kind and check this post of mine: viewtopic.php?f=8&t=2918&start=810#p45578 thanks!

Hey Scrat,

I see... already posted a lot of times about the RC Filter on this topic and the last time was in December viewtopic.php?f=8&t=2918&start=770#p44864 the RC filter is the best way to get the RSSI readings on PWM output RX´s but you can also wait for KVT 2.3 to use the PWM
I use the RC Filter since almost ever (as far as I remember) and since 2.2 I use it on the MWii FC with perfect values since they were smoothed by Hamburger. Anyway, either way (FC or OSD) you should be just fine with it.

Cheers,
-KV

Yesterday I have removed capacitor and leave just 1kohm resistor on rssi signal line and it works. When Tx is turned on I have rssi readings form 95 to 98% and Tx turned off the readings are form 2 to 4%.

[jevermeister]

I do not know how I killed the bootloader with the eeprom cleaner.

I did not use eeprom clean this time after my collegue rescued the osd.

Could this be the reason why it is not working? as said, other sketches work and the upload of the sketch gives me no errors...

How can I tell if the sketch is running correctly?

maybe by adding a blink somewhere?

Nils

[int77]

As for the time cycle is 50ms for Hi and 100ms for Low. It is 20hz actually.

Sorry for my imprecision, it’s actually 50ms/20Hz in high speed loop with MAX7456_DrawScreen(). But… in my understanding MSP request scheduler is included in the same 50ms loop; in normal mode there are 6 queued MSP requests. As far as MSP scheduler issues only one request per 50ms loop, new MSP_ATTITUDE packet with MW angles should arrive every 300ms. Additionally there is extra MSP_ATTITUDE request in 100ms loop. It means, actual MwAngle and on-screen AH update rate will be slightly higher than 10Hz. The same considerations are valid for other data coming from MW, and update rates will be even lower (~3.3Hz actually) due to the fact that there is no extra MSP requests in 100mS loop. All that results in a perception that minimOSD is slow…
But there is a lot of room to improve information update rate on the screen. Good reference for high speed loop might be NTSC frame rate which is 30Hz (or even VSYNC frequency which is 60Hz in reason of 2 fields per frame). And probably MSP request scheduler might be moved to a faster loop.
It could be particularly interesting for aggressive low altitude flights where AH/altitude update rates are important

[jevermeister]

Ok, it's working again, did the eeprom clean and reuplaoded the code, now it seems to work, have to test it on the video though.

Thanks for helping me guys

[kataventos]

As for the time cycle is 50ms for Hi and 100ms for Low. It is 20hz actually.

... And probably MSP request scheduler might be moved to a faster loop.
It could be particularly interesting for aggressive low altitude flights where AH/altitude update rates are important

Hey,
sorry for my misunderstanding also, you are so very right. Carlo sent me an email calling my attention to your last post.
I will continue to keep things going with the new gadgets (OSD / GUI) and screen layout, and Carlo will look at that particular case.

Thanks

Ok, it's working again, did the eeprom clean and reuplaoded the code, now it seems to work, have to test it on the video though.

Thanks for helping me guys

Hey Nils, great you have it working, only saw your posts now

[carlonb]

Sorry for my imprecision, it’s actually 50ms/20Hz in high speed loop with MAX7456_DrawScreen(). But… in my understanding MSP request scheduler is included in the same 50ms loop; in normal mode there are 6 queued MSP requests. As far as MSP scheduler issues only one request per 50ms loop, new MSP_ATTITUDE packet with MW angles should arrive every 300ms. Additionally there is extra MSP_ATTITUDE request in 100ms loop. It means, actual MwAngle and on-screen AH update rate will be slightly higher than 10Hz. The same considerations are valid for other data coming from MW, and update rates will be even lower (~3.3Hz actually) due to the fact that there is no extra MSP requests in 100mS loop. All that results in a perception that minimOSD is slow…
But there is a lot of room to improve information update rate on the screen. Good reference for high speed loop might be NTSC frame rate which is 30Hz (or even VSYNC frequency which is 60Hz in reason of 2 fields per frame). And probably MSP request scheduler might be moved to a faster loop.
It could be particularly interesting for aggressive low altitude flights where AH/altitude update rates are important

Hi int77,
what you think is correct, but unfortunatelly today I've tried to increase the refresh rate (20Hz dedicated only to AH) and I saw that there are'nt advangates about refresh speed on Horizon line moving my copter (on desk).
I need to investigate better about it.
Bye
Carlo

[carlonb]

Deleted for post duplication, sorry

[jevermeister]

So after some absence I am back onboard.

A few questions: Is it possible to bring back the preview of the OSD in the gui? I think it was very handy...

Are the vertical bars left and right of the artificial horizon gone or can they still be activated, I liked this fighter pilot style.

The OSD is now installed with r370. I have not flown yet, but I am looking forward to, seems to be smoother than mobidrone but some flickering is noticeable.
KV are you on that after the comment regarding the update rate etc?

Nils

[turkawa]

A few questions: Is it possible to bring back the preview of the OSD in the gui? I think it was very handy...
Nils

+1 on that!!

Are the vertical bars left and right of the artificial horizon gone or can they still be activated, I liked this fighter pilot style.
Nils

+1 on that also!!

And KV, do you have a possible release date on mind??.. Don't mean to rush you or anything like that!!
Just curious!!

[int77]

Hi int77,
what you think is correct, but unfortunatelly today I've tried to increase the refresh rate (20Hz dedicated only to AH) and I saw that there are'nt advangates about refresh speed on Horizon line moving my copter (on desk).
I need to investigate better about it.
Bye
Carlo

Hi Carlo
Probably the gain isn't so obvious due to discrete nature of the AH drawing related to by-character output.

I've played a little bit around that, and there seems to be some improvements after next modifications:
- MAX7456_DrawScreen() loop time set to 17ms (~60hz close to VSYNC frequency)
- MSP scheduler moved to a separate 5ms loop, this way full MSP dataset from MW is obtained every 30-35ms (roughly one time per NTSC video frame). This should be compatible with ~3ms cycle time and one MSP request / cycle capability on MWii side.
- Doing that, some other routines using initial 50ms loop have to be adapted (like trip, flying time and blink frequency calculations)

It seems to be faster on the desk, but I’ve not tested this mod in the field yet. Modified main loop is in attached file for your reference.

[scrat]

A few questions: Is it possible to bring back the preview of the OSD in the gui? I think it was very handy...
Nils

+1 on that!!

Are the vertical bars left and right of the artificial horizon gone or can they still be activated, I liked this fighter pilot style.
Nils

+1 on that also!!

And KV, do you have a possible release date on mind??.. Don't mean to rush you or anything like that!!
Just curious!!

For 1st I don't know.
For 2nd...you can set them to On in minimosd menu with your Tx sticks.

[jevermeister]

thank you scrat! will try that after I move to the new software

[carlonb]

Hi int77,
what you think is correct, but unfortunatelly today I've tried to increase the refresh rate (20Hz dedicated only to AH) and I saw that there are'nt advangates about refresh speed on Horizon line moving my copter (on desk).
I need to investigate better about it.
Bye
Carlo

Hi Carlo
Probably the gain isn't so obvious due to discrete nature of the AH drawing related to by-character output.

I've played a little bit around that, and there seems to be some improvements after next modifications:
- MAX7456_DrawScreen() loop time set to 17ms (~60hz close to VSYNC frequency)
- MSP scheduler moved to a separate 5ms loop, this way full MSP dataset from MW is obtained every 30-35ms (roughly one time per NTSC video frame). This should be compatible with ~3ms cycle time and one MSP request / cycle capability on MWii side.
- Doing that, some other routines using initial 50ms loop have to be adapted (like trip, flying time and blink frequency calculations)

It seems to be faster on the desk, but I’ve not tested this mod in the field yet. Modified main loop is in attached file for your reference.

Hi int77,
Thaks for your effort, I downloaded your mod and I will take a look and test it.
Carlo

[Crashpilot1000]

Hi just stumbled upon the dogfight (old project 2012/2013) osd https://code.google.com/p/dogfight-osd/ what an idea. But where is the dogfightfun, when you know where the enemy is?

[subaru4wd]

Hi just stumbled upon the dogfight (old project 2012/2013) osd https://code.google.com/p/dogfight-osd/ what an idea. But where is the dogfightfun, when you know where the enemy is?

I have been doing some formation flying with a few friends... this would be awesome to have, as it is very difficult to find a flying quadcopter in a FPV camera.

[bicycle]

Hey guys, one quick thing I noticed, the word DISARMED appears in the compass sometimes and even scrolls around with the letters. That's with version 2.2 release

Also, when do you guys plan on releasing 2.3? I'd like to use the new graphical fix (it looks really good) but the current repo version doesn't work with the 2.2 GUI and I can't get Processing to make a working GUI (always crashes a moment after serial is opened)

Thanks!

[kataventos]

...(always crashes a moment after serial is opened)

Thanks!

Hi,

Yes it is know, last changes are not in the repo yet. I will synchronize when they are all ready to go. Carlo is also taking care of the new cycle time speed.

Be patient, I will announce it soon

[kataventos]

Hi,

Sorry but sometimes I do not have the time to answer all questions.
Someone asked above about the side bars and someone answered to it Side bars will continue to exist of course, and from now on with a real purpose.
Also made other developments in this area regarding real data to assist the flight. When I thought on this was mainly thinking on fixed wings but it will also be useful for Multirotors.

Developments were:

-Pitch Ladder 30° space with warning if pitch gets equal or above given (30°) inclination;
-Side Bars with the purpose of showing real Pitch degrees.
_______________________________________________________

-Throttle indication with excellent resolution for precise indication;
-Smaller (to release screen) but equally efficient Heading Graphic;
-Sensors present will show a black box with the first letter of corresponding sensor;
-Sensors active will show the letter lit;
-GPS will have the corresponding letter "G" blinking until a 3D Fix, at this time the letter will be replaced by the 3DFix box;
-Return home and hold now have new icons.
(we are preparing WP NAV related info (not on this next r2.3) )

User now must know he´s units... all indications are now "icon unit free".
Are excluded functions like amperage, voltage´s, consumed current, coords, RSSI, time, etc...

Have fun and fly safe,
-KV




PS: About the GUI with screen we will see... but for now the "screen" have no purpose in being there and would take me precious time to keep other developments going.
I understand it looks cool but my Java programming capabilities are far... light years far from what I would which them to be

-The GUI is mainly a development tool and user friendly to easily start the OSD in a fully capable configured condition regarding the ATM present functions which we consider not so important on the field. All other adjustments/functions can also easily be configured on the OSD/field using the sticks.

2.3 Dev GUI will have new configurations which I really think important as you can see on the following PIC:

-Volume flight warnings;
-Amperage reading with new adjustments already explained on the repository WIKI (as many other new things about latest developments)
-Video voltage warning detached from Main voltage;
-PWM input really working as never before which includes a divider also;
-Vertical speed warning;
...

What made me add this new features were real necessity of having them on screen during flight (eg) a friend broke a wing during flight because he did not noticed the vertical speed... some fixed wings have this kind of stuff



The OSD is a tool to fly with, not a desk tool to play around We will only focus on the important and really needed stuff to make our flights even more real with most needed information on screen...
With this said I also would like you all to remember that we have a Donation link on the repo... at least throw a "bone" so we can feel welcome and warm!

[teslahed]

Can anyone offer me any advice on tuning the standard rctimer current meter for use with the minimOSD running the teamKVOSD firmware?

I've done the hardware mod on the minimOSD and i'm pretty sure that bit is working ok;



(The picture shows the soldering done to the ATMEL chip before i added the 1K resistor and pin for the current sensor after i'd finished doing something similar for the voltage sensor pin.)

I've enabled the current sensor in the GUI like this;



When i do short test runs by hovering over my bed i get roughly sensible values for mAh consumed showing on the OSD. On one run of 177mAh consumed on the OSD my charger told me that i put 174mAh back into the previously full battery and another of 270mAh my charger put 230mAh back in. So i am in the right area with these result.

The current reading seems to jump all over the place. The digital values flicker on the OSD as if updating too fast and are almost unreadable.

The only value i can alter is the 'Offset' value which is currently on the default setting of 0.

Do i need a low pass filter somewhere between the rctimer current meter and the minimOSD? How should i be altering the single 'Offset' variable?

[howardhb]

@ teslahed, before figuring out the "offset" variable, you must have, a t least, a stable analog to digital conversion.

I suggest a low pass filter by connecting a capacitor as shown in the attached picture.
(experiment with capacitor values up to 10uF)

Filter

H.

[teslahed]

Thanks for the suggestion howard.

I am not sure why your circuit diagram is different to the one shown on the hardware mod page;



But i've got the bits required so i'll give it a go and see what happens.

[teslahed]

I just did a quick test - i seem to be getting sensible current readings now so i think that's helped, thanks howard.

I've just got a battery on balance charge and when that's ready i'm going to do another test flight to see if the mAh counter is working any better.

Edit - the current meter is showing about 20 amps in the hover when i know from past experiments with a watt meter that it should be about 10. I need to work out how to adjust the scaling...