1 pointNo problem guys I love your plane its awesome I'm glad to be of help. And thanks also Matty260191
1 pointThanks again for your time and info. I guess I’m going to go for the RX 550. I checked three different tech spec sources for the Sapphire Pulse RX 550 (the card I’ll be getting) power requirements getting various results: 50 watts (CNET); 65 watts (techpowerup); and <65 watts (Sapphire, the manufacturer’s web site). From this I’m assuming that 65 watts should be the cards’ peak (maximum) power consumption at any given time. I’m also going to pull the HD 5450 card and send it back (I have 30 day free return). However, the RX 550 from the vendor is out of stock until Aug 22 with an estimated delivery date to me around the first few days of Sep. My HD 6750 card still works but the cooling fan is getting ready to go (very wobbly and makes a lot of racket, gets very annoying after a while). I was trying to be pro-active by getting a new card (the HD 5450) to avoid suffering T3DP downtime waiting to find and get a replacement card if/when the fan fails. So here hopes the fan will hold on (literally) for another month. According to my base computer specs (HP Pavilion Elite 510Y) there is also an integrated ATI (mobility) Radeon 4200 video card that has never been used (can’t use it if another graphics card is plugged into PCIe slot). I’m assuming in a worst case scenario that the 4200 card should keep me going on limited basis (DVI and VGA sockets, 512 MB vram and 500 Mhz core speed); but definitely not T3DP. However, would the 4200 card’s 500 Mhz core clock speed be fast enough to run a playable Tower 2011 since it has less graphic requirements? My computer’s 8 GB ram and 2.8 GHz processing speed and the 4200 card provide over the minimum Tower 2011 system requirements, but then so did the HD 5450 card for T3DP except for the slow core clock speed making the game unplayable.
1 pointThat's strange. it is almost always the other way round -- the inputs from the encoder pile up whilst the display keeps up easily. Anyway, the normal way of dealing with these things, and one which i've used in several case of encoder+display going back many years, is to update the display locally, directly from the encoder changes, whilst also feeding the latter to the sim, only reading values to display when the encoder changes have paused for a measurable time, like half a second or so. I don't know if that's possible using this "mobiflight", whatever that is (software or hardware?). Sounds like something is badly wrong there then. Sorry, what do you mean "not stable"? Changing on its own without relation to the encoder or sim value? What LVAR? I thought you just said you were using the offset! If you are reading an L:Var instead then I'm not surprised it is slow. Accessing local Gauge values is very slow by comparison. Neither are any good as they are, and you certainly don't need two in any case. But it isn't worth going into any details to help you further until you clarify two things: 1. What has an LVAR got to do with it. what is wrong with the offset? 2. Why is offset 0x66C0 being used? What does that have to do with anything? Pete