KV Team Multiwii OSD

postaL · Post by **postaL** » Wed Mar 06, 2013 5:57 am

Macbook air running 10.7.5.

Uploaded firmware ok.

GUI has a hiccup when changing the display property on items (on/off) and it updating in the preview area.

Doesn't seem to work w/ timecops Baseflight.

howardhb · Post by **howardhb** » Wed Mar 06, 2013 6:14 am

Just one question:
When using the "callibrate Acc" function from OSD, the acc does callibrate, but the values Acc Roll, Pitch and Z display 0
Should "live" MW values be displayed?

H.

kataventos · Post by **kataventos** » Wed Mar 06, 2013 3:14 pm

postaL wrote:Macbook air running 10.7.5.

Uploaded firmware ok.

GUI has a hiccup when changing the display property on items (on/off) and it updating in the preview area.

Doesn't seem to work w/ timecops Baseflight.

Hi,
first of all take a look at the tutorials/Wiki... you don´t even have the correct char map installed.

As for time-cop base-flight!!?? Our software is suppose to work with MW latest developments, we don´t use "private" base-flights to developments.

EDIT: GU´s screen will have a new and dedicated propose in future, don´t mind that for now!

kataventos · Post by **kataventos** » Wed Mar 06, 2013 3:19 pm

howardhb wrote:Just one question:
When using the "callibrate Acc" function from OSD, the acc does callibrate, but the values Acc Roll, Pitch and Z display 0
Should "live" MW values be displayed?

H.

Hi,
no and yes! at this time you have no output for those values, but I think that is useful so, we will change that for next release.

KV

copterrichie · Post by **copterrichie** » Wed Mar 06, 2013 3:23 pm

Just a thought for the next release: Add a feature to change the polling/Frequency rate.

postaL · Post by **postaL** » Wed Mar 06, 2013 4:50 pm

kataventos wrote:Hi,
first of all take a look at the tutorials/Wiki... you don´t even have the correct char map installed.

As for time-cop base-flight!!?? Our software is suppose to work with MW latest developments, we don´t use "private" base-flights to developments.

EDIT: GU´s screen will have a new and dedicated propose in future, don´t mind that for now!

I installed the character map as per the instructions on the website. When viewing the character map in the GUI, it shows as the right font.

As for working w/ baseflight, I just went out on a limb hoping that it would work since it's a fork of MW.

...guess I was wrong.

copterrichie · Post by **copterrichie** » Wed Mar 06, 2013 4:59 pm

If baseflight serial handler is the same as MW, then there is no reason it should not work. The MWC GUI works with baseflight right?

postaL · Post by **postaL** » Wed Mar 06, 2013 5:10 pm

copterrichie wrote:If baseflight serial handler is the same as MW, then there is no reason it should not work. The MWC GUI works with baseflight right?

It does. good point mr richie! (theCLAN!)

I only have the tx from the FC, to the rx of the minimosd hooked up, as I read somewhere that since I wasn't looking to use the PID tuning from it, I didn't need the minimosd to talk back to the FC. Guess i'll try hooking both up and see if that helps.

kataventos · Post by **kataventos** » Wed Mar 06, 2013 5:22 pm

postaL wrote: Guess i'll try hooking both up and see if that helps.

So, definitely that is your problem! on the wiki you have that information. The requests must be answered since start of communication or no communication at all

Probably you read that on AP site.

But, what went wrong with the char map upload?

It must be installed by the GUI and the new .mcm is on the data folder.

KV

postaL · Post by **postaL** » Wed Mar 06, 2013 5:53 pm

kataventos wrote:
postaL wrote: Guess i'll try hooking both up and see if that helps.

So, definitely that is your problem! on the wiki you have that information. The requests must be answered since start of communication or no communication at all
Probably you read that on AP site.

But, what went wrong with the char map upload?

It must be installed by the GUI and the new .mcm is on the data folder.

KV

Thanks for the reply KV, I'll go solder the other lead and hopefully that corrects everything.

As for the font, It was installed using the GUI.

Browse for font, select the right .mcm.

Prompted that font loaded correctly, click OK.

Click "upload". Wait 30 seconds while it goes through each of the 256 characters.

I will report back soon.

