MultiWii OSD - MWOSD

Fastrack · Post by **Fastrack** » Thu Sep 25, 2014 1:43 am

Corrupt characters.. with 1.1 and 1.2pre3.

I did a EEPROM clear with 1024 bytes before each (Which now I know doesn't have anything to do with the max7456 chip). First thing is I upload the font file.

I'm using the Minimosd from witespy. Connected to the Multiwii (running 2.3) I see corrupt characters.

When just connected via FTDI and try to do a "Simulate on OSD" I do not get a video signal?? I'm assuming "Simulate on OSD" is supposed to bring up the video and show you a preview.?

Edit 1: I did some more reading last night, and corrupt characters can be caused by not enough current/voltage from the USB port (ftdi). So I used my 5V BEC which is powered via a 12V 260mA AC/DC adapter and feed that into the MAX side of the board. On the FTDI side I did not connect the power. The results are the same, the characters are still messed up.

I even tried TeraTerm from the rush-osd to upload the character set.. Same result!
https://code.google.com/p/rush-osd-deve ... Map_Upload

Edit 2: I removed the "solder" bridges on the board (front and back) and powered the max side with a 3S and the other side via the FTDI adapter.. SAME THING... no change!!!

I put the soldered the bridges back.

Fixed: I took a look at my FTDI adapter and it was outputting 3.3V! There was a bridge with a 0 ohm resistor on the 5V pad, but the board is silk screened wrong. the 3.3V pad needs to be bridged, which produces 5V.

I flashed using just the FTDI adapter 1.2pre3 and uploaded the character set again.. It's all good, characters are 100%.

Remaining Issue: The characters seem dim on the screen, I've read this could be tvl > 600. I'm not sure though... Mine is 800tvl

I've tried searching Google, but I haven't had much luck,... Just issues with the "Run cam" but mine isn't that..

This is my camera:
http://www.surveilzone.com/sony-double- ... ase-hs1170

Ben

shikra · Post by **shikra** » Fri Sep 26, 2014 1:40 pm

@ Fastrack. good to figure out the issue. a few have been caught with that one!

For the dim characters I am not aware of a fix for that yet. I think I understand the issue. Pretty sure that its ignoring start of new frame so only every other frame shows the image. Therefore its running at 50% brightness.

What can try - in config enabling these two:
#define FASTPIXEL // Optional - may improve resolution - especially hi res cams
#define WHITEBRIGHTNESS 0x00 // Optional change from default 0x00=120%,0x10=90%0x11=80% default is 0x01=100%,

shikra · Post by **shikra** » Fri Sep 26, 2014 1:54 pm

I'm feeling a lot of love in here!

unfortunately I'm only into chicks... )

I had a test flight yesterday - unfortunately the waypoints were not counting up. In case not following the GPS thread have asked to confirm which info I need to read.
I think I'm reading the correct one and it simulates OK but have to wait for feedback on that.

The other bits work OK - indicators for Mission and the waypoint. Just got to get the number working and I think we are good to release.

jaames74 wrote:
shikra wrote:This is how waypoint / mission mode will look. From about 15 secs in...:

@ Jaames74 - does that look the sort of thing??
Note that the waypoint number is actually "step" number as far as i can tell. I need to understand the whole navigation stuff a bit more - its not my thing really as I normally just fly acro FPV so not 100% sure what info can get easily from the controller.

wtf?? WOW!!
i think i love you!!

Fastrack · Post by **Fastrack** » Sat Sep 27, 2014 12:35 am

shikra wrote:@ Fastrack. good to figure out the issue. a few have been caught with that one!

For the dim characters I am not aware of a fix for that yet. I think I understand the issue. Pretty sure that its ignoring start of new frame so only every other frame shows the image. Therefore its running at 50% brightness.

What can try - in config enabling these two:
#define FASTPIXEL // Optional - may improve resolution - especially hi res cams
#define WHITEBRIGHTNESS 0x00 // Optional change from default 0x00=120%,0x10=90%0x11=80% default is 0x01=100%,

I had Fastpixel enabled already (after I made my post) and that did improve it. It was hard to explain, it wasn't that the fonts were "see-through" like the picture on the first few pages. But I think it was just that the characters are thin.

I uploaded the Fonts by ABL and they look good. viewtopic.php?f=8&t=4865&p=55552&hilit=font#p55552

But what really improved it.. Was a setting in my camera to switch from CRT to LCD! The characters are mint now. At least inside... I have to take it outside and do some colour adjust etc..

The "HB Elevation" Lines were very thin, but now they look great.

Ben

tungsten2k · Post by **tungsten2k** » Sat Sep 27, 2014 1:44 am

Okay, it seems this Mac GUI doesn't work at all (similar to previous reports from others).

I know you don't have a Mac, so how can I help ? I can setup a WebEx if you want to play with it yourself.

Code: Select all

Sep 26 17:41:04 FiveAngle com.apple.launchd.peruser.503[146] (MW_OSD_GUI.448656[47403]): Job failed to exec(3) for weird reason: 13
Sep 26 17:41:04 FiveAngle.local Finder[181]: 8837325: Attempting to SIGCONT to pid #47403 failed, with errno=#3, or the process failed to actually start
Sep 26 17:41:04 FiveAngle.local Dock[178]: no information back from LS about running process LSASN:{hi=0x0;lo=0x1ec1ec}
Sep 26 17:41:04 FiveAngle.local Finder[181]: 8837325: Attempting to SIGCONT to pid #47403 failed, with errno=#3, or the process failed to actually start
Sep 26 17:41:34 --- last message repeated 98 times ---

UPDATE: shikra, you've changed the executable name from default

For all mac users, you now need to chmod like this:

OLD: chmod +x MW_OSD_GUI.app/Contents/MacOS/JavaApplicationStub

NEW: chmod +x MW_OSD_GUI.app/Contents/MacOS/MW_OSD_GUI

or download this one ready to go:
https://www.dropbox.com/s/562jpplpjt4x1 ... UI.app.dmg

shikra, when you're ready to release, send me the final and I'll create a dmg of it just like this that you can include, so Mac users won't have such a tough time right out of the gate.

I'll mess with the Mac version more tonight but it seems to not be working with my CP2102 TTL USB bridge.

-=dave

shikra · Post by **shikra** » Sat Sep 27, 2014 11:10 pm

@tungsten - thanks for the offer - can you pm me an email address and I'll send over some instructions to hopefully compile it into a proper app.

No idea about that file name stuff ... I wouldn't know how to do it if I tried on a MAC !!

shikra · Post by **shikra** » Sat Sep 27, 2014 11:14 pm

@fastrack - thats really interesting feedback. What you describe with CRT/LCD directly relates to what I suspected - not detecting every other interlacing frames. Cuts line thickness in half + effect of 50% brightness.

Just to confirm - is that setting on the camera?? if so can you describe where? You could become a V popular guy if its on the cam

shikra · Post by **shikra** » Sat Sep 27, 2014 11:22 pm

@Jaames74

I think the Mission waypoint / steps are working OK on OSD now
I had a very quick test flight in garden and it looked good.

Have a 26 step mission planned for monday. Will know for sure then!

Fastrack · Post by **Fastrack** » Mon Sep 29, 2014 12:30 am

shikra wrote:@fastrack - thats really interesting feedback. What you describe with CRT/LCD directly relates to what I suspected - not detecting every other interlacing frames. Cuts line thickness in half + effect of 50% brightness.

Just to confirm - is that setting on the camera?? if so can you describe where? You could become a V popular guy if its on the cam

My camera is from SurveilZone, it's the HS1170 based on the effio-v chipset, 800tvl and part of the 960H series.

It's a menu setting on page two of the options. Under Sys Setting called "LCD/CRT", there is no question the picture improves, as it's not blown out anymore (clouds/blue sky), even after contrast/brightness it still did not look right.. Until I changed it to LCD... the difference is/was huge. The text is also improved! I'm going to try your fonts and see what I like better, now I have that issue solved.

Question: How do you do the virtual current sensor cal? Do you just mount a current meter, hover at a safe distance and read the amp meter display (the weight of the current meter would effect this value slightly)? I've looked all over but I can't find how to enter the data obtained into the gui... ? Is the value like the others.. ie "150" is actually 15.0 amps?

This is the one I have:
http://www.hobbyking.com/hobbyking/stor ... lyzer.html

... Off topic... This was my first ever FPV flight.. the OSD worked perfectly. The hobby king alarm started to sound and a few seconds later the voltage on the lcd started to flash! (I have it set for 3.4V)

But man alive I could barely look at the screen, all I wanted to do was look at the quad

FPV is not easy.. HAHA!

tungsten2k · Post by **tungsten2k** » Mon Sep 29, 2014 2:31 am

Fastrack wrote:Question: How do you do the virtual current sensor cal?

https://code.google.com/p/multiwii-osd/wiki/Calibration

-=dave

shikra · Post by **shikra** » Mon Sep 29, 2014 12:15 pm

Fastrack wrote:Question: How do you do the virtual current sensor cal? Do you just mount a current meter, hover at a safe distance and read the amp meter display (the weight of the current meter would effect this value slightly)? I've looked all over but I can't find how to enter the data obtained into the gui... ? Is the value like the others.. ie "150" is actually 15.0 amps?

Just to add - 150 would be 15.0 amps. This figure is the current draw at 50% throttle - or more accurate - a PWM value of 1500

its not necessarily the hover value.

If you can tied down your copter, connect an ammeter and run it at approx 50% throttle, then adjust the OSD so it matches the ammeter value. Alternatively use the battery capacity method as outlined in the link.

shikra · Post by **shikra** » Mon Sep 29, 2014 12:29 pm

Just to update - tested navigation this morning with latest dev version of multiwii R1705 and it worked good. 26 points through to an excellent autolanding.

Check out the mode icon - indicates the waypoint icon next to it. About 1 minute in it starts clocking through them pretty rapidly.
Normal speed video starts at 1:37

Code locked - no more last minute additions.

visper · Post by **visper** » Mon Sep 29, 2014 12:46 pm

We're sorry, this video is private.

shikra · Post by **shikra** » Mon Sep 29, 2014 2:35 pm

problem between the keyboard and the seat - fixed!!

Fastrack · Post by **Fastrack** » Mon Sep 29, 2014 3:20 pm

tungsten2k wrote:
Fastrack wrote:Question: How do you do the virtual current sensor cal?

https://code.google.com/p/multiwii-osd/wiki/Calibration

-=dave

Thanks Dave, I saw/read that link

I was more wondering "the method" people use to do this once it's connected inline!

shikra wrote:
Fastrack wrote:Question: How do you do the virtual current sensor cal? Do you just mount a current meter, hover at a safe distance and read the amp meter display (the weight of the current meter would effect this value slightly)? I've looked all over but I can't find how to enter the data obtained into the gui... ? Is the value like the others.. ie "150" is actually 15.0 amps?

Just to add - 150 would be 15.0 amps. This figure is the current draw at 50% throttle - or more accurate - a PWM value of 1500 its not necessarily the hover value.

If you can tied down your copter, connect an ammeter and run it at approx 50% throttle, then adjust the OSD so it matches the ammeter value. Alternatively use the battery capacity method as outlined in the link.

Okay I was correct 150 is 15.0

I was stumped about the voltage warning setting at first.. what on earth is 138 in the GUI.. lol I then saw it in a FAQ on a webpage that it meant 13.8v

My quad hovers at 51% throttle according to the screen/OSD. I also have my Taranis "speaking" the throttle values if I flip a switch.. HEHE

Ben

Hypermobile · Post by **Hypermobile** » Tue Sep 30, 2014 4:56 pm

@Shikra,

Running the 1.2 Pre 3 (multiwii 2.4 config.h) >> Eosbandi Nav B7.

It still stops Overlaying. as it was in R1.1
Could it have something to do with powersupply.

FC has a dedicated BEC
And since the OSD gets pretty hot....i though it would be safer for the FC to use one of my ESC Becs for powering the OSD...

Maybe the voltage is not so stable as should....during more or less acrobatic flying. (high load/no load on the battery)

Fastrack · Post by **Fastrack** » Wed Oct 01, 2014 2:45 am

So I tethered my quad in door frame that's 4' wide.

- Using the OSD throttle @ 50%, I got 17.35A
- I disconnected the OSD and hooked up bluetooth.. @ 1500 pwm in MultiWiiConf, I got 18.35A
- Switched back to the OSD and saw 17.17A to get 18.35A I had raise the throttle to 55%

Since I can't see the MultiWiiConf readout and the OSD at the same time, I can't see what 50% related to? But you said 50% is 1500 pwm?

It's not a huge difference... But I'm not sure why it's different?

I tend to over analyze things... so if these are crazy questions.. let me know.. LOL

Should these be sync'd up with the Multiwii Config values?

GlobalVariables.h:
// STICK POSITION
#define MAXSTICK 1900
#define MINSTICK 1100
#define MINTROTTLE 1000

//For Current Throttle
uint16_t LowT = 1100;
uint16_t HighT = 1900;

Multiwii - Config.h:
MINTHROTTLE 1220
MAXTROTTLE 2000
MINCOMMAND 1000 << I underswtand if motor_stop is enabled this is used for MINTHROTTLE vs the above.

Multiwii.h
MINCHECK 1100
MAXCHECK 1900

I do have SImonK firmware so I should probably be using 1064 for MINTHROTTLE, but this was the default from Witespy.

Ben

Mariete · Post by **Mariete** » Wed Oct 01, 2014 9:59 pm

Yesterday I did a quick test with 1.2 Pre 3 (Using Naze32) everything fine :-)

