Holton181

I really wish @RagnarDA, @Cobra847 or anyone else from the team could chime in on this already!

I'm back. As I said you missed my edit I did at the same time you posted the above. The reason why you don't seem to be able to make the return-to-course to work whatever you try might be due to your controller. I don't know what you have, but if it doesn't have high resolution and/or have noisy, maybe worn potentiometers and maybe in addition have a centering mechanism that isn't efficient enough to bring it to dead center (and not just to appear to be centered), it would for sure be difficult to get it working. In all my tests all stick deflection has been itsy bitsy tiny even for a high res, noise free controller with a very good centering mechanism. Other than that I have no clue. Regarding my theory I realized now when trying to find a better explanation for you, I was a bit too fast sharing it. It is only partly explaining what is happening. The rest I haven't figured out yet. I remember from the University that the subject of "automatic control engineering" (what this thread is all about) was considered among the most difficult subjects to wrap your head around. So don't bother to much about my theory for now. Let's just stop at the conclusion it doesn't seem to work as intended. But I would like to add a thought I forgot to share previously. In my first rest regarding the return-to-course functionality I said it really did return even if not centering the stick. It really did. Then in the second test, where I deflected the stick a bit more and both in pitch and bank, it returned to altitude but not to course. Now why this inconsistency? I really have no clue!

I see you missed my edit. But it doesn't change the issue you are experiencing. I might figure out a better way to explain, but have to take my little kid to bed right now.

I rerun this latest test (without the long wait), and as soon the plane had settled on the new course I re-centered the stick. Then it returned to set course. Good. I have a theory: The implementation of the scaling constant for the corrective signal (Δ-course) or the steering input for the control surfaces is related to the angular deflection from set course for the bank, and deflection from set altitude for the pitch. This we know. But to RETURN to said course or altitude one needs to make a correction that is double the deflection (and opposite). If the correction is the same size as the deflection we will only settle the attitude. For the altitude hold this seems to be correct, for a stick deflection lower than a particular value. If above this value the AP can't even halt the angular pitch change. But for the course it seems the correction is the same as the deflection, explaining why it can level the plane in bank and stop the turn, and also why this is a relatively slow process, but it can't make it return since the deflection and correction is of the same size but opposite so no resultant signal to stear it back on course. The slow process might be a way to limit oscillations, and would not be experienced as slow if the correction signal was correctly double the deflection. As a side note, the manual for the real aircraft only mention "the control surfaces" when talking about returning on course, while the Heatblur manual only mention the "rudder servo" for the same task. Edit: I realized I used "stick deflection" when I actually only meant either angular deflection from set course or deflection from set altitude. Corrected, but there is still one "stick deflection"stick present and is meant that way.

