ARBS/DMT/MC/ dumb bombing, whats missing and whats not modeled yet

[Harlikwin]

@Elmo since you asked I figured I post it here. Its MC/ARBS/DMT issues, because all three are closely related.

 

The issue is that the weapon systems modeling is all funneled to a the master computer (MC). This modeling is either broken or non existent as are many of the systems that feed the MC.

 

 

In a simple case you wanna drop a dumb bomb on target.

Arbs google patent here: https://patents.google.com/patent/US3699310A/en

 

1. DMT issues

First finding the target using the DMT, and then locking is not easy per your SME, and generally done at short(er) ranges. Currently you can lock the DMT on anything from pretty much any distance so thats broken. I'm not sure if there is some easy way to "simulate" a contrast lock, but it should lock at "shorter ranges, not from "anywhere".

 

2.1 ARBS basic ranging

You find target with the ARBS which gives you the range/Height over target (HOT). Problems here are: no contrast lock modeled at all, video res is all wrong, but most egregiously and the angle rate solution is instant and perfect (which it should not be, the ARBS has to meet specific angle track rates for certain periods of time to determine range, this is well known, and not "sekrit.

 

Given the 2mrad/sec "minimum" track rate this works out to ~.1 deg/sec

 

Case1. 7000ft alt, 5mi range, 450kts straight and level: 1 second angle rate change = .42 deg/sec (good enough)

 

Case2. 7000ft alt, 10mi range, 450kts straight and level: 1 second angle rate change =.109 deg/sec (not good enough)

 

Case3. 2000ft alt, 5mi range, 450kts straight and level: 1 second angle rate change =.128 deg/sec (barely good enough)

 

Case4. 2000ft alt, 2.5mi range, 450kts straight and level: 1 second angle rate change =.517 deg/sec (plenty good enough)

 

Case5. 500ft alt, 2.5mi range, 450kts straight and level: 1 second angle rate change =.133 deg/sec (barely good enough)

 

So taking at look at the three barely good enough data points and plotting them range/alt, it looks pretty linear. Of course velocity is gonna change it a bit. but you can get some sort of "feel" for what range alt combos are gonna produce enough angle rate change for the system to work.

 

Plus the Kalman filter needs to have some reasonable level of inputs over some period of time to "smooth" the data. So it probably takes a few seconds to "lock" once its "in range".

 

And if it doesn't know the slant range it goes to the "flat world assumption" (CCIP, RCIP, BCIP, GCIP etc.) for that data. Those are degraded modes (check the tacman for the proper order)

 

2.2 ARBS and moving targets and wind correction:

 

Once the ARBS has the the HOT, it has certain ways of accounting for moving targets, or also wind effects on the aircraft (movers and winds are handled in a similar way in the real AC). In the ARBS mode it kicks in in a 20 degree dive or more, and uses the sideways angle track difference to compute the lateral drift (it doesn't care if the plane drifts or the target moves). If its less than that it it uses the INS to compute wind drift on the plane.

 

And this is an issue thats been brought up time and time again here for several years. If someone has more detail to add, or if I missed anything please add it.

 

In terms of approximating the ARBS the Key issues IMO are.

 

1. DMT, make it harder to lock stuff, or at shorter ranges at least

2. ARBS ranging, should only work at shorter ranges as you can see, and should take some amount of time for the kalman filter to work (few secs)

3. IF ARBS can't get a HOT solution, it should revert to a simpler "mode" RCIP, BCIP etc.

4. ARBS wind/mover correction should be added

Edited September 29, 2020 by Harlikwin

[TLTeo]

To add to your point 1), in DCS there is at least one precedent for lock range being a function of available light, and that is the Wallaye in the Hornet. Its lock range decreases as you get closer to sundown/sunset, but it (unfortunately) it does so in a way that's pretty artificial. You can have perfectly good lighting and be able to see the target, but if you're close to 6:30 - 7:00 am you won't get a good lock until you're about 2 miles out, while half an hour later, with the same exact visibility, you will lock at about 5nm, and so on.

 

This makes me suspect that "contrast lock" can only be simulated in a very rudimentary form in DCS, and Razbam have opted to skip that entirely.

[Shrike88]

Not modeled yet or correctly modeled. Will have to compile a .trk to show in a test range as I’m sure I’ll get tagged for no track. However there have been countless issues over the years with

1.ripple interval spacing is not correctly modeled, should be interval based on set impact distance, right now Seems it’s modeled for time

2. Ripple interval with ARBS does not sequence the drop to place the designated target with DMT in the middle of the drop sequence. Current model is incorrect as the drop STARTS at the designated target

3. LOFT/TOSS modes not implemented

[RAZBAM_ELMO]

Not modeled yet or correctly modeled. Will have to compile a .trk to show in a test range as I’m sure I’ll get tagged for no track. However there have been countless issues over the years with

1.ripple interval spacing is not correctly modeled, should be interval based on set impact distance, right now Seems it’s modeled for time

2. Ripple interval with ARBS does not sequence the drop to place the designated target with DMT in the middle of the drop sequence. Current model is incorrect as the drop STARTS at the designated target

3. LOFT/TOSS modes not implemented

 

Ok so a few things to touch on there.

 

!. By what do you mean "it seems"? I encourage discussion and constructive criticism, however that dialogue must contain the evidence for a statement. Only saying it is so because it "seems" that way is no way in furthering the discussion. Please provide evidence to your statement prior to making a claim.

 

2. Again I would like to look into this but it requires evidence. Actually had a very very VERV large conversation with our SME into expanded functions of some systems to be announced at a later date.

 

3. Yes they are not implemented at this time. We could throw in something reminiscent of the LABS system in the F-86 sabre but that would not be realistic to the harrier. We are however exploring options to see how it can best be implemented with what is offered. While it may seem easy enough on the outside like " oh just teach it ballistic traj. data from a Mk.82" Well we thought it would be that easy too however the complex systems in the harrier has made implementing a reliable version very difficult. We are however constantly using CB testers and various versions of a base system to see what can work and what wont.

[Shrike88]

Ok so a few things to touch on there.

 

!. By what do you mean "it seems"? I encourage discussion and constructive criticism, however that dialogue must contain the evidence for a statement. Only saying it is so because it "seems" that way is no way in furthering the discussion. Please provide evidence to your statement prior to making a claim

 

 

Thanks for the response elmo .

 

I will provide the work, in creating a track and compiling another bug report for this again. However I have done years ago in the past I believe. Just do us the favor before writing off the reports and familiarize yourself with

 

TACMAN - 000 Vol.1 = 1.14.5.4.5 INTERVAL CONTROL

 

There it clearly states that Ripple sequencing and stick length spacing is set as FEET when in Auto and CIP mods, However when in DSL mod its milliseconds

 

Maybe this is where the issue was when it was implemented. But I clearly remember issues with variance when differentiating between MK-82 LD and HD

 

I just ask if i crate a test map and demonstrate it and provide the time for the track you please pass it up the chain to Zeus and this gets fixed. Thanks again for your time. I appreciate the new zeal in creating a better and more responsive forum.

Edited September 30, 2020 by Shrike88

[lukeXIII]

CCIP/CCRP modes behave exactly the same. The problems for each submode specifically:

 

CCIP/AUTO: Not reverting to other submodes when a target is not locked.

RCIP/*RAUT: RCIP only functioning correctly with no designation and VV not intersecting ground. RAUT not functioning correctly.

*BCIP/BAUT: Pressure altimeter settings not affecting calculations. BCIP not functioning correctly when designation not present.

*GCIP/GAUT: Not functioning correctly when designation not present.

 

*Not working correctly according to the TACMAN. The TACMAN does not mention how DTED is implemented into munition delivery so how they should work could be different based on newer documentation.

 

So taking at look at the three barely good enough data points and plotting them range/alt, it looks pretty linear. Of course velocity is gonna change it a bit. but you can get some sort of "feel" for what range alt combos are gonna produce enough angle rate change for the system to work.

 

Plus the Kalman filter needs to have some reasonable level of inputs over some period of time to "smooth" the data. So it probably takes a few seconds to "lock" once its "in range".

 

So far the specific information on the ARBS I've found is:

-Target lock acquisition period: 160 ms

-Minimum spin rate for accurate range calculation: 2 mr/sec

-Ballistics iteration rate: 11 Hz (possibly 16 Hz)

 

How did you determine what angular rates are "good enough"? i.e is it 1.2x the minimum rate? 3x the minimum rate? Unless there is data that suggests otherwise, just the minimum rate should be used.

 

Likewise how many measurements are required to generate a range? The video below at 6:20 is the only source I can find that shows the TV tracker in operation (it's a gr7 but equipped with the same ARBS system). It's hard to tell exactly but it doesn't look like it takes a couple seconds to generate a CCIP solution

 

Edited September 30, 2020 by lukeXIII

[Harlikwin]

CCIP/CCRP modes behave exactly the same. The problems for each submode specifically:

 

CCIP/AUTO: Not reverting to other submodes when a target is not locked.

RCIP/*RAUT: RCIP only functioning correctly with no designation and VV not intersecting ground. RAUT not functioning correctly.

*BCIP/BAUT: Pressure altimeter settings not affecting calculations. BCIP not functioning correctly when designation not present.

*GCIP/GAUT: Not functioning correctly when designation not present.

 

*Not working correctly according to the TACMAN. The TACMAN does not mention how DTED is implemented into munition delivery so how they should work could be different based on newer documentation.

 

 

 

So far the specific information on the ARBS I've found is:

-Target lock acquisition period: 160 ms

-Minimum spin rate for accurate range calculation: 2 mr/sec

-Ballistics iteration rate: 11 Hz (possibly 16 Hz)

 

How did you determine what angular rates are "good enough"? i.e is it 1.2x the minimum rate? 3x the minimum rate? Unless there is data that suggests otherwise, just the minimum rate should be used.

 

Likewise how many measurements are required to generate a range? The video below at 6:20 is the only source I can find that shows the TV tracker in operation (it's a gr7 but equipped with the same ARBS system). It's hard to tell exactly but it doesn't look like it takes a couple seconds to generate a CCIP solution

 

Where did you find that lock time of 160ms? I assume thats for the DMT trying to lock the target? PM me if its a 1.16 issue.

 

Yeah, I just used 2mrad/sec (~1/10 of a degree) as the minimum number.

 

Basically the way it works is that under that 2mrad/sec I Assume nothing is reported to kallman filter or a 0 or infinite range value. The kallman filter is gonna need some distribution of ranges to come up with a statistical average of the slant range. Measurement is probably some sort of continuous feed from the ARBS tracker so what I suspect happens is that that at either very low track rates or likely also really high track rates, the range is less accurate, but it has some sort of solution. As to how long, I don't have a number. Based on talking to SME's I gather its pretty quick if the track rates are decent. The technique as described is "dive bombing" roughly, point plane at target as you are diving in, "Lock" tgt/sweeten lock, and then continue dive till release. So likely on the order of seconds for the whole process. But under those circumstances you are basically at very close range (1-2mi) and likely mid/high alt (few thousand feet above tgt) so in that circumstance your angle track rates are gonna be well above the minimum. Plus you get the wind/mover correction function of the ARBS to "work".

Edited October 1, 2020 by Harlikwin

[Fri13]

The video below at 6:20 is the only source I can find that shows the TV tracker in operation (it's a gr7 but equipped with the same ARBS system).

 

That as well shows well the DMT function with the slewing.

 

You can slew the TV targeting box around in the HUD. The targeting box is stabilized to HUD itself (TDC left = box moves left in HUD, regardless aircraft attitude) until it is tried to lock on something, and only when the DMT detects the contrast and can lock on it - then targeting box is stabilized on the ground and the TDC inputs are relative to the ground and not to HUD.

 

So one can slew the DTM around HUD for a proper wanted position in it, and then try to get a lock on contrasty ground.

 

Closest thing that there is for this is the Su-25T functionality, except that Su-25T Shkval ground stabilization is not there but only for HUD attitude.

 

The manufacturer own ARBS video as well demonstrates that, as well the contrast lock functionality, easy air-to-air target acquirement without AIM-9 seeker, and so on. (Do not get confused what are the A-4 features/functions).

[toilet2000]

That as well shows well the DMT function with the slewing.

 

You can slew the TV targeting box around in the HUD. The targeting box is stabilized to HUD itself (TDC left = box moves left in HUD, regardless aircraft attitude) until it is tried to lock on something, and only when the DMT detects the contrast and can lock on it - then targeting box is stabilized on the ground and the TDC inputs are relative to the ground and not to HUD.

 

So one can slew the DTM around HUD for a proper wanted position in it, and then try to get a lock on contrasty ground.

 

Closest thing that there is for this is the Su-25T functionality, except that Su-25T Shkval ground stabilization is not there but only for HUD attitude.

 

The manufacturer own ARBS video as well demonstrates that, as well the contrast lock functionality, easy air-to-air target acquirement without AIM-9 seeker, and so on. (Do not get confused what are the A-4 features/functions).

 

 

Indeed, DMT should not be "ground stabilized" but rather lock onto contrast and keep that lock when possible.

 

 

The "ground stabilized" slewing is done through the INS mode, by using the Sensor Select Switch to select this slewing mode. This lets you "ground stabilize" the designation (most likely using a "plane" at alt 0 according to you alt, might be integrated with DTED with newer version though), even when slewing Mavericks around.

 

 

Right now, when the aircraft is set to use the DMT as the targeting/TDC-enabled sensor, it acts like a combined (and perfectly accurate) DMT+INS mode.

Edited October 6, 2020 by toilet2000

[RAZBAM_ELMO]

Indeed, DMT should not be "ground stabilized" but rather lock onto contrast and keep that lock when possible.

 

 

The "ground stabilized" slewing is done through the INS mode, by using the Sensor Select Switch to select this slewing mode. This lets you "ground stabilize" the designation (most likely using a "plane" at alt 0 according to you alt, might be integrated with DTED with newer version though), even when slewing Mavericks around.

 

 

Right now, when the aircraft is set to use the DMT as the targeting/TDC-enabled sensor, it acts like a combined (and perfectly accurate) DMT+INS mode.

 

While correct we cannot change that the locks dont happen because of contrast in DCS. The game doesnt work that way. For CCD or TV it simply asks if there is a unit where the sensor is looking and the game will say yes or no. For IR it has to point at the center of the 3D structure model to lock. So while unrealistically perfect that is as much as we can manage with how the game interprets sensors and locking logic

[LastRifleRound]

While correct we cannot change that the locks dont happen because of contrast in DCS. The game doesnt work that way. For CCD or TV it simply asks if there is a unit where the sensor is looking and the game will say yes or no. For IR it has to point at the center of the 3D structure model to lock. So while unrealistically perfect that is as much as we can manage with how the game interprets sensors and locking logic

 

I think by perfectly accurate he meant that the INS designation is just as accurate as DMT.

 

If the two modes were split as they should be, DMT should not offer a solution nor be ground stabilized if it cannot achieve a lock as you describe.

 

If SSS up is used, then the DMT would act as it does now, pointimg in the direction of the designation. The solution, however, would degarded as the height over target would be according to the aircrafts height over the ground at the time of designation.

 

It's not up to RAZ to make a true contrast lock in DCS, but the existing lock methodology should be required to stabilize the DMT and therefore get a precise slant range.

[Fri13]

It's not up to RAZ to make a true contrast lock in DCS, but the existing lock methodology should be required to stabilize the DMT and therefore get a precise slant range.

 

Exactly. It is up to Eagle Dynamics to create a contrast detection system that everyone can use. But third party should be able to do it by themselves as well if wanted.

It just would be better for ED to develop it for all modules.