postaL · Post by **postaL** » Wed Mar 06, 2013 6:18 pm

Making steps forward... baby steps, but steps none the less.

(side note: DISARMED doesn't go away when armed).

FYI, this is a RCtimer MinimOSD clone.

http://www.rctimer.com/index.php?gOo=go ... oductname=

copterrichie · Post by **copterrichie** » Wed Mar 06, 2013 6:21 pm

For one, you need to reload the fonts.

postaL · Post by **postaL** » Wed Mar 06, 2013 6:23 pm

copterrichie wrote:For one, you need to reload the fonts.

Loaded the font 3 times now :/

copterrichie · Post by **copterrichie** » Wed Mar 06, 2013 6:23 pm

With the LATEST? I think not.

postaL · Post by **postaL** » Wed Mar 06, 2013 6:26 pm

latest file that is on application.macOSX > data > MW_FONT_OSD.mcm

r345

edit: trying w/ r340 now.

kataventos · Post by **kataventos** » Wed Mar 06, 2013 6:33 pm

postaL wrote:(side note: DISARMED doesn't go away when armed).

FYI, this is a RCtimer MinimOSD clone.

http://www.rctimer.com/index.php?gOo=go ... oductname=

I think that this OSD works just fine but you must not forget to power the 12v side to upload the char map as I said before here!

After you have a success font upload with the GUI and using the new font map, you must define on GUI to use (BOX NAMES and not BOX IDS) I presume...
I don´t know what is the date of the MW firmware you are using but does not have BOXIDS for sure, in that case you need to use BOXNAMES for correct recognition, to be honest I don´t even know if it will work I´m afraid!

I suggest you to use latest developments for accurate info on altitude/others and to take full advantage of the OSD actual firmware.

Hope this can help you, good luck!

KV

copterrichie · Post by **copterrichie** » Wed Mar 06, 2013 6:34 pm

Dude, for someone that dishes out a load of crap, you surely are behind.

http://code.google.com/p/rush-osd-development/ Current is R345

kataventos · Post by **kataventos** » Wed Mar 06, 2013 6:39 pm

copterrichie wrote:Dude, for someone that dishes out a load of crap, you surely are behind.

http://code.google.com/p/rush-osd-development/ Current is R345

If he is running the app on a MAC I think that he will have no problem on using r340, but I think that the main problem is that he forgot to power the 12v side for uploading the char map.

copterrichie · Post by **copterrichie** » Wed Mar 06, 2013 6:40 pm

kataventos wrote:
copterrichie wrote:Dude, for someone that dishes out a load of crap, you surely are behind.

http://code.google.com/p/rush-osd-development/ Current is R345

If he is running the app on a MAC I think that he will have no problem on using r340, but I think that the main problem is that he forgot to power the 12v side for uploading the char map.

Well, he can also make the modification to 5V as I did.

kataventos · Post by **kataventos** » Wed Mar 06, 2013 6:55 pm

copterrichie wrote:
kataventos wrote:
copterrichie wrote:Dude, for someone that dishes out a load of crap, you surely are behind.

http://code.google.com/p/rush-osd-development/ Current is R345

If he is running the app on a MAC I think that he will have no problem on using r340, but I think that the main problem is that he forgot to power the 12v side for uploading the char map.

Well, he can also make the modification to 5V as I did.

You have no jumpers to solder on that version, but I do think that it would work with 5v on the 12v side... one thing is for sure, it needs to be powered for a successful upload!
Of course that if you have good electronic skills you can bypass the regulator and mod to work with the 5v of the ATmel side...

postaL · Post by **postaL** » Wed Mar 06, 2013 6:57 pm

Ok. I must have missed the whole "power w/ 12v on that side when uploading font" part. My mistake.

It shows everything correctly now. It just doesn't show "ARMED" when armed, nor which flight mode i'm in. (with r345). I will try r340 to see if it has the same issue.

richie, pipe down and go back to the corner. i'm done talking to you.

kataventos · Post by **kataventos** » Wed Mar 06, 2013 7:23 pm

postaL wrote:Ok. I must have missed the whole "power w/ 12v on that side when uploading font" part. My mistake.

It shows everything correctly now. It just doesn't show "ARMED" when armed, nor which flight mode i'm in. (with r345). I will try r340 to see if it has the same issue.

richie, pipe down and go back to the corner. i'm done talking to you.

OK PostaL 95% done,

now you have to choose BOXNAMES instead of BOXIDS on GUI, if that does not work please change your MW version to latest one besides, you will have the OSD Switch that is useful for cleaning up the center of the screen !
Using r340 will not make a difference because the only change was the font upload routine as you can see on changes doc.

Please report an image of it working too like the ones that you reported not working! people normally just report when the stuff don´t work...

For example do you use NTSC or PAL, 16:9 or 4.3 screen? position stuff on screen on different users hardware is important to us because sometimes the stuff work but not as we intended to or the same as shown on developers hardware, this kind of stuff is important to us and can be changed to match correctly on different setups

Thanks Postal,
KV

PS: for example, things layout should be like the one you see here: viewtopic.php?f=8&t=2918&start=220#p32006

postaL · Post by **postaL** » Thu Mar 07, 2013 2:36 am

Success!

Thank you KV for walking me through it.

It's setup w/ a Pixim Sealwolf camera, NTSC. I Imagine its a 4.3 screen.

Is there a way to reposition where things are on screen?

/me goes and reads wiki again.

copterrichie · Post by **copterrichie** » Thu Mar 07, 2013 2:48 am

Good, now back to your den before I get a can of RAID. LOL

kataventos · Post by **kataventos** » Thu Mar 07, 2013 3:00 am

postaL wrote:Success!

Thank you KV for walking me through it.

It's setup w/ a Pixim Sealwolf camera, NTSC. I Imagine its a 4.3 screen.

Is there a way to reposition where things are on screen?

/me goes and reads wiki again.

Nice, glad to help

looking good on that setup.

For your question, not at this time I´m afraid to say, it is our next step 8-)

that is why I told before here to not bother with the GUI screen at this moment!

PS: Remember that every value on screen is MW dependent, and I see there (-23ft) on altitude... that is a 7 meters error in just 1:04 min, you should consider to update your MW code to "trust" your altitude!

Have fun,
KV

kataventos · Post by **kataventos** » Thu Mar 07, 2013 3:03 am

copterrichie wrote: !

copterrichie · Post by **copterrichie** » Thu Mar 07, 2013 3:04 am

kataventos wrote:
copterrichie wrote: !

It's personal. :mrgreen:

kataventos · Post by **kataventos** » Thu Mar 07, 2013 3:06 am

@PostaL

forgot to ask if you are using RSSI over MW?

postaL · Post by **postaL** » Thu Mar 07, 2013 3:11 am

kataventos wrote:@PostaL

forgot to ask if you are using RSSI over MW?

Yes. And, I haven't calibrated the sensors yet, which is why it's off.

And don't mind richie, once a troll, always a troll.

howardhb · Post by **howardhb** » Thu Mar 07, 2013 7:23 pm

I just compiled the bug-fix for page 5. (KV_Team_OSD.ino Change log f3f051e8e945)
I can report that "live" acc values are now displayed

I made some minor changes to wording and removed colons....

I made a small change on page 6.
The position of the accumulated "DRAINED AMPS" was offset to the right.
Nothing serious but I wanted it to look perfect!
I edited Screen.ino:

Code: Select all

.
.
MAX7456_WriteString_P(configMsg57, LEVT);
    xx= pMeterSum / EST_PMSum;
    MAX7456_WriteString(itoa(xx,screenBuffer,10),LEVD-3);
.
.

kataventos · Post by **kataventos** » Fri Mar 08, 2013 7:56 pm

@Howardb

Hi,
that is a lot of happiness 8-)

