KV Team Multiwii OSD

howardhb · Post by **howardhb** » Mon Jan 27, 2014 7:22 pm

I need to work out how to adjust the scaling...

I knew that would be your next step!

As an aid, apply the following......
(Please don't shoot me down, I have not tested this but it seems logical to scale for your specific sensor)

So, you need to calculate and define the scaling factor for your sensors' output.....
I've attached an excel spreadsheet so you can determine the scaling factors for your sensor.
I don't know which sensor you are using so just edit the blue fields to enter your sensors constants.
Note: RCTimer sensors output only 3.3 Volts when it's maximum permissible "input" is applied.
The analog reference (in the KV_Team code) is set to (DEFAULT) 5V, so the scaling factor calculations are based on 5V.

Assuming you are on KV_Team 2.2
In GlobalVariables.h, create the definition of the current scaling factor by using the value obtained from the spread-sheet:
(replace x.xxxxxx with the value from the spread-sheet - use all the decimal digits)

Code: Select all

#define  CURRENT_SCALE_FACTOR      10 * x.xxxxxxf

(you must add the f after the constant that is calculated in the spreadsheet)

Then apply the scaling factor like this:
in KV_Team_OSD.ino
change to this:

Code: Select all

if (!Settings[S_MWAMPERAGE]) {
    amperage = (analogRead(amperagePin) - Settings[S_AMPOFFSET]) * CURRENT_SCALE_FACTOR;
    if (amperage >=999) amperage=999; 
    }

You can still use the offset (in the GUI)

I've edited the code as above and it compiles ok.

teslahed · Post by **teslahed** » Mon Jan 27, 2014 9:11 pm

Thanks howard,
If it helps narrow it down at all I'm using the rctimer current and voltage sensor.
RCTimer Voltage & Current Sensor 90A
50V/90A = 63.69mV / Volt 36.60mV / Amp
Hardware Features:
• 51.8V Max
• 89.4A Max
• Analog output scaled for 3.3V ADC

Thanks for the help with the spreadsheet. I make it to be;

Code: Select all

#define  CURRENT_SCALE_FACTOR      10 * 0.0873046875f

I've altered the code and i'll give this a go (probably tomorrow now). I notice there are a bunch of extra variables in the screenshot of the GUI for version 2.3 - i'm guessing that's so people don't have to mess about with stuff like this in the future?

carlonb · Post by **carlonb** » Mon Jan 27, 2014 9:53 pm

teslahed wrote:Thanks howard,
If it helps narrow it down at all I'm using the rctimer current and voltage sensor.
RCTimer Voltage & Current Sensor 90A
50V/90A = 63.69mV / Volt 36.60mV / Amp
Hardware Features:
• 51.8V Max
• 89.4A Max
• Analog output scaled for 3.3V ADC

Thanks for the help with the spreadsheet. I make it to be;
Code: Select all
#define  CURRENT_SCALE_FACTOR      10 * 0.0873046875f
I've altered the code and i'll give this a go (probably tomorrow now). I notice there are a bunch of extra variables in the screenshot of the GUI for version 2.3 - i'm guessing that's so people don't have to mess about with stuff like this in the future?

Hi my friends,
About current sensor, what version are you using ?
I inform you that with the next version 2.3 no more need adjust scale factors.
Only need to set in GUI the sensitivity of sensor (see your specific device datasheet) and set the offset (0H,0L if the sensor is unidirectional, or 2H,0L if is bidirectional) as explained in VIKI.
Furtermore we have added a S/W smoother in order to slowdown the digits on screen so an external hardware filter with a capacitor is no needed.
I've done many tests about the current consumption precision and with 5000mah batt I've obtained an average error of about 4,7% (example: the real charge with my batt charger gives me 3968mah, the OSD show me 3762mah -5.5% less), I think it's not so bad.

Bye
Carlo

teslahed · Post by **teslahed** » Tue Jan 28, 2014 4:45 am

When will 2.3 be out?

The current sensor is just the rctimer one; http://www.rctimer.com/product_861.html 50v/90a

howardhb · Post by **howardhb** » Tue Jan 28, 2014 8:28 am

@Carlo, Thanks for the update on 2.3 - looking forward to it being rolled out, soon hopefully.

In the mean time, @ teslahed,

#define CURRENT_SCALE_FACTOR 10 * 0.0873046875f

is'nt correct.
MinimOSD uses a 5V analog reference so you will need to use 5V as the Arduino analog REFERENCE (in the spread-sheet)
so, for your 50V / 90A sensor, (actually 51.8V / 89.4A) the current scale factor will be 0.13227983f

H.

IceWind · Post by **IceWind** » Sun Feb 02, 2014 11:32 pm

Just tried on mine as I have a similar sensor, at least the specs are the same. AttoPilot 90A.

Voltage is working fine but Amps is reading lower than it should. I put my Amp meter in line and it reads when on 0.33A
but the OSD keeps changing from 0.3A and 0.1A
When giving full throttle (no props) the amp meter reads 2.34A and the OSD is reading 1.7A.

kataventos · Post by **kataventos** » Tue Feb 04, 2014 12:49 am

teslahed wrote:When will 2.3 be out?

Hi,
2.3 will be out soon and fully loaded.

We are just dealing with the new cycle time speed, everything else like reported issues with correct reading on current sensing and others are now solved as well as the long time issue called PWM RSSI

...

The GUI will from now on have this small size because we are going to use several configuration pages along the way.
The changes on 2.3 are many and the change log is being prepared as well as the WIKI.

Cheers,
-KV

turkawa · Post by **turkawa** » Tue Feb 04, 2014 2:27 pm

As i told you before..
That freakin gps alt hold video got me hooked on multirotors so you better hurry brother

kataventos · Post by **kataventos** » Tue Feb 04, 2014 3:11 pm

Hey, on last post I forgot the small video...

turkawa wrote:As i told you before..
That freakin gps alt hold video got me hooked on multirotors so you better hurry brother

Ahahah

I remember you my friend! We talked by email... I wish you great flights and hope you managed to get your setup tuned.

Cheers

kataventos · Post by **kataventos** » Tue Feb 04, 2014 3:24 pm

@Howardhb

Hey,
cheers friend, sorry I only saw your post´s now! That is in fact a nice work around for the dev 2.2 and I honestly did not remember that at the time :mrgreen:

But as Carlo said before, you don´t need it on 2.3 dev

int77 · Post by **int77** » Tue Feb 04, 2014 11:19 pm

kataventos wrote:Hey, on last post I forgot the small video...
s

Looks promising!

Home arrow and heading on the side of the screen is questionable from an ergonomic point of view; sure it can be moved to user-defined position, but default layout should be some kind of reference

The best position for it could be top-center of the screen as before (in my opinion).

From an ergonomic point of view it would be interesting to merge home arrow indicator with AH central reference symbol, like on Range Video OSD: https://www.youtube.com/watch?v=OMQ5L9ox4kM
It should be possible to implement similar concept on minimOSD, using home arrow characters (modified as needed) and angle-to-home-driven selection of the character for AH central reference symbol. The question is "will be available video resolution enough and comfortable"...

kataventos · Post by **kataventos** » Wed Feb 05, 2014 12:45 am

Hi Int77 / everyone else,

I agree in some point about home arrow and heading... but, because home arrow is two chars now it won´t fit as nicely as before at the screen center!
Because of this and wanting to really change the screen together with new implementations on this dev like Volume flight etc , I saw most of the videos online about this particular case.

I found that most use the home arrow indicator on many different places as well as heading. After some flight tests I asked myself:

- What do you really need at the center on an extreme visible place and what´s more important for the pilot??

1- RC link;
2-Flight mode;
3-Autopilot ability in case of emergency.

Heading is nice to have as reference for the pilot on another case of satellite lost to find way back... but only few pilots are able to really take it into account when they start they´r flight. So, in this case it should be as well on the top and in this case I found the left top spot the best one to implement it for default. Also made it smaller to free up the screen and found that with current resolution it is exactly the same.

Using the 180° option (set on GUI) it will now behave as the MWii Gui showing -180<0>180° (this also make´s more sense and easier to read at least is what I think...) with 360° option it will be as before.

Now... to balance the screen with new implementations like the new throttle indicator and the above mentioned two chars arrow I found the default the best place to be because pilot can easily look at it in some point if lost without loosing the horizon etc. The same for Altitude, LOS, and Speed, they are on visible accessible places (in my opinion :geek:

)

Coordinates at bottom left corner, followed by current and time (both On and Fly) followed by instant consumption and Batt voltage. Due to the amount of warnings able to be set, most of the data is not so critical at this time for the pilot to be always looking at, but ... we sure need it on screen!

Bottom line and like you said, the user can always set them to whatever he likes better if these default places that I found really balanced to fly with are not so suitable in they´r case.
I understand that we all have different brains that respond differently to certainly colors, spots, warning blink frequencies, etc. Because of this we have them all user configurable at this time.

This is why we are not coding to just one or two guys... we make it for everyone and we try to always have this in mind together with natural evolution that is most of the times difficult to keep up.

I hope you understand my points regarding your thoughts about the new up coming release. We really try to make this for everyone and we truly dedicate lot´s of hours of our free time to it but sometimes is hard... Also the Team ATM is just me and Carlo no work was done by the other members because lack of time and probably no interest in continuing developing this OSD... Very hard work for two none coders if you get my point

Anyway, we truly hope that you all have wonderful time flying with it.

Cheers,
-KV

PS: I forgot to mention that I also thought about pilots that don´t use the full sensors and in this case it does not matter GPS related data, HEADING, etc. And they just have lot´s of fun flying FPV with just a ACC on they´r boards... Sensors present/active are now on the left and start counting from the right to the left etc etc ... I sure forgot to mention lot´s of stuff that I took into account but that´s OK! We will see after the release the users acceptance to it :ugeek:

For now our main concern will be only with the Cycle time and screen update rate, because everything else should just be fine for now. Although all your thoughts and suggestions are in truth taken into account as always. Even when does not look like they are

PS1: I also forgot to mention that we really need to manage memory because we really need to try to keep up the evolution on MWii, because of this some functions that could be really better need to stop developing to give room to other new´s to come...

int77 · Post by **int77** » Thu Feb 06, 2014 12:57 am

Hi KV,

You're driving dvpt according to your understanding and analysis and it's the right way to go. You've just posted the screen layout here, so it's natural to suppose you expect some feedback

From other hand, top level semi-professional OSDs are inspired by military HUD (Head-Up Display) systems that are very well optimized from an ergonomic point of view... so some basic principles are already established. Sure it's not the same applications as low cost OSD for multirotors but it might worth to take into account.

Cheers,
int77

kataventos · Post by **kataventos** » Thu Feb 06, 2014 8:21 am

Hi Int77,

of course my friend that is exactly why I post examples before the release of a development version and I truly appreciate your comments.

Well, I see al your point´s and I´m also well aware of what is a HUD but my point of view is:
- Would it be appropriated to hobby flights/pilots?
- Would it work with the amount of information needed on screen at once?

If you ask me what would be my election screen... I would say this one below.

It is more like a supposed HUD (because if you really look for them you will see lot´s of different screens with different data... sometimes you see the same data in very different places...) using the actual code principles. I only made some changes regarding LOS which is here using ItoaPadded to justify from right to left, no Icons on "obvious" data, and 8 positions arrow home indicator.

Everything I really need is on this screen and the look is at least for me the best with everything well balanced which is as important as everything else.

Question: Do you think regular pilots would go for this code/screen below? :geek:

I think not...
In my opinion we need to adapt the entire concept to the real necessity itself, more than just make it look like... As always we are open to suggestions

Now for "the other" reality:

Cheers,
-KV

int77 · Post by **int77** » Fri Feb 07, 2014 12:44 am

Wow, you did extended study. Let me try to summarize my thought about HUD, and then transpose that to our case.

What are critical parameters constantly consulted by regular pilot in the case of a plane, particularly during maneuvers? It could be
- orientation (heading / AH)
- altitude / vertical speed
- horizontal speed (mainly to prevent stall situations and anticipate plane evolutions)
If we analyze different HUD layouts, common point is that we have exactly these key elements located at the center of the screen, with some variations but always in the positions allowing pilot to not change the focus.

Transposing that to RC FPV multi-rotor case, the situation isn't so different. We might replace horizontal speed by throttle. Due to limited flight time and RC range, we should add to the key parameters direction to home and maybe distance to home / powermeter - Vbat / RSSI.
All other stuff is secondary (don’t need constant monitoring) and might be moved to the edge of the screen to avoid over-loading.
Your latest screen layout is close to that. I don't know if majority of regular hobby pilots will go for this kind of layouts, but I will. You know, hobby pilots are pilots anyway

Cheers,
Int77

kataventos · Post by **kataventos** » Sun Feb 09, 2014 5:54 pm

Hi Int77,

yep, have been studding

This must not be mistaken with the OSD 2.3 dev that will be released soon.

This is a new project that will be using same hardware and principles but not as comfortable as the OSD. It is made from scratch for speed and resolution and will not be able to tune PID´s, calibrate Mag or anything to do with writing to the FC EEPROM. Also no changing stuff place´s

It´s difficult to read if you don´t know your screen (for newbies) and will change between three (or more) screens with the old OSD SW. It is as close as possible to the real HUD concept and HAVE NO DATE to the first release.
We are starting the HUD from scratch in order to really feel the G´s making it hard to breath. Before you try this HUD you really need to make some abdominal´s and personal training in order to fly fast without passing out ... :mrgreen:

wuudogg · Post by **wuudogg** » Mon Feb 10, 2014 1:27 am

That looks slick. Can't wait to try it out !

msev · Post by **msev** » Mon Feb 10, 2014 10:53 am

Where's the home indicator, thats an essential part of the HUD for rc pilots

... and if u manage to squeeze mah consumed on the "kvt hud", maybe with small fonts, it would be also cool to have

.

rortega · Post by **rortega** » Mon Feb 10, 2014 10:57 am

Dear kataventos, I have got some crazy ideas in mind (please dont kill me)...a radar on screen.

I know that it is dificult and need extra hardware and extra code, of course, but every time that Jacobo and I fly our quads at the same time we havewe think that could be

int77 · Post by **int77** » Mon Feb 10, 2014 1:47 pm

Looks fast and promising. What kind of timings are you using?

Home direction indicator is missing… BTW, i've played a little bit around that on my side, it might be something like this:
http://www.youtube.com/watch?v=7VzikVJfZEI Probably too small, but I’ve tested it in the field yesterday, and it seems to be OK in real flight conditions… any way, might be extended to more than one character pattern if better resolution needed.

About code size – if you’re starting from scratch probably it’s a good time to review a little bit code structure to have more efficient usage of the memory. I can comment on that next time if it’s interesting. Would be good to keep in MWii-HUD some features allowing configuring MWii FC.

Hobby pilots seem to be interested by HUD concept…

whakahere · Post by **whakahere** » Mon Feb 10, 2014 4:49 pm

I have a witespy board and I have updated to the latest 2.2

I would like to put the current sensor data and I do have a 100amp TBS current sensor. I believe I can connect this to the board. It does have three wires (grn,+ve,sig) Since I am pulling the voltage from the naze32 board what do I have to connect to the minimosd board?

Do I just connect the signal wire to VIOUT and leave the grn and +ve as I am already getting that data? Will the current sensor work?

teslahed · Post by **teslahed** » Sun Feb 23, 2014 2:28 pm

kataventos wrote:Hi Int77,

yep, have been studding

This must not be mistaken with the OSD 2.3 dev that will be released soon.

Is it sad that i've been checking https://code.google.com/p/rush-osd-deve ... loads/list most days for the next release?

Need anyone to help beta test it? I can't wait for the new current sensor options to be available. I have my current sensor all wired up and ready to go!

LeoLeo · Post by **LeoLeo** » Tue Feb 25, 2014 2:43 pm

Dear developers of the OSD,

I have some Problems allready described in this thread: viewtopic.php?f=17&t=4720
Since I was not sure if this error is coming from the OSD, I made a general thread for it.

After more than 6 hours of reading in this thread here (back to page 74) I saw one guy who seemed to have the same problem as I have.
Since you made fun of him I'm not sure if it's a good idea to even post here.

Anyway, maybe you guys could have a look at my above mentioned thread. I even uploaded a video on youtube where you can see the home arrow not pointing to home position, distance values wrong and speed wrong.

Regards,
Leo

shikra · Post by **shikra** » Wed Feb 26, 2014 1:45 pm

Leo,

Unfortunately there is a MW bug affecting I2C GPS users - at least for some of the features you mention. Its not KVOSD fault...
I'm surprised its not commented on more often.

You are welcome to try my version which has a fix implemented. Need to enable //#define I2CGPS in config.h

Files are here:

http://www.flypix.co.uk/ftp

LeoLeo · Post by **LeoLeo** » Wed Feb 26, 2014 3:03 pm

Hello shikra,

thank you for your answer and your code. On what revision is this based?
As I see it, the only thing your patch changes is this:

Code: Select all

#if defined I2CGPS
    GPS_speed = read16()*10;
#else
    GPS_speed = read16();
#endif

Since we have bad weather today, I'm not able to test it. Since the error relies in MWii (as you say), I fear that the lower digits of the speed get truncated by only multiplying by 10.

Best regards,
Leo

PS: since this is offtopic, could some moderator move these three posts to my above mentioned thread?

shikra · Post by **shikra** » Wed Feb 26, 2014 3:20 pm

yep - I2C speed is in dcms, you'll not loose any resolution e.g. 100 dcms form I2C = 1000 converts to 35kmh

Sorry to kv for offtopic - I'll drop you a pm...

LeoLeo · Post by **LeoLeo** » Wed Feb 26, 2014 3:32 pm

Thanks shikra, that solves at least one of my problems.

How is the direction of the home arrow determined? Does it somehow include the heading information of the gps?
Since the gps can only determine a heading while actually flying in a certain direction, may this be some cause of a bug?

At ground with the GUI attached I can't see any "jumping" of the MAG value. If the OSD only relies on the MAG data, I don't see why it could jump (as seen in my Video http://www.youtube.com/watch?v=ag_R_i92bzI).

Leo

JirkaA · Post by **JirkaA** » Tue Mar 04, 2014 9:17 am

Hi guys,

yesterday I enlive my MinimOSD with Crius AIUP v2. Everything seems to be worked when OSD is connected to ftdi port together with BT module (of course, OSD has connected RXD only), but until GUI connection through BT only. When I disconnect GUI, OSD data are not updated anymore. Is there an posibility how to connect OSD idependently on GUI to another serial port? Thank you for answers..

Fred31 · Post by **Fred31** » Tue Mar 04, 2014 11:01 am

Hello all,

Does anyone use the last development version available under https://code.google.com/p/rush-osd-development/source/list?name=default:
952249bf7491 ; Currently working on moving EEPROM to 16bit resolution. Volume values for Dist and Alt meantime changed. ; Jan 11, 2014 ; Cat...@Kataventos.lan

I have successfully compile and download the sketch on my MinimOSD board.
But when I compile and tun the KV_TEAM_OSD_Gui, I have an error when I open the Serial port associated to my FTDI. I'm running Windows 8.1 64bit and Windows 7 64bit.
I have compiled the interface through processing 2.1.1 (64bit) and 1.5.2 with the associated ControlP5 library.

Does anyone reach to use the KV_TEAM_OSD_GUI from the last development version?

Thank you

Frédéric

Gartenflieger · Post by **Gartenflieger** » Wed Mar 05, 2014 4:08 pm

I think the development is not actually going on in the google code repository.
Non-developers are supposed to use the 2.2 download.

Regards
Christoph

scrat · Post by **scrat** » Thu Mar 06, 2014 10:16 am

Kataventos are you here? We need info when v2.3 will be released.

Fred31 · Post by **Fred31** » Fri Mar 07, 2014 10:15 am

Gartenflieger wrote:I think the development is not actually going on in the google code repository.
Non-developers are supposed to use the 2.2 download.

Regards
Christoph

Thank your response.

So, I will wait the official KV Team OSD 2.3 Version.

Best regards

Fred

strachg · Post by **strachg** » Fri Mar 07, 2014 8:17 pm

Hi folks can anyonevyell me how to disable some of the overlay like rssi. I don't use it and would like To remove it from the screen any help would be appreciated. Thanks

Gartenflieger · Post by **Gartenflieger** » Fri Mar 07, 2014 8:41 pm

You can either dig into the source code and remove it there or wait for the 2.3 release where the display items will be user-configurable.

regards
Christoph

strachg · Post by **strachg** » Fri Mar 07, 2014 8:48 pm

Hi Christoph can u tell me where this code is and is it just a case of undefining it

Gartenflieger · Post by **Gartenflieger** » Fri Mar 07, 2014 8:54 pm

I have no idea. Maybe just run a search for RSSI.

carlonb · Post by **carlonb** » Fri Mar 07, 2014 9:38 pm

strachg wrote:Hi Christoph can u tell me where this code is and is it just a case of undefining it

Which version are you using? I can address you...
Cheers
carlo

strachg · Post by **strachg** » Fri Mar 07, 2014 10:08 pm

Hi carlo I'm using version 2.2 and it's the witespy board and I'm using multiwii version 2.3 thanks

carlonb · Post by **carlonb** » Fri Mar 07, 2014 10:29 pm

strachg wrote:Hi carlo I'm using version 2.2 and it's the witespy board and I'm using multiwii version 2.3 thanks

Hi strachg,
Switch the OSD ON and with the RC sticks go to page 8 of OSD menu'.
Go with the cursor under ITEM and with the yaw stick select the item you want, RSSI in your case.
Move the cursor under DSP (Display) and with yaw select OFF.
Move the cursor to the bottom line SAVE-EXIT and with yaw stick save and exit...
That's all.
Bye

strachg · Post by **strachg** » Fri Mar 07, 2014 10:36 pm

Hi carlo. I don't have that option on any screen. The only thing on screen 8 is gps nothing else

strachg · Post by **strachg** » Fri Mar 07, 2014 10:45 pm

Hi carlo. I got it ignore my last post. Thank you very much all sorted now.

One last thing. When I plug the 4 s lipo in to read voltage on display it works fine but I get a light coloured band right through the screen where the text is.

carlonb · Post by **carlonb** » Sat Mar 08, 2014 10:34 am

strachg wrote:Hi carlo. I got it ignore my last post. Thank you very much all sorted now.

One last thing. When I plug the 4 s lipo in to read voltage on display it works fine but I get a light coloured band right through the screen where the text is.

I don't understand exactly what you see on the screen, but I think no matter about the 4S lipo voltage readings. May be a supply/ground issue ?
Show me with a pict to see better.
Bye

ABL · Post by **ABL** » Sat Mar 08, 2014 10:48 am

carlonb wrote:Switch the OSD ON and with the RC sticks go to page 8 of OSD menu'.
Go with the cursor under ITEM and with the yaw stick select the item you want, RSSI in your case.
Move the cursor under DSP (Display) and with yaw select OFF.
Move the cursor to the bottom line SAVE-EXIT and with yaw stick save and exit...

You can't turn off RSSI with this. Option is "Off", but RSSI stays on screen.
This is one of many issues (i won't say "bugs" because there's none) with 2.2. Not sure why you stopped upload code to google code - someone could just fix that, but now, if i understand correctly there are two code forks (one in google code, another in your PC, "unreleased 2.3").
And no, i didn't started to use kv-osd again - tested on ground ;-)

carlonb · Post by **carlonb** » Sat Mar 08, 2014 11:08 am

ABL wrote:
carlonb wrote:Switch the OSD ON and with the RC sticks go to page 8 of OSD menu'.
Go with the cursor under ITEM and with the yaw stick select the item you want, RSSI in your case.
Move the cursor under DSP (Display) and with yaw select OFF.
Move the cursor to the bottom line SAVE-EXIT and with yaw stick save and exit...

You can't turn off RSSI with this. Option is "Off", but RSSI stays on screen.
This is one of many issues (i won't say "bugs" because there's none) with 2.2. Not sure why you stopped upload code to google code - someone could just fix that, but now, if i understand correctly there are two code forks (one in google code, another in your PC, "unreleased 2.3").
And no, i didn't started to use kv-osd again - tested on ground

Hi ABL, that's true, there is a second fork in our developer PC

The MASTER of KV OSD site and google code repository (my friend Kataventos) I know he's is very busy now with it's job so the project go on very slow but we have many improvements to commit. Have patience.

About RSSI issue in vers. 2.2....I wil take a look...I never seen this.

Bye
carlo

strachg · Post by **strachg** » Sat Mar 08, 2014 11:13 am

Hi carlo. I use goggles so can't take picture but it's exactly the same as this one http://static.rcgroups.net/forums/attac ... 1342428122

carlonb · Post by **carlonb** » Sat Mar 08, 2014 11:46 am

strachg wrote:Hi carlo. I use goggles so can't take picture but it's exactly the same as this one http://static.rcgroups.net/forums/attac ... 1342428122

OK, I saw, it's not easy to say why... are you sure about power supply, no strange loops with GND, have you mod the WITESPY OSD as indicated in his site or in KV OSD TEAM site ?
http://code.google.com/p/rush-osd-development/wiki/Supported_Hardware

P.S.: What about RSSI OFF ? I'm looking for infos, please look at the previous post, ABL seems still have RSSI issue.
Bye
Carlo

strachg · Post by **strachg** » Sat Mar 08, 2014 2:46 pm

Hi Carlo, I have the latest witespy board which has all the mods built in. on the fc side of the board i have +5v, ground, tx and rx connected on the video side i have video in and vide out connected only. everything works great but when i plug the main battery into batt 1 or 2 the white streaks appear. I read elsewhere that this can be because the minimosd is to bright but i cant see anywhere in the code to reduce brightness. Oh and rssi is still appearing even after switching to off in menu 8. thanks.

carlonb · Post by **carlonb** » Sat Mar 08, 2014 6:04 pm

strachg wrote:......
Oh and rssi is still appearing even after switching to off in menu 8. thanks.
.......

Hi strachg,
Here the code mod for RSSI BUG, add the lines in red on RSSI display routine in file screen.ino . This bug is already solved in next release.

Bye, Carlo

void displayRSSI(void)
{
if(!(MwSensorActive&mode_osd_switch) || rssi<=(Settings[S_RSSI_ALARM]+5)){
if(Settings[L_RSSIPOSITIONDSPL]){ // Add this line
if(rssi <=(Settings[S_RSSI_ALARM]) && !BlinkAlarm){
screenBuffer[0] = SYM_RSSI;
return;
}
screenBuffer[0] = SYM_RSSI;
// Calcul et affichage du Rssi
itoa(rssi,screenBuffer+1,10);
uint8_t xx = FindNull();
screenBuffer[xx++] = '%';
screenBuffer[xx] = 0;
MAX7456_WriteString(screenBuffer,((Settings[L_RSSIPOSITIONROW]-1)*30) + Settings[L_RSSIPOSITIONCOL]);
} // Add this line
}
}

subaru4wd · Post by **subaru4wd** » Sat Mar 08, 2014 6:27 pm

So, what seem to be the hold-up with v2.3?

You mention these bugs are already resolved. What is the final step before release? I hear PWM RSSI is fully opterational in v2.3 as well? These are things a lot of us are waiting (patiently) for the past several months for.

No pressure, just... nobody else seems to be writing MultiWii compatible firmware for this stuff. So a lot of people are depending on you.

Thanks Carlo & Katavenos!

juanquy · Post by **juanquy** » Sun Mar 09, 2014 7:59 am

Please help:

I have this compiling error:

Error compiling:
In file include from KV_Team_OSD.ino:28:0:
GlobalVariables.h:714:32: error: variable 'item_table' must be const in order to be put into read-only section by means of '__attribute__((progmen)) '

KV_Team v2.3
Ubuntu 13.10, Arduino IDE 1:1.0.5+dfsg2-1

p.s
Tried the file KV_Team_OSD v2.2 (dev-r345) Feb 2013 and compile + upload was successful.

help please

JC