Thank you Dennis. Still have no much time to analyse my mistake. I think I thought that PPM is captured by PIN12. Your board seems to have PPM connected to pin 12 and 24. I thought that PPM is connected to 24 only to pass trace below ATmega IC.

Still have not read your code what for PPM is connected to both pins?

Originally Posted by kristaps_r

Thank you Dennis. Still have no much time to analyse my mistake. I think I thought that PPM is captured by PIN12. Your board seems to have PPM connected to pin 12 and 24. I thought that PPM is connected to 24 only to pass trace below ATmega IC.

Still have not read your code what for PPM is connected to both pins?

You only need to connect it to pin12 (PB0). And yes, Pin 24 is only used to bypass/get the trace out.

Sounds like you have done it just right

Originally Posted by quad007

is there a way to get this to remove blue screen from LCD? sorry if this has been answered, i tried advanced search function.

I don't think so. MAX7456 will normally change to internal sync when no external sync is present. Off course you will not have blue-screen anymore, but getting a black screen from MAX7456 will not help much.

But I haven't tried, just doubt it will actually work

Originally Posted by Dennis Frie

I don't think so. MAX7456 will normally change to internal sync when no external sync is present. Off course you will not have blue-screen anymore, but getting a black screen from MAX7456 will not help much.

But I haven't tried, just doubt it will actually work

This is an interesting tidbit piece if information! So In theory, all of the setup screens and even development can be done with the camera/video source off?

Originally Posted by rimshotcopter

This is an interesting tidbit piece if information! So In theory, all of the setup screens and even development can be done with the camera/video source off?

Exactly
I fried my test-bench camera a while ago. The OSD was never really tested with a camera before I had the first PCB-version up and running

Hi Dennis,

DFmaxOSD in action!

Thanks!

Originally Posted by jalves

Hi Dennis,

DFmaxOSD in action!

Thanks!

Haha, that's a quite early software-version
But as most changes is related to sensors etc. you will most likely find, that it works just fine.

Have you done any specific changes to the software/hardware? As far as I remember you have the very first hardware-version with large crystals and no ISP-connector or I2C connectors.

A new software version have been uploaded
http://code.google.com/p/diy-osd-max7456/downloads/list

Main changes:

• Barometer altitude fixed for hanging characters
• Negative sign replaced with a proper one (one that can actually be seen)
• The inverted colors on lift/sink rate for barometer, is now shown with a negative-sign instead
• Max mah increased from 9999 to 32000 mah
• 2 modes added to barometer, to have both black and white in both bars. That makes it possible to see the bar with both black and white background
• Timer will change from min:sec to hour:min at 59 min and 59 sec.

Furthermore, a LOT have been changed in the layout options. This means pretty much everything can be moved around. A lot have been changed in the code, so if you find any hanging characters etc. please let me know.

• Speed position
• LOS position
• Altitude position
• Pressure sensor altitude position
• Current position
• timer position
• Voltage position
• mah position
• GPS coordinates position
• Home-arrow position

Not really anything I would normally post, but here goes anyway.

My tripod was at home and I decided to fly with my directional antenna laying on the ground (totally on purpose to train "flying through static" off course.. Okay, not really)

I have a lot of nice recordings as well, but this was mainly to show something a bit different

Flying through static (3 min 28 sec)

New software is installed: I am pleased with the new changes so far

Originally Posted by rimshotcopter

This is an interesting tidbit piece if information! So In theory, all of the setup screens and even development can be done with the camera/video source off?

it would be better to get a black screen very shortly, than to have the LCD go blue screen, and wait 0.5-2 seconds for it to "reboot" to active signal.

Man an antibluescreen device would be nice though , some that "emulates" how those 100$+ dvrs work that passthrough the video and don't go black...But of course cheaper ..

Ok back on topic...Awesome stuff, D. I see from the video that the AH is working pretty good I guess? What about combined with the baro is that problem already fixed? Or do they still mess with each other?

Btw pcbs are on the way from good ol' China

So, with the aim of telemetry and aircraft-aircraft communications, I worked with Dennis to figure out some requirements. We came up with a 868MHz radio modem, 26dBm TX (500mW), -126dB RX - see attached. This should easily give least 10KM of high speed telemetry, with a chip change we can get to -133dBm (at very low speeds obviously) but that IC s 3x the price.

By changing the L network (tuning) this can easily be switched to 900/915MHz.

The aim is for a multi-aircraft radar screen and ultra long range telemetry.

The RF module + host board is only 20mm wide, or just 18mm wide as just a module. The host board is required, as the RF board is only 1mm thick, 4 layers and impedance controlled. Over it's length, the solder on the frontend and RF IC's could be easily flexed off or the joints broken - so the host board is required. This makes it much stiffer and allows the mounting of the UART/I2C connectors. The boards came out much longer than I had hoped, at about 63mm for the two side facing connectors or 58mm for the two down, two side facing connectors. I'm not sure which board I want to have made. There is also a board with a FTDI chip and USB connector on it to allow interfacing with a laptop/computer.

It's envisioned that these boards would work standalone with a GPS pass-through so that people not using this OSD can be displayed on screen, or receive telemetry - or so it can be used with APM/others. This OSD would talk to it over I2C, sending it data to transmit and retrieving data that has been received.

With an android/windows phone or PC, it would be able to stream live ATC data to the planes to display fullsize air traffic on the OSD view. This would be a fantastic safety feature. Obviously, the software on laptop or phone would have to support the ATC for your city/area.

If it performs just anything close to what the specifications suggest, it will make an incredible telemetry link. With he possibilities of multiple receivers and transmitters for downlink to ground-station, plane-to-plane etc. this gives a lot of new possibilities.

An arrow pointing towards another moving plane, direction to a moving car, recording and logging data on ground-station - you name it.

Originally Posted by msev

Man an antibluescreen device would be nice though , some that "emulates" how those 100$+ dvrs work that passthrough the video and don't go black...But of course cheaper ..

Ok back on topic...Awesome stuff, D. I see from the video that the AH is working pretty good I guess? What about combined with the baro is that problem already fixed? Or do they still mess with each other?

Btw pcbs are on the way from good ol' China

No, i haven't worked more on the artificial horizon or looked into multiple sensors.
The performance of the artificial horizon is still not acceptable, it was just to show, that it does work more or less, with few vibrations and low G-force. It was mounted on my plane anyway and can be turned on/off with a switch