sneaking on the repo...

In truth, you really unjustified that on screen :shock:

your idea is fine but is not the correct way of doing it.

Now for the changes:
1- colons make distinction between provided information and editable parameters;
2- RAW this and RAW that will only make the code grow bigger with information that you don´t need because it is obvious;
We are always trying to save a "bit" for really needed stuff, resources are very important.

Well, but in some point I must agree with you

and on the next release probably the layout will be as follows:

Or this:

Cheers,
KV

howardhb · Post by **howardhb** » Fri Mar 08, 2013 8:38 pm

Your wish, is my command, Obi-Wan Kenobi! :lol:

My changes were only an exercise in understanding how the code works and not intended to indicate anything else.

that is a lot of happiness

Keep up the good work!

H.

kataventos · Post by **kataventos** » Sat Mar 09, 2013 1:19 pm

howardhb wrote:Your wish, is my command, Obi-Wan Kenobi!

My changes were only an exercise in understanding how the code works and not intended to indicate anything else.

that is a lot of happiness

Keep up the good work!

H.

Hi Howardhb,

you are funny and make me laugh

Tell you what :roll:

you remind me when I started to go deep into this... Well, this is mainly a developers forum and for your efforts should say that we will take the colons out
(I don´t like them either even with all the good sense on their existence) and to change some more regarding your text ideas :ugeek:

