DCS-BIOS(ish): How to convert common data lat-long to MGRS and back?

[jrsteensen]

Firmly in the design phase of my UH-1 pit. I have decided to go with a UH-1V variant vs the H however, to add a little simpler radio management and have some "GPS" based navigation. Have my panels about 80 percent done, then on to flight controls, instruments, and structure.

 

I'm currently designing a ASN-128, Doppler/GPS Navigation Set. (See picture below). Hardware wise, I'm good. Simple keymatrix, few backlight LEDs for the panel, and a single indicator plus displays.

 

Software....well, all I get from the computer is coordinates in lat/long. I need to be able to convert them to MGRS (Military Grid Reference System) and back, and be able to input MGRS coordinates and have them be converted to lat/long for manipulations as far as ground track, navigation, bearing, etc.

 

I've been looking at the GeographicLib C++ library, but...well...not a C++ guy...at all.

 

Anybody have any ideas on how to do this, simply, and preferably inside my arduino sketch without having to add another software layer on the PC?

 

Edited April 24, 2015 by jrsteensen

[jrsteensen]

I should note, than I plan on using arduino due's to run all this. It should only take one for the center console, one for the instrument panel, and one for the overhead console, with a couple mini pro's for the flight controls, and a dedicated due for the more complicated panels, like this one.

[FSFIan]

I've been looking at the GeographicLib C++ library, but...well...not a C++ guy...at all.

 

Anybody have any ideas on how to do this, simply, and preferably inside my arduino sketch without having to add another software layer on the PC?

 

My idea of doing this simply is exactly what you have done: find a library that does the work for you and use it. It doesn't get any simpler than that (other than getting other people to program your sketch for you).

 

Without more information about what you tried and what went wrong, I don't really know what questions you need an answer to.

 

• If you tried using the C++ version but it did not compile, try the C version of the library instead. According to their documentation, "This is a self-contained library (requiring only the standard C math library)", so it should not use any advanced features (e.g. C++ exceptions) that may be problematic on embedded systems.
  
• You say you are "not a C++ guy" yet you don't want to involve "another software layer". So I assume that you want to learn C++. Where did you get stuck?
  

[Warhog]

The photo you posted...is that a real radio or one of the 80% you've finished. If its your build, it looks really nice and well worn. It couln't get more authentic...unless of course it is a real panel.

 

Can we see more pics of your work?

 

My next pit is also a Huey.:smilewink:

[jrsteensen]

It's definitely a real panel - I'm still designing that one specifically. I have completed the design of all the overhead panels, and all flight/armament center pedestal panels. Just need to finish the avionics. (Nav, radios, IFF, and CM panels)

 

I'm on my way out the door to go camping with my son for Cub Scouts, but I'll post pics on Monday.

 

As far as the code...found the example MGRS program below in there:

 

// Example of using the GeographicLib::GeoCoords class
#include <iostream>
#include <exception>
#include <string>
#include <GeographicLib/GeoCoords.hpp>
using namespace std;
using namespace GeographicLib;
int main() {
 try {
   // Miscellaneous conversions
   double lat = 33.3, lon = 44.4;
   GeoCoords c(lat, lon);
   cout << c.MGRSRepresentation(-3) << "\n";
   c.Reset("18TWN0050");
   cout << c.DMSRepresentation() << "\n";
   cout << c.Latitude() << " " << c.Longitude() << "\n";
   c.Reset("1d38'W 55d30'N");
   cout << c.GeoRepresentation() << "\n";
 }
 catch (const exception& e) {
   cerr << "Caught exception: " << e.what() << "\n";
   return 1;
 }
 return 0;
}

 

 

Which appears to be almost exactly what I want to do - but I can't figure out how to call it in the arduino sketch. Is it possible to use a portion of the C code directly in the sketch?

[jrsteensen]

Ian;2382870']

 

• 
  
• If you tried using the C++ version but it did not compile, try the C version of the library instead. According to their documentation, "This is a self-contained library (requiring only the standard C math library)", so it should not use any advanced features (e.g. C++ exceptions) that may be problematic on embedded systems.
  
• You say you are "not a C++ guy" yet you don't want to involve "another software layer". So I assume that you want to learn C++. Where did you get stuck?
  

 

OK, I guess I worded it poorly. I'd like to do this conversion natively on the arduino during the sketch versus adding another PC conversion layer between DCS-BIOS and talking to this panel. I was hoping that someone may have already written this library over in the arduheli / quadcopter world, but had no luck locating it, but no such luck. I feel a hair in over my head on this one - I am a mechanical designer, with a very good electronics background (I work in the aerospace/defense industry)...but not much of a programmer.

[FSFIan]

To save code size, the build process used by the Arduino IDE disables some C++ features, including exceptions, which are required by the C++ version of the GeographicLib. The geodesic calculation routines are also available as a pure C library, which should compile on the Arduino (see "Implementations of the geodesic routines in other languages").

 

For conversion from/to MGRS, the MIT-licensed GDAL project includes conversion code: mgrs.c,

 

Compiling the complete GDAL project (if at all possible) would probably result in too much code to fit onto the ATMega's program memory, but those two files look like they don't depend on anything else.

[jrsteensen]

The photo you posted...is that a real radio or one of the 80% you've finished. If its your build, it looks really nice and well worn. It couln't get more authentic...unless of course it is a real panel.

 

