MultiWii OSD - MWOSD
-
- Posts: 7
- Joined: Mon Sep 23, 2013 10:24 pm
Re: MultiWii OSD - MWOSD
There is a guy on FPVLab that has modified the code and merged in some TinyOSD code to let a MinimOSD function stand alone with a GPS module connected.
http://fpvlab.com/forums/showthread.php ... post511794
I think this would be a great feature to add. Some of us fly small planes and don't need a flight controller. We need battery volts/amps, time, a home arrow, distance from home, altitude, speed and GPS coords.
http://fpvlab.com/forums/showthread.php ... post511794
I think this would be a great feature to add. Some of us fly small planes and don't need a flight controller. We need battery volts/amps, time, a home arrow, distance from home, altitude, speed and GPS coords.
-
- Posts: 48
- Joined: Sat Jun 22, 2013 2:37 am
Re: MultiWii OSD - MWOSD
I made a similar thing with 3 adjustable 2-24V 1A outputs years ago for various testing purposes. I blinged it out with a backlit 4 digit meter, fuses for each channel (on the backside), and a cooling fan:
Also, here is how I added the 33k resistor to my current sensor for 1.1V output:
My GUI calibration value was rather high at 980. The amp readings are exact, and mAh is very close. I may trim the calibration by 1's after gathering some more data.
Adrianm1972, I am not sure if that can be done with easily with the code, but it's a great idea. Although in the grand scheme of things, Nazemini does not add much weight or bulk to a GPS+OSD+IVsensor, and you get precise alt, AH, RTL, etc... and there is passthrough mode if you really don't like the FC part.
Kev
Also, here is how I added the 33k resistor to my current sensor for 1.1V output:
My GUI calibration value was rather high at 980. The amp readings are exact, and mAh is very close. I may trim the calibration by 1's after gathering some more data.
Adrianm1972, I am not sure if that can be done with easily with the code, but it's a great idea. Although in the grand scheme of things, Nazemini does not add much weight or bulk to a GPS+OSD+IVsensor, and you get precise alt, AH, RTL, etc... and there is passthrough mode if you really don't like the FC part.
Kev
-
- Posts: 48
- Joined: Sat Jun 22, 2013 2:37 am
Re: MultiWii OSD - MWOSD
Shikra, I was thinking about adding a fixed wing efficiency panel. A simple mi/mAh display would be a good start (groundspeed/amps); with that number we can practice optimal cruising speed (for max range). The display can also include sink rate per amp, which could be used to maximize flight time. MinimOSD firmwares have similar displays with much more detailed info; maybe that is possible with MWiiOSDng, but for now I was thinking those 2 values would go a long way toward helping the pilot control the plane. I'm not a real coder, but I could tackle the needed lines in screens & screenlayout. Before start tinkering I wanted to run the idea past you first; you think this is doable... or better yet easy (just add the required lines to screens & screenlayout... no memory/processing concerns)?
Here is my feedback on the scrolling ladders:
I personally found the current implementation of speed & velocity ladders nearly useless. When I am accelerating/decelerating with throttle for example, I just see the left bars moving fast, but it gives me no idea how quickly I am approaching the critical speeds (stall & overspeed). Likewise, when I dive down I just get distracted by a moving ladder on the right, which offers no help in deciding when to pull up. This strays from the original point of adding the ladders; so the pilot sees the overall scale of acceleration and climbrate... so the pilot can easily visualize impending problems and react immediately to stay within the flight envelope. It's kind of like the difference between having a digital speedometer in your car, and having a dial guage... every driver prefers the dial... same with pilots, we prefer dials not digits. To make the ladder more like a dial it should be static, with a moving carat, and bold bars on top & bottom indicating overspeed & stall speed (like the redline on a tachometer). Likewise for the altitude ladder; have a static ladder with moving carat, where the bottom of the ladder is ground, and top is some set (GUI set?) max altitude... probably with a 400ft default. The current scrolling ladders do have arrows at the top and bottom to indicate direction; those would no longer be necessary if a static ladder+moving carat system is used. A great example is the climbrate ladder; it's almost perfect (IMHO the carat needs to be bolder, but that's minor). I'd love to see this happen in MWiiOSDng, but I'm an amateur coder so all I can offer is assistance. What do you think?
My feedback on map mode... replace it with a simple "spotter's arrow", & make a better way to measure GCS orientation:
I've gotten used to the old "home arrow+distance" over the years, but yknow, I just had to give the new map mode a shot. I put it in Radar mode, figuring radar mode contains GS orientation info that the home arrow does not... ie normal map mode to me is just a glorified home arrow, where as radar mode can help my spotter do his job. Unfortunately as I was flew circuits around the 3/4mi field, radar mode was useless to my spotter; the map sides are narrowed to avoid overlapping the sideladders, and the spotter has to think hard to figure out orientation (versus having just an arrow). So maybe another "plane arrow" can be added so spotters can quickly find the plane? Also, it didn't help that the launch direction was not recorded accurately during the launch (it was like 45* off!!!). In the northern hemisphere where I live, always facing north means maximum sun in my monitor. So facing N isn't a great option. I was thinking of a better way to set GCS orientation... enter the OSD stick menu, orient my transmitter north, move the right stick in the direction where my GCS is oriented, and have the OSD use pulsein values to calc the GCS heading vector, no? The setting could be saved in EEPROM so a reset isn't needed unless GCS orientation is changed. IMHO, such a feature would be a huge help to the average FPV hobbyist... seems long overdue actually.
That's it... no expectations... just planting seeds from my decades of RC pilot experience, and offering my meager coding skills to help a worthy coder should he/she decide to grow 'em.
Kev
Here is my feedback on the scrolling ladders:
I personally found the current implementation of speed & velocity ladders nearly useless. When I am accelerating/decelerating with throttle for example, I just see the left bars moving fast, but it gives me no idea how quickly I am approaching the critical speeds (stall & overspeed). Likewise, when I dive down I just get distracted by a moving ladder on the right, which offers no help in deciding when to pull up. This strays from the original point of adding the ladders; so the pilot sees the overall scale of acceleration and climbrate... so the pilot can easily visualize impending problems and react immediately to stay within the flight envelope. It's kind of like the difference between having a digital speedometer in your car, and having a dial guage... every driver prefers the dial... same with pilots, we prefer dials not digits. To make the ladder more like a dial it should be static, with a moving carat, and bold bars on top & bottom indicating overspeed & stall speed (like the redline on a tachometer). Likewise for the altitude ladder; have a static ladder with moving carat, where the bottom of the ladder is ground, and top is some set (GUI set?) max altitude... probably with a 400ft default. The current scrolling ladders do have arrows at the top and bottom to indicate direction; those would no longer be necessary if a static ladder+moving carat system is used. A great example is the climbrate ladder; it's almost perfect (IMHO the carat needs to be bolder, but that's minor). I'd love to see this happen in MWiiOSDng, but I'm an amateur coder so all I can offer is assistance. What do you think?
My feedback on map mode... replace it with a simple "spotter's arrow", & make a better way to measure GCS orientation:
I've gotten used to the old "home arrow+distance" over the years, but yknow, I just had to give the new map mode a shot. I put it in Radar mode, figuring radar mode contains GS orientation info that the home arrow does not... ie normal map mode to me is just a glorified home arrow, where as radar mode can help my spotter do his job. Unfortunately as I was flew circuits around the 3/4mi field, radar mode was useless to my spotter; the map sides are narrowed to avoid overlapping the sideladders, and the spotter has to think hard to figure out orientation (versus having just an arrow). So maybe another "plane arrow" can be added so spotters can quickly find the plane? Also, it didn't help that the launch direction was not recorded accurately during the launch (it was like 45* off!!!). In the northern hemisphere where I live, always facing north means maximum sun in my monitor. So facing N isn't a great option. I was thinking of a better way to set GCS orientation... enter the OSD stick menu, orient my transmitter north, move the right stick in the direction where my GCS is oriented, and have the OSD use pulsein values to calc the GCS heading vector, no? The setting could be saved in EEPROM so a reset isn't needed unless GCS orientation is changed. IMHO, such a feature would be a huge help to the average FPV hobbyist... seems long overdue actually.
That's it... no expectations... just planting seeds from my decades of RC pilot experience, and offering my meager coding skills to help a worthy coder should he/she decide to grow 'em.
Kev
Re: MultiWii OSD - MWOSD
cheers Trug
Firstly - memory is a little tight - anything new going in now has to either be a #define option if would not be in core use - or have an equivalent amount of memory saving elsewhere in the code.
Secondly no idea when. i'll be free to start again in 3 weeks when current project finishes. Multiple hud / movable screen options next!.
Efficiency:
OK to add this in.
I had a little look at this the other day. W/hr figure / estimated duration that sort of stuff.
OK to add it, but as per above - needs to be a #define option
Ladders:
- original intention was pure bling !!
- no reason why couldn't have it as a moving carat option against static ladder. Probably make that a #define choice - carat on top or along side?
- I'd suggest for the amount of scrolling the best way would be to perhaps define the scroll speed to match whatever speed range you want.so say 1mph increase scrolls 1 time in a sec and 10mph 10 times?
- top arrows were for the guys who didn't like the scrolling effect. Actually they were a surprising pain in the ass to get right.
- have to also consider negative altitude - either ignore
Vario bar - I'm going to put an option to make it a bit longer - had that request. Maybe see if can thicken it up a little too.
Map mode:
This is first iteration - low res / proof of concept - so open for improvements!
fixedwing launch accuracy - I suspect this may not work with fixed wing - it takes direction from its orientation when armed (unless forcing north option). I don't think fixedwing uses that?? Solve that and I think the whole map thing would improve for fixed wing. Can orientate with your GCS then. I'll have to ask Patrik for guidance on whats needed there.
So are you suggesting a second arrow for the spotter on the OSD? Was a bit unclear.
I hear you on map sides. I was going to address this with the multiple layout options. Widen them and relocate speed/ alt etc. Think thats when map mode will become of more use
Just as fyi - all I usually fly with is volts and timer! Not sure why I'm here really
Firstly - memory is a little tight - anything new going in now has to either be a #define option if would not be in core use - or have an equivalent amount of memory saving elsewhere in the code.
Secondly no idea when. i'll be free to start again in 3 weeks when current project finishes. Multiple hud / movable screen options next!.
Efficiency:
OK to add this in.
I had a little look at this the other day. W/hr figure / estimated duration that sort of stuff.
OK to add it, but as per above - needs to be a #define option
Ladders:
- original intention was pure bling !!
- no reason why couldn't have it as a moving carat option against static ladder. Probably make that a #define choice - carat on top or along side?
- I'd suggest for the amount of scrolling the best way would be to perhaps define the scroll speed to match whatever speed range you want.so say 1mph increase scrolls 1 time in a sec and 10mph 10 times?
- top arrows were for the guys who didn't like the scrolling effect. Actually they were a surprising pain in the ass to get right.
- have to also consider negative altitude - either ignore
Vario bar - I'm going to put an option to make it a bit longer - had that request. Maybe see if can thicken it up a little too.
Map mode:
This is first iteration - low res / proof of concept - so open for improvements!
fixedwing launch accuracy - I suspect this may not work with fixed wing - it takes direction from its orientation when armed (unless forcing north option). I don't think fixedwing uses that?? Solve that and I think the whole map thing would improve for fixed wing. Can orientate with your GCS then. I'll have to ask Patrik for guidance on whats needed there.
So are you suggesting a second arrow for the spotter on the OSD? Was a bit unclear.
I hear you on map sides. I was going to address this with the multiple layout options. Widen them and relocate speed/ alt etc. Think thats when map mode will become of more use
Just as fyi - all I usually fly with is volts and timer! Not sure why I'm here really
Re: MultiWii OSD - MWOSD
Would love to have this option! Its on the list... and not difficult - just time consuming - Might contact him to see if he can implement
Thanks for link too. Too many forums and threads to read!
Thanks for link too. Too many forums and threads to read!
Adrianm1972 wrote:There is a guy on FPVLab that has modified the code and merged in some TinyOSD code to let a MinimOSD function stand alone with a GPS module connected.
http://fpvlab.com/forums/showthread.php ... post511794
I think this would be a great feature to add. Some of us fly small planes and don't need a flight controller. We need battery volts/amps, time, a home arrow, distance from home, altitude, speed and GPS coords.
-
- Posts: 14
- Joined: Sat Oct 26, 2013 1:13 am
Re: MultiWii OSD - MWOSD
+1 on the efficiency parameter additions!
Regarding map mode, all it needs is an increase in resolution IMO. It's a bit choppy and has limited use as-is. The eagle-tree "virtual map" is a great go-by, the chevron moves around the clear area of the OSD, you can specify what distance corresponds to the box that the chevron moves in, resolution is high, north is up (critical for me), and it is extremely easy for me or a spotter to tell where I am. If you are beyond the distance set in the chevron box, the chevron simply moves around the edge.
http://www.youtube.com/watch?v=UKXyzslsjgQ
On another note, this weekend when I performed a quick roll input, the OSD completely disappeared. This was on a kv-modded witespy board. I had to land, power-cycle the airplane, and everything was fine thereafter, even when repeating the quick stick inputs. I have a standalone 3 amp BEC (5A max) powering the 5v stuff (including 2 servos), this should not be close to the 3 amp limit, but I will hook it up to my watt meter and see what it pulls with load on the servos. Any other ideas? Do I need an anti-brownout capacitor pack? Is there anything that can be done about this in the firmware, so that if it happens, it comes back? Would be scary to have happen on a long-range flight.
Regarding map mode, all it needs is an increase in resolution IMO. It's a bit choppy and has limited use as-is. The eagle-tree "virtual map" is a great go-by, the chevron moves around the clear area of the OSD, you can specify what distance corresponds to the box that the chevron moves in, resolution is high, north is up (critical for me), and it is extremely easy for me or a spotter to tell where I am. If you are beyond the distance set in the chevron box, the chevron simply moves around the edge.
http://www.youtube.com/watch?v=UKXyzslsjgQ
On another note, this weekend when I performed a quick roll input, the OSD completely disappeared. This was on a kv-modded witespy board. I had to land, power-cycle the airplane, and everything was fine thereafter, even when repeating the quick stick inputs. I have a standalone 3 amp BEC (5A max) powering the 5v stuff (including 2 servos), this should not be close to the 3 amp limit, but I will hook it up to my watt meter and see what it pulls with load on the servos. Any other ideas? Do I need an anti-brownout capacitor pack? Is there anything that can be done about this in the firmware, so that if it happens, it comes back? Would be scary to have happen on a long-range flight.
Re: MultiWii OSD - MWOSD
Agree ....
Will never have resolution of eagle as they use graphics rather than fonts like we are limited too with the minim OSD
For distance, this version auto ranges and changes dependent upon distance - and sits around outside when reach maximum like Eagle.
Would it be a big deal to replace the aircraft ^ on the map with a dot - can massively improve resolution ? Could still potentially use the ^ in a fixed location if necessary.
Thats a bummer on the OSD. I'm not totally convinced, but I think its the max chip that is having the issue. In almost all castes a 1000uf cap near the supply to it cures for me. Only in one large copter running 50gr digital servos I had to put the servos on its own supply. Don't think it feasible to fix with firmware. Sorry!
Will never have resolution of eagle as they use graphics rather than fonts like we are limited too with the minim OSD
For distance, this version auto ranges and changes dependent upon distance - and sits around outside when reach maximum like Eagle.
Would it be a big deal to replace the aircraft ^ on the map with a dot - can massively improve resolution ? Could still potentially use the ^ in a fixed location if necessary.
Thats a bummer on the OSD. I'm not totally convinced, but I think its the max chip that is having the issue. In almost all castes a 1000uf cap near the supply to it cures for me. Only in one large copter running 50gr digital servos I had to put the servos on its own supply. Don't think it feasible to fix with firmware. Sorry!
-
- Posts: 14
- Joined: Sat Oct 26, 2013 1:13 am
Re: MultiWii OSD - MWOSD
shikra wrote:Would it be a big deal to replace the aircraft ^ on the map with a dot - can massively improve resolution ? Could still potentially use the ^ in a fixed location if necessary.
hmm... A dot with a separate direction indicator could work, but then it might be hard to find it on the screen when you need it. How much of a resolution increase can be had with the existing ^ character? (you already do have a direction arrow in the upper right corner)
what about 3 or 4 dots, to indicate your track? kinda like "mouse trails" in Windows... just an idea. might be distracting to some, but I think this could be an effective solution?
Re: MultiWii OSD - MWOSD
I'll try out a 4 pixel circle and with resolution increase of 9. Should look much smoother on the display. See what it looks like then make a call of which way to go.
Increasing resolution for the > is a challenge - the issue is the font space. It is very limited. And particularly with requirements of other features impacts this I think with everything else on the agenda, best is double in vertical axis only.
Like the ingenuity of mouse trails! very creative thought. For font based approach like this hardware its a no go. Its doable with EagleTree type OSD
Increasing resolution for the > is a challenge - the issue is the font space. It is very limited. And particularly with requirements of other features impacts this I think with everything else on the agenda, best is double in vertical axis only.
Like the ingenuity of mouse trails! very creative thought. For font based approach like this hardware its a no go. Its doable with EagleTree type OSD
-
- Posts: 7
- Joined: Mon Sep 23, 2013 10:24 pm
Re: MultiWii OSD - MWOSD
shikra wrote:Would love to have this option! Its on the list... and not difficult - just time consuming - Might contact him to see if he can implement
Thanks for link too. Too many forums and threads to read!Adrianm1972 wrote:There is a guy on FPVLab that has modified the code and merged in some TinyOSD code to let a MinimOSD function stand alone with a GPS module connected.
http://fpvlab.com/forums/showthread.php ... post511794
I think this would be a great feature to add. Some of us fly small planes and don't need a flight controller. We need battery volts/amps, time, a home arrow, distance from home, altitude, speed and GPS coords.
Great news! It would be great to have a robust, full feature, low cost OSD. The Witespy KV1.1 OSD has all pins exposed to headers, onboard voltage divider for batt voltage and video voltage, Current sensor and RSSI inputs. Adding GPS to it would be awesome.
Re: MultiWii OSD - MWOSD
Hello,
might need a bit of help here.
Managed to load MW OSD onto the hobbyking's minim' osd and connected it to naze32 baseflight. Uploaded fonts in GUI.
Once I power it up, I get the screen displaying the correct voltage, on min time and DISARMED status. When I arm the copter, the props spin up, but DISARMED stays there and nothing changes.
The only change to Config.h file I did is to #define BASEFLIGHT.
Is there anything I'm missing?!
might need a bit of help here.
Managed to load MW OSD onto the hobbyking's minim' osd and connected it to naze32 baseflight. Uploaded fonts in GUI.
Once I power it up, I get the screen displaying the correct voltage, on min time and DISARMED status. When I arm the copter, the props spin up, but DISARMED stays there and nothing changes.
The only change to Config.h file I did is to #define BASEFLIGHT.
Is there anything I'm missing?!
Re: MultiWii OSD - MWOSD
Do you have the most up to date Baseflight firmware?
Try uncommenting #DEFINE BOXNAMES which will make the OSD compatible with older MSP. That is typically what causes the problem you are encountering.
Try uncommenting #DEFINE BOXNAMES which will make the OSD compatible with older MSP. That is typically what causes the problem you are encountering.
Re: MultiWii OSD - MWOSD
shikra wrote:HFMan wrote:4) When I turn off my UHF TX to check RSSI, RSSI drops down to near zero, then it jumps up to 100% and stays there.
Thanks - bug identified and fixed/ tested for next release
Let me guess- if RSSI Min is set too high, then if voltage goes below that value it changes to 100%? Ask me how I know... DragonLink latest firmware lowered the low side of RSSI when it gets low, I didn't make the corresponding change in MWOSD config.
Re: MultiWii OSD - MWOSD
ah - I couldn't figure out why you were seeing that because usually calibrate when tx is off and wouldn't expect signal to go below that.
What I found in the code was if RSSI went below this value, as it becomes a negative value, and the variable is unsigned, it sees that as 100%
I amended because i know some prefer RSSI=0% at loss of control rather than no signal.
So you did point out a "bug" that may have surfaced one day. So thanks! But glad you found the issue
What I found in the code was if RSSI went below this value, as it becomes a negative value, and the variable is unsigned, it sees that as 100%
I amended because i know some prefer RSSI=0% at loss of control rather than no signal.
So you did point out a "bug" that may have surfaced one day. So thanks! But glad you found the issue
Re: MultiWii OSD - MWOSD
Mac osd GUI doesn't seem to work. I've tried both downloads (current and old version) and both of them say they are damaged and needs to be trashed. Any idea how to fix this?
Re: MultiWii OSD - MWOSD
downloaded the whitespy version. any idea what is the difference?
Re: MultiWii OSD - MWOSD
What do you mean "downloaded the witespy version" ? For MWOSD, there is one version- R1.1.
Re: MultiWii OSD - MWOSD
shikra wrote:@subaru / trug
Here is a packaged version to try with the new witespy boards with config.h option preset.
Also untested FASTPWM support for the RX units out there with high frequency refresh rates. If you guys use that would love to have it tested / verified
https://drive.google.com/uc?export=down ... WtqT2xtSDg
This is the WiteSpy version. It has some adjustments in the code that take account for incorrect hardware used on some newer Witespy OSD boards which give incorrect voltage readings.
Re: MultiWii OSD - MWOSD
HFMan wrote:What do you mean "downloaded the witespy version" ? For MWOSD, there is one version- R1.1.
saw it and downloaded the file but hae the original one in mine but since it is a whitespy board I might as well try it
Re: MultiWii OSD - MWOSD
Hello Shikra,
I was wondering about the the possibility of allowing more current to be displayed. I noticed the setting right now is limited to 99.9A but with FPV rigs capable of pulling 30A+ per motor this is exceeded easily. Is there any elegant solution that would work and make it to the main release?
I was wondering about the the possibility of allowing more current to be displayed. I noticed the setting right now is limited to 99.9A but with FPV rigs capable of pulling 30A+ per motor this is exceeded easily. Is there any elegant solution that would work and make it to the main release?
Re: MultiWii OSD - MWOSD
Does anynone know the voltage out of the divider ...ballpark that goes to the 328p.....
Im getting .78 can it work with that ? For the ADC voltage sensor on the OSD board
Im getting .78 can it work with that ? For the ADC voltage sensor on the OSD board
- tungsten2k
- Posts: 62
- Joined: Sat Jun 21, 2014 10:49 pm
Re: MultiWii OSD - MWOSD
subaru4wd wrote:shikra wrote:@subaru / trug
Here is a packaged version to try with the new witespy boards with config.h option preset.
Also untested FASTPWM support for the RX units out there with high frequency refresh rates. If you guys use that would love to have it tested / verified
https://drive.google.com/uc?export=down ... WtqT2xtSDg
This is the WiteSpy version. It has some adjustments in the code that take account for incorrect hardware used on some newer Witespy OSD boards which give incorrect voltage readings.
I loaded this version (MWOSD v1.1.1) on my WS board (purchased a few weeks ago) and so far, I am unable to get the virtual amps meter to register anything. I've tried all kinds of values including 0/0, 6/100, 60/255, but Current always shows as "0.0a" and no mA are ever registered. I have "use multiwii" selected in MWOSD and it displays the volts correctly without any problem. "ADJUST VOLTS" is set to 110 and "MAIN VOLTS ALARM" is set to 108". Does the minimosd board need to have mains voltage connected directly to it for the virtual amp gauge to work at all ? I would imagine the software wouldn't care, unless the sampling rate on the minimosd is much higher than Baseflight samples the main bat voltage input on the FC.
Should I try the standard MWOSD1.1 version without your modifications instead ? Or does yours recognize the WS boards and make the adjustments accordingly just for those ?
All other features seem to work as expected (and not work, where not expected, since this is an acro board running the latest Baseflight).
EDIT: I forgot to mention, I have "VOLT REF" set to "5V" and have verified voltage in put on the board is 5.03v (coming from the output of two linear 1A 5V BECs built-in to the WiteSpy BS-12A ESCs running in parallel)
ps- Thanks Subaru4wd for putting the effort into to help those with incorrect HW. I've just got into FPV and really appreciate your contributions I've found littered throughout the standard places. And thanks to all devs working on this stuff. Having worked in software companies my entire professional carrier, it's pretty amazing what one, or a handful of guys can do on their own without that paycheck forcing them to play nice with each other.
-=dave
Re: MultiWii OSD - MWOSD
Hi sorry for delay - been working on another project which has just finished so I'm free again for a bit.! Time to start some changes
@ReadError
A simple easy way would be to go to a 1A resolution. Would that work? If capable of 100A then thats still a step resolution change of only 1% Thats probably more than finger on a tx could manage.
@ Debogus - voltage at pin = voltage in * 1.5/23.5
Your sound about right for 3s
@Tungsten2k - I am completely confused by your question! Do you have a physical hardware sensor? If so - is it connected to the OSD or to the multiwii controller
@ReadError
A simple easy way would be to go to a 1A resolution. Would that work? If capable of 100A then thats still a step resolution change of only 1% Thats probably more than finger on a tx could manage.
@ Debogus - voltage at pin = voltage in * 1.5/23.5
Your sound about right for 3s
@Tungsten2k - I am completely confused by your question! Do you have a physical hardware sensor? If so - is it connected to the OSD or to the multiwii controller
- tungsten2k
- Posts: 62
- Joined: Sat Jun 21, 2014 10:49 pm
Re: MultiWii OSD - MWOSD
shikra wrote:@Tungsten2k - I am completely confused by your question! Do you have a physical hardware sensor? If so - is it connected to the OSD or to the multiwii controller
tungsten2k wrote:I am unable to get the virtual amps meter to register anything.
I do not have any physical hardware sensor. Have I misunderstood what the Virtual Amp Meter function is ? I assumed this did not require any shunt resistor hardware and relied only on the calibration settings and algorithm to estimate usage based on time and throttle position.
-=dave
Re: MultiWii OSD - MWOSD
OK - thanks re-reading again carefully I get it!
So for virtual sensor to work correctly it needs:
Display Amps and/or Display mah enabled
Use virtual sensor enabled
Use Multiwii ** disabled **
A zero adjust - typically 0-10
An amsp adjust which is approx 10* your hover current dra in amps
It also needs to be able to view the throttle setting from multiwii/baseflight . Can test this by enabling "display throttle setting"
I now run baseflight one one copter now - I'm pretty sure it works OK with it, but will confirm.
So for virtual sensor to work correctly it needs:
Display Amps and/or Display mah enabled
Use virtual sensor enabled
Use Multiwii ** disabled **
A zero adjust - typically 0-10
An amsp adjust which is approx 10* your hover current dra in amps
It also needs to be able to view the throttle setting from multiwii/baseflight . Can test this by enabling "display throttle setting"
I now run baseflight one one copter now - I'm pretty sure it works OK with it, but will confirm.
- tungsten2k
- Posts: 62
- Joined: Sat Jun 21, 2014 10:49 pm
Re: MultiWii OSD - MWOSD
shikra wrote:OK - thanks re-reading again carefully I get it!
So for virtual sensor to work correctly it needs:
...
Use virtual sensor enabled
Use Multiwii ** disabled **
So the main voltage reading from the FC board won't work and I have to run an additional main voltage line into the mimimOSD board directly ?
Okay, time to rip it all apart and solder some more wires on (these 220-sized quads are *tight* )
Thanks for clarifying ! I'm curious, is there a reason the pack voltage reading from the flight controller won't work ? Does it just not sample fast enough to accurately gauge the voltage at the moment ? (If my question doesn't make sense, I may not understand how the systems works).
Thanks again,
-=dave
Re: MultiWii OSD - MWOSD
Mixing up the two parts here.
If reading battery from the multiwii FC, then select "use Mwii" in the main battery section on GUI
if using virtual sensor, do not select "use Mwii" in the Amperage section
Does that help?
If reading battery from the multiwii FC, then select "use Mwii" in the main battery section on GUI
if using virtual sensor, do not select "use Mwii" in the Amperage section
Does that help?
Re: MultiWii OSD - MWOSD
My Altitude doesnt reset...... have a baro on a HK 328p .....Everything else seems to work .....Did I miss something ?......
Right now I just want it for that ,,,not alt hold yet....Oh and when I save n the OSD menu it only keeps the info as long as the battery is plugged in .. moved curser to save and exit then pull down throttle ...Had this problem setting the voltage ..... Changed the values in the GUI and they stick
Right now I just want it for that ,,,not alt hold yet....Oh and when I save n the OSD menu it only keeps the info as long as the battery is plugged in .. moved curser to save and exit then pull down throttle ...Had this problem setting the voltage ..... Changed the values in the GUI and they stick
- tungsten2k
- Posts: 62
- Joined: Sat Jun 21, 2014 10:49 pm
Re: MultiWii OSD - MWOSD
shikra wrote:Mixing up the two parts here.
If reading battery from the multiwii FC, then select "use Mwii" in the main battery section on GUI
if using virtual sensor, do not select "use Mwii" in the Amperage section
Does that help?
Not really.
That's what I assumed before, and I had it set to "Use MultiWii", and of course, the voltage displayed within MWOSD, but virtual AMP meter did not function. Above you said that in order to get the virtual *AMP* guage to work required me to connect the main voltage direclty to the minimOSD, so I took the thing apart and ran mains voltage to the "Batt 2" connections on the minimOSD and then unselected "Use MultiWii" in the amperage section of MWOSD.
Wouldn't you know it, voltage reads the same as it does when it was getting it from the flight controller, but still no virtual amp guage: reads 0.0a and never moves.
In short, virtual amp guage does not function.
EDIT: Added picture to show voltage and throttle position functioning, but virtual amp guage not functioning (Amps adjust set to 100, idle Amps set to 6)
EDIT2: This is the Flip32 and I am running Subaru4wd's MWOSD binary.
-=dave
Re: MultiWii OSD - MWOSD
Thinking my Baro issue was the result of poor foam shielding ....changed it ,now it although it varies many feet, it starts off at zero....what a sensitive bugger
Re: MultiWii OSD - MWOSD
@Tungsten - sorry if I confused you over the main voltage - I'm not sure where I wrote that, but how its connected does not impact virual amps.
The only thing I can think is to load the clear eeprom sketch then try again.
The only thing I can think is to load the clear eeprom sketch then try again.
Re: MultiWii OSD - MWOSD
shikra wrote:@ReadError
A simple easy way would be to go to a 1A resolution. Would that work? If capable of 100A then thats still a step resolution change of only 1% Thats probably more than finger on a tx could manage.
Hello Shikra,
In baseflight we currently have 2 modes of sending the amperage value over MSP:
Code: Select all
case MSP_ANALOG:
headSerialReply(7);
serialize8((uint8_t)constrain(vbat, 0, 255));
serialize16((uint16_t)constrain(mAhdrawn, 0, 0xFFFF)); // milliamphours drawn from battery
serialize16(rssi);
if (mcfg.multiwiicurrentoutput)
serialize16((uint16_t)constrain((abs(amperage) * 10), 0, 0xFFFF)); // send amperage in 0.001 A steps
else
serialize16((uint16_t)constrain(abs(amperage), 0, 0xFFFF)); // send amperage in 0.01 A steps
break;
When mcfg.multiwiicurrentoutput is '1', the MSP is sent using the Multiwii steps (0.001A), by default it is 0 which sends the baseflight current steps (0.01A). Since there is already a define for baseflight for the mag fix, could this be incorporated in to the code to change the scaling factor for /100 to /10 ? I was playing around with the display and adding another digit in the current field does not really cause any issues, there is quite a bit of space between that and the voltage still. This way we could keep our precious 0.1A of resolution and not require any MSP changes.
If the extra digit is too much thats fine too, myself and many others would be grateful to just have the higher amperage being displayed.
Excellent work, lovin it.
Re: MultiWii OSD - MWOSD
Sounds like a solution
1 - Baseflight default appears to be 10* resolution - we add that in as standard when choosing baseflight.
1a - also to support this for multiwii 2.4 as I believe this will become default too
2 - Allow any current draw to go to a cap of 999.9 amps
Will be added some time next week when back in the office and can test.
1 - Baseflight default appears to be 10* resolution - we add that in as standard when choosing baseflight.
1a - also to support this for multiwii 2.4 as I believe this will become default too
2 - Allow any current draw to go to a cap of 999.9 amps
Will be added some time next week when back in the office and can test.
Re: MultiWii OSD - MWOSD
Hi fellas - just switched over to this from the KV variant... and I gotta say I like this much better.
One thing I couldn't seem to find... how do I change the timer from "on min" to "fly min" where it's based on throttle input? I couldn't find it in the GUI... is this controlled in the sketch?
thanks!
One thing I couldn't seem to find... how do I change the timer from "on min" to "fly min" where it's based on throttle input? I couldn't find it in the GUI... is this controlled in the sketch?
thanks!
Re: MultiWii OSD - MWOSD
awesome... looks like i'll proceed with installation then!
thank you!
thank you!
Re: MultiWii OSD - MWOSD
I attempted to setup PWM RSSI this evening using a KVOSD from witespy and the MWOSD firmware. I have a FrSky D4R-ii RX setup in CPPM mode so CH2 outputs PWM RSSI.
How exactly am I supposed to connect the hardware? GND and +5 or GND and signal from the RX? And I'm assuming that the two connections on the OSD should be TXTSSI and the GND directly underneath it (if the video in/out is on the bottom)?
I tried +5 and signal from the RX but the RSSI doens't change much, maybe a few percent but not much. Use PWM is on under RSSI in the GUI and I even tried changing the min and max to 0/255 and 255/0 and there's no real change except inverting the signal strength.
Can someone tell me if I am doing anything right?
How exactly am I supposed to connect the hardware? GND and +5 or GND and signal from the RX? And I'm assuming that the two connections on the OSD should be TXTSSI and the GND directly underneath it (if the video in/out is on the bottom)?
I tried +5 and signal from the RX but the RSSI doens't change much, maybe a few percent but not much. Use PWM is on under RSSI in the GUI and I even tried changing the min and max to 0/255 and 255/0 and there's no real change except inverting the signal strength.
Can someone tell me if I am doing anything right?
Re: MultiWii OSD - MWOSD
To connect, just need the RSSI signal pin on the frsky to rssi on the OSD
Unfortunately I believe FrSky use non standard high frequency PWM RSSI on those rx which most OSD will not read. the next release has some code (untested) that I think will work.
Options are to use analogue converter - or try latest beta test version linked below and report back. Will need to enable #define FASTPWMRSSI
https://drive.google.com/a/mitel.com/?t ... Gl2WkIwUlU
Unfortunately I believe FrSky use non standard high frequency PWM RSSI on those rx which most OSD will not read. the next release has some code (untested) that I think will work.
Options are to use analogue converter - or try latest beta test version linked below and report back. Will need to enable #define FASTPWMRSSI
https://drive.google.com/a/mitel.com/?t ... Gl2WkIwUlU
Re: MultiWii OSD - MWOSD
Hi, are the macosx and linux OSD GUI apps supposed to work at all? I just flashed MWOSD 1.1 on a MinimOSD board from ReadyToFlyQuads and I'm trying to configure it, but the macosx app silently refused to run on my Mac and the linux directories didn't contain anything that could be executed on Linux. edit: Scratch that, the Linux app works just fine, I don't understand how I didn't notice that you just need to give it the +x bit to run it.
Last edited by ttsalo on Mon Jul 14, 2014 7:42 pm, edited 1 time in total.
Re: MultiWii OSD - MWOSD
shikra wrote:To connect, just need the RSSI signal pin on the frsky to rssi on the OSD
Unfortunately I believe FrSky use non standard high frequency PWM RSSI on those rx which most OSD will not read. the next release has some code (untested) that I think will work.
Options are to use analogue converter - or try latest beta test version linked below and report back. Will need to enable #define FASTPWMRSSI
https://drive.google.com/a/mitel.com/?t ... Gl2WkIwUlU
I tried the MWOSD R1.1 a1b1 firmware. I removed the comments on the definitions for FASTPWMRSSI, SMOOTHFILTER, and STAGE2FILTER. It wouldn't fit so I commented out SPORT (cause I'm not providing any S PORT sensor data to the Naze32). I cleared the OSD using an EEPROM Clear Arduino sketch and then loaded the a1b1 firmware. Turned on RSSI and Use PWM and left the min/max the defaults. The RSSI in my googles fluctuates between 0 and 1%. If I change the min to 0 and the max to 3, I start seeing it fluctuate between 66 and 100%. I know the PWN voltage is 3.1v on my multimeter, so I'm wondering if this is being captured instead of the PWM signal.
How can I help you debug this issue?
Thanks,
John
Edit - I did some more research and what I understand the problem to be is.....that the PWM signal frequency from the FrSky receiver is too fast for the Arduino to deal with it. Is that true? If so, based on this post (http://www.fpvhub.com/index.php?topic=16916.0) it looks like the frequency is 110kHz.
And this post (http://bluepichu.wordpress.com/2012/07/ ... uino-fast/) explains how to deal with a specific PWM frequency on the Ardunio. What I take from the Arduino post is that the Arduino can't clock fast enough to read a 110kHz signal. If that's the case, couldn't you use the example in the Arduino and only run the clock at 55kHz then double the value?
Re: MultiWii OSD - MWOSD
@ shadowjig - thanks for testing It was worth a shot. Leave with me - I'll look into this next week as I now have a frsky tx I can test.
The post you reference was for generating a PWM signal. Arduino micros or millis timer is indeed to slow to read as its something like 20,000 times faster than standard PWM , but it can be done in a good enough way for what we need.
The post you reference was for generating a PWM signal. Arduino micros or millis timer is indeed to slow to read as its something like 20,000 times faster than standard PWM , but it can be done in a good enough way for what we need.
Re: MultiWii OSD - MWOSD
shikra wrote:@ shadowjig - thanks for testing It was worth a shot. Leave with me - I'll look into this next week as I now have a frsky tx I can test.
The post you reference was for generating a PWM signal. Arduino micros or millis timer is indeed to slow to read as its something like 20,000 times faster than standard PWM , but it can be done in a good enough way for what we need.
Sounds good, just let me know when you need something tested. I'm just starting my first mini quad build with FPV and I choose all open source projects. And this OSD firmware is great, thanks for moving forward with additions from the previous OSD projects.
- tungsten2k
- Posts: 62
- Joined: Sat Jun 21, 2014 10:49 pm
Re: MultiWii OSD - MWOSD
shikra wrote:@Tungsten - sorry if I confused you over the main voltage - I'm not sure where I wrote that, but how its connected does not impact virual amps.
The only thing I can think is to load the clear eeprom sketch then try again.
Thanks for the clarification (and the suggestion). I removed the extra voltage lead from the miminosd, selected Use MW for main volts, wiped and reflashed with the same sketch and the virtual amp meter is now working. Gremlin eradicated
Thanks again,
-=dave
Re: MultiWii OSD - MWOSD
Excellent - thanks for the feedback.
Am just finishing up some bits for the beta of release - hopefully available in next week or two
Am just finishing up some bits for the beta of release - hopefully available in next week or two
MultiWii OSD - MWOSD
I'm having a little problem with my witespy board. Under heavy throttle the text starts to dim or Flickr. Someone on another forum suggesting putting a capacitor in the 5 V input. I have not try this yet. Do you think that would solve my problem?
- tungsten2k
- Posts: 62
- Joined: Sat Jun 21, 2014 10:49 pm
Re: MultiWii OSD - MWOSD
My measurments show the witespy minimosd board takes about 110ma during use. If you're browning out something of such little power draw, you have other problems.
If you're actually using a lot of 5v power on other stuff (gimble servos, gps, camera, etc) then you need a bigger BEC. If you're running 4x ESCs with built-in linear regulator BECs (like BS-12a, Afro-12, etc) you can connect more than one BEC line to the FC and it will provide additional capacity (not double, but probably 60% or more). I would measure the static voltage on the BEC line of each ESC and pick the two that have the closest/highest output voltage (they'll likely be slightly different, somwhere in the 4.98v-5.02v range).
Note: you cannot do this with ESCs that have switching regulators (you've been warned ) In that case, you'll need to segment out your power. You can run the servos off one BEC with everything else running off another (for example).
-=dave
If you're actually using a lot of 5v power on other stuff (gimble servos, gps, camera, etc) then you need a bigger BEC. If you're running 4x ESCs with built-in linear regulator BECs (like BS-12a, Afro-12, etc) you can connect more than one BEC line to the FC and it will provide additional capacity (not double, but probably 60% or more). I would measure the static voltage on the BEC line of each ESC and pick the two that have the closest/highest output voltage (they'll likely be slightly different, somwhere in the 4.98v-5.02v range).
Note: you cannot do this with ESCs that have switching regulators (you've been warned ) In that case, you'll need to segment out your power. You can run the servos off one BEC with everything else running off another (for example).
-=dave
- tungsten2k
- Posts: 62
- Joined: Sat Jun 21, 2014 10:49 pm
Re: MultiWii OSD - MWOSD
Question: Is there a reason I am seeing "DISARM" scroll in the compass heading area of the overlay occasionally ? I have no idea why it's in there. It doesn't do it all the time either.
At first I thought it was more gremlins similar to my previous issue of the amps guage not working, but my friend just set his up the same way and he sees the same "DISARM" scrolling in there.
If this is a "feature" could someone explain to me what it's indicating ?
Thanks !
-=dave
ps- virtual amps guage appears to be working phenominally now - calibrated on a 1500mAh/128g battery; MWOSD indicated 1140mAh used, charger put in 1126ma. I then flew a 2200mAh/179g battery (felt like a pig) and MWOSD indicated 1625, charger put in 1611ma . I'll try later with a 1300mAh/117g battery and remove the Mobius to make sure the estimation works okay for a lighter setup. Thanks again !
At first I thought it was more gremlins similar to my previous issue of the amps guage not working, but my friend just set his up the same way and he sees the same "DISARM" scrolling in there.
If this is a "feature" could someone explain to me what it's indicating ?
Thanks !
-=dave
ps- virtual amps guage appears to be working phenominally now - calibrated on a 1500mAh/128g battery; MWOSD indicated 1140mAh used, charger put in 1126ma. I then flew a 2200mAh/179g battery (felt like a pig) and MWOSD indicated 1625, charger put in 1611ma . I'll try later with a 1300mAh/117g battery and remove the Mobius to make sure the estimation works okay for a lighter setup. Thanks again !
Re: MultiWii OSD - MWOSD
@ tungsten - have you enabled #define BASEFLIGHT in config.h ?
@jmisuraca - brightness is related to voltage on the cam / vtx so it could be dropping under load - or it could also be bad earthing layout. Grounding vtx, osd and cam to a central point closest to battery may help. Worth trying the big cap too.
@jmisuraca - brightness is related to voltage on the cam / vtx so it could be dropping under load - or it could also be bad earthing layout. Grounding vtx, osd and cam to a central point closest to battery may help. Worth trying the big cap too.
Re: MultiWii OSD - MWOSD
shikra wrote:@ tungsten - have you enabled #define BASEFLIGHT in config.h ?
@jmisuraca - brightness is related to voltage on the cam / vtx so it could be dropping under load - or it could also be bad earthing layout. Grounding vtx, osd and cam to a central point closest to battery may help. Worth trying the big cap too.
Hey shikra,
I was wondering if the baseflight current output has made it in to this beta release, if so I am game to test it.