MultiWii OSD - MWOSD
Re: MultiWii OSD - MWOSD
Pro Mini (5v 16mhz) 328
but I tried Uno, Nano 328 and Mini 328 as well w/o any luck
but I tried Uno, Nano 328 and Mini 328 as well w/o any luck
Re: MultiWii OSD - MWOSD
Hey Shikra,
Not sure if this was reported or not, but I was flashing 4 OSDs and tried to do the save config stuff but it seems like anything that has 'Use MWii' is not preserved.
Here is a paste of the config file:
==
http://hastebin.com/udilijuwal.xml
==
I am using 1.3pre4
Not sure if this was reported or not, but I was flashing 4 OSDs and tried to do the save config stuff but it seems like anything that has 'Use MWii' is not preserved.
Here is a paste of the config file:
==
http://hastebin.com/udilijuwal.xml
==
I am using 1.3pre4
Re: MultiWii OSD - MWOSD
IS anyone else interested in adding this?
truhlik_fredy wrote:Nice OSD, I like it a lot, works pretty well. I have just one issue, I have headfree and head adjust modest setup to a pot (to save on Rx channels and save switches on transition). Now it's very easy to set it up to same undesired mode and forget it. Would be possible to add this mode to the OSD as well? I can see return to home, auto hold, acro, horizon, but I would like to have headfree & head-adjust added to them so I can clearly see in which mode I'm.
Re: MultiWii OSD - MWOSD
At first look - this appears to be a bug - and always been there !
ReadError wrote:Hey Shikra,
Not sure if this was reported or not, but I was flashing 4 OSDs and tried to do the save config stuff but it seems like anything that has 'Use MWii' is not preserved.
Here is a paste of the config file:
==
http://hastebin.com/udilijuwal.xml
==
I am using 1.3pre4
Re: MultiWii OSD - MWOSD
its hardware limit. can only utilise preset sprites...
quicker response line:
it currently update 20 times a second...
But is limited by the speed at which it receives data from the flight controller.
This can be improved, but at the cost to update speed for other info from flight controller.
using vsync and pwm rssi will slow down refresh rate.
Is this noticeable in flight - or playing on bench? I don't notice horizontal refresh speed issues it in flight at all...
quicker response line:
it currently update 20 times a second...
But is limited by the speed at which it receives data from the flight controller.
This can be improved, but at the cost to update speed for other info from flight controller.
using vsync and pwm rssi will slow down refresh rate.
Is this noticeable in flight - or playing on bench? I don't notice horizontal refresh speed issues it in flight at all...
bulesz wrote:Guys, just a quick question: making/having a graphics OSD instead of charset (sprite) based is hardware (MinimOSD) or software limited? For example having a quicker response horizon line... ?
Many thanks,
B
-
- Posts: 3
- Joined: Tue Feb 24, 2015 10:04 pm
Re: MultiWii OSD - MWOSD
Hey guys, complete noob with MWOSD and Arduino here, I'm really struggling. I've been able to connect my OSD to the GUI 1.2 and I can adjust most things (NOT all, I'll get to that eventually) but I can't get the thing to talk to Baseflight on my Naze32. I connect everything as required then get the DISARMED message and a few other fields but nothing else. I've checked and double-checked the Tx-Rx/Rx-Tx connection, which I understand is the main DOH!! issue.
It seems to be the problem with resetting baudrate, as described in FAQ 11 and on Page 6 of this thread. There also seems to be a requirement to enable BASEFLIGHT somewhere.
I just can't work out how to reset baudrate and see if that solves the problem. The User Guide for the GUI says to "minimize the PORT COM tab to access and change (baudrate)", but when I do that I see nothing appear on the GUI relevant to baudrate. I have no idea what config.h is, to set it that way; I assume it's some type of CLI editor, but I don't see the options on the GUI screen or elsewhere.
To complicate matters I'm one of those weirdo Mac users. I am using Parallels and WinXP, and the GUI is working fine. As far as I can tell it's reading and writing correctly. In this particular case I'm sure it's not a Mac related issue.
Sorry to ask noob questions, I've trawled through this thread, but it seems I don't have the required level of assumed knowledge. Any help would be appreciated!
EDIT: I've found the config.h file, it just seems to be a text file I opened on WordPad with information only. I take it that's not actually what I'm required to edit, I'll need some sort of Arduino editor? I've found Arduino Manager on the MacApp store, does anyone know if that works OK?
It seems to be the problem with resetting baudrate, as described in FAQ 11 and on Page 6 of this thread. There also seems to be a requirement to enable BASEFLIGHT somewhere.
I just can't work out how to reset baudrate and see if that solves the problem. The User Guide for the GUI says to "minimize the PORT COM tab to access and change (baudrate)", but when I do that I see nothing appear on the GUI relevant to baudrate. I have no idea what config.h is, to set it that way; I assume it's some type of CLI editor, but I don't see the options on the GUI screen or elsewhere.
To complicate matters I'm one of those weirdo Mac users. I am using Parallels and WinXP, and the GUI is working fine. As far as I can tell it's reading and writing correctly. In this particular case I'm sure it's not a Mac related issue.
Sorry to ask noob questions, I've trawled through this thread, but it seems I don't have the required level of assumed knowledge. Any help would be appreciated!
EDIT: I've found the config.h file, it just seems to be a text file I opened on WordPad with information only. I take it that's not actually what I'm required to edit, I'll need some sort of Arduino editor? I've found Arduino Manager on the MacApp store, does anyone know if that works OK?
Re: MultiWii OSD - MWOSD
The config.h is a text file that can be edited in NotePAd, NotePad++, WordPad (or MAC equivalents) or in the Arduino IDE editor.
The Arduino Web site has some getting started guides that may be worth reading. The Arduino IDE is not hard to use and I think it does run on a MAC.
In the config.h file you will need to check for the correct lines are un-commented or commented out for the hardware you have.
This includes which minimOSD board (Witespy or Rushduino) and for using BaseFlight.
The OSD's Baud rate is also in there and defaults to 115200 which should work with BaseFlight.
Are you connecting the the correct Naze pins?
The last time I used a minimOSD with Baseflight it just worked.
I don't use a MAC (although I just bought one for my wife so am learning) so can't help with that part.
The Arduino Web site has some getting started guides that may be worth reading. The Arduino IDE is not hard to use and I think it does run on a MAC.
In the config.h file you will need to check for the correct lines are un-commented or commented out for the hardware you have.
This includes which minimOSD board (Witespy or Rushduino) and for using BaseFlight.
The OSD's Baud rate is also in there and defaults to 115200 which should work with BaseFlight.
Are you connecting the the correct Naze pins?
The last time I used a minimOSD with Baseflight it just worked.
I don't use a MAC (although I just bought one for my wife so am learning) so can't help with that part.
-
- Posts: 3
- Joined: Tue Feb 24, 2015 10:04 pm
Re: MultiWii OSD - MWOSD
waltr wrote:The config.h is a text file that can be edited in NotePAd, NotePad++, WordPad (or MAC equivalents) or in the Arduino IDE editor.
The Arduino Web site has some getting started guides that may be worth reading. The Arduino IDE is not hard to use and I think it does run on a MAC.
In the config.h file you will need to check for the correct lines are un-commented or commented out for the hardware you have.
This includes which minimOSD board (Witespy or Rushduino) and for using BaseFlight.
The OSD's Baud rate is also in there and defaults to 115200 which should work with BaseFlight.
Are you connecting the the correct Naze pins?
The last time I used a minimOSD with Baseflight it just worked.
I don't use a MAC (although I just bought one for my wife so am learning) so can't help with that part.
Thanks waltr. I've had some limited success. Worked out how to edit the serial.ino with Arduino IDE, set now to Baseflight and it seems to work. I'm seeing armed/disarmed, modes, heading, RSSI, and time. There are problems with the heading and GPS-derived data, which displays on the OSD, but don't make any sense (ie it shows 5-7 satellites, but doesn't acknowledge the craft is moving - speed, home arrow, heading don't change). Also not getting GPS coordinates on screen, even though I've set them to display on the GUI. Not able to enter the OSD menu mode using the sticks either.
So about half of it is working, but at least I'm getting comms.
Also having problems with the GUI. All the blue slider switches work fine, but the red value fields don't change at all, or require five or ten clicks to come to life. Any known issues there?
And yes, everybody, EVERYBODY tells me MinimOSDs "just work". Except mine. I'm probably up to 10 hours worth of work on this OSD, and I've clearly got at least that again until it's right...
Those Vector systems look great...
-
- Posts: 3
- Joined: Tue Feb 24, 2015 10:04 pm
Re: MultiWii OSD - MWOSD
OK I've worked through a bunch of issues now. For any other noobs like me, here are some solutions. For the experts, you can chuckle along...
1. GPS - still haven't quite solved this one, but the baudrate of my GPS is 38k, but it had somehow gone back to the 115k default in Baseflight. Changed in back to 38k, works fine. Now wait and see if it defaults back...
2. Position info on OSD (speed, home arrow and distance) - will only appear when there is an adequate GPS fix AND the system is ARMED. Apparently home position is recorded when you arm, which is obviously the reference point the system needs.
3. Stick menus - you need to have FULL RATES for the stick menus to be selected. And DISARMED. I had very low rates dialled in for gimbal shots.
I haven't yet solved...
4. Heading - still don't know what's going on here. Correct heading is being displayed through Baseflight, but it's miles out on the OSD. It will show approximately the correct heading (+/- 20 degrees, which isn't great), then the heading value reduces or increases as I rotate left and right, but then settles back on the initial heading, even though the craft is perhaps 180 degrees away. No change if armed or disarmed. Have deselected and reselected on the GUI, no joy. Do I need to do the calibration dance like you do for NAZA? I didn't see anything like that on the Calibration wiki.
5. GPS Co-ordinates - still not displayed at the top of the screen where I selected it. Will try a couple of different HUD options. One of the FAQs refers to a fix which cures a problem where the top of the screen is cut off. Ran out of time to check that today.
6. Still can't enter any numbers in the red fields of the GUI. Now that the stick menu is working, I'll enter those preferences through the OSD.
So that's my extremely steep learning curve for today. I'd be interested to hear anyone else's experiences, either expert or noob.
1. GPS - still haven't quite solved this one, but the baudrate of my GPS is 38k, but it had somehow gone back to the 115k default in Baseflight. Changed in back to 38k, works fine. Now wait and see if it defaults back...
2. Position info on OSD (speed, home arrow and distance) - will only appear when there is an adequate GPS fix AND the system is ARMED. Apparently home position is recorded when you arm, which is obviously the reference point the system needs.
3. Stick menus - you need to have FULL RATES for the stick menus to be selected. And DISARMED. I had very low rates dialled in for gimbal shots.
I haven't yet solved...
4. Heading - still don't know what's going on here. Correct heading is being displayed through Baseflight, but it's miles out on the OSD. It will show approximately the correct heading (+/- 20 degrees, which isn't great), then the heading value reduces or increases as I rotate left and right, but then settles back on the initial heading, even though the craft is perhaps 180 degrees away. No change if armed or disarmed. Have deselected and reselected on the GUI, no joy. Do I need to do the calibration dance like you do for NAZA? I didn't see anything like that on the Calibration wiki.
5. GPS Co-ordinates - still not displayed at the top of the screen where I selected it. Will try a couple of different HUD options. One of the FAQs refers to a fix which cures a problem where the top of the screen is cut off. Ran out of time to check that today.
6. Still can't enter any numbers in the red fields of the GUI. Now that the stick menu is working, I'll enter those preferences through the OSD.
So that's my extremely steep learning curve for today. I'd be interested to hear anyone else's experiences, either expert or noob.
Re: MultiWii OSD - MWOSD
Ok, and yes, STICK Commands only work if the Stick End Point values exceed the mincheck and maxcheck values.
Never use GPS so have no answers there.
However, in the config.h file (not the .ino file) are #defines for GPS and other features. Check that these are not commented out.
Never use GPS so have no answers there.
However, in the config.h file (not the .ino file) are #defines for GPS and other features. Check that these are not commented out.
Re: MultiWii OSD - MWOSD
feature request in case it hasn't already been requested:
-ability to move items around via the GUI would be great
-option to add pitch&roll angle values to screen (unless it's already there & I didn't see it)
thanks
-ability to move items around via the GUI would be great
-option to add pitch&roll angle values to screen (unless it's already there & I didn't see it)
thanks
Re: MultiWii OSD - MWOSD
GUI based OSD editor is in current version
-
- Posts: 3
- Joined: Sun Mar 01, 2015 11:38 pm
Re: MultiWii OSD - MWOSD
2 questions i cant seem to find out.
1. Why are there 5 ino. files in MW OSD R1.3 pre3 and are you suppose to use them all? Just want to use the Naze32 Acro fc and the osd to show battery voltage, timer, and horizon.
2. Is R1.3 pre3 for quadcopters and r1.3 pre4 for fixed wing.
Thanks, Matt
1. Why are there 5 ino. files in MW OSD R1.3 pre3 and are you suppose to use them all? Just want to use the Naze32 Acro fc and the osd to show battery voltage, timer, and horizon.
2. Is R1.3 pre3 for quadcopters and r1.3 pre4 for fixed wing.
Thanks, Matt
-
- Posts: 3
- Joined: Sun Mar 01, 2015 11:38 pm
Re: MultiWii OSD - MWOSD
The reason I asked that question was because I could not for the life of me get the MWosd to work. The hud would not display at all. All I would see is the camera and no overlay of the hud. I actually got it to work finally but maybe one of you guys could figure out why it worked when I did what I did. I installed MWosd R1.3 pre4 on a Micro Minimosd from readytoflyquads.com. I selected NTSC is the gui. The the osd will not show overlay when ntsc is selected on my camera but when i select Pal on my camera the overlay works. I have the 600 camera from Fatshark, which came with my Predator 2 goggles. Does anyone know what would cause the osd to not work when the camera is on NTSC and thats what I selected in the GUI?
Thanks, Matt
Thanks, Matt
Re: MultiWii OSD - MWOSD
Deet wrote:GUI based OSD editor is in current version
How? The only thing thwt I was able to do within the GUI was turn OSD items on and off, but I didn't see any way to move them around (wasn't obvious to me at least).
What I'm referring to is a method for placing items in custom screen locations, similar to how it can be done using the original APM/minimOSD configuration tool.
-
- Posts: 3
- Joined: Sun Mar 01, 2015 11:38 pm
Re: MultiWii OSD - MWOSD
Figured out what it was the fatshark manual is incorrect about the pal/ntsc jumper being in is pal being out is ntsc.
Rubadub- in R1.3 pre4 all the way to the right if you click on layout editor you can move items around to were you want them. Click on the plus or minus next to text and select which item you want to move then click on the up,down,right, or left button to move item.
Rubadub- in R1.3 pre4 all the way to the right if you click on layout editor you can move items around to were you want them. Click on the plus or minus next to text and select which item you want to move then click on the up,down,right, or left button to move item.
Re: MultiWii OSD - MWOSD
I'm trying MultiWii OSD for the first time. I hooked up my new board and flashed the latest firmware R1.3.
Bug: When I set the "Time Zone Offset" to say 2.0 and then do a "WRITE" the value will change (display) to 0.2.
Bug: When I set the "Time Zone Offset" to say 2.0 and then do a "WRITE" the value will change (display) to 0.2.
Re: MultiWii OSD - MWOSD
Noted- thanks. I can't verify, but understanding the conformational changes I think this is valid!
Leo wrote:I'm trying MultiWii OSD for the first time. I hooked up my new board and flashed the latest firmware R1.3.
Bug: When I set the "Time Zone Offset" to say 2.0 and then do a "WRITE" the value will change (display) to 0.2.
Re: MultiWii OSD - MWOSD
should the PWM RSSI feature work with the PWM RSSI signal from an FrSKy RX?
EDIT:
nevermind, it seems that FrSky PWM is too fast to read, so the only option is an RC filter.
Another question:
Even after enabling the VSYNC interrupt option, I'm still getting a line of specks/"sparklies" along the very top of the screen (NTSC video signal). Any ideas what might be causing this and how to fix? possibly a timing issue? I've worked extensively with the KV-OSD, which also uses the VSYNC interrupt algorithm, and have never had any issues with artifacts/"sparklies" showing up in the video. I'm making the effort to switch to MWOSD and give it a shot, but the constant presence of artifacts along the very top of the screen is very distracting and might be a deal breaker. Can one of the devs/shikra please look into this?
EDIT:
nevermind, it seems that FrSky PWM is too fast to read, so the only option is an RC filter.
Another question:
Even after enabling the VSYNC interrupt option, I'm still getting a line of specks/"sparklies" along the very top of the screen (NTSC video signal). Any ideas what might be causing this and how to fix? possibly a timing issue? I've worked extensively with the KV-OSD, which also uses the VSYNC interrupt algorithm, and have never had any issues with artifacts/"sparklies" showing up in the video. I'm making the effort to switch to MWOSD and give it a shot, but the constant presence of artifacts along the very top of the screen is very distracting and might be a deal breaker. Can one of the devs/shikra please look into this?
Re: MultiWii OSD - MWOSD
for rssi -
in config.h there is a fastrssi option, but note that for many of the frsky issues, actually it because they are not sending an rssi pww signal....... to make it mor confusing is seemed to change after a certain software version.. So try frsky rssi
for sparklies...
I have just tried - and unfortunately confirmed.... although it only seems to show up if using text on the top line like the GPS data in default. that may be because I am testing with no camera input.
I just loaded the KV 2.3 and its exactly the same ...
Canbe improved, but at compromise of slight reduction in screen refresh speeds. I'll see what can do.
Surprised no-one has mentioned before.
You may find that having VYSNC disabled is better - averaging out the sparklies across the screen might be less visually impacting
in config.h there is a fastrssi option, but note that for many of the frsky issues, actually it because they are not sending an rssi pww signal....... to make it mor confusing is seemed to change after a certain software version.. So try frsky rssi
for sparklies...
I have just tried - and unfortunately confirmed.... although it only seems to show up if using text on the top line like the GPS data in default. that may be because I am testing with no camera input.
I just loaded the KV 2.3 and its exactly the same ...
Canbe improved, but at compromise of slight reduction in screen refresh speeds. I'll see what can do.
Surprised no-one has mentioned before.
You may find that having VYSNC disabled is better - averaging out the sparklies across the screen might be less visually impacting
Re: MultiWii OSD - MWOSD
@rubadub
for sparklies...
Have just tested a solution for this and it seems to work well. Sparklies removed.
The downside - the screen will "only" approx 20 times a second.... as cinema films run at 24 frames a second I don't think anyone will notice the difference
Will include in future bugfix and can send you file to test if needed
for sparklies...
Have just tested a solution for this and it seems to work well. Sparklies removed.
The downside - the screen will "only" approx 20 times a second.... as cinema films run at 24 frames a second I don't think anyone will notice the difference
Will include in future bugfix and can send you file to test if needed
Re: MultiWii OSD - MWOSD
shikra wrote:for rssi -
in config.h there is a fastrssi option, but note that for many of the frsky issues, actually it because they are not sending an rssi pww signal....... to make it mor confusing is seemed to change after a certain software version.. So try frsky rssi
for sparklies...
I have just tried - and unfortunately confirmed.... although it only seems to show up if using text on the top line like the GPS data in default. that may be because I am testing with no camera input.
I just loaded the KV 2.3 and its exactly the same ...
Canbe improved, but at compromise of slight reduction in screen refresh speeds. I'll see what can do.
Surprised no-one has mentioned before.
You may find that having VYSNC disabled is better - averaging out the sparklies across the screen might be less visually impacting
Thanks Shikra,
I tried the fastrssi option but unfortunately it didn't work. I'm using the D8R-II Plus RX with 27ms CPPM firmware. I did a quick search through the thread, and apparently these FrSky receivers put out a weird PWM signal for RSSI that's too fast to be read with an ATMega328. Anyway, I ended up implementing an RC filter and it seems to work fine, although it would have been nice to avoid the filter and use pure PWM.
For the sparklies, I'll need to double check, but I'm almost positive that they're not present in KV-OSD. I just checked some flight recordings and the artifacts are not there (although maybe the DVR is trimming them out of the recordings). I initially tried it with VSYNC disabled (default), and it was pretty bad; a large, wide band of sparklies that slowly cylced vertically across the screen.
FYI, I'm running a very minimal OSD layout, with only voltage, rssi, flight time, flight mode, AH center line, and throttle. Nothing on the top lines or GPS data being shown.
Last edited by rubadub on Thu Mar 05, 2015 12:17 am, edited 1 time in total.
Re: MultiWii OSD - MWOSD
shikra wrote:@rubadub
for sparklies...
Have just tested a solution for this and it seems to work well. Sparklies removed.
The downside - the screen will "only" approx 20 times a second.... as cinema films run at 24 frames a second I don't think anyone will notice the difference
Will include in future bugfix and can send you file to test if needed
cool. sounds great.
So the 20Hz update rate will fix it? what was the old update rate? 10Hz? (haven't looked at the code yet).
Would 15Hz fix it, or is 20Hz the minimum to completely fix it?
Re: MultiWii OSD - MWOSD
update speed is not straightforward to describe. I made very rough approximation in answer. Here is a more detailed one, but also not the complete picture!
Frequency at which Screen is refreshed with data:
no vsync - as fast as it can. Continues looping with no waiting. Not tested actual.
vsync - limited to 50/60hz max.
vsync with fix - limited to 25/30 hz max. A very rough counter test looking like it was 22-24hz on PAL. Its close enough to PAL/ NTSC frame rate to be effectively the same.
Frequency at which data is updated from multiwii...
Attitude (AHI line) requested 10 times per second. Never verified how many actually received per second
Everything else from multiwii is requested approx twice per second
Direct analogue reading of volts / current to the osd is fastest - this is done at speed of screen refresh
PWM rssi slows down update a little ( unlikely to notice - maybe dropping screen refresh 24 times to 23 a second)
Frequency at which Screen is refreshed with data:
no vsync - as fast as it can. Continues looping with no waiting. Not tested actual.
vsync - limited to 50/60hz max.
vsync with fix - limited to 25/30 hz max. A very rough counter test looking like it was 22-24hz on PAL. Its close enough to PAL/ NTSC frame rate to be effectively the same.
Frequency at which data is updated from multiwii...
Attitude (AHI line) requested 10 times per second. Never verified how many actually received per second
Everything else from multiwii is requested approx twice per second
Direct analogue reading of volts / current to the osd is fastest - this is done at speed of screen refresh
PWM rssi slows down update a little ( unlikely to notice - maybe dropping screen refresh 24 times to 23 a second)
Re: MultiWii OSD - MWOSD
shikra wrote:@rubadub
for sparklies...
Have just tested a solution for this and it seems to work well. Sparklies removed.
The downside - the screen will "only" approx 20 times a second.... as cinema films run at 24 frames a second I don't think anyone will notice the difference
Will include in future bugfix and can send you file to test if needed
Hello shikra,
I've noticed the same issue with sparklies. The effect seems to be more pronounced when upgrading from MWOSD R1.2 to R1.3, even with vsync and fastpixel enabled. I can confirm with rubadub that KVOSD didn't have sparklies. I used it for some time, but upgraded to MWOSD some time ago since it has better features and more support .
Would you mind sending me the code to test as well?
Thank you!
Re:
HFMan wrote:Shikra,, if we put OSD on a soft serial port (Cleanflight), is 19,200 baud fast enough for the above polling frequency?
Yes. there will be a little slow down, but I still think will be good enough for most. Only a few years ago OSDs were 1 hz update speed.. Many still only run 5hz on the GPS.
Re: MultiWii OSD - MWOSD
Can you try downloading 1.3 again. I have just sneaked the hopeful fix.
No real change in that code area from 1.2 to 1.3
As an update....
I just retested this morning 1.1, 1.2, 1.3 and kv - all still give me sparklies on row 1 when I enable any characters on it!
KV only seems to have one character on it - so hardly notice it until other data there
I suspect maybe its always been there ? I do recall seeing it, but must admit I thought it was some video tearing issue
The cause is from trying to update 480 character positions for the display in the small time period before they start to displayed. It runs over - hence impacting row 1 first. The fix does is to spread the load across 2 field updates.
Anyway - hopefully we also now have this solved too. Its been interesting.
No real change in that code area from 1.2 to 1.3
As an update....
I just retested this morning 1.1, 1.2, 1.3 and kv - all still give me sparklies on row 1 when I enable any characters on it!
KV only seems to have one character on it - so hardly notice it until other data there
I suspect maybe its always been there ? I do recall seeing it, but must admit I thought it was some video tearing issue
The cause is from trying to update 480 character positions for the display in the small time period before they start to displayed. It runs over - hence impacting row 1 first. The fix does is to spread the load across 2 field updates.
Anyway - hopefully we also now have this solved too. Its been interesting.
GigaHurtz wrote:shikra wrote:@rubadub
for sparklies...
Have just tested a solution for this and it seems to work well. Sparklies removed.
The downside - the screen will "only" approx 20 times a second.... as cinema films run at 24 frames a second I don't think anyone will notice the difference
Will include in future bugfix and can send you file to test if needed
Hello shikra,
I've noticed the same issue with sparklies. The effect seems to be more pronounced when upgrading from MWOSD R1.2 to R1.3, even with vsync and fastpixel enabled. I can confirm with rubadub that KVOSD didn't have sparklies. I used it for some time, but upgraded to MWOSD some time ago since it has better features and more support .
Would you mind sending me the code to test as well?
Thank you!
Re: MultiWii OSD - MWOSD
Hello shikra,
I think your fix resolved the issue! MWOSD has never been clearer. I also really like the larger fonts in R1.3. Thanks so much for the continued development and support!
A quick unrelated question: With the Naze32 acro (which doesn't have a barometer, IIRC), is it possible to obtain altitude above ground level and display this on the OSD? For example, set the GPS altitude where the system is armed to a reference, and subtract the altitude from this in flight?
I think your fix resolved the issue! MWOSD has never been clearer. I also really like the larger fonts in R1.3. Thanks so much for the continued development and support!
A quick unrelated question: With the Naze32 acro (which doesn't have a barometer, IIRC), is it possible to obtain altitude above ground level and display this on the OSD? For example, set the GPS altitude where the system is armed to a reference, and subtract the altitude from this in flight?
Re: MultiWii OSD - MWOSD
Sorry I posted this in the FPV forum earlier, just found this tread and thought it was more appropriate here.
I'm having trouble setting up my team KV minimOSD and MultiWii pro ez3.0 Black board. Both from readytoflyquads flashed with MultiWii 2.4 (also tried 2.3) and MultiWii OSD 1.3. I've been successful in the past with all things MultiWii and I think I must be missing something simple. I am not able to get the boards talking to one another over the serial port. The strange thing is that I can get the boards to talk, but only over serial port 2 (GPS). I have to change the baud rate on the OSD to make this work of course. There seems to be something special about serial port 2 and I haven't been able to figure out what that is? I've tried all the normal trouble shooting, making sure the baud rate is correct and swapping the tx/rx.
So I know the OSD works because it does work using 57600 baud rate on serial port 2. It doesn't work on any other serial ports using any baud rate. I know the serial ports work because I can use the bluetooth module on them. What is special about serial port 2? I would simply use serial port 2, but the GPS won't work on other serial ports.
Any thought would be greatly appreciated!
Edit: There was something wrong might the FC board. I luckily had a second on lying around and flashed it was the same firmware and it worked fine. That was a headache, but glad I figured it out.
I'm having trouble setting up my team KV minimOSD and MultiWii pro ez3.0 Black board. Both from readytoflyquads flashed with MultiWii 2.4 (also tried 2.3) and MultiWii OSD 1.3. I've been successful in the past with all things MultiWii and I think I must be missing something simple. I am not able to get the boards talking to one another over the serial port. The strange thing is that I can get the boards to talk, but only over serial port 2 (GPS). I have to change the baud rate on the OSD to make this work of course. There seems to be something special about serial port 2 and I haven't been able to figure out what that is? I've tried all the normal trouble shooting, making sure the baud rate is correct and swapping the tx/rx.
So I know the OSD works because it does work using 57600 baud rate on serial port 2. It doesn't work on any other serial ports using any baud rate. I know the serial ports work because I can use the bluetooth module on them. What is special about serial port 2? I would simply use serial port 2, but the GPS won't work on other serial ports.
Any thought would be greatly appreciated!
Edit: There was something wrong might the FC board. I luckily had a second on lying around and flashed it was the same firmware and it worked fine. That was a headache, but glad I figured it out.
Re: MultiWii OSD - MWOSD
You need to ask the KV Team that question
Re: MultiWii OSD - MWOSD
Hello everyone,
So far I really like MWOSD 1.3. There is one issue that I'm having though with the artificial horizon. I can't seem to get it to track the actual ground that well...it seems to respond too slowly and doesn't seem to match the ground. It also doesn't track when doing 360 degree rolls. Note that my FPV camera is mounted on my plane (flying wing) at about a 5 degree downward angle.
In order to resolve any pitch misalignments, would I need to adjust the board pitch angle adjustment in baseflight?
Thanks!
So far I really like MWOSD 1.3. There is one issue that I'm having though with the artificial horizon. I can't seem to get it to track the actual ground that well...it seems to respond too slowly and doesn't seem to match the ground. It also doesn't track when doing 360 degree rolls. Note that my FPV camera is mounted on my plane (flying wing) at about a 5 degree downward angle.
In order to resolve any pitch misalignments, would I need to adjust the board pitch angle adjustment in baseflight?
Thanks!
Re: MultiWii OSD - MWOSD
hey can I add another possible feature request for the GUI?
In the font editor, please consider adding a couple of more options, such as:
- "clear" for clearing out an entire font image
- "copy/paste" for copying one font image onto another
- ability to manually edit the current font index, to be able to edit one font image and then save it at another index (I guess it's an alternative to copy/paste)
- ability to hold down mouse and drag, in order to 'draw' continuous lines/areas of a specific color
- basic 'swatch/color' selector (black, white, gray/transparent), so that you don't have to do the multi-click deal in order to switch between colors for each pixel (i.e., select 'black' and all subsequent pixels will be black, select white & all future clicked pixels will be white, etc.)
...there are probably a bunch of other things that could be added to that list, but it would require a lot more work and the goal isn't to turn it into a full-blown graphics editor. I just thought that it might be cool to add some better functionality into the built-in font editor.
In the font editor, please consider adding a couple of more options, such as:
- "clear" for clearing out an entire font image
- "copy/paste" for copying one font image onto another
- ability to manually edit the current font index, to be able to edit one font image and then save it at another index (I guess it's an alternative to copy/paste)
- ability to hold down mouse and drag, in order to 'draw' continuous lines/areas of a specific color
- basic 'swatch/color' selector (black, white, gray/transparent), so that you don't have to do the multi-click deal in order to switch between colors for each pixel (i.e., select 'black' and all subsequent pixels will be black, select white & all future clicked pixels will be white, etc.)
...there are probably a bunch of other things that could be added to that list, but it would require a lot more work and the goal isn't to turn it into a full-blown graphics editor. I just thought that it might be cool to add some better functionality into the built-in font editor.
Re: MultiWii OSD - MWOSD
While flying with MWOSD 1.3 and Cleanflight i realized my OSD compass is always pointed north no matter what. But whats odd, is when I am upside down my compass shows I am traveling South!?!
Re: MultiWii OSD - MWOSD
Is there a sketch for manually loading an .mcm font file directly instead of sending the characters over serial?
I'm having problems with what appears to be some kind of corruption of the font data in he MAX7456' EEPROM. When the OSD first starts up and before the start screen appears, I'll see a quick full-screen flash of all characters being set to the "number one" (instead of being blank). Then, I'll see what I initially thought was an extension of the sparklie problem, strange random white specks that only appear at the very top of the screen. I tried it on a couple of different minim's, and both initially were fine but then started displaying the same problems after a few font and sketch uploads.
The fact that the character for the number one seems to be sticking somehow and showing up in the background makes me think that there might be a corruption problem during the serial upload of the character data, so I'd like to see if I can upload the font file directly from a sketch instead of from the GUI over serial.
EDIT:
nevermind, found my own solution. I used Dennis Frie's font uploader sketch from his DIY OSD project.
Also, I found the cause of the problem with the white specks appearing on line one and with the strange behavior at startup with the entire screen being filled with one of the font characters instead of being all clear/blank.
The problem was that the 0x00 address space within the MW OSD default character map is currently occupied instead of being left blank, which seems to be the convention for these MAX7456 font files (it was being used for the SYM_AH_CENTER_LINE character). What I mistakenly believed to be a 'number one' character was actually this glyph for the AH center-line & it was being painted all over the screen. Since it was going by pretty fast, I thought it was a 'number one'. Upon closer inspection, I realized that it was one of the AH characters.
My solution was to move this AH character to an empty slot (address 0x26), redefine SYM_AH_CENTER_LINE as 0x26, and set the 0x0 address to store a 'blank' character. Upon doing this, the screen correctly went blank at startup,and the random specks at the top of the screen disappeared.
What I'm guessing happens is that, somewhere in the code, there's some attempt to clear or zero out the character map (such as to clear the screen). Thus, some of the memory slots were being filled with all zeros, which is in turn interpreted as character address 0x00 by the MAX7456. Since that particular address is usually reserved for a 'blank' character, it doesn't cause a problem, as essentially "nothing" is painted on the screen by referencing a zero address. However, since the default MWOSD font set is using 0x00 for that AH symbol, it apparently screwed things up.
Anyway, that's just a guess on my part, and I haven't looked deep into the code to find out what might be causing the screen buffer to be incorrectly filled with zeros instead of 'blank' ascii characters (character adress 0x20). Perhaps Shikra might be able to provide some insight into this?
I'm having problems with what appears to be some kind of corruption of the font data in he MAX7456' EEPROM. When the OSD first starts up and before the start screen appears, I'll see a quick full-screen flash of all characters being set to the "number one" (instead of being blank). Then, I'll see what I initially thought was an extension of the sparklie problem, strange random white specks that only appear at the very top of the screen. I tried it on a couple of different minim's, and both initially were fine but then started displaying the same problems after a few font and sketch uploads.
The fact that the character for the number one seems to be sticking somehow and showing up in the background makes me think that there might be a corruption problem during the serial upload of the character data, so I'd like to see if I can upload the font file directly from a sketch instead of from the GUI over serial.
EDIT:
nevermind, found my own solution. I used Dennis Frie's font uploader sketch from his DIY OSD project.
Also, I found the cause of the problem with the white specks appearing on line one and with the strange behavior at startup with the entire screen being filled with one of the font characters instead of being all clear/blank.
The problem was that the 0x00 address space within the MW OSD default character map is currently occupied instead of being left blank, which seems to be the convention for these MAX7456 font files (it was being used for the SYM_AH_CENTER_LINE character). What I mistakenly believed to be a 'number one' character was actually this glyph for the AH center-line & it was being painted all over the screen. Since it was going by pretty fast, I thought it was a 'number one'. Upon closer inspection, I realized that it was one of the AH characters.
My solution was to move this AH character to an empty slot (address 0x26), redefine SYM_AH_CENTER_LINE as 0x26, and set the 0x0 address to store a 'blank' character. Upon doing this, the screen correctly went blank at startup,and the random specks at the top of the screen disappeared.
What I'm guessing happens is that, somewhere in the code, there's some attempt to clear or zero out the character map (such as to clear the screen). Thus, some of the memory slots were being filled with all zeros, which is in turn interpreted as character address 0x00 by the MAX7456. Since that particular address is usually reserved for a 'blank' character, it doesn't cause a problem, as essentially "nothing" is painted on the screen by referencing a zero address. However, since the default MWOSD font set is using 0x00 for that AH symbol, it apparently screwed things up.
Anyway, that's just a guess on my part, and I haven't looked deep into the code to find out what might be causing the screen buffer to be incorrectly filled with zeros instead of 'blank' ascii characters (character adress 0x20). Perhaps Shikra might be able to provide some insight into this?
Re: MultiWii OSD - MWOSD
OK, today my QC got a new device installed:
(picture shows incomplete hookup)
Everything works like a charm. However it took me a while to figure out how to connect everything because the tips and howto's on the net wouldn't work with my setup.
I'll post a diagram of how I needed to put everything together once I've successfully completed a first flight with it.
Leo
(picture shows incomplete hookup)
Everything works like a charm. However it took me a while to figure out how to connect everything because the tips and howto's on the net wouldn't work with my setup.
I'll post a diagram of how I needed to put everything together once I've successfully completed a first flight with it.
Leo
Re: MultiWii OSD - MWOSD
Something odd happened today
My osd reads MWversion 0.0 ?
what can i do to fix this
0.0 means I cannot enter stick mode I tried KVteam and MWosd It happens on both so I fear my naze32 is the problem >
worked perfect yesterday ?
I measured with a voltmeter rx and tx pin and both give around 3v ..so i dont think its the actual board ?
I even reflashed my naze board band flashed the osd about 5 times ?
I am kinda stuck ..
all i done is swap some cabling
My osd reads MWversion 0.0 ?
what can i do to fix this
0.0 means I cannot enter stick mode I tried KVteam and MWosd It happens on both so I fear my naze32 is the problem >
worked perfect yesterday ?
I measured with a voltmeter rx and tx pin and both give around 3v ..so i dont think its the actual board ?
I even reflashed my naze board band flashed the osd about 5 times ?
I am kinda stuck ..
all i done is swap some cabling
Re: MultiWii OSD - MWOSD
feature request:
find a simple way to change the baseflight looptime (not sure how this would work if it needs to be done via the CLI)
find a simple way to change the baseflight looptime (not sure how this would work if it needs to be done via the CLI)
-
- Posts: 1
- Joined: Sun Mar 29, 2015 10:05 pm
Re: MultiWii OSD - MWOSD
HI,
I would like to know if I can use this firmware on a Witespy micro board or minimOSD board on a fixed wings plane with the pixhawk?
I would like to know if I can use this firmware on a Witespy micro board or minimOSD board on a fixed wings plane with the pixhawk?
Re: MultiWii OSD - MWOSD
CaptainElios wrote:HI,
I would like to know if I can use this firmware on a Witespy micro board or minimOSD board on a fixed wings plane with the pixhawk?
Not yet. Is planned for the future but no date..
Re: MultiWii OSD - MWOSD
Hey - thansk for the time to raise these sugegstions....
I would like to... but have no time. I hope maybe someone else will pick this up - or better still implement it in a chrome version of the GUI
I use and recommend this one - it has most of what you request already. Its included in the source files on repository actually.
https://minimosd-extra.googlecode.com/s ... wizard.jar
Interesting. I had guessed that for the quick flash at startup. Actually I don't mind this because it tells me something and helps with troubleshooting! But interesting to see impact on the random specks at to of screen. I can see why it might.
No referenced to that character being reserved as a 2blank" - but will do that for future... thanks for the tip. It may also help those who don't use vsync. I had always assumed it was switching noise.
probably not
Doesn't look like can change this via MSP so doesn't fit with current way OSD can make changes.
To do via CLI, I don't know what is required. I will add to wishlist. It may require too much memory to add this
rubadub wrote:hey can I add another possible feature request for the GUI?
In the font editor, please consider adding a couple of more options
I would like to... but have no time. I hope maybe someone else will pick this up - or better still implement it in a chrome version of the GUI
I use and recommend this one - it has most of what you request already. Its included in the source files on repository actually.
https://minimosd-extra.googlecode.com/s ... wizard.jar
rubadub wrote:Also, I found the cause of the problem with the white specks appearing on line one and with the strange behavior at startup with the entire screen being filled with one of the font characters instead of being all clear/blank.
Interesting. I had guessed that for the quick flash at startup. Actually I don't mind this because it tells me something and helps with troubleshooting! But interesting to see impact on the random specks at to of screen. I can see why it might.
No referenced to that character being reserved as a 2blank" - but will do that for future... thanks for the tip. It may also help those who don't use vsync. I had always assumed it was switching noise.
rubadub wrote:change the baseflight looptime
probably not
Doesn't look like can change this via MSP so doesn't fit with current way OSD can make changes.
To do via CLI, I don't know what is required. I will add to wishlist. It may require too much memory to add this
Re: MultiWii OSD - MWOSD
shikra wrote:Noted- thanks. I can't verify, but understanding the conformational changes I think this is valid!Leo wrote:I'm trying MultiWii OSD for the first time. I hooked up my new board and flashed the latest firmware R1.3.
Bug: When I set the "Time Zone Offset" to say 2.0 and then do a "WRITE" the value will change (display) to 0.2.
Has this been fixed yet?
Re: MultiWii OSD - MWOSD
Hi Leo - sorry not yet - this will be included as part of the work on the serial protocol. I have to get that working then any reported bugs like this will be prioritised over enhancements
ETA prob 2 weeks for availability
ETA prob 2 weeks for availability
Re: MultiWii OSD - MWOSD
No problem I just wasn't sure if I missed the change.
Re: MultiWii OSD - MWOSD
No worries - I uploaded the roadmap. Interpret that as a wish list and whats done will be what developers want to do first ! After bugs of course.
https://github.com/ShikOfTheRa/scarab-o ... ROADMAP.md
For me, after bugs, focus will be fixedwing , then as many of the smaller items before a beta release of 1.4 .
https://github.com/ShikOfTheRa/scarab-o ... ROADMAP.md
For me, after bugs, focus will be fixedwing , then as many of the smaller items before a beta release of 1.4 .
Re: MultiWii OSD - MWOSD
shikra wrote:Hey - thansk for the time to raise these sugegstions....
I would like to... but have no time. I hope maybe someone else will pick this up - or better still implement it in a chrome version of the GUI
I use and recommend this one - it has most of what you request already. Its included in the source files on repository actually.
https://minimosd-extra.googlecode.com/s ... wizard.jar
thanks, I'll check that out.
yeah, chrome app would be nice.
shikra wrote:probably not
Doesn't look like can change this via MSP so doesn't fit with current way OSD can make changes.
To do via CLI, I don't know what is required. I will add to wishlist. It may require too much memory to add this
I took a look at the BF code, and apparently all you need to do to enter the CLI is send '#' followed by a set command.
Sending 'exit' automatically saves, exits, and reboots the board, so there would be nothing else required to do, other than wait for the board to reboot.
I'm thinking possibly something like this (assuming looptime will be set to 2500)?
Code: Select all
Serial.println('#');
Serial.println("set looptime=2500");
Serial.println("exit");
//wait for board to reset and resume processing serial commands/data...
I'm guessing/hoping that the 'println()' function should take care of sending the correct line-ending for the CLI to process the commands, although I haven't verified it yet.
Anyway, since you're busy, I might try to prototype this and see how well it works.
Do you have a github repo for MWOSD?
Re: MultiWii OSD - MWOSD
JohnOCFII wrote:rubadub wrote:Do you have a github repo for MWOSD?
https://github.com/ShikOfTheRa/scarab-osd
cool, got it, thanks.
-
- Posts: 1
- Joined: Wed Apr 01, 2015 3:49 pm
Re: MultiWii OSD - MWOSD
Is it possible to add all the pid configurations in MWOSDrev 1.4?
PLEASEEEEEE
PLEASEEEEEE
Re: MultiWii OSD - MWOSD
shikra wrote:CaptainElios wrote:HI,
I would like to know if I can use this firmware on a Witespy micro board or minimOSD board on a fixed wings plane with the pixhawk?
Not yet. Is planned for the future but no date..
If we could use MWOSD with APM/PX4 someday that would be awesome!!
RSSI and battery voltage monitoring with an APM is a pain in the ass. IF MWOSD could read mavlink data, and still display voltage and rssi from the onboard pins that would solve a lot of peoples problems. Like the fact that monitoring a 2nd battery is virtually impossible with APM/PX4