Snappy

The main attitude indicator seems to indicate too much pitch, it overindicates by 5 degrees it seems. Either that, or the standby indicator is off by 5 degrees. But the standby indicator seems to agree with the the pitch value in the infobar. Not sure, there could be several reason, the 10 degree intervall pitch markings on the main ADI could be placed wrong, the ADI itself could move too fast in pitch , or the standby indicator and info bar pitch show the wrong value. But one of the 2 is wrong by 5degrees. The 3 values seem to agree when on the ground or when at 90 degree pitch up/down. These pics were taken immediately after take off , so the standby ADI should still be reasonably accurate. Above the main ADI is at 20 degrees nose up, the standby ADI and Infobar show 15degrees nose up. Below the main ADI is at 30 or 31 degrees nose up, the standby ADI and infobar show 25 degrees nose up. The parallax error depending on viewing angle is negliable so thats not it either. Regards Snappy.

If you perform a short approach flip/flop the lateral guidance you receive seems buggy if you approach the runway centreline at higher intercept angles. According to the manual about short approach without TILS : If the aircraft is outside of the ±20° sector or if the angle of travel is more than 90° relative to the runway heading, a steering command is set towards an approach circle similar to that of the normal phase 1. The approach circle is set 10 km from the touchdown point and is displayed as an angle command on the ADI and HUD. The bearing and distance on the course ring and the distance indicator displays is toward the destination LF. However this doesn't seem to work at the moment. If you follow the lateral HUD guidance you get along the mentioned circle, you end up not on the extended centreline (as shown on central indicator/calculated by the nav system ) but on a parallel course left or right of it. Something like this: The lateral offset is significant in its size. And its not the nav systems accumulated error that causes it, because your central indicator looks something like this after you follow the lateral guidance through and roll out on final approach course : So you can see, even the nav systems own calculation of where the destination airport and extended centreline are shows it to be quite off to one side of you, in other words the nav system should have been capable of accurate lateral guidance. The yellow commanded course of the CI points to the destination airport itself, but the HUD lateral guidance is decoupled from that and guides you onto the false parallel of the extended centreline. If you keep following the HUD lateral guidance sometimes it later corrects itself and leads to the approach course, but by then you are much closer to the airfield and have to make large corrections. With TILS use ,it gets somewhat better, but even then, until steady TILS signal is received it often guides you significantly offset to one side and then with the TILS signal is suddenly realizes that and you get a big correction guidance, which results in large heading corrections you have to make until you are established on final approach. I`m unsure in how far this is related to my other bug report here, where the nav system incorrectly takes LB1 instead of LF1 as the current destination waypoint during Phase 2 , or whether this is a separate bug. Regards, Snappy

Ah very good that you point that out, didn't know that ! Thank you ! @TOViper I'm very sorry, looks like the manual passage needs to be amended again ://

Thanks a lot @TOViper, that clarifies the behaviour for future Viggen pilots

Ok, I just just checked in DCS, in ANF the FPV shows correctly across the entire pitch range. Sorry for the incorrect bug report then, but I had only the DCS VIGGEN manual for reference and it seemed incorrect based on that. @TOViper maybe this limitation can also be included in the new Viggen DCS manual's HUD section if its still up for edit? Kind regards, Snappy

Hmm strange. What does the actual manual say about the behaviour in ANF mode?

Hi Myse, do you have a manual reference for that? I searched for "FPV" and in the latest beta 2.1 manual, and there are only 3 hits and not one mentions that limitation. I also read the entire HUD section of the manual and couldn't find that limitation. Maybe I 'm lookin in the wrong place.