Can we see more pics of your work?

 

My next pit is also a Huey.:smilewink:

 

Here is my panel design so far. Overhead console panels are complete, and the majority of the center pedestal panels are complete.

 

[ATTACH]116920[/ATTACH]

 

What I have left is:

ASN-128D - Doppler/GPS Navigation Unit

AN/ARC-210 - UHF/VHF/ADR (Decided to go with this to replace the majority of the radios in the cockpit IAW one of the pictures of a modified UH-1V.)

CM Panel

AN/APX-XXX - IFF

AN/ARC-199 - HF COMM (I will likely link this with a teamspeak output since HF comms are INOP in DCS.)

SIM CONTROL - This panel will be all the sim control features - Track IR Freeze/Center, Power on, F1-F12 keys for comms, and trackball, plus any other misc controls I need.

 

On the instrument panel, the two nav gauges will be replaced with the V model HSI and HSI control panel. As part of the V model upgrade, there is a selector switch to swap between the ADF and GPS so in ADF mode, it will function much like the existing H model ADF, but swap over to GPS, and the HSI indicator will be driven by the ASN-128 model.

 

After panels are done, I will start on the instrument panel gauges, then structure, flight controls, seat, etc. (I actually have a several thousand item BOM already built, but still refining.)

 

All of these panels are (externally) designed IAW the relevant mil standards.

Edited April 27, 2015 by jrsteensen

[jrsteensen]

Here is a picture of the almost finished design for hardware for the ASN - decided to go with the D model versus the C model pictured above. Unfortunately, while I located the real alphanumeric displays...they would have cost almost 600 dollars, versus the less than 100 for a quality 4.5" LCD...so, dot matrix font time, and it will be able to be purposed for other games/sims/functions. (I may incorporate the software side sim features via that TFT versus making switches for tir centering, pausing the game, etc.)

 

[jrsteensen]

Hey Ian, is there any way that I can create additional variables and constants that can be visible to all my arduinos? For example, I would like my ARC-210 and ARC-210 Half Size RDU to be able to share freqs between them, and for my HSI to talk to the ASN, etc.

[FSFIan]

Hey Ian, is there any way that I can create additional variables and constants that can be visible to all my arduinos? For example, I would like my ARC-210 and ARC-210 Half Size RDU to be able to share freqs between them, and for my HSI to talk to the ASN, etc.

 

Not currently.

We could reserve some of the address space for user-defined variables (e.g. 0xe000 through 0xeffe) and implement a POKE command to write values there. That mechanism could also be used to send calibration offsets (such as offset values for servos) to some panels.

 

Pull requests are welcome, I won't get to work on this for a while (my current priority is to implement communication over RS-485).

 

Are you thinking of implementing frequency settings that do not exist in the DCS Huey?

[jrsteensen]

Ian;2390571']Not currently.

We could reserve some of the address space for user-defined variables (e.g. 0xe000 through 0xeffe) and implement a POKE command to write values there. That mechanism could also be used to send calibration offsets (such as offset values for servos) to some panels.

 

Pull requests are welcome, I won't get to work on this for a while (my current priority is to implement communication over RS-485).

 

Are you thinking of implementing frequency settings that do not exist in the DCS Huey?

 

Yes, as well as drive my HSI from the ASN device, be able to edit the waypoints and flight plans for the ASN on the PC, and all sorts of little things I need to be able to do down on the hardware layer.

 

Unfortunately, I wouldn't even know where to start on reserving those addresses and making them accessible.

[agrasyuk]

As far as non matrix display I think this will be easy enough to emulate with "dot matrix" font that already exists in game. (Unless you already seen this - I with lots of help from Ian messed with it here: http://forums.eagle.ru/showthread.php?p=2314907#post2314907)

If I was able to do it you surely will too.

 

 

Perhaps I don't see the entire picture of what you want to accomplish with dual RDUs, but I don't see why they absolutely have to communicate to each other. Each will display freq info taken directly from game export and each will send control signals independently back to game.

Or are you building up something on tip of that?

[jrsteensen]

As far as non matrix display I think this will be easy enough to emulate with "dot matrix" font that already exists in game. (Unless you already seen this - I with lots of help from Ian messed with it here: http://forums.eagle.ru/showthread.php?p=2314907#post2314907)

If I was able to do it you surely will too.

 

 

Perhaps I don't see the entire picture of what you want to accomplish with dual RDUs, but I don't see why they absolutely have to communicate to each other. Each will display freq info taken directly from game export and each will send control signals independently back to game.

Or are you building up something on tip of that?

 

I was actually planning on doing that - there are several good 5x7 and 5x8 matrix fonts available that I should be able to load on the TFTs SD cards and use.

 

The radios likely don't need to talk to each other. Really need it for my navigation avionics though - I'm concerned that 100 waypoints with all relevant information will eat up all my memory on the arduino due in a hurry, and would like to use a PC based utility (even if directly editing it in notepad++) to edit the WP and flight plan library for ease. I also need to drive the HSI as there is no I/O available for an HSI in the huey. I can get in some of the functionality between the radio compass and ADF, but all I can do is drive it from the DCS ADF stations for the huey, not use it for the flightplans and waypoints in my ASN device.