chilau2000 · Post by **chilau2000** » Thu Oct 02, 2014 2:12 pm

Hi

I am currently running mwosd with a naze 32 acro (without baro and magnetometer) and ublox gps.
Was wondering if the home arrow direction will work without the magnetometer. The arrow does seem to move but is always off.
I have a ezosd which gives home arrow direction and that does not have a compass module.

shikra · Post by **shikra** » Thu Oct 02, 2014 4:41 pm

@chilau - no sorry it relies upon the mag data from the FC.

@fastrack - probably overthinking it a bit! Alll need to do is adjust the OSD so the the OSD displays the same as the amp meter at somewhere around the hover point. Its an approximation so not going to be as good as a hardware sensor. That said I've been quite surprised at the accuracy.

@Mariete - thanks for teh feedback

@Hypermobile - as you describe it does sound like a hardware fault. Possibly as it warms up. If it were me, I'd swap it out. they are uqite cheap now. Worst case you get a spare:)

Fastrack · Post by **Fastrack** » Thu Oct 02, 2014 5:52 pm

shikra wrote:@chilau - no sorry it relies upon the mag data from the FC.

@fastrack - probably overthinking it a bit! Alll need to do is adjust the OSD so the the OSD displays the same as the amp meter at somewhere around the hover point. Its an approximation so not going to be as good as a hardware sensor. That said I've been quite surprised at the accuracy.)