Hi, the FPV display in the HUD seems very buggy. I do understand that the Viggen does not have a modern HUD with 10 degree segments of pitch ladder, but currently it also displays the FPV in a very incoherent buggy manner. The manual says : "Flight path vector (FPV) Indicates the direction of current flight path vector in a 3-dimensional space in the form of a stylized aircraft symbol. Wings stick out of the circle at the 9 and 3 o’clock positions. The “vertical fin” at 12 o’clock is the airspeed deviation indicator. Level flight is attained with wings of the FPV lined up with the horizon. If the FPV is centered in the gap in the artificial horizon the aircraft is on the commanded course from the navigation system." There is no mention of any limitation, so I take it, as long as the aircraft's actual flight path is within the HUD area as viewn from the pilots point of view , the FPV should be displayed / visible in the HUD. To best illustrate the problem you can set up a flight, where you start airborne at a high speed of 550+ kts and take two RB24 or 74 as loadout, ( stay in mode NAV , switch the weapons selector to IR-BB , but don't unsafe the trigger ( I'll get to why) . Now pitch up 90 degrees to pure vertical. You will see that the FPV disappears already when passing 30degrees of pitch (as shown on the ADI) When you are at 90 degrees pitch up and still have enough forward airspeed , the aircrafts actual flight path is pure vertically upwards, which means, you should see the FPV in the HUD. But you don't in DCS. If you unsafe the trigger, you will see the IR missile symbology (just to prove the HUD is technically able to project something at any pitch attitude) . Now the funny thing is , if you now safe the trigger again, the FPV magically does appear correctly in the HUD. Very odd. The same also goes for significant pitch down attitudes (where the correct display of the FPV should be even more critical) I tested this some more. It appears the FPV incorrectly disappears when passing 30 degrees pitch up or down (on the ADI) and oddly reappears only when the pitch is reduced to 20 degrees up/down approximately. With aircraft pitch or more precisely aircraft flight path between 30 and 90 degrees from the horizontal the FPV is wrongly not shown inside the HUD. With my above "workaround" you can force it, but it works only until the next time you exceed 30 degrees pitch. Sorry for the long explanation, I tried to make it understandable and reproducable. In summary : the FPV incorrectly incorrectly does NOT show flight path or better put, is not visible despite flight path in HUD FOV between 30 and 90 degrees pitch attitude approx, when the aircrafts actual flight path is within HUD field of view. Some pics to illustrate: 1. Pure vertical and still forward speed for vertical aircraft flight path. (weapon selector in IR BB) 2. unsafed the trigger for RB24/74 , correctly symbology shown, in other words, the HUD is generally able to project . Now 3rd pic, after putting trigger back to safe, the FPV is now finally correctly displayed/calculated : Kind regards, Snappy

Hi @TOViper! Very good. The only possible addition I can think of is under section Indication, Maybe add that "During preheating KB-H/KA SL light illuminates steadily and extinguishes when the preheating is complete" Or something along those lines. This could also be added to the Indication section of the U22/A pod description kind regards, Snappy

Like I wrote above it was a misinterpretation of what he wrote . I took his sentence „For the old pod (U22), only Mode A will emit. Mode B is pre-heat“ to mean that preheating was restricted to mode B . I was focusing on the preheating part, not the emitting part. Snappy

Ok, then I misunderstood your point.

With all due respect @Zabuzard, your mentioned own manual says otherwise or is written wrong , the page for the older U22 pod says the following: null Regardless of that , the U22 Pod does not pre-heat in mode B either . Its broken completely. Kind regards, Snappy

Hi TOViper, sorry forgot to write that , latest OB, MT version.

Hi @TOViper , yes It was like @razo+r wrote , there used to be a slight discrepancy on the compass rose on the ground and once aligned with the runway centreline you could press the reference button and see it snap onto the correct course. It was only a small correction, maybe 3-5 degrees max. But it could well be that this initial discrepancy has become eliminated by one of the patches and the compass rose is now always spot-on by default, I just re-familiarized myself with the Viggen after quite a while. Like I said, in the air the reference button works and performs its function in regards to altitude setting like it should. Regards, Snappy

I tested now in several different mission and setups. The older U22 jamming pod seems broken. After a cold start it does not warm up neither in mode A nor B , the KB-H/KA SL light never comes on. Neither does the MOTVERK light. Also it does not work if you set up a mission where you start airborne already. And if you get targeted it does not jam at all. The newer U22/A pod seems to be working ok. Kind regards, Snappy.

Hi, has something been changed with use of the reference button on ground? I used to be able to press it once aligned with the runway centerline and you could see the compass on the central indicator do the manual update/correction and snap to runway heading. The manual also mentions that function , the manual course setting: "Manual course setting If needed. Press Reference button (on stick) after carefully aligning with the runway heading." This no longer seems to work, you can press the reference button, but nothing happens , the compass rose does not adjust. In the air the reference button works as it should. Can somebody confirm this? regards, Snappy

Hi, not sure if this is tracked already, a cursory forum search came up emtpy. The FR 22 radios group and base number indications are not backlit by the instrument light setting like they should. In DCS at night, with instrument, panel and floodlights full on , they look like this: Compared to this picture from the Viggen Simulator from F 15 wing , @SwedishWaffle,hope its ok, if I use your pic from reddit for this: And also another one from the simulator at NYO, also shows that the base and group channel numbers are backlit: My picture from latest open beta, multithread variant. Would be nice if this could get fixed , because its kind of annoying at night, having to use flashlight or zoom in alot just to read the numbers while droning around at low level .. Kind regards, Snappy

ViggenFlipFlop.trk There is a bug , the system wrongly shows LB as destination waypoint for landing phase 2, when it really should be LF. The first pic is in phase 1, I have just switched to LANDN NAV and correctly it shows LB 1 as destination. The second pic is just a moment later, after I performed the flipflop from LANDN NAV to LANDN P/O and back. On the radar display you can see that the system correctly shortened the approach as intended, but the destination Waypoint is still wrongly shown as LB1. Third pic is from the new 2.1 beta manual page 151, which shows that during phase 2, the landing destination waypoint should be LF. I also attached a track, but not sure how well Viggen replays work out. Kind regards, Snappy

Hi, there seems to be a bug in the radar system rendering .The visualized sweep on the scope seems to be wrongly coupled to the existence of radar returns on the scope. I don't think this is correct. If you manually move radar antenna far upwards , after a certain point (when no ground returns are painted anymore) the beam itself completely disappears too and stops sweeping. Alternatively You can also leave the antenna elevation untouched and pull up the aircraft itself 90 degrees vertical pitch , same effect. Once the radar no longer paints any returns, the sweeping beam itself disappears. Happens in A1 and A2 mode. I really dont think this is correct. Of course it's correct that there are no radar returns after a certain radar antenna elevation upwards, but I don't think the radar itself should stop sweeping/showing the beam , just because there are no returns at the moment. I attached a small track from the caucasus instant action mission "airborne intercept" - but not sure how well viggen tracks play out. In the track I first showed the 90 degrees pull up version with antenna elevation untouched , thereafter I levelled off again and then manually adjusted antenna upwards till the sweeping beam disappeared again . In case the track doesnt work correctly, please test the two above methods. Kind regards Snappy ViggenBeamUpwards.trk

@Silhou Silhou, please kindly add the track and material from @Some1 to that bug report, because he actually tested the pipper calculationin a very controlled environment, with constant target G and closure. See his original bug report: Kind regards, Snappy

Really interesting bit about the exchange flying in the Viggen, thanks a lot! I wonder what he means , when he wrote the swedish pilot flew a hands off 4 degree approach , with his hands literally on his head? 4 degrees is probably the approach descent angle,ok. But I thought the autopilot couldn't do approaches in the Viggen? Or was that changed in the JA variant? Regards, Snappy

The keyboard keybinds for HUD brightness increase and decrease do not seem to work. I also tried deleting them and assigning different keys to them. Still the HUD brightness doesnt change. Even after pressing them for a long time. Only method to adjust HUD brightness is via the clickable brightness dial below it. Regards Snappy

Yea, well, sorry but that is no solution. If the target is not maneuvering , you don't need a lead computing sight all. The very purpose of it is to provide a lead calculation for you. It's literally in the name. It cannot compensate for erratic , constantly jinking targets no, but in this case the target is flying a steady horizontal and very predictable turn at a constant low G. Ideal conditions for a lead computing sight.

Ok, yes, fair enough, I can understand that line of thinking with the purchase salvaging. Thanks for explaining . Hmm no really good way to go about it then. I don't have the answer either. Personally I decided not to buy anymore from EDs own module lineup , until they improve a lot on product bugfixing and core. I'll stick to 3rd party with better track records. But everyone gets to make their own decision of course.

Attached are several short tracks with a practice F-14 target set up to fly steady horizontal 2.5G circles and me aiming for the radar target dot with the gunsight in ANT mode and the target locked on in radar and within effective gun range. Still the rounds pass behind the target. 2.5 G is not much of a turn.If you want to score hits you have to aim further in front of the radar dot. The problem doesn't get better with even higher G turns of the target. If you would aim for target center mass (like you see on guncam photos, with the pipper squarely on target center mass) the rounds also would pass behind the target. Mission file is attached, in case its needed to play back tracks. Kind regards, Snappy F1RadarTGTgunsV1.trk F1RadarTGTgunsV2.trk F1RadarTGTgunsV3.trk F1MirageGunsFighter2.miz