Target Points, Shkval, and altitude

[slug88]

I've not seen this discussed before, and a search turned up nothing, so this might just be a new one.

 

We all know that, given a predefined TP (target point) loaded into the PVI-800, we can get the Shkval to automatically point directly to the TP simply by selecting it and uncaging. Now, my question is, how does the Shkval know where to point? We know that the PVI-800 stores the TP's lat and long coordinates, and it also knows the helicopter's lat and long coordinates, and presumably it's altitude (I'm going to guess that the PVI-800 only know about or cares about the baro altitude). However, to get the path from the helicopter to the TP, the PVI-800 also needs to know the TP's altitude. This is very simple trig; you need both the helicopter's height above the target, as well as it's horizontal distance away from the target, to get the angle of inclination to the target. I thought perhaps the PVI-800 assumes all targets to be at sea level (or altitude 0 on the baro alt, depending on your air pressure adjustment), but this is clearly false, since it still accurately points to predefined TP's on high mountain tops. This is important, because it implies that the PVI-800 must store elevation data for each predefined TP.

 

So, given those assumptions, my question is this: when creating a new TP in-mission, how can we assign it's elevation? Recently I was playing the second-to-last mission of IgorMK's excellent Georgian Havoc campaign. In this mission, you're given the coordinates of a building that you need to destroy, which sits at an altitude of 1.8km ASL in a high mountain town. I created a new TP with the provided coordinates, and, to my surprise, when I selected the new TP and uncaged the Shkval, it pointed far short of the actual target. It seemed clear that the PVI-800 assumed that the new target was at sea level.

 

Now, I didn't like the idea of acquiring the target by constantly lasing the ground and lining up the Shkval sight with the TP icon in the ABRIS, so I came up with what I thought at the time was a rather clever solution. Using the "Info" function on the ABRIS, I found that the elevation at the target's coordinates was about 1800m ASL. I then noted that, again according to the ABRIS, my GPS altitude was something like 2100m ASL, which meant that I was 300m above the target. So I thought, if the PVI-800 thinks my TP is at sea level, I'll just adjust my baro altimeter so that it reads 300m, and that way the PVI-800 will know the proper height difference and will correctly aim the Shkval! Alas, I was disappointed to find that adjusting my baro altimeter seemingly had no effect whatsoever on the Shkval's inclination when uncaging on the TP. That leads then to my second question: how does the PVI-800 know the helicopter's altitude? Clearly, it's not paying attention to the baro altimeter.

[Haril]

The PVI gets all its position information from gyroscopes and accelerometers. This is why, in real life, it goes out of sync with reality. In the game, it's currently modelled as a perfect system that never goes out of sync.

 

As to how the PVI knows the height difference to the target point, I can't say. It seems unlikely that it has an internal memory of the height above sea level of every point on the earth's surface, so if it is indeed accurately pointing at targets with a large difference in altitude when selecting pre-configured points, perhaps the ground crew have a way of specifying a height when they create the mission plans. I don't believe they use the pilot's controls to do it, rather they use a seperate computer and transfer them on a floppy disk.

[Martillo1]

In the last months, my Shkval does not align to the TP in vertical when released, just horizontal.

[AlphaOneSix]

That leads then to my second question: how does the PVI-800 know the helicopter's altitude? Clearly, it's not paying attention to the baro altimeter.

 

 

I'll answer this one first, since it's easy. It gets altitude info from the pitot static system, just like the barometric altimeter. Of course, the altimeter itself has no connection whatsoever to the flight navigation system, they just use the same method to get their information.

[Frederf]

If the PVI-800 and related systems are getting altitude information from the static port, then that's effectively getting info from the barometric altimeter (ok not the altimeter, an altimeter, which explains why the QFE knob has no effect).

 

I thought WPT and AIR FIELD points are strictly 2D while NAVTGT points are 3D, but I can find absolutely no evidence to support this crazy feeling. On second thought, if coordinates were (X,Y,Z) then the PVI-800 would obviously (right?) be designed to enter these.

 

Perhaps point altitude is assumed to be your PVI BARO (not the one bolted to the front panel) alt. minus your RADAR alt.? Behavior would thus change when out of RADAR alt. range?

[slug88]

so if it is indeed accurately pointing at targets with a large difference in altitude when selecting pre-configured points, perhaps the ground crew have a way of specifying a height when they create the mission plans. I don't believe they use the pilot's controls to do it, rather they use a seperate computer and transfer them on a floppy disk.

 

This is my thought as well. It seems bizarre however that the pilot isn't able to input TP elevation data on the fly. I guess that's 1980's tech for you.

 

It gets altitude info from the pitot static system, just like the barometric altimeter. Of course, the altimeter itself has no connection whatsoever to the flight navigation system, they just use the same method to get their information.

 

Ah, now that makes sense. Thanks much!

 

Perhaps point altitude is assumed to be your PVI BARO (not the one bolted to the front panel) alt. minus your RADAR alt.? Behavior would thus change when out of RADAR alt. range?

 

Interesting thought, but my limited tests don't corroborate this. I set up a test in which I hovered about 200m over the floor of a high mountain valley, and entered coordinates for a new TP over the mountain wall about 2km in front of me. If I understand your idea correctly, then you suggest it might have assigned the elevation of the new TP to the same elevation as the valley floor. When uncaging my ShkVal, however, I found that it again seemed to point at sea level, with the angle of inclincation being greater than 45 degrees from what I could tell (indicating that the TP was more than 2km beneath my current aaltitude). This is confirmed by the ABRIS; if you use the INFO button to select the flashing TP, it will read out an elevation of 0m.

 

The interesting thing is, you can enter a new TP to the PVI-800 with the correct altitude; you simply can't do it with the lat/long coordinates method. Instead, if you use your Shkval and LRF, as you would when performing an INU fix, the TP will clearly have the correct elevation assigned to it. I verified this in the same test described above, and the TP created with the Shkval properly rested at the correct mountain peak. So it's absolutely clear to me that the PVI-800 stores elevation data for TP's and can be updated in flight with new elevation data, its just that for some reason we don't have the ability to key it in manually.

[Frederf]

I'm guessing the mission editor points zapped into the PVI memory at mission start also have the magical height value shared with "on the fly" NAVTGT points.

 

I'm curious to see what kind of altitude and displacement is erroneously generated by not being able to specify the height of a keyed-in PVI points. Testing-ho!