Lol .. I tend to over think this stuff.. But yeah your right it's a approximate anyway! :idea:

Ben

o_lampe · Post by **o_lampe** » Fri Oct 03, 2014 2:03 pm

Hi Shikra,
thanks for such a nice OSD sw and GUI!

I have a question, which is a little out off the box:

Can I use a HW pin on the minim-OSD to make the text flip vertically?
Reason for the question is: I want to use the OSD as a powermeter for my electric recumbent bike and at the same time I use two nightvision cameras at front and rear. I can switch the monitor between both cameras, but the cameras are mirrored as they are used in cars for reverse cams. To have a corrected view for the frontcam, I can switch the monitor to " unmirror" the view. Unfortunately the text from the OSD get's mirrored at the same time. I can't switch the camera to show unmirrored video.

In the next step, I want to add a small arduino-nano with external GPS/mag combo to give me home direction and distance to home and probably GPS speed.
Is it possible to strip down the MWII-Nav code to make it fit in the nano? I wouldn't need the whole horizon and waypoint-stuff. Sorry it get's OT here..

Another headake I got from trying to connect the OSD to my CriusAIOP board. I read a few pages in rush-OSD/ KV-OSD threads and this thread too, but I got more and more confused. Why isn't this mentioned in their google-wikis? Same goes to other HW-changes like reading/connecting high voltage battery ( 16S ) and HW-current sensors. All I found is related to APM FCs.

