Jump to content

Recommended Posts

Posted (edited)

I find I am able to clear Hung Stores simply by reloading the DSMS and not by clearing the individual station and recycling power etc. Is this correct? And just as an easy-to-remember formula that should work out correctly most if the time, would it be right to add a zero to the beginning of any five digit UTM coordinates (assuming still in same zone), and divide the last 3 digits by 60 of Lat/Lon, as well as add a zero to the front of the Lon? Probably not, but my head hurst from trying to figure this stuff out.

 

Edit: One other question. The elevation given by radio by JTAC is usually slightly different from the numbers that come through with the data transfer. Is that correct?

 

Thanks

Edited by hassata

[sIGPIC][/sIGPIC]

Posted (edited)

By "clear" do you mean you are able to release the weapon, or do you mean the DSMS page graphics for that hung station return to normal?

 

The STAT page should show the affected 1760 station with a red color and corresponding failure text, do you see that after your DSMS reload?

 

Off to test...

Edited by WarriorX
Posted (edited)
I find I am able to clear Hung Stores simply by reloading the DSMS and not by clearing the individual station and recycling power etc. Is this correct?

Well, when I hung a store a few months ago just see if I could clear it by doing a new DTS upload, it worked for me.

 

And just as an easy-to-remember formula that should work out correctly most if the time, would it be right to add a zero to the beginning of any five digit UTM coordinates (assuming still in same zone), and divide the last 3 digits by 60 of Lat/Lon, as well as add a zero to the front of the Lon? Probably not, but my head hurst from trying to figure this stuff out.

 

Ok... so you are talking about three separate things here.

 

1)When near the edge of a grid square, JTAC will omit zeros, apparently. If I were you, if I saw anything less than a 6 digit grid then I'd just put the targetting pod on the ground near the JTAC and try to figure out which zeros were omitted. If an erroneous, five digit grid is possible, then it's possible you could get as few as two digits, possibly even less (a no digit grid for the 1 meter that rounds to XXT XX 00000 00000?) However, a five digit grid will be most common.

 

So to figure out which zeros were omitted, put the TGP on the ground and see what the MGRS coordinates are of the TGP- switch to the CNTL page of the TGP and switch it from L/L to MGRS.

 

So, if the JTAC was giving you MGRS coordinates of like, 38T KM45623, then you could resolve the error as to whether the actual coordinates were KM045623 or KM456023 by looking at the targeting pod's MGRS readout near the JTAC/target area.

If the targeting pod said,

 

38T KM 07832 58209

 

Then you know you are near the western edge of a grid square and the correct JTAC coordinates are

38T KM045623.

 

Conversely, if the targeting pod readout is:

 

38T KM 48612 06327

 

Then you know you are near the southern edge of a grid square and the correct JTAC coordinates are

38T KM456023.

 

2) To convert from Degrees Minutes Seconds (given in the format: 34 45' 19", for example), to degrees and minutes (with three places after the decimal place), is simple. How many minutes are there in 19 seconds? The answer of course is 19/60 = 0.316666.... The CDU requires entry of lat/long coordinates to a precision of thousandths of a minute. So round that number to the nearest thousandth (0.317) and add it to the number of whole minutes you have in your coodinate (in this example, 45).

 

So the new coordinate is: 34 45.317'

 

 

3) Since longitude ranges from +180 degrees to -180 degrees, (or 0 to 180 degrees east and west), then you have to put a zero in front your entered longitude coordinate if the number of degrees is less than 100, or the CDU doesn't know what to make of it. The CDU can only take one format for entered coordinates, and it's not about to do "well you entered 9 digits for your longitude so I'm going to add a zero in front" kind of error checking/correction. This is probably a good thing because if you are not being very precise and consistent on entering coordinates, then there is a good likelihood your JDAM might blow up the wrong piece of dirt.

 

 

Edit: One other question. The elevation given by radio by JTAC is usually slightly different from the numbers that come through with the data transfer. Is that correct?

 

Thanks

 

There appear to be some bugs with shared elevation data with just about every received datalink coordinate except a DMS-left-long shared SPI. For example, wingman altitude appears to typically displayed as 2 thousand feet less than actual on the TAD. JTAC targets are shared at the wrong altitude too. Is this what you are talking about.

Edited by Speed
  • Like 1

Intelligent discourse can only begin with the honest admission of your own fallibility.

Member of the Virtual Tactical Air Group: http://vtacticalairgroup.com/

Lua scripts and mods:

MIssion Scripting Tools (Mist): http://forums.eagle.ru/showthread.php?t=98616

Slmod version 7.0 for DCS: World: http://forums.eagle.ru/showthread.php?t=80979

Now includes remote server administration tools for kicking, banning, loading missions, etc.

Posted (edited)

Thanks Speed-that's extremely helpful.

 

Edit: The elevation data error I was talking about is I guess part of the shared data bug.

Edited by hassata

[sIGPIC][/sIGPIC]

Posted

Wow, I never would have thought of reloading my DSMS page to clear a hung store. I guess it's for the better though if it is a bug and not a real feature.

If you aim for the sky, you will never hit the ground.

Posted
Thanks for bringing it up.
NP-thanks for making the sim even better.

 

Just executed correct UTM and lat/lon coordinates input and prosecuted my first JTAC tasking! Of course, I forgot to call IP inbound and had Matt screaming at me to abort for my troubles lol.

[sIGPIC][/sIGPIC]

Posted (edited)

why ?

 

When near the edge of a grid square, JTAC will omit zeros, apparently.

 

I was just wondering if it's really like that in a real life situation. Do real JTACs really communicate with pilots in such unclear way ? Why ? Wouldn't it be easier if JTAC just gave the pilot the whole unmistakable coordinates (with no digits missing or anything) ? Just curious if there's any reason for this.

Edited by lanmancz

[sIGPIC][/sIGPIC]

 

Gigabyte Aorus Z390 Elite, Intel i9 9900K, Fractal Design Kelvin S36, Zotac GTX 1070 8GB AMP Extreme, 32GB DDR4 HyperX CL15 Predator Series @ 3000 MHz, Kingston SSD 240GB (OS), Samsung 970 EVO 1TB M.2 NVMe (sim), Fractal Design Define R5 Black Window, EVGA SuperNOVA 750 G2, Win 10 Home x64, Thrustmaster Warthog HOTAS, Saitek Pro Flight Rudder Pedals, Thrustmaster MFD Cougar Pack, TrackIR (DelanClip), 3x 27" BenQ EW2740L, Oculus Rift S

 

Posted
I was just wondering if it's really like that in a real life situation. Do real JTACs really communicate with pilots in such unclear way ? Why ? Wouldn't it be easier if JTAC just gave the pilot the whole unmistakable coordinates (with no digits missing or anything) ? Just curious if there's any reason for this.

 

It's just a bug, make a search and you will find other threads that discuss it.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...