MultiWii OSD - MWOSD

shikra · Post by **shikra** » Thu Jun 05, 2014 4:57 pm

Should have done this ages ago - built myself a test rig. Can adjust volts / amps /rssi and also pwm rssi. Save having to ask people to test or connect up copter...

Adrianm1972 · Post by **Adrianm1972** » Thu Jun 05, 2014 5:14 pm

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.

Truglodite · Post by **Truglodite** » Sat Jun 07, 2014 7:34 am

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:

: Test Supply

Also, here is how I added the 33k resistor to my current sensor for 1.1V output:

: Adding a 33kOhm resistor like this changes the output from 5V to 1.1V @ 90A.

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

Truglodite · Post by **Truglodite** » Sun Jun 08, 2014 10:29 pm

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

shikra · Post by **shikra** » Mon Jun 09, 2014 1:01 pm

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

shikra · Post by **shikra** » Mon Jun 09, 2014 4:53 pm

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.

SecretSpy711 · Post by **SecretSpy711** » Mon Jun 09, 2014 5:51 pm

+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.

shikra · Post by **shikra** » Tue Jun 10, 2014 1:18 pm

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!

SecretSpy711 · Post by **SecretSpy711** » Tue Jun 10, 2014 9:53 pm

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?

shikra · Post by **shikra** » Wed Jun 11, 2014 11:25 am

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

Adrianm1972 · Post by **Adrianm1972** » Wed Jun 11, 2014 4:52 pm

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.

rank · Post by **rank** » Thu Jun 12, 2014 12:03 am

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?!

subaru4wd · Post by **subaru4wd** » Thu Jun 12, 2014 2:53 am

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.

HFMan · Post by **HFMan** » Thu Jun 12, 2014 5:45 am

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.

shikra · Post by **shikra** » Thu Jun 12, 2014 5:02 pm

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

whakahere · Post by **whakahere** » Sun Jun 15, 2014 5:15 pm

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?

tanman · Post by **tanman** » Mon Jun 16, 2014 1:28 am

downloaded the whitespy version. any idea what is the difference?

HFMan · Post by **HFMan** » Mon Jun 16, 2014 4:09 pm

What do you mean "downloaded the witespy version" ? For MWOSD, there is one version- R1.1.

subaru4wd · Post by **subaru4wd** » Mon Jun 16, 2014 4:53 pm

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.

tanman · Post by **tanman** » Tue Jun 17, 2014 8:04 am

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

ReadError · Post by **ReadError** » Sat Jun 21, 2014 11:33 am

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?

Debogus · Post by **Debogus** » Sat Jun 21, 2014 10:28 pm

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

tungsten2k · Post by **tungsten2k** » Tue Jun 24, 2014 10:48 pm

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

shikra · Post by **shikra** » Thu Jun 26, 2014 9:51 am

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

tungsten2k · Post by **tungsten2k** » Thu Jun 26, 2014 4:29 pm

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

shikra · Post by **shikra** » Thu Jun 26, 2014 5:24 pm

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.

tungsten2k · Post by **tungsten2k** » Thu Jun 26, 2014 5:30 pm

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

shikra · Post by **shikra** » Thu Jun 26, 2014 8:21 pm

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?

Debogus · Post by **Debogus** » Fri Jun 27, 2014 12:10 am

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

tungsten2k · Post by **tungsten2k** » Fri Jun 27, 2014 6:38 am

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

Debogus · Post by **Debogus** » Sat Jun 28, 2014 6:03 am

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

shikra · Post by **shikra** » Sat Jun 28, 2014 10:54 pm

@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.

ReadError · Post by **ReadError** » Fri Jul 04, 2014 6:15 am

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.

shikra · Post by **shikra** » Fri Jul 04, 2014 12:04 pm

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.

ummagawd · Post by **ummagawd** » Mon Jul 07, 2014 7:48 am

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!

HFMan · Post by **HFMan** » Tue Jul 08, 2014 5:13 am

As soon as you arm, the timer automatically switches to flight time.

ummagawd · Post by **ummagawd** » Tue Jul 08, 2014 7:24 pm

awesome... looks like i'll proceed with installation then!

thank you!

shadowjig · Post by **shadowjig** » Wed Jul 09, 2014 3:21 am

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?

shikra · Post by **shikra** » Wed Jul 09, 2014 9:27 am

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

ttsalo · Post by **ttsalo** » Thu Jul 10, 2014 12:23 am

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.

shadowjig · Post by **shadowjig** » Thu Jul 10, 2014 2:47 am

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?

shikra · Post by **shikra** » Thu Jul 10, 2014 11:15 am

@ 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.

shadowjig · Post by **shadowjig** » Thu Jul 10, 2014 3:29 pm

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 · Post by **tungsten2k** » Mon Jul 14, 2014 5:55 am

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

shikra · Post by **shikra** » Mon Jul 14, 2014 10:06 am

Excellent - thanks for the feedback.

Am just finishing up some bits for the beta of release - hopefully available in next week or two

jmisuraca · Post by **jmisuraca** » Thu Jul 17, 2014 7:39 am

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 · Post by **tungsten2k** » Thu Jul 17, 2014 4:38 pm

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

tungsten2k · Post by **tungsten2k** » Thu Jul 17, 2014 4:53 pm

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 !

shikra · Post by **shikra** » Thu Jul 17, 2014 7:05 pm

@ 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.

ReadError · Post by **ReadError** » Thu Jul 17, 2014 8:29 pm

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.