Olaf

shikra · Post by **shikra** » Fri Oct 03, 2014 3:52 pm

@olampe

- to enable reversing is possible, but would require the font file to have normal fonts + reversed fonts. Easy if you kept display to text only and limit the non text font.
Also would need to reverse the character positions on the screen + a small read of the select pin.
Its not difficult - just takes time. Well outside scope of this project unfortunately. i can give guidance if you want to have a go....

Can't connect up OSD to a 32u4 based controller - so i'd probably plump for TC's naze32 if you want smallest option that supports OSD and GPS

Must admit I've not created anything for hardware connectivity. On purpose as I just don't have the time to help with queries + there are so many options out there. The guys who sell the hardware can do their bit as they make the money. Credit to multiwiicopter.com - he sent me some boards to help with test / dev of OSD.

Cool to see electric bike BTW - we just had electric hybrid to test at work. A big 4x4 with 155 MPG ......

o_lampe · Post by **o_lampe** » Sat Oct 04, 2014 9:22 am

shikra,
the arduino nano has a 328p processor. IIRC,it has 2 serial ports. I also have an outdated i2c_to_serial GPS board, but I'm not sure if that works with GPS/mag combos?

Regarding the hardware connections: it would help to understand how the MWOSD-board gets the information from the FC. Does it poll data, or do I have to enable any "#define blabla" options in FC-config.h? Are the rx/tx lines crossed? Stuff like that is universal and mostly not HW-dependant. A few words of explanation in your wiki, to help the minimOSD-newbie won't hurt.