So, keep up your happiness :mrgreen:

and the most important which this is all about...

Have fun.

KV

KasparsL · Post by **KasparsL** » Sun Mar 10, 2013 1:23 pm

Hi,
I am struggling to get the v345 fw working. i am compiling with Arduino 1.0.1 and uploading the hex with avr-asp.
I do not see anything on screen exept grey background. And the GUI seems not to change anything on the minimOSD board. If I change to minim, hit write, then read - it will show rushduino again. Am i missing something? The v2.1 works for me OK.

kataventos · Post by **kataventos** » Sun Mar 10, 2013 2:11 pm

KasparsL wrote:Hi,
I am struggling to get the v345 fw working. i am compiling with Arduino 1.0.1 and uploading the hex with avr-asp.
I do not see anything on screen exept grey background. And the GUI seems not to change anything on the minimOSD board. If I change to minim, hit write, then read - it will show rushduino again. Am i missing something? The v2.1 works for me OK.

Hi,

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

KasparsL · Post by **KasparsL** » Sun Mar 10, 2013 2:35 pm

kataventos wrote:
KasparsL wrote:Hi,
I am struggling to get the v345 fw working. i am compiling with Arduino 1.0.1 and uploading the hex with avr-asp.
I do not see anything on screen exept grey background. And the GUI seems not to change anything on the minimOSD board. If I change to minim, hit write, then read - it will show rushduino again. Am i missing something? The v2.1 works for me OK.

Hi,

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

Thanks for the link. It still doesnt work. I did like in the wiki - compiled and programmed via arduino. I did not change anything in the code, should I?

Can You post a hex file for minimOSD (I have v0.1) board to try?

kataventos · Post by **kataventos** » Sun Mar 10, 2013 4:48 pm

Hi,

you have to follow all steps carefully, to me you are not making the RESET on GUI! This is the only thing that comes to my mind...
First reset and then program it, why are you using the USBASP? You should use FTDI, honestly I don´t think you can program it with GUI that way.

Your options will programmed on GUI, no need to change config.h.

KV

PS: No hex posted because honestly it will not change a bit on your problem.

KasparsL · Post by **KasparsL** » Sun Mar 10, 2013 6:17 pm

kataventos wrote:Hi,

you have to follow all steps carefully, to me you are not making the RESET on GUI! This is the only thing that comes to my mind...
First reset and then program it, why are you using the USBASP? You should use FTDI, honestly I don´t think you can program it with GUI that way.

Your options will programmed on GUI, no need to change config.h.

KV

PS: No hex posted because honestly it will not change a bit on your problem.

I was programming the firmware using AVR-ASP. But I did upload the bootloader and programmed the minimOSD using FTDI dirrectly from Arduino IDE.
After that I run the GUI, sellect the COM port, connect, hit reset, confirm, hit restart. After change from rushduino to minimOSD, hit write. After hit read - and it reads back default values including rushduino board selected.

Should I see at least something on monitor after firmware is loaded?

power67 · Post by **power67** » Sun Mar 10, 2013 10:37 pm

Hi KasparsL,

It sounds like you are not getting proper comunication between the gui and the osd board. lets start by getting some more information.

What version of the code are you uploading to the arduino? what version of the gui?

when you say it reads back default values, what is being shown? Can you post a screen shot of the gui after you click read?

If your osd board is still saying that it is set for the rushduino, it will not show anything on the monitor.

I have the same min board and have done a great deal of development and testing with it.

lets get you fixed up.

Ross

