DragonOSD+ configuration

Support related stuff, for various products
Daniel Wee
Site Admin
Posts: 2245
Joined: Wed 25 Feb 25 2009 8:00 pm

Re: DragonOSD+ configuration

Post by Daniel Wee » Mon 22 Nov 22 2010 12:11 am


I personally don't think the dBm conversion is going to be very useful at all without some precise calibration. In this respect, the simple percentage display is likely to be the more useful one. The OSD reads various RSSI voltages from different receivers and unless you know how each receiver represents the RSSI voltage in relation to actual dBm levels, it would not be possible to provide a dBm type display. Even if you did know the particular receiver type, you would still need to calibrate it accordingly. At the moment, dBm calibration is not provided for in the DOSD+.

The other option is for an analogue temperature sensor (LM60 I think). Most people don't use this but this is provided as a legacy option for people still using an older sensor, or those who need an extra temperature sensor.

Posts: 4
Joined: Sun 26 Sep 26 2010 1:10 am

Re: DragonOSD+ configuration

Post by yvesOttawa » Tue 23 Nov 23 2010 7:19 am

ok Daniel. Thanks for clarification on this. I was planning on displaying the RSSI under the App's Telemetry section for the user but I will simply report back the value as a percentage which would be V3_read / RSSIHIGH x 100 with a max cap value of 100, and min cap value of 0.

Daniel Wee
Site Admin
Posts: 2245
Joined: Wed 25 Feb 25 2009 8:00 pm

Waypoint Management

Post by Daniel Wee » Sun 09 Jan 09 2011 9:48 pm

Waypoint Management

The various waypoints are actually stored in EEPROM and only loaded into RAM as and when needed. At any given point, only one waypoint can be loaded into the RAM buffer. The waypoint in RAM can be accessed as normal variables using the regular query and write commands. The variables are:-


The details of these variables are described here:-


At any given time, the OSD system keeps track of which waypoint is loaded and if the needed waypoint is not loaded, it will load it before performing waypoint actions. This allows the RAM waypoint buffer to be shared among different applications safely, albeit at some performance penalty if there are too many re-loads. For this reason, it is not recommended to continually poll or query the different waypoints. Such querying should be kept at a minimal if performed during flight.

To write to a waypoint location, for example, you would load up the above variables and when the buffer is completely built up, flush it to EEPROM with the $JW command. The format is:-

$JW 2

which would write the data to waypoint 2. Conversely, $JG is used to load a waypoint from EEPROM into RAM, as follows:-

$JG 3

which would load waypoint 3 into the RAM buffer, which can then be read out by querying the variables listed above.

When using this system, it is important to note that you would normally use waypoints 1 and upwards. Waypoint 0 isn't actually used except to store the home location. In practice Waypoint 0 isn't used at all. The system maintains a separate home waypoint which is used for RTH and for end of mission waypoints. In total there are 20 waypoints allowed (although this can be increased) but only 19 are usable since waypoint 0 isn't used (although it can be written and queried.)

[Not implemented before version 16.9] In theory, you can store multiple flight paths because of the way the system works. You could, for example, store a flight path defined by waypoints 1 to 5 with waypoint 5 being an end marker. Then you could put a second flight path starting from waypoint 6 to 10 and so on. When the user wants to activate the flight path, he simply changes the current waypoint from the menu, to the starting waypoints - in this case 1 or 6. In practice, most people are only using one flight path.

It is important to check if a loaded waypoint is valid by checking the WPSTAT and WPMODE variables associated with the waypoint. For WPSTAT:-

-1 inactive and invalid
0 inactive but contains valid info
1 active and valid

For WPMODE, the parameters are the same as that for global waypoint mode - VISIT, NEXT, and so on. Normally, if the mode is VISIT, the system will head out to the current waypoint, then reset the current waypoint to HOME and RTH upon hitting the waypoint. For NEXT - which is normally what is used for waypoint controlled flights, the current waypoint is incremented sequentially until an inactive or invalid waypoint is encountered, or until it has reached waypoint 19 (which is the last available waypoint memory at the time of writing.)

As such, you would want to always make sure that your waypoint paths are terminated with a waypoint where the WPSTAT is set to -1. This waypoint simply serves as a terminator. The contents of the waypoint variables are otherwise ignored. In the current implementation, the waypoint will skip over all inactive waypoints until an active waypoint is found or the last waypoint is reached. Because of this, any unused waypoints should be cleared with a WPSTAT of -1 if not used. From version 16.9 onwards, a single invalid waypoint will suffice as terminator, whereas in earlier versions you need to make sure that all trailing waypoints are marked as invalid (WPSTAT of -1).

Post Reply