OT: Nice to meet a colleague! The biggest 4x4 we converted to electric drive was a humvee, but we also did some diesel/electric busses and trams worldwide. Check out "Detroit electric sp:01", our fastest e-car designed by ECE cars

Arakon · Post by **Arakon** » Sat Oct 04, 2014 10:18 am

1 serial port only on the 328p. The I2C board has absolutely nothing to do with the mag, those combo boards just have the mag stuck onto the same board as the GPS, but technically, they're entirely seperate units.

HFMan · Post by **HFMan** » Sun Oct 05, 2014 6:02 pm

Does anybody know if the 'compass' and home arrow on the OSD work properly when an Naze32 acro is configured for fixed wing and a gps is installed? Got a buddy with this setup in his wing, and the compass is flat out wrong most of the time, as is the arrow that points home. Distance to home appears to work and is accurate.

shikra · Post by **shikra** » Sun Oct 05, 2014 7:27 pm

@Hfman - sorry it relies on mag. Need the Naze32 with mag

@o_lampe -

Connections - see if I can find some diagrams I can link too. Tx on FC is connected to Rx on OSD. Rx on FC is connected to Tx on OSD.

Polling - yes it polls for data. Which data depends upon what options are configured or mode.

Config.h - 95% of people probably don't need to touch config.h only play with it if need some functionality which is missing or to select non standard hardware / board types

Regarding the hardware connections: it would help to understand how the MWOSD-board gets the information from the FC. Does it poll data, or do I have to enable any "#define blabla" options in FC-config.h? Are the rx/tx lines crossed? Stuff like that is universal and mostly not HW-dependant. A few words of explanation in your wiki, to help the minimOSD-newbie won't hurt.

shikra · Post by **shikra** » Tue Oct 07, 2014 3:24 pm

Hello

MW OSD R1.2 is now available to download:
https://code.google.com/p/multiwii-osd/

As well as software, some other amendments:

xPRimNT · Post by **xPRimNT** » Wed Oct 08, 2014 3:08 am

Awesome work Shikra.

I've been using MWOSD on a Quad with excellent success, and I'm glad to see all the continued work!

However, being halfway through a lightweight FPV plane build, I'm suddenly disheartened in the fact that I never even though about the home arrow being reliant on the compass. I'm not sure why it didn't cross my mind, but I definitely can't change the setup now!

But, that brings up the question, does the home arrow NEED to rely on the magnetometer? I know it is currently coded as such, and I don't have any knowledge on this, but is there a possibility of alteration to allow the home arrow to work with GPS alone?

BestView · Post by **BestView** » Wed Oct 08, 2014 7:18 am

The home arrow works fine on my fixed wing without a magnetometer, only GPS. I'm using an Afromini32 with PatrikE's Baseflight code.

shikra · Post by **shikra** » Wed Oct 08, 2014 9:47 am

OK - let me give a better answer than last time !!!

The OSD is completely dependant upon the Flight controller for the "compass", heading, and direction to home arrow.
There are two values it gets from the controller - heading and angle to home.

Under normal multiwii code I'm 95% sure it needs the MAG.

For PatrikE's code I don't know - I think he uses GPS alt instead of baro. Its quite possible he uses GPS for direction too. From your vid it looks good to me!

Patrik is probably better placed to answer - and confirm for standard code too.

OSD doesn't know or care how its generated.

xPRimNT · Post by **xPRimNT** » Wed Oct 08, 2014 2:09 pm

Interesting.

Thanks for the replies.

