Problem resolved!
It was PAL/NTSC problem by line counts.




With dimmed background



I just add few line for NTSC and SimpleOSD compability, please include these lines to the code.

I moved the hardware declarations to the top of your code.(below #include <avr/delay.h>)

//===========================
// HARDWARE: Arduino or SimpleOSD??
//===========================
// from code version 5 support for 16 mhz SimpleOSD have been added. It uses the same microcontroller etc - but it uses a LM1881 chip to detect new line and frame.
// Select hardware by changing "#define controller" to "#define controller 1" or "#define controller 2"
// and comment/outcomment the three lines under SimpleOSD/Arduino. 

//Arduino = 0, SimpleOSD = 1
#define controller 1

then these lines for video system selection

//===========================
// VIDEO SYSTEM: PAL or NTSC?
//===========================
//PAL = 0, NTSC = 1
#define VIDEO_SYSTEM 1
 
#if (VIDEO_SYSTEM == 0) 
  //PAL
  #define toplinetext 39
  #define toplinenumbers 49
  #define butlinenumbers 269
  #define timer_line 250
  #define gps_nmea_line 30
  #define summaryline 100
  #define current_calc_line 290
#else 
  //NTSC
  #define toplinetext 24
  #define toplinenumbers 34
  #define butlinenumbers 229
  #define timer_line 210
  #define gps_nmea_line 15
  #define summaryline 100
  #define current_calc_line 260
#endif

Your dimming declarations updated for SimpleOSD

// This is used for dimming. can be changed to another pin if you want. 
#if (controller == 0) //define Arduino's dim pin B0
  #define DimOn  DDRB |= 0b00000001;
  #define DimOff DDRB &= 0b11111110;
#else //define SimpleOSD OPEN's dim pin C5
  #define DimOn  DDRC |= 0b00100000;
  #define DimOff DDRC &= 0b11011111;
#endif

Some details about SimpleOSD for your updates.

• ADC reference is 5V
• voltage dividers is 1/11 (1kohm+10kohm)
• Volt1 pin is C7
• Current1 pin is C4
• Volt2 pin is C2
• Current2 pin is C3
• Audio Out is B3 with 100nF capacitor. You can use as PWM based buzzer for alarm sounds.

Cheers
Melih

Originally Posted by MelihK

Problem resolved!
It was PAL/NTSC problem by line counts.




With dimmed background



I just add few line for NTSC and SimpleOSD compability, please include these lines to the code.

I moved the hardware declarations to the top of your code.(below #include <avr/delay.h>)

//===========================
// HARDWARE: Arduino or SimpleOSD??
//===========================
// from code version 5 support for 16 mhz SimpleOSD have been added. It uses the same microcontroller etc - but it uses a LM1881 chip to detect new line and frame.
// Select hardware by changing "#define controller" to "#define controller 1" or "#define controller 2"
// and comment/outcomment the three lines under SimpleOSD/Arduino. 

//Arduino = 0, SimpleOSD = 1
#define controller 1

then these lines for video system selection

//===========================
// VIDEO SYSTEM: PAL or NTSC?
//===========================
//PAL = 0, NTSC = 1
#define VIDEO_SYSTEM 1
 
#if (VIDEO_SYSTEM == 0) 
  //PAL
  #define toplinetext 39
  #define toplinenumbers 49
  #define butlinenumbers 269
  #define timer_line 250
  #define gps_nmea_line 30
  #define summaryline 100
  #define current_calc_line 290
#else 
  //NTSC
  #define toplinetext 24
  #define toplinenumbers 34
  #define butlinenumbers 229
  #define timer_line 210
  #define gps_nmea_line 15
  #define summaryline 100
  #define current_calc_line 260
#endif

Your dimming declarations updated for SimpleOSD

// This is used for dimming. can be changed to another pin if you want. 
#if (controller == 0) //define Arduino's dim pin B0
  #define DimOn  DDRB |= 0b00000001;
  #define DimOff DDRB &= 0b11111110;
#else //define SimpleOSD OPEN's dim pin C5
  #define DimOn  DDRC |= 0b00100000;
  #define DimOff DDRC &= 0b11011111;
#endif

Some details about SimpleOSD for your updates.

• ADC reference is 5V
• voltage dividers is 1/11 (1kohm+10kohm)
• Volt1 pin is C7
• Current1 pin is C4
• Volt2 pin is C2
• Current2 pin is C3
• Audio Out is B3 with 100nF capacitor. You can use as PWM based buzzer for alarm sounds.

Cheers
Melih

Hi Melih
Good to see you here

Thanks for the code-updates. I will include it later today and update the analog-input selection and voltage-divider as well (for "arduino" users).

The information about connections on SimpleOSD is great - it makes it quite a lot easier to program

The mah calculation at the moment relies on the timing in the pal-signal. I will try to update that as well.

Thanks for your time - looking forward to the SimpleOSD open release

Originally Posted by carlonb

Try to measure the real voltage on 4.7K resistor, must be around 3.2V more or less, this is the voltage read by A0 pin.
The magic formula:
5V:1024=3.2V:X X=1024*3.2/5 X=6,55
Sobstitute the 3.2 with your measured voltage on A0 pin.

Note, have you set the chip to read on analog port A0 ?
This original line read A1 port:
#define mux_batVoltage ADMUX = (0<<MUX3) | (0<<MUX2) | (0<<MUX1) | (1<<MUX0) | (1<<REFS0) |(0<<REFS1);
in this:
#define mux_batVoltage ADMUX = (0<<MUX3) | (0<<MUX2) | (0<<MUX1) | (0<<MUX0) | (1<<REFS0) |(0<<REFS1);


Ciao, carlo

BINGO!!!!!! Perfect now. Thanks so much

So (I just ordered the current sensor) The current sensor wire will go to A1 and my voltage divider circuit will stay on A0 Correct??

Thanks again

Originally Posted by mrfliboy

BINGO!!!!!! Perfect now. Thanks so much

So (I just ordered the current sensor) The current sensor wire will go to A1 and my voltage divider circuit will stay on A0 Correct??

Thanks again

That's correct !
Bye

Little update...

• NTSC support (line numbers from Melih used)
• mah code updated to support timing in NTSC video signal
• In setup it's only necessary to choose controller and video system (PAL or NTSC)
• The input used for current-sensor and voltage-divider can be set by just writing the pin-number
• Calibration for voltage-divider added to setup-section
• Dimming added to SimpleOSD version (thanks Melih)

Only had time for a quick test, but everything seems to work

Originally Posted by Dennis Frie

Little update...

• NTSC support (line numbers from Melih used)
• mah code updated to support timing in NTSC video signal
• In setup it's only necessary to choose controller and video system (PAL or NTSC)
• The input used for current-sensor and voltage-divider can be set by just writing the pin-number
• Calibration for voltage-divider added to setup-section
• Dimming added to SimpleOSD version (thanks Melih)

Only had time for a quick test, but everything seems to work

Code 10 is working. Very nice. Thanks for all your efforts. Code 10 was easy as they get to setup. I have changed the lines a tad for my own liking and finished the more compact version. Current sensor on its way and than mounting on the quad. Great Project. Lots of fun. Whats Next?

Originally Posted by mrfliboy

Code 10 is working. Very nice. Thanks for all your efforts. Code 10 was easy as they get to setup. I have changed the lines a tad for my own liking and finished the more compact version. Current sensor on its way and than mounting on the quad. Great Project. Lots of fun. Whats Next?

Glad to hear you like the update. It should make the configuration a bit easier.

Looking good
Year, what's next? Guess it's time to get it airborne

All my FPV-gear is at another place atm, so I will probably not be able to test it IRL right away. If you get a chance to try it out on your quad a little recording would be nice

Originally Posted by Dennis Frie

Glad to hear you like the update. It should make the configuration a bit easier.

Looking good
Year, what's next? Guess it's time to get it airborne

All my FPV-gear is at another place atm, so I will probably not be able to test it IRL right away. If you get a chance to try it out on your quad a little recording would be nice

I think the need for the zero altitude is next or needed most. No problem on the video. Should be feasible this weekend. Thanks again

Originally Posted by mrfliboy

I think the need for the zero altitude is next or needed most. No problem on the video. Should be feasible this weekend. Thanks again

If you upload a video I will update the altitude to support an offset (which will be set with homeposition)

I'll take a look at it

Originally Posted by Dennis Frie

If you upload a video I will update the altitude to support an offset (which will be set with homeposition)

I'll take a look at it

Heck now I'm gona have to take it out tomorrow.

Stay Tuned

Originally Posted by mrfliboy

Heck now I'm gona have to take it out tomorrow.

Stay Tuned

Haha, no hurry.. Otherwise I have to work on the code as well

Originally Posted by mrfliboy

I think the need for the zero altitude is next or needed most. No problem on the video. Should be feasible this weekend. Thanks again

Here you go...
It's not a pretty implementation - but as long as you don't check the code you will never notice it

Auto-zero when home-position is set, and it also supports negative height from start point. If you turn altitude offset on it will not show negative heights (relative to above sea level), but this shouldn't be any problem as long as you stay above the water

Max altitude is 9999 m vs 99999 if you don't use altitude offset

It would probably be an idea to re-write the altitude_offset code one day (it's a mess :P) but as I don't expect anyone to ever find the limits I can't really be bothered

Wow, I'm really excited to see the progress of this project, very nice! I've been kind of busy with other things lately, but I've got a SimpleOSD 16MHz heading my way in the mail. When I have it, I'm definitely gonna try it out in my tricopter and hopefully record a video.

Has anyone flown with it yet?

Nice, what about the "reducing range" issue, have you looked into that? Was it reducing rc range or video tx range? Which rc system do you have?

Originally Posted by msev

Nice, what about the "reducing range" issue, have you looked into that? Was it reducing rc range or video tx range? Which rc system do you have?

No, I haven't looked into that but I know Dennis mentioned it. I'm planning to use the SimpleOSD hardware and I've used it before without issues. I think the only difference with the new one is the 16MHz crystal so hopefully it won't cause any problems, but I will make a range test before I fly of course.

I use FrSky 2.4GHz system.

Dennis, this is premium work, I follow this thread hourly and You come up with better code and more features day by day. Thank You for such an effort. Also thanks to other contributors and code hackers that volunteer code improvements.

I had a question, is there possibility to add some RSSI indicator / processing on screen? That could be usable.

Jancis I know that feeling, I'm refreshing this thread every few hours , and always I see something new. I'm totally hooked

One small request, can someone write a written parts list, except the arduino and gps ..

Originally Posted by andreas77

No, I haven't looked into that but I know Dennis mentioned it. I'm planning to use the SimpleOSD hardware and I've used it before without issues. I think the only difference with the new one is the 16MHz crystal so hopefully it won't cause any problems, but I will make a range test before I fly of course.

I use FrSky 2.4GHz system.

We didnt release 16Mhz Arduino booted opensource version of SimpleOSD

SimpleOSD XL version including 14.7mhz Xtal and MegaLoad boot loader for hex files. You can load the hex files from arduino(press the shift key when compiling) with megaload software(38.400 baud). Update procedure same with SimpleOSD XL.

SimpleOSD OPEN will be different than XL, it is including 16Mhz xtal and Arduino boot.

Originally Posted by MelihK

We didnt release 16Mhz Arduino booted opensource version of SimpleOSD

SimpleOSD XL version including 14.7mhz Xtal and MegaLoad boot loader for hex files. You can load the hex files from arduino(press the shift key when compiling) with megaload software(38.400 baud). Update procedure same with SimpleOSD XL.

SimpleOSD OPEN will be different than XL, it is including 16Mhz xtal and Arduino boot.

I'm Camal on your forum.. does it ring any bells?

Originally Posted by andreas77

Wow, I'm really excited to see the progress of this project, very nice! I've been kind of busy with other things lately, but I've got a SimpleOSD 16MHz heading my way in the mail. When I have it, I'm definitely gonna try it out in my tricopter and hopefully record a video.

Has anyone flown with it yet?

Thanks
Sounds great with the SimpleOSD 16 mhz, that shouldn't take many minutes to load the code and get it up and running

Originally Posted by msev

Nice, what about the "reducing range" issue, have you looked into that? Was it reducing rc range or video tx range? Which rc system do you have?

I installed the OSD shortly in a plane just before my vacation and noticed the reduction in RC-range. It was with standard 35 mhz radio. I tested a bit and it seemed to be caused by the pixel-blasting, but I can't explain why.

It was without shielded cables etc. but even then it's not okay.

Originally Posted by andreas77

No, I haven't looked into that but I know Dennis mentioned it. I'm planning to use the SimpleOSD hardware and I've used it before without issues. I think the only difference with the new one is the 16MHz crystal so hopefully it won't cause any problems, but I will make a range test before I fly of course.

I use FrSky 2.4GHz system.

The hardware in SimpleOSD should be pretty close to the hardware used in this project. It's gonna be interesting to see if I have the same problems with the 16 mhz version of SimpleOSD
Tested shortly with the cheap hobbyking OSD - no sign of reduction in range (it also uses same hardware - almost).

With 2.4 ghz I would be surprised if you get any reduction in range.

Originally Posted by Jancis

Dennis, this is premium work, I follow this thread hourly and You come up with better code and more features day by day. Thank You for such an effort. Also thanks to other contributors and code hackers that volunteer code improvements.

I had a question, is there possibility to add some RSSI indicator / processing on screen? That could be usable.

Thanks
Year, it's a progress in work - so I have to make some progress right

But right now it seems more or less finish - can't really find anything important missing.

RSSI just needs to be connected to another analog input pin, read and printed like the voltage, perhaps scaled to percent. It's not supported in the software, but you should be able to add it without problems.

Originally Posted by msev

Jancis I know that feeling, I'm refreshing this thread every few hours , and always I see something new. I'm totally hooked

One small request, can someone write a written parts list, except the arduino and gps ..

Glad to hear you like the progress

Regarding the parts-list, I'm just gonna quote myself:

Originally Posted by Dennis Frie

By request from user...

This is the schematic and the components I use at the moment. Works great for now.
Next time I buy components, I will order a couple of zener-diodes and a 10K pot. But for now, this is what I use. I get a very good sync with HK camera and fatshark (not tested with other cameras).


Components used:
1 x Atmega.
For an "easy and small hardware solution" I can recommend Arduino Pro mini (16 mhz)
http://www.sparkfun.com/products/9218

Arduino nano from dealextreme should be great as well, but I haven't received the board yet.
http://www.dealextreme.com/p/arduino-nano-v3-0-81877

Other Arduino boards can be used as well, but those mentioned have a nice size
Please note, you need AIN0, AIN1 and RX/TX. For some reason AIN0/AIN1 (can't remember which one) is not breaked out on the Arduino Mega (1280) board, and maybe other boards as well. Please check

Resistors:
2 x 120 ohm
1 x 10K ohm
1 x 100K ohm

Variable resistors:
1 x 50K pot

Diodes:
3 x 4148

Capacitors:
1 x 0.1 uF

As mentioned above, I would probably change a few components if I had the components laying around. But as I get a perfect sync I haven't really been bothered to order new components.

GPS:
http://flytron.com/osd-headtrackers/...ps-module.html

On current-sensor a 0.1 uF capacitor is added on Vin. A little lowpass filter is added on the output to average the pulses from the switching.

Originally Posted by Dennis Frie

Auto-zero when home-position is set, and it also supports negative height from start point. If you turn altitude offset on it will not show negative heights (relative to above sea level), but this shouldn't be any problem as long as you stay above the water

The option for a reset button for home and altitude would be nice. When using a wing type plane glding in the wind, the forward speed would be zero (or even negative). If done above the home position, the OSD would reset or show the summary.


Received my DealExtreme Arduino Nano's today. I will test them this evening.

Originally Posted by Sleurhutje

The option for a reset button for home and altitude would be nice. When using a wing type plane glding in the wind, the forward speed would be zero (or even negative). If done above the home position, the OSD would reset or show the summary.


Received my DealExtreme Arduino Nano's today. I will test them this evening.

Resetting home in air would require a connection to the RC-receiver. That will not be supported, at least not right now

The home position will not reset before the OSD is turned off, so that is not gonna be a problem.

If it turns out to be a problem with the summary-screen showing up I can just add some parameters you can set. This is pretty easy implemented if it turns out to be a problem:

- Current consumption is less than
- height less than
- Speed less than
- time greater than
- LOS less than

Hey Dennis

I think Sleurhutje means a push button that you can push to set home when u want (not rc controll) like most osds you can just push a button (on the aeroplane) and set home...

Would that be possible?

Chers and thanx again for your AWSOME work
Willie

Doesn't the osd automatically set home position?

Originally Posted by SX_

Hey Dennis

I think Sleurhutje means a push button that you can push to set home when u want (not rc controll) like most osds you can just push a button (on the aeroplane) and set home...

Would that be possible?

Chers and thanx again for your AWSOME work
Willie

Oh, in that case I misunderstood.

Adding a button to reset home-position etc. is no problem. Just add the push-button and write the pin-number used, I can update the code - takes around 2 minutes

Originally Posted by msev

Doesn't the osd automatically set home position?

Yes, home-position is automatically set. It waits for GPS-fix and sets home-position (you can add a little delay between GPS-fix and set-home-position in setup)

I just updated post #1 for people who haven't followed the thread (it's a long thread to read through), anything else that should be written?

Originally Posted by Dennis Frie

As this project is almost finish, I think it's time for a little update/summary here in post #1.

The main purpose of this project was to make a DIY OSD that can be made with;

• Opensource software
• Simple and cheap hardware
• Only little technical knowledge

It's not intended to be a graphic-heavy OSD, but an easy readable OSD with the most important info. But it's opensource and you can do whatever you want with it.

Quite a few updates and features have been added by request from users - and I hope to continue this. Feel free to post suggestions - but be reasonable. I don't mind to implement a feature - but I'm not gonna rewrite it all for another purpose etc.

I decided to make this project freely available and opensource - and I don't plan to earn anything on my work. Neither do I intend to sell or produce anything - but others are welcome to use it as they want.

If you don't want to make the hardware yourself the software also supports SimpleOSD OPEN (16 mhz with arduino bootloader). It's not released yet, but should be available shortly.

The OSD support theses features at the moment:

• Easy hardware design with Arduino
• Easy setup section added to code
  
• Speed from GPS
• Altitude from GPS
• Flight timer from GPS
• Position from GPS
• Heading from GPS
• Current from current sensor
• mAh used
• Auto set home position
• Calculate Line of sight
• dimming of text background
• Arrow pointing home
• Speed in km/h
• Flight summary (max altitude, max speed, max LOS, total distance traveled and average speed)
• Support NTSC and PAL
• Support SimpleOSD open 16 mhz version with arduino bootloader

Maybe a written parts list hehe

Thanks again, Code 10 ALT offset is a winner

I got everything all mounted, just need to do some ground tests and up up and away. lol

Hi Dennis,
Very good OSD, thanks a lot

Sorry if may annoing you, but we can save a top line text "SPEED LOS ALT" if you can add at side of each data field a big symbol like "K/H", "|->" (Side arrow as LOS), and a "Top Arrow" as ALT, as I saw somewere.

What do you think?

Ciao, and thanks al ot again.
Carlo

Originally Posted by mrfliboy

Thanks again, Code 10 ALT offset is a winner

I got everything all mounted, just need to do some ground tests and up up and away. lol

Looking good

Originally Posted by carlonb

Hi Dennis,
Very good OSD, thanks a lot

Sorry if may annoing you, but we can save a top line text "SPEED LOS ALT" if you can add at side of each data field a big symbol like "K/H", "|->" (Side arrow as LOS), and a "Top Arrow" as ALT, as I saw somewere.

What do you think?

Ciao, and thanks al ot again.
Carlo

I was thinking about replacing Speed with km/h, LOS and ALT with m, CUR with A and VLT with V
But it's gonna be a tight fit in top
- or alternatively just remove the topline with text. It's not exactely hard to remember 3 things - but as it can be done by just changing the linenumber I suppose people do it themself if they want.

Just tested.
Writing A, V and mah in buttom works fint.
km/h and 2 x m in top makes it a bit too "crowded".

very nice

this definitely goes on my project 'to do' list

Dennis, my wife is going to want to kick you in the jewels, haha. This is just what I have been looking for - a K.I.S.S. OSD .

Bob

Ordered this temp/current sensor. See if it's usable right away or if the current sensor needs a modification.

Originally Posted by Sleurhutje

Ordered this temp/current sensor. See if it's usable right away or if the current sensor needs a modification.

It should work just fine
But if you don't need the temperature sensor it's cheaper to buy from for example flytron (the weight and size is also preferable):
http://flytron.com/sensors/64-ultral...nt-sensor.html

Originally Posted by Dennis Frie

It should work just fine
But if you don't need the temperature sensor it's cheaper to buy from for example flytron (the weight and size is also preferable):
http://flytron.com/sensors/64-ultral...nt-sensor.html

The HK Quanum sensor is cheaper at $16,99 and shipping costs are lower. And the Quanum is a true Hall sensor, the Flytron is a resistor which is less accurate.

Ask and ye shall receive, in all its unedited glory. Enjoy

05-0101-00.20.18.mp4 (8 min 49 sec)

recorded thru SanDisk V-mate

Strictly LOS ad close range testing, Flytron Current sensor arrived today, so now I have to squeeze that on the quad. LOL

Great work, it looks awsome!!

Any one have any idea where i could buy a arduino pro that accepts western union?
I dont have paypal at the mo ???

Cheers
Willie

Originally Posted by mrfliboy

Ask and ye shall receive, in all its unedited glory. Enjoy

Strictly LOS ad close range testing, Flytron Current sensor arrived today, so now I have to squeeze that on the quad. LOL

Looking good but it looks like the Altitude isn't correctly displayed. Right after take off it jumps from 0.7 to 91.3.

Perhaps the decimals on the speed (and altitude) is a bit overkill. It distracts when flying around. That will cause your eyes to get tired more quickly...

yeah, i've always sucked at soldering. thought this is simple enough schema so i could actually do it, so finally moved it from breadboard to permanent one but it wouldn't work. There has to be some shorted wire or something because lights on android wouldn't light up when usb attached.

i give up on this - fried arduino, spent on components, but in the end my lameness require commercial solution :/

anyhow, great work guys, thank you!

Originally Posted by Sleurhutje

Looking good but it looks like the Altitude isn't correctly displayed. Right after take off it jumps from 0.7 to 91.3.

Perhaps the decimals on the speed (and altitude) is a bit overkill. It distracts when flying around. That will cause your eyes to get tired more quickly...

Later in the vid I reboot the arduino, when it was running - numbers it seemed the best LOL I'm sure its just a tweak needed somewhere.

Originally Posted by mrfliboy

Ask and ye shall receive, in all its unedited glory. Enjoy

http://www.youtube.com/watch?v=CwRT33koYIs

recorded thru SanDisk V-mate

Strictly LOS ad close range testing, Flytron Current sensor arrived today, so now I have to squeeze that on the quad. LOL

Very nice to actually see it in action, thanks a lot

Except for the altitude-fix it seems to work pretty good. I will try to find the problem with the altitude later, and also add some parameters to make sure flight-summary only show when you need it to

Originally Posted by Dennis Frie

Very nice to actually see it in action, thanks a lot

Except for the altitude-fix it seems to work pretty good. I will try to find the problem with the altitude later, and also add some parameters to make sure flight-summary only show when you need it to

I've got the current sensor all hooked up and working. Hopefully more testing today or tomorrow. Thanks

Originally Posted by Jancis

yeah, i've always sucked at soldering. thought this is simple enough schema so i could actually do it, so finally moved it from breadboard to permanent one but it wouldn't work. There has to be some shorted wire or something because lights on android wouldn't light up when usb attached.

i give up on this - fried arduino, spent on components, but in the end my lameness require commercial solution :/

anyhow, great work guys, thank you!

Sent you a PM


Another quick test vid with Flytron current sensor 50A, will report back on ma used after done charging

05-0101-00.03.05.mp4 (3 min 7 sec)

Just finished charging the lipo. DIY OSD said 793 ma used, put back in (drum roll please) 808ma. Too Cool !!!!!!!!!

Originally Posted by mrfliboy

Just finished charging the lipo. DIY OSD said 793 ma used, put back in (drum roll please) 808ma. Too Cool !!!!!!!!!

Wow, that's pretty accurate. Charging probably included some balancing. My experience is that charging adds about 2 to 5 percent extra charge capacity compared to what's actually used. For good accuracy you need to cycle your batteries a few times, fully charge it, fly with them and discharge them like you did in the cycling process. You can measure how much capacity is left by further discharging. This method is more accurate. But hey, we're talking about only <2% difference.

Originally Posted by mrfliboy

Sent you a PM


Another quick test vid with Flytron current sensor 50A, will report back on ma used after done charging

Just finished charging the lipo. DIY OSD said 793 ma used, put back in (drum roll please) 808ma. Too Cool !!!!!!!!!

That's sweet - only 1,89 % difference between charger and OSD, not bad at all

Your tests and feedback are much appreciated
I don't have the time to update the code today, but I will look at it tomorrow.

A little update...

This should be fixed in version 0.11:

• Auto altitude offset added (as an option under setup)
• No altitude info from GPS (with altitude offset on) will no more show as 6220 meter (thanks to mrfliboy - noticed this on his movie)
• Maximum speed in summary should be fixed (showed a weird string now and then)
• Parameters added to flight summary, it's now possible to choose when flight summary is displayed
• Couple of small changes
• CUR and VLT replaced with A and V. What do you prefer?

These parameters can be changed to make flight summary show when you want it to (anything else that should be added?).
- Speed less than
- LOS less than
- current less than
- flight time more than
- altitude less than

Originally Posted by Dennis Frie

A little update...

This should be fixed in version 0.11:

• Auto altitude offset added (as an option under setup)
• No altitude info from GPS (with altitude offset on) will no more show as 6220 meter (thanks to mrfliboy - noticed this on his movie)
• Maximum speed in summary should be fixed (showed a weird string now and then)
• Parameters added to flight summary, it's now possible to choose when flight summary is displayed
• Couple of small changes
• CUR and VLT replaced with A and V. What do you prefer?

These parameters can be changed to make flight summary show when you want it to (anything else that should be added?).
- Speed less than
- LOS less than
- current less than
- flight time more than
- altitude less than

Excellent, I had no problem with vlt and cur, but if it stays to me the mah looks outa place. LOL I loaded the new code 11. Went to fire the old quad up and lo and behold (a mishap in my hobbyroom) another Gaui esc fried out. Great escs but very fragile imo. So I'm down until I at least get another or replacement.

In the meantime I'll test the osd on my scratchbuilt stryker lookalike hopefully tomorrow.

Sorry to hear about the ESC, but at least it wasn't caused by the OSD

Year, the mah is a bit mis-placed, but it also looked kinda weird putting it behind the numbers. But if you have any better ideas I'll give it a shot

Originally Posted by Dennis Frie

Sorry to hear about the ESC, but at least it wasn't caused by the OSD

Year, the mah is a bit mis-placed, but it also looked kinda weird putting it behind the numbers. But if you have any better ideas I'll give it a shot

Me personally has no problem with the original lettering and all, it fit perfectly on my screen and is crystal clear in my goggles. (sounds like code 11 mrfliboy). LOL

Thanks again for the codes. So far this has been a blast.

Originally Posted by mrfliboy

Me personally has no problem with the original lettering and all, it fit perfectly on my screen and is crystal clear in my goggles. (sounds like code 11 mrfliboy). LOL

Thanks again for the codes. So far this has been a blast.

Changing to CUR and VLT again takes a few minutes - it was mainly a test

I received a PM regarding the latest schematic, and realized it's not very clear. This is the values I use at the moment. Please note that the schematic posted a while ago has R3 and R4 mixed up - my mistake, sorry guys.



It's the same schematic as shown on page 1 since the beginning of this thread - only the dimming resistor have been added and SPI-resistor have been made smaller to "match" the dimming.

Dennis, would it be possible to use a variable resistor for R1 and R2?

Originally Posted by rimshotcopter

Dennis, would it be possible to use a variable resistor for R1 and R2?

No problem at all
But they should off course be pretty accurate around 100 ohm - I guess something like 200 - 400 ohm pot will do fine.

Originally Posted by Dennis Frie

Changing to CUR and VLT again takes a few minutes - it was mainly a test

UR the man Thanks

Originally Posted by Dennis Frie

No problem at all
But they should off course be pretty accurate around 100 ohm - I guess something like 200 - 400 ohm pot will do fine.

Thank you.

Guess this will be one of the last updates - unless anyone find bugs or have ideas for improvements

• Start-up screen added. Shows number of satellites, sat-fix, delay (from sat-fix to set-home) and the time (this can be used to check if the gps update-rate is right)
• Possible to hide GPS-coordinates if altitude > x (but can be set to show every x second anyway)

Originally Posted by Dennis Frie

Guess this will be one of the last updates - unless anyone find bugs or have ideas for improvements

• Start-up screen added. Shows number of satellites, sat-fix, delay (from sat-fix to set-home) and the time (this can be used to check if the gps update-rate is right)
• Possible to hide GPS-coordinates if altitude > x (but can be set to show every x second anyway)

We need RTH

Originally Posted by vipix

We need RTH

And dont forget the fullblown IMU.

Originally Posted by vipix

We need RTH

It would be great if everything could be implemented on one microcontroller - but the controller is already pretty busy
Main problem is, that interrupt can't be used as they will disturb/interrupt the OSD (very easy to see).

It might be possible to use the hardware-controlled PWM output's to control a couple of servos without using interrupts, but you still have to read the servo-inputs as well.

While it might be possible I have to admit - I like the KISS concept
I prefer to have all my servos etc. connected directly to my receiver, but it would be fun to "play with".

Originally Posted by LKJ

And dont forget the fullblown IMU.

Year I know I talked about it a while ago
I have found 3 axis gyro and accelerometer that costs around 15 $ total. This would make a dead cheap IMU. Guess this could be a fun winter-project, but I don't have any plans to make it official. I believe projects like ArduPilot is a better choice, if you don't want to code yourself

Dennis, in your opinion, how difficult would it be to add an horizon bar to the display?

Originally Posted by rimshotcopter

Dennis, in your opinion, how difficult would it be to add an horizon bar to the display?

It should be possible with a bit of code-work, and not too difficult to implement.

You can use a 2-axis accelerometer and the summary-lines to show the artificial horizon. Something like this will keep the start-up screen and summary:
(if homepos == 1 && landed == 0) {
Put artificial horizon code here
}

Then you just have to draw a fancy artificial horizon

thank you, I am going to start building today.

Originally Posted by rimshotcopter

thank you, I am going to start building today.

Sounds great
Please post a picture or two when you get the OSD up and running, always great to see

RTH can be done with another arduino board.
If you made this OSD so good, so you can easelly make RTH, for you - no problems

GPS info from OSD GPS, only one thing is required...

Another test done. My quad was a little erratic due to unmatched esc's, but flyable.

Code 12 was used, unfortunately I forgot to define alt offset and flight summary. But Gps and current sensor were working well.

DIYOSDCODE12.mp4 (2 min 11 sec)

Originally Posted by mrfliboy

Another test done. My quad was a little erratic due to unmatched esc's, but flyable.

Code 12 was used, unfortunately I forgot to define alt offset and flight summary. But Gps and current sensor were working well.

http://www.youtube.com/watch?v=MsraIBoZqxg

Thanks a lot

Good to see your quad is still flying.

I'm not quite sure if I like the flashing GPS-coordinates, but it can just be turned off in "setup".

Anything you miss or think should be improved?

Edit; Sorry about the default settings, they just ended with the last thing I was testing :P

No worry on the settings, I need to proof the code better. LOL

I'm not too sure I'd call that flying, it was a handful at times.

For my application it is perfect. I'm hoping to try it on a wing next. Maybe this week.

Thanks again for all your work on this project. Its a winner

Originally Posted by mrfliboy

No worry on the settings, I need to proof the code better. LOL

I'm not too sure I'd call that flying, it was a handful at times.

For my application it is perfect. I'm hoping to try it on a wing next. Maybe this week.

Thanks again for all your work on this project. Its a winner

No problem at all - I'm thankful someone dare to test it

I just ordered a couple of new props for my quad - that makes testing in the backyard easier than a big plane.

Thank you Dennis, it is working. I used the DVD Player as a video source and the ODS sync'ed right up with a few turns of the Pots.

Awesome Job and Thanks again.

Originally Posted by rimshotcopter

Thank you Dennis, it is working. I used the DVD Player as a video source and the ODS sync'ed right up with a few turns of the Pots.

Awesome Job and Thanks again.

thanks awesome congrats!

Follow-up: With your advise Dennis, I replace R1 and R2 with a 1K variable resistor, (that was the lowest value I had on-hand) and I am loving this display. I did a little more tuning and I am happy. Now I need to move the parts to a board test again.

Thank you.

Originally Posted by rimshotcopter

Follow-up: With your advise Dennis, I replace R1 and R2 with a 1K variable resistor, (that was the lowest value I had on-hand) and I am loving this display. I did a little more tuning and I am happy. Now I need to move the parts to a board test again.

Thank you.

Looking good
When you find the desired values for R1 and R2 you can just measure the resistance and replace it with a permanent resistor if you want.

I noticed the text is not centered very well on you and mrfliboys screens. Kinda weird as it is just opposite on my screen (the text is a bit to the left).
I will take a look at it tomorrow, I might be able to move the text a bit on the NTSC version.

Just wondering if you'd considered a simple circuit to add a black shadow to the right of the letters so that you don't need the dimming? This should be simple enough just using a couple of diodes, a capacitor and a couple of resistors:
Example circuit

In the circuit, the clock is the serial data out that you are using for the OSD, the length of the black shadow is controlled by the two resistors either side of the capacitor and the capacitor. The right most resistor isn't needed since the output would be where that connects to the diode. The 3V is probably not correct, but that should be the black reference voltage.

Originally Posted by android78

Just wondering if you'd considered a simple circuit to add a black shadow to the right of the letters so that you don't need the dimming? This should be simple enough just using a couple of diodes, a capacitor and a couple of resistors:
Example circuit

In the circuit, the clock is the serial data out that you are using for the OSD, the length of the black shadow is controlled by the two resistors either side of the capacitor and the capacitor. The right most resistor isn't needed since the output would be where that connects to the diode. The 3V is probably not correct, but that should be the black reference voltage.

You could make a little circuit to add the black shadow - but I would make it digitally to get a good shadow (should be possible with a couple of gates, transistors and a clock). I don't think an analog solution with just resistors, diodes and capacitors will give you a very nice shadow. As the capacitor has an exponential voltage when charging/discharging I think it will just add some "weird" after-effect to the letters, but I might be wrong.

But in this project I intend to keep the hardware as simple as possible to let as many as possible join. If you give it a shot with an additional circuit, please post your results.
You can also try to add the shadow by turning the dimming on and off on the right time, but this is gonna be quite a challenge.

I was thinking something like this:
http://www.falstad.com/circuit/#%24+...625E-5+2+-1%0A

I know the values are all wrong, but its showing the general concept.

Originally Posted by android78

I was thinking something like this:
http://www.falstad.com/circuit/#%24+...625E-5+2+-1%0A

I know the values are all wrong, but its showing the general concept.

Year, I got the idea - but I still don't think it's a good solution. I would make it with a digital circuit - or even easier to copy, start coding

With the hardware at the moment it should be possible to add shadows - but I don't have any good idea how to do it smart. Time is so critical you can't use "if" "when" "while" etc. to show pixels.

Anyway, just a quick test to show you how it can be done with a bit of code. This is made with a shadow as thin as possible. (the one to the right is with a bit thicker shadow)


(Simple example, but same thing can be done with more "advanced" figures, letters etc. - but it's not easy.)

And a little update ...

• Some of the code changed a bit and re-arranged to be more efficient.
• Option added to "align" text - all the text can be moved left and right to fit/center perfect
• Summary centered

Most of you probably want notice any difference between 12 and 13 - but if you need to add ekstra text-lines to display or move text left it's improved a bit

Originally Posted by Dennis Frie

Year, I got the idea - but I still don't think it's a good solution. I would make it with a digital circuit - or even easier to copy, start coding

With the hardware at the moment it should be possible to add shadows - but I don't have any good idea how to do it smart. Time is so critical you can't use "if" "when" "while" etc. to show pixels.

Anyway, just a quick test to show you how it can be done with a bit of code. This is made with a shadow as thin as possible. (the one to the right is with a bit thicker shadow)

I guess I'm just trying to save as many clock cycles as possible so that things like artificial horizon could be a possibility, hence looking for a solution that doesn't require any. On review, I agree that a digital solution would be better. I do think that a couple of extra components will be preferential to the coding in the arduino though given that it seems the interrupts just for shifting the data into the serial seem to use up a large portion of the cycles.
I hope to get my arduino for this project before the weekend. I'll let you know if I find a good solution... time to look in my box for a latch and inverter chip... that should do the trick. ;-)

Originally Posted by android78

I guess I'm just trying to save as many clock cycles as possible so that things like artificial horizon could be a possibility, hence looking for a solution that doesn't require any. On review, I agree that a digital solution would be better. I do think that a couple of extra components will be preferential to the coding in the arduino though given that it seems the interrupts just for shifting the data into the serial seem to use up a large portion of the cycles.
I hope to get my arduino for this project before the weekend. I'll let you know if I find a good solution... time to look in my box for a latch and inverter chip... that should do the trick. ;-)

Well, quite a lot of the reading is done on the lines where the text is displayed anyway, so it's not too bad.
Shifting out serial? If you refer to the Serial.print command - that's way too slow to be used with this
The pixels are shifted out with SPI.

Regarding the artificial horizon, I think you have enough time to get a descent result

Dennis, there are a few I2C GPS devices out now or what about using a second ardunio to handle the house keeping tasks such as the Serial.print etc.?

Just did a quick test with a line on the screen and an accelerometer in one directoin - seems to work fine.

Originally Posted by rimshotcopter

Dennis, there are a few I2C GPS devices out now or what about using a second ardunio to handle the house keeping tasks such as the Serial.print etc.?

That would definitely make a few things easier - but the plan is to keep the hardware as simple as possible

Excellent!

Summary Lines, what exactly is needed to turn on the flight summary

Say for a Quad or a Plane

// Depending on model it can be necessary to edit the parameters that defines when flight-summary will show. To disable it, just put for example 0 in speed. The speed will never be less than 0.
// On heli/quad, current should be set.

#define summary_speed 5 // Speed less than (in km/h)
#define summary_los 100 // LOS less than (in meters)
#define summary_current 0 // Current less than (in amps)
#define summary_time 10 // Flight time more than (in seconds)
#define summary_altitude 100 // altitude less than (in meters)

Just loaded Code 13 and am stumped on this. Thanks as always

I have the second one built with a different GPS, this one is for the Stryker lookalike

Originally Posted by Dennis Frie

Just did a quick test with a line on the screen and an accelerometer in one directoin - seems to work fine.

That is great. I had no time to follow that.
Still I ended up changing the MWC software to output the ACC 2 axis code and to create a cable.
If you release a test example I could easily try it out.

Originally Posted by IceWind

That is great. I had no time to follow that.
Still I ended up changing the MWC software to output the ACC 2 axis code and to create a cable.
If you release a test example I could easily try it out.

It was just a quick test (took 10 minutes), wasn't really planning to do artificial horizon as I don't need it
Just for fun, and to show it can be done easy - at least in one direction.

Originally Posted by mrfliboy

Summary Lines, what exactly is needed to turn on the flight summary

Say for a Quad or a Plane

// Depending on model it can be necessary to edit the parameters that defines when flight-summary will show. To disable it, just put for example 0 in speed. The speed will never be less than 0.
// On heli/quad, current should be set.

#define summary_speed 5 // Speed less than (in km/h)
#define summary_los 100 // LOS less than (in meters)
#define summary_current 0 // Current less than (in amps)
#define summary_time 10 // Flight time more than (in seconds)
#define summary_altitude 100 // altitude less than (in meters)

Just loaded Code 13 and am stumped on this. Thanks as always

I have the second one built with a different GPS, this one is for the Stryker lookalike

For your quad I would recommend just to use the current as an indication. If you use 0 A (or just below, say 3 amps or something like that) - chances are your quad is on the ground

The quad:
#define summary_speed 99 //We don't care about speed
#define summary_los 9999 // LOS less than (in meters)
#define summary_current 3 // Less than 3 amps - you should be on the ground
#define summary_time 0 // This one can be added if you don't want it to show before minimum x seconds have pasted.
#define summary_altitude 9999 // altitude less than (in meters)

This should do it for the quad. For a plane I would do something like this (only use LOS and speed:

A plane:
#define summary_speed 5 // Speed less than (in km/h)
#define summary_los 100 // LOS less than (in meters)
#define summary_current 99 // Current less than (in amps)
#define summary_time 0 // Flight time more than (in seconds)
#define summary_altitude 9999 // altitude less than (in meters)

And a quick video.
Not pretty at all - just to show a quick and dirty implementation :P
www.student.dtu.dk/~s092916/acc_test_xvid.avi
(please note this is done with the first components i found on my desk - so no resistor on dimming, random resistor on SPI - no circuit to ensure sync (just a variable power supply etc.)

If any of you try to code a proper artificial horizon, please be aware that you probably want a higher sampling rate than used with the voltage and current reading
That will make it more smooth.

Solution using logic gates:
Logic gate solution to add shadow
Two logic components solution

Originally Posted by Dennis Frie

It was just a quick test (took 10 minutes), wasn't really planning to do artificial horizon as I don't need it
Just for fun, and to show it can be done easy - at least in one direction.

I sure would love to see the code you do have so that I may learn from it please.

Originally Posted by android78

Solution using logic gates:
Logic gate solution to add shadow
Two logic components solution

It have been a while since I have used digital electronic with gates etc - but it was exactly something like that I would consider to build instead of the analog solution.
I haven't checked your circuit in details - but it seems pretty simple to assemble.

Originally Posted by rimshotcopter

I sure would love to see the code you do have so that I may learn from it please.

It's already deleted again, it wouldn't really be useful for a proper implementation.

But if you just scale the accelerometer right and remove the offset to match the line number - you can more or less just write something like:

if (line == acc_data) {
Draw a line
}

It was really as simple implemented as that. It's gonna take a bit more code to add the second direction.

Originally Posted by Dennis Frie

For your quad I would recommend just to use the current as an indication. If you use 0 A (or just below, say 3 amps or something like that) - chances are your quad is on the ground

The quad:
#define summary_speed 99 //We don't care about speed
#define summary_los 9999 // LOS less than (in meters)
#define summary_current 3 // Less than 3 amps - you should be on the ground
#define summary_time 0 // This one can be added if you don't want it to show before minimum x seconds have pasted.
#define summary_altitude 9999 // altitude less than (in meters)

This should do it for the quad. For a plane I would do something like this (only use LOS and speed:

A plane:
#define summary_speed 5 // Speed less than (in km/h)
#define summary_los 100 // LOS less than (in meters)
#define summary_current 99 // Current less than (in amps)
#define summary_time 0 // Flight time more than (in seconds)
#define summary_altitude 9999 // altitude less than (in meters)

Thanks again, I should have another quad video up tomorrow with code13. Thanks

Originally Posted by mrfliboy

Thanks again, I should have another quad video up tomorrow with code13. Thanks

You are welcome - I enjoy some feedback
If you still have problems with summary (or need further explanation) just let me know.

Originally Posted by Dennis Frie

It's already deleted again, it wouldn't really be useful for a proper implementation.

But if you just scale the accelerometer right and remove the offset to match the line number - you can more or less just write something like:

if (line == acc_data) {
Draw a line
}

It was really as simple implemented as that. It's gonna take a bit more code to add the second direction.

Thank you.

Feedback, I have most of the components installed and wired but have not tested it yet. Will update you when bench testing is done.

Originally Posted by mrfliboy

Thanks again, I should have another quad video up tomorrow with code13. Thanks

mrfliboy - I'm afraid you are right. Something doesn't work right. Try to limit altitude to 500 meters - for some reason 9999 doesn't work:
#define summary_altitude 500 // altitude less than (in meters)

EDIT; I have just tested the config-parameters I gave you. Please use this instead - need to check why 9999 as altitude doesn't work,

The quad:
#define summary_speed 99 //We don't care about speed
#define summary_los 9999 // LOS less than (in meters)
#define summary_current 3 // Less than 3 amps - you should be on the ground
#define summary_time 0 // This one can be added if you don't want it to show before minimum x seconds have pasted.
#define summary_altitude 500 // altitude less than (in meters)

This should do it for the quad. For a plane I would do something like this (only use LOS and speed:

A plane:
#define summary_speed 5 // Speed less than (in km/h)
#define summary_los 100 // LOS less than (in meters)
#define summary_current 99 // Current less than (in amps)
#define summary_time 0 // Flight time more than (in seconds)
#define summary_altitude 500 // altitude less than (in meters)

Originally Posted by Dennis Frie

And a quick video.
Not pretty at all - just to show a quick and dirty implementation :P
www.student.dtu.dk/~s092916/acc_test_xvid.avi
(please note this is done with the first components i found on my desk - so no resistor on dimming, random resistor on SPI - no circuit to ensure sync (just a variable power supply etc.)

If any of you try to code a proper artificial horizon, please be aware that you probably want a higher sampling rate than used with the voltage and current reading
That will make it more smooth.

Nice job.
My hope is to be able to to have an artificial horizon with pitch and roll, so will probably use the same serial output that you are using for the character display with a single line 'character' on the screen... may need to have 3 byte wide characters (one for start, middle, and end of line segment) to get the correct position on screen.
To display:
00000000 00000001 11111111 11111000
01111111 11111110 00000000 00000000
The first line you need the following:
0b00000001
0b11111111
0b11111000

If you have a better solution, let me know.

Originally Posted by android78

Nice job.
My hope is to be able to to have an artificial horizon with pitch and roll, so will probably use the same serial output that you are using for the character display with a single line 'character' on the screen... may need to have 3 byte wide characters (one for start, middle, and end of line segment) to get the correct position on screen.
To display:
00000000 00000001 11111111 11111000
01111111 11111110 00000000 00000000
The first line you need the following:
0b00000001
0b11111111
0b11111000

If you have a better solution, let me know.

If you start with "up and down" (pitch?) you know hoe "high" the center of the line should be. If you then add the "left and right" (roll?) you should be able to calculate the start-line and "size of the area".
If you don't draw the line all the way from left to right - you should be able to use the waiting time to do the calculations. Just an idea - it can probably be done a lot smarter

Originally Posted by rimshotcopter

Thank you.

Feedback, I have most of the components installed and wired but have not tested it yet. Will update you when bench testing is done.

Looking good
From what I have heart it sounds like most people have been lucky the first time - hopefully your build will work as well

Keep us updated

You can only push your luck so far. LOL Code13 used. Unmatched esc's on my quad did my Aiptek camera in. I knew it was unstable but had to test the new osd settings anyway. First video is of a test with a 9600 baud rate Sirfset chip GPS, not good results. Sluggish and no response of GPS. Any suggestions with this GPS?? I have a few of these

Quad9600GPS.mp4 (7 min 7 sec)

Second video is with my normal GPS 38400baud, all I wanted to do was test flight summary. LOL Warning graphic ending (not really)

QuadCrashTest.mp4 (2 min 47 sec)

New escs later this week on there way.