Thread: Discussion DragonOSD+V2 with RTH
View Single Post
Old Mar 22, 2010, 09:09 AM
Daniel Wee is offline
Find More Posts by Daniel Wee
Registered User
Joined Aug 2005
4,093 Posts
Using the PPM stream accomplishes at least two important things:-

1. Reduction of cables. Typically you need one control channel, one rudder or aileron channel, and one elevator channel. This is a minimum of 3 servo cables between the receiver and the OSD. While it may not seem like much, if the two are separated quite a bit, there can be a lot of cables in between, which will contribute to noise pick up, noise radiation, extra weight, and so on. With the PPM stream input, all you need is just one servo cable to replace three or four cables between the receiver and the OSD. This also allows for a smaller OSD board (one of the aims of this OSD is keep it small and light) and simpler installation.

2. Channel assignment flexibility. With just the PPM stream, you don't have to worry about hooking up the wrong channel. All that can be configured in the menu so if you decide to re-assign the control channel on your radio, or the elevator channel, for example, you do not need to re-wire anything in your plane. Just a simple menu change will suffice.

Apart from that, having the PPM signal also allows for more features to be added in the future, without the need for more cabling. It does create a bit of an inconvenience for users of more traditional receivers but at the same time there are benefits that come with it. I do realize that this is the first time such a thing has been tried with an OSD but I have a hunch that this could be the way to go with future OSDs, reflecting the trend that MikroKopter has taken. If nothing else, at least we're innovating and not just producing more of the same.

Some of the goals of the DragonOSD+ were:-
1. affordable so that even if it were destroyed, the pain to the wallet would be less
2. matches the text/graphics quality with full screen (edge-to-edge) display capability
3. black bordered text/graphics for high visibility
4. full graphics engine capable of rendering lines, circles, graphics, etc.
5. multi-font support
6. small and light so that it can fit into small planes
7. energy efficient with wide power supply range without getting hot, heavily filtered
8. fewer cables to hook up for RTH capability
9. user upgradable firmware, without need for special programmer
10. universal peripheral/sensor bus that can take many devices easily
11. huge logging capability (this OSD will log multiple flights and you can download to Google Earth files)
12. audio alert capability
13. expandability and device flexibility (will accept different types of GPSes, for eg.)

The idea is to have the above full-featured OSD at a price of much lower featured OSDs. And to have the quality such that even without the RTH features, it would still outperform and outprice other non-RTH capable OSDs. Truth is it was hard trying to get all of that into one small package and in the process, one of the decisions that had to be taken concerned the PPM-stream input.

Daniel

p.s. From a software point of view, some of the goals were:-
1. "uncluttered look" philosophy
2. user can select multiple styles (eg. you can select from 3 or 4 compass styles, etc.)
3. screen display configurability
4. can be configured in-flight
5. can also be configured via serial terminal
6. sensors/devices auto-detection
Daniel Wee is offline Find More Posts by Daniel Wee
Last edited by Daniel Wee; Mar 22, 2010 at 09:51 AM.
Reply With Quote