My plan is to use PatrikE's Modifications, and I know that it does not require the mag for RTH. As such, it uses GPS for getting home, so if the OSD is just getting that data, then I may be in luck!

Still have to finish building, but will certainly give it a try. Thanks again.

kilby · Post by **kilby** » Wed Oct 08, 2014 3:34 pm

I have heard it said that on a fixed wing you can get getaway without a compass as a fixed wing aircraft is always (well near enough) moving forward so a heading can always be calculated from gps data.

Multi rotors are different as forward movement is not necessarily taking place therefore a magnetometer is required.

Sorry for butting into the conversation

o_lampe · Post by **o_lampe** » Wed Oct 08, 2014 4:31 pm

Success!

Thanks to shikras explanations, I got it running! MWII V2.3 on a miniMWC with I2C-GPS and a minimOSD from HK.

It's a huge mess with all the cables and adapters...but hopefully it will fit in the small cockpit, I have on my e-bike.

One remark on the new v1.2: in config.h:
I was desperately searching were I could select my minimOSD ( only whitespy and rushOSD were listed )
A short remark in the description that minimOSD doesn't need to be selected, would have saved me a few hours, trying to make it run with rushOSD selected :lol:

I also found, that the GUI is sometimes very slow and unresponsive...
Everytime I tried to switch an option on/off it toggled the blue bar of the option in the right place...and then dropped back! Very frustrating...but eventually I got it working without knowing, what I did different this time?!

Now I have to deal with the mirrored text and compass...tomorrow

THX for the help so far
Olaf

shikra · Post by **shikra** » Thu Oct 09, 2014 1:10 pm

I'll add an option for MinimOSD as default... in reality it will do nothing

For GUI - try downloading 1.2 again. I made a small change to the GUI only. Mainly cosmetic, but one bit may help

Also - turn off the simulator may help speed up any gui response issues when making config changes.

------------
For you electric bike...

You want a rear facing camera and a front facing - and to switch between them, but both with an OSD...?

What not feed both cameras into a switcher like this...
http://hobbyking.com/hobbyking/store/__ ... tcher.html
Then the output of that through the OSD to your monitor? . Any mirroring can be set on camera. No need to mess with code
Also Some of the cams have a built in reversing distance "ladder" I noticed it in mine this week as I'm fitting to a camper.

roderz · Post by **roderz** » Sat Oct 11, 2014 7:10 pm

Did anyone get the GUI to work with a MAC?

I keep getting a damaged file message.

What's the secret to unleashing this awesome piece of work on my Macbook Air?

o_lampe · Post by **o_lampe** » Sat Oct 11, 2014 7:48 pm

I'm trying to read amperes from the multiwii-fc. In Mwii-conf I can't see an amp-value but the powermeter value. It increases by 1 (mAh?) each second, no matter how low or high I set the "psensornull" value.

The amp-value from the OSD is always 5.5A and is also unchanged by the "psensornull" value or the zero adjust value in the OSD-GUI.
Unless I unplug the currentsensor, then I get different amp-readings, which indicates, I'm reading the right port.

I read the powermeter wiki and also your current calibration wiki, but no luck.
It seems, there is an error in the MWII-powermeter code? At least for my bidirectional 50A sensor, it doesn't work.

shikra · Post by **shikra** » Sat Oct 11, 2014 10:11 pm

@ Olaf - which sensor? bi-directional can be a bit odd sometimes

@roderz -Can you check the MAC fixes in the FAQ .....
https://code.google.com/p/multiwii-osd/wiki/FAQ

roderz · Post by **roderz** » Sun Oct 12, 2014 5:25 am

Noted and many thanks shikra.

It now loads on my Macbook.

Great stuff!

41south · Post by **41south** » Mon Oct 13, 2014 3:12 am

Howdy all, some newbie questions that I haven't quite got to grips with

I bought a Witespy board ages ago and it appears to have minimosd on it (the Arducam config app connects and configs the layout etc)

To load mwosd firmware it looks like I first need to do that via Arduino? Can I use the same usb/ftdi adapter I have for the above or do I need to go via the isp header pins?

Edit: Sorted! Arduino worked just fine via my ftdi adapter

o_lampe · Post by **o_lampe** » Mon Oct 13, 2014 12:15 pm

shikra wrote:@ Olaf - which sensor? bi-directional can be a bit odd sometimes

It's a ACS758B-050B from DFrobot. It has 40mV/A sensitivity and a zero current output of 1.58V
I have a datasheet, but can't upload here ( .pdf)