dramida · Post by **dramida** » Sun Mar 10, 2013 11:18 pm

I had several FPV long flights with minim OSD and R345 of KV_Team and i found a serious bug which made me lose orientation several previous flights:

The Home arrow drifts 45 degrees left off target when starts to move back home from long trips.The change of home is at 3:17 when starting twords home from PH stationary position (i knew location visualy)

http://youtu.be/OFfTc9lNYXY?t=3m17s

At 3.58 the Home ( a row of cars on the fields) is straight in front , can see it visualy, but Home arrow heading is off by 45 degrees left

http://youtu.be/OFfTc9lNYXY?t=3m58s

After seeing the home location as i land, you could judge for yourself if you could reach home following home arrow. My two previous atempts failed and i brought the copter home visualy from a few hundreds meters.

I tested RTH and works right on target as i calibrated the mag previously. So the error must be in OSD.

postaL · Post by **postaL** » Mon Mar 11, 2013 2:04 am

If I can add a suggestion,

For the ALT reading, add an option that will allow it to 0 on arm.

ie: Sensor shows 539 ft when disarmed, when you arm and take off, your "home" point is 0 ft, instead of 539.

KasparsL · Post by **KasparsL** » Mon Mar 11, 2013 10:31 am

power67 wrote:Hi KasparsL,

It sounds like you are not getting proper comunication between the gui and the osd board. lets start by getting some more information.

What version of the code are you uploading to the arduino? what version of the gui?

when you say it reads back default values, what is being shown? Can you post a screen shot of the gui after you click read?

If your osd board is still saying that it is set for the rushduino, it will not show anything on the monitor.

I have the same min board and have done a great deal of development and testing with it.

lets get you fixed up.

Ross