I let the above test run for quite some time, but it never returned. It was just a "quick" test with arbitrary selected stick deflections (2200 in pitch, 900 in roll). The cat yanked the stick before I got the time to re-center the stick (I wasn't sitting at the controls at the time). Conclusion: amount of stick deflection do seem to have an effect on the ability to return on course even if the plane has settled. For it to return the stick has to be deflected very lightly or completely centered. Secondary conclusion: Never bring your cat to the lab.

Even if a bit OT, I agree with you that the Nevada should have been the free map and not the Caucasus. They could have done it so that everyone paying for it (or EA A-10C) would get the Caucasus for free when finally ported to DCS 2, while everybody else would have to buy it for the same price as Nevada previously, while getting Nevada for free. That way it would be quite fair and square. And since most missions and campaigns for Caucasus would need some rework the extra income from people buying the new Caucasus could cover some of that work.

I just tested to deflect the stick both in roll and pitch in the order of 5 degrees (rough estimate) while in HÖJD and kept it there. It levelled off pretty quickly in both axis and returned to set altitude, but the bank took several minutes to really stop the turn and I can't yet see any tendencies towards restoring the course. Still running and waiting.

Due to how small input deflections I did, it could almost represent a changed side wind and in my opinion the AP should be able to adjust for that within seconds, like the altitude hold. The size of the deflections where also small enough to represent 4-5LSB change on a 10bit controller or 2LSB on a 9bit controller (my Saitek Evo). Really not much and in the order of noisy potentiometers. To even make the pitch start to change while in HÖJD I had to deflect the stick about 3300 compared to immediately bank when deflecting it sideways, and in the above tests it was side deflections of about only 300, an order of ten lower than making the pitch change.

Actually didn't time it, should have done when you mention it. For the small yanks where I returned to center (after 1-2s deflected, relative small change in course) about 10-15s, the ones were I kept the stick deflected maybe 10-15min, maybe more.

I'm running a test for the return-to-course issue. Surprisingly enough it does seem to work! ...sort of... Mind you, it is HIGLY sensitive on controller input and INCREDIBLY slow! I attached the (very simple) mission I used, a start-in-air flight across the widest part of the Black Sea with x-tank and no wind, start with active pause. This is how I went about: I opened DXTweak (controller management software) on my second monitor and made sure my stick and pedals was thoroughly centered (with an input value close to 32768 out of 65536). Turned off my TrackIR. Loaded the mission (in active pause) and activated HÖJD and noted indicated speed (about 850km/h). Deactivated active pause and got a pitch jump, it did return to set pitch and altitude within a few seconds though. Heading was not affected. the steering dot stayed inside the FPV circle (not perfectly centered though, but steady). Made sure to stabilize the speed at the original noted above and noted throttle input value in DXTweak for reference if repeating the test later. Kept it flying this way to make sure everything was stabilized. Adjusted seat height and zoom to bring the HUD to fill my main screen to really see even tiny changes. Yanked the stick carefully to one side, the plane initiated a turn away from course, then returned the stick to center. All with an eye on DXTweak. The displacement was about 250-300 of the input value (less than 0.5% of 65536 or 1% of 32768 ). If the return-to-course would not work, the plane would settle at the new course it had at the moment I returned the stick to center, but it didn't, it returned slowly to previously established course towards the WP! I repeated this test several times with stick deflections of the same size but in both directions with the same result, slow return to course after recenter. It didn't return to EXACTLY the same course, but very close. With the history of Heatblure being very thorough about system modeling, I would not be surprised if they added some sort of small system errors causing this. Next thing I tested was to keep the stick at said 250-300 deflection. At first the return-to-course didn't seem to work, but I let it go on. S..l..o..w..l..y.. the turn rate decreased, almost settled on a new course, then S..l..o..w..l..y..started to return to set course! After a loooong time the course settled almost towards the WP. It was more off in relation to the WP than the previous tests, but I guess the return-to-cource isn't actually returning to the exact same track that should have been if no stick deflection, but rather just return to the same direction. In this case the return-to-cource was so slow that the plane shifted its position sideways quite much in relation to said track that it ended up quite far away but parallel to it. My conclusion is that return-to-cource actually do work, but is WHAY to slow to make it practically usable. Remember that the deflections I used in this test was VERY small and performed very carefully, barely touched the stick. Imagine what bigger deflections would do. The altitude hold on the other hand is fast enough to be usable. I get the impression that the issue with slow return-to-cource might be just a wrong order of magnitude of the scaling constant for the corrective signal (Δ-course) or the steering input for the control surfaces. Course hold test No wind.miz

[emoji106]

Glad you like it [emoji106]

But you said your self the course is drifting, didn't you? From OP: In that respect ATT and HÖJD should act the same. They don't drift from course. My comment was about that part of your OP, not the returning to course (as I said I didn't get working either).

Yes it can. Inside the zip there is a folder with the same name as the zip. The content of that folder goes directly into the main DCS install folder, same tree structure. Overwrite all files. I suggest you make a backup of the original files first.

Just tested the course and pitch hold in HÖJD mode during a 300km flight over water. And I must say it does seem to work. I didn't test the <7°-return-to-course behavior thoroughly, but focused on leveling out and pitch. It held bank, pitch, course and altitude rock solid. BUT! it is incredibly sensitive about getting your stick and pedals centered. Touching them an itsy bitsy tiny bit and you start to drift. Toggling HÖJD off and on stabilized the bird again, but obviously at a slightly different altitude and course. To make sure it didn't just work because I had really made an effort centering my controls, I disabled HÖJD while zoomed in on the flight path vector and observed that it did bank and pitch slowly. Engaged HÖJDand it stabilized. Disabling again and it started to bank and pitch exactly the same as before. Turned HÖJD off and on several times and observed the same behavior. Then for fun I adjusted my controls very slightly and finally succeeded to get it stabilized merely by the controls and only SPAK. I did briefly test the <7°-return-to-course by moving either stick or pedals just a notch, but could not observe any stabilizing nor return to previous course, but then again I can't guarantee that I was within <7°. I also in the beginning reduced power from first stage AB to just disabling it with HÖJD active, with no change in attitude or altitude. Note! I have a "full length" helicopter HOTAS (PFT Lynx) with no springs or detents, enough friction on all axes to let go in any position and with small angle, 12 bit Hall sensors (12 bit controller board) on all of them, effectively giving me more than 11bit real and noise free resolution on my stick. Due to the sensitivity of the axis in the Viggen, I assume low resolution controllers and/or noisy pots can make life pretty hard with these things.

I don't remember exactly in what way Leatherneck/Heatblur talked about the Swedish/Scandinavian map they planned for the Viggen, if they saw it as a free asset to it or a payed standalone. Maybe never gave any hints in any direction? Would be stupid business vice in my opinion to give it away for free.

A free water world is good for some people, I'm indifferent to it as long as it doesn't require much resources from other projects. I don't think a clean water world does. Otherwise I totally agree with you.

First I would like to say I'm not a programmer but have enough basic knowledge to read code and create simple scripts, but without knowledge about what is going on under the hood. So please bare with me. I have an export script to export NMEA 0183 sentences (GGA and GMC) to any devise/app that can connect via UDP or Serial Port and utilize these sentences. It now finally work pretty well if one can live with the position error that exist between real, spherical world and DCS flat counterpart. I don't consider this cheating, since we already have the NS430 and position is grabbed by LoGetSelfData, so should not trigger any server anti-cheating flags. There is only one minor but irritating issue I would like to know if possible to handle from the script. I hope some of you LUA wizards can help me. The problem is with Bluetooth Virtual Serial Ports (I can't test for physical serial ports). It works perfectly fine, as long as I have something listening to the port. But as soon as I stop the listener DCS freeze. Starting the listener and DCS unfreeze as if nothing had happen. I suspect it is something with the Bluetooth part of the connection, and since DCS basically only sees a COM port it might not be possible to avoid. Or is it? This is the tree blocks involved in the serial communication: Start=function(self) ... --Bluetooth ---[[ sPort = "COM3" com = io.open(sPort,"w+b") --]] ... end ActivityNextEvent=function(self,t) ... --Bluetooth ---[[ com:write(string.format("$%s*%x\r\n$%s*%x\r\n", GGA,csGGA,RMC,csRMC)) -- fills the serial buffer com:flush() -- send the serial buffer --]] ... end Stop=function(self) ... --Bluetooth ---[[ com:close(sPort) --]] ... end And I have this in the end if involved some how: -- ============= -- Overload -- ============= do local PrevLuaExportStart=LuaExportStart LuaExportStart=function() BS_NMEA:Start() if PrevLuaExportStart then PrevLuaExportStart() end end end do local PrevLuaExportActivityNextEvent=LuaExportActivityNextEvent LuaExportActivityNextEvent=function(t) local tNext = t tNext = BS_NMEA:ActivityNextEvent(t) if PrevLuaExportActivityNextEvent then PrevLuaExportActivityNextEvent() end return tNext end end do local PrevLuaExportStop=LuaExportStop LuaExportStop=function() BS_NMEA:Stop() if PrevLuaExportStop then PrevLuaExportStop() end end endCOM3 is the Bluetooth VP configured as "incoming" in Windows 7 Pro. The listener I'm using is my Android phone with an app specially for overriding the devise GPS with NMEA sentences from an external Bluetooth GPS. So, what do you say?

[emoji106] But I put my money on an all water map for the Carrier OPS guys. Nothing for a rotor head like me. But still good.

Good one, thanks. Then I guess the implementation of the course hold is bugged.

[emoji106]

Yes, but for what I understand the AFK is suposed to be used during approaches not cruising, and you are supposed to correct the attitude as the speed changes to 550, when it settle at 550 it's perfectly fine to engage ATT and expect it to hold the pitch, even if you just cruising. I might be wrong. In my opinion your example where the ATT failed to hold pitch is an example of going outside the operation envelope for the AP so to say, you are not supposed to change the power after ATT activation, as you said yourself it works if keeping the speed stable (easy task ones initial stabilization, no need for an AP channel). Same as in the Shark if you are familiar with that. The AP is there to help you when operating it properly, but also not put you in danger (like risking going into a stall) if operating it in a bad way (like reducing thrust after engagement).

It's only when using the Bluetooth virtual port, not UDP. It freeze the second I hit "Fly" on the briefing window at mission start, and it unfreeze the second any application start listening to the port. If I stop listening the app DCS freeze again, start and it unfreeze. These are the three blocks used for it: at start --Bluetooth ---[[ sPort = "COM3" com = io.open(sPort,"w+b") --]]sending --Bluetooth ---[[ com:write(string.format("$%s*%x\r\n$%s*%x\r\n", GGA,csGGA,RMC,csRMC)) -- fills the serial buffer com:flush() -- send the serial buffer --]]stop --Bluetooth ---[[ com:close(sPort) --]]COM3 is the Bluetooth VP configured as "incoming" in Windows 7 Pro. I basically know nothing about these things but have used examples around the web to get it working. I assume I should do some sort of test on the port before sending. Searched the web how to but could not find anything. Checking the io.open in the beginning for errors should not help, since that is only done at start and the issue is strictly related to if anything is listening on the port: If it is, all good. If not, freeze. Also, it can be a Bluetooth issue, and since DCS and the script isn't really aware of that, only seeing the serial port, it might not be possible to do anything about it?

I would say its quite natural, since the AP doesn't control the engine unless in "Automatiskt fart kontroll" during a landing (which is a different system anyhow what I know of). It's actually quite similar to the AP in the Shark, more like a stability aid and you need so stabilize before giving full authority to it. Imagine what would happen if it would do everything in its power to maintain the pitch if almost cutting power, you would quickly be brought into a stall. Better to let the pitch decrease and keep the wings producing lift and give the pilot time to correct his mistake. After all it's the pilot flying. Keeping the engine power stable is not really an issue for the pilot in a fixed wing, basically setting the throttle to get wanted power and he can basically let go and use his left hand for other things without bothering. Not very tiresome in long flights either. Leting go of your stick for long periods isn't that good idea without engaging ATT. Holding it and trying to manually maintain attitude (while possibly review mission plans, navigate, operating radios, etc) for long flights on the other hand is something different. That's what the AP in the Viggen is for, helping out with the stick and rudder, not the throttle (and not to the level of pilot taking a nap) For the other issues discussed here I agree it would be nice to get some consistent official explanations.

Here. Do you do this step for each engine immediately after the start sequence has started (all green lamps on the engine start panel lit)? Or do you wait a while for the rpm to reach the said 20%? If you wait, the engine won't start. Then you need to crank it a while to remove excessive fuel. You should operate the shutoff lever immediately after the rpm needle start moving. I suggest you read the official manual on this procedure since it goes more in depth (not necessary to perform all system checks), and also describes routines if failing.