I really don't want to solder cables on the minimOSD atmega pins, otherwise I'd test it the direct way.
I'll dig in the mWii code for the pmeter calculation, maybe I find something odd there...

shikra · Post by **shikra** » Mon Oct 13, 2014 12:47 pm

I had a quick look at the datasheet and I think that one:
Is Bi-directional
Requires a 5v supply to the sensor
Has an offset of 2.5v

I'd suggest...
Must have reference voltage set to 5v - or a 5:1 resistor ladder to drop voltage down to use 1.1v reference
Make sure it has 5v supply if its needed. Check carefully - don't trust me fully on that!!
in config.h, enable and set AMPERAGEOFFSET to 450
Then try following calibration guide

I updated the FAQ/calibration today as had couple of question on this now over the months.

o_lampe · Post by **o_lampe** » Mon Oct 13, 2014 5:32 pm

My sensor reads 1.58V at zero current, maybe it's faulty...
I changed the AMPERAGEOFFSET to 450 ( was 158 ) and it doesn't change anything..
Actually I did the same zero offset stuff in MWii's config.h . I expect when minimOSD just polls data, it should read 0.0A.

I've set the other amperagemax value to 1000 ( +/- 50A ) . Is that correct?

<edit > How can this sensor read -50A with a sensitivity of 40mV/A and a zeroA of 1.58V. The output would be -0.42V! It's definitely broken...

(

shikra · Post by **shikra** » Mon Oct 13, 2014 7:03 pm

Just to clarify... where is the sensor connected? to the OSD or to Multiwii FC ?? I assumed it was the OSD.

If its the multiwii FC then everything I've said is crap... lol.

schnupperm · Post by **schnupperm** » Tue Oct 14, 2014 1:28 am

Hello,
first of all, thanks for that nice OSD.

Last weekend I tried to add something like a flight path vector to the 1.2 release. It takes gimbal status and FOV of the camera/monitor combination into account and should point in the direction the copter is flying. If anyone wants to try it, I attached a diff against rev 1.2.

shikra · Post by **shikra** » Tue Oct 14, 2014 9:18 am

@o_lampe

Looked at your photo and I think you have the current sensor connected to the multiwii controller. If that is the case then you have to do all the config on the multiwii FC itself. All the OSD does is display the value the FC sends it. It makes assumption that it is set correctly.

For Clarity, I updated the calibration wiki to advise that. I can see how one would think the adjustments would be relevant. Its same for voltage too....

This describes how to...
http://www.multiwii.com/wiki/index.php?title=Powermeter

shikra · Post by **shikra** » Tue Oct 14, 2014 10:17 am

@schnupperm - I'm not quite sure what it does - can you describe a little? Seems to display deviation between heading and direction copter is facing??

o_lampe · Post by **o_lampe** » Tue Oct 14, 2014 11:07 am

Sorry for all this OT...

I got it working: The A2 port of the miniWii is the problem. It is designated as HV powerinput and messed up the current sensor signal. I had to redirect voltage measure to A0 and current to A1 ( on miniWii's config.h ). Finally I got a zero current readout of 2.5V instead of 1.58V and adjustable parameters, too...

Too bad, I can't adjust pmeter zero with MWiiConf, always have to go the arduino-IDE hard way:

erase eeprom
flash new parameter
start MWiiConf and calibrate acc
and theeeeen
connect OSD and check the readout...

Now comes the same odyssey with some current flow to adjust the PINT2mA Parameter :evil:

Thanks again shikra, for all the time and help making OSD better

shikra · Post by **shikra** » Tue Oct 14, 2014 1:00 pm

Cool! got there in the end. You had me puzzled for a while - but on a positive we have updated documentation and save memory saving from when looked at the code

schnupperm · Post by **schnupperm** » Tue Oct 14, 2014 5:20 pm

@schnupperm - I'm not quite sure what it does - can you describe a little? Seems to display deviation between heading and direction copter is facing??

Yes, I calculate the diff. between heading and GPS ground course and the angle at which the copter is ascending/descending. With the result I try to mark a point in the video image to which the aircraft is flying, using the user supplied info about the FOV of the video system. (I think this is called flight path vector in a HUD). It seems to work quite good for me as long as the reported ground course from the MW-controller is accurate and the copter is not flying backwards.