Yes, it feels like there is no communication between GUI and minimOSD board. I am using files from archive KV_Team_OSD_dev_r345.zip (http://code.google.com/p/rush-osd-development/downloads/list)

I did try again at work, downloaded again the files, used Arduino 1.0.3 and USB to Serial adapter (CP2102 based).
I can compile and upload the firmware using Arduino, but after that I am stuck - the GUI seems not to change anything to the minimOSD.
I even tried to change the default board in firmware:

Code: Select all

1,   // S_BOARDTYPE

and also change the pin numbers for both rushduino an minimosd options to be "minimosd" ones like this:

Code: Select all

void MAX7456Configure() {
  // todo - automatically recognising card.
  if(Settings[S_BOARDTYPE] == 0) {   // Rush
    MAX7456SELECT = 6;      // ss 
    MAX7456RESET  = 10;       // RESET
  }

  if(Settings[S_BOARDTYPE] == 1) {   // MinimOSD
    MAX7456SELECT = 6;       // ss
    MAX7456RESET = 10;       // RESET
  }
}

, but it did not help, I do not see anything on monitor.

Here is the screenshot what i got: http://kaspars.id.lv/projects/osd_scrn_01.png

I can program the previous version (v2.1) and it works just fine.

howardhb · Post by **howardhb** » Mon Mar 11, 2013 3:01 pm

@kasparsL, I see on your screen-shot that your ftdi is connected to com9.

I had "issues" with SiLabs CP2102 com ports above #7 (Win7 64bit)
To change the com port number, in control panel, click on devices, ports: then right click on the com port and then click on advanced.
Change port number to be below 8.
Also, make sure the port is configured for 115200 baud, No parity and One Stop bit

Worked for me..... :ugeek:

carlonb · Post by **carlonb** » Mon Mar 11, 2013 3:05 pm

postaL wrote:If I can add a suggestion,

For the ALT reading, add an option that will allow it to 0 on arm.

ie: Sensor shows 539 ft when disarmed, when you arm and take off, your "home" point is 0 ft, instead of 539.

Which MWii version are you using?
I know that with an old MWii vers. at statup we had the absolute altitude, but with the newest MWii versions at startup we have the relative zero ft at ground.

Ciao, Carlo

KasparsL · Post by **KasparsL** » Mon Mar 11, 2013 5:36 pm

howardhb wrote:@kasparsL, I see on your screen-shot that your ftdi is connected to com9.

I had "issues" with SiLabs CP2102 com ports above #7 (Win7 64bit)
To change the com port number, in control panel, click on devices, ports: then right click on the com port and then click on advanced.
Change port number to be below 8.
Also, make sure the port is configured for 115200 baud, No parity and One Stop bit

Worked for me.....

Thanks for advice, but the USB to Serial works OK for me even on COM35. I can upload firmware from Arduino and communicate with devices. But I did try your sudgestion - I lowered the number to COM4 and set the default baud rate to 115200, but it did not help

Could someone please compile a hex file for minimOSD, which is working, so I could find the problem with my setup? I have 2x OSD boards, both acts the same, so i am doing something wrong.

postaL · Post by **postaL** » Mon Mar 11, 2013 5:47 pm

carlonb wrote:
postaL wrote:If I can add a suggestion,

For the ALT reading, add an option that will allow it to 0 on arm.

ie: Sensor shows 539 ft when disarmed, when you arm and take off, your "home" point is 0 ft, instead of 539.

Which MWii version are you using?
I know that with an old MWii vers. at statup we had the absolute altitude, but with the newest MWii versions at startup we have the relative zero ft at ground.

Ciao, Carlo

Ah, that must be it. I'm using a Naze32 board w/ Baseflight. (32 bit multiwii).

howardhb · Post by **howardhb** » Mon Mar 11, 2013 6:35 pm

@KasparsL, just for your tests, attached is a working hex file, compiled and tested working, a few minutes ago.
note: It has a few simple layout changes as described in my posts above....

KV_Team_OSD_HEX.zip: (23.89 KiB) Downloaded 312 times

kataventos · Post by **kataventos** » Mon Mar 11, 2013 7:48 pm

dramida wrote:I had several FPV long flights with minim OSD and R345 of KV_Team and i found a serious bug which made me lose orientation several previous flights:

The Home arrow drifts 45 degrees left off target when starts to move back home from long trips.The change of home is at 3:17 when starting twords home from PH stationary position (i knew location visualy)
...but Home arrow heading is off by 45 degrees left

After seeing the home location as i land, you could judge for yourself if you could reach home following home arrow. My two previous atempts failed and i brought the copter home visualy from a few hundreds meters.
I tested RTH and works right on target as i calibrated the mag previously. So the error must be in OSD.

Hi,
will try to reproduce the error flying far as soon as the weather permits. But at this moment I can say that I never had that problem and I can assure you plenty of flights with it.
I am not saying that the bug is not there, just saying that I need to reproduce in order to fix and so far so good...

Cheers,
KV

EDIT: Since what distance are you having that issue, can you say...?? One thing crossed my mind at this moment

kataventos · Post by **kataventos** » Mon Mar 11, 2013 7:51 pm

postaL wrote:
carlonb wrote:
postaL wrote:If I can add a suggestion,

For the ALT reading, add an option that will allow it to 0 on arm.

ie: Sensor shows 539 ft when disarmed, when you arm and take off, your "home" point is 0 ft, instead of 539.

Which MWii version are you using?
I know that with an old MWii vers. at statup we had the absolute altitude, but with the newest MWii versions at startup we have the relative zero ft at ground.

Ciao, Carlo

Ah, that must be it. I'm using a Naze32 board w/ Baseflight. (32 bit multiwii).

Have warned you before about that and pointed the altitude issue...

KasparsL · Post by **KasparsL** » Tue Mar 12, 2013 12:07 am

howardhb wrote:@KasparsL, just for your tests, attached is a working hex file, compiled and tested working, a few minutes ago.
note: It has a few simple layout changes as described in my posts above....

KV_Team_OSD_HEX.zip

Thanks for the hex! I tried it and it did not work. But after further research i have find out, that the isue is with EEPROM writing or reading. The eeprom is always empty (all 0xFF).
I changed the code like this:

Code: Select all

void readEEPROM(void)
{
  for(int en=0;en<EEPROM_SETTINGS;en++){
     Settings[en] = EEPROM_DEFAULT[en];
  }
}

and

Code: Select all

1,   // S_BOARDTYPE

It works like that, I see everything on screen, can controll it (simulate) and even font upload worked, but ofcorse cant change any settings....
I will try other eeprom writing code to make sure, that eeprom is not damaged.
Any other thoughts? I did not see any locks on memory, maybe i need to look elsewhere?