Phil4125

Hi Pete, Sorry Just wondered if anyone here knew what the issue is. I guess it is CrgSim related so will post on AVSIM and see if anyone knows. Thanks Phil

I have discovered a small problem with CrgSim in that the Left Nav display reacts correctly but the right display doesn't respond to either of the VOR/ADF switches , the Range setting , the ARPT, STA orWPT functions. The left display works as it should. I know the right display is receiving data as it responds to the Mode setting and centre/ normal functions. Settings are correct in the Coms Manager. I have been unable to find an email or website for Chalk River Graphics to ask Chuck, so any help would be useful. Has anyone any ideas or clues as to why this is so ?? Phil Endean

tried Paintshop pro and adobe photoshop and even at the lowest compression they were still too big. as jpegs they are over 8Mb. I didn't think about it until I whipped them off the camera and saw the size of them. I could have turned the camera down but by then I had done then and apathy took over. Up until 2018 we lived not far from you in Matlock but we decided that NZ was a nicer place to retiure to so I came home and brought my lovely wife with me. She loves it here and has done since I first brought her here in the 1990's. Hope the pics have arrived by now. Let me have your thoughts. Phil

Hi Pete, Further investigation this morning I discovered that if I set the bank angle to say 20 deg in FSX and then move my switch up to 25 then FSX jumps to 30 so I guess that it is as you said. I will have to work on a fiddle for that. Will let you know how I get on. I did see the note but didn't quite understand it. I think a fix in the interface is maybe the best way. i.e tell the interface what angle we need and then let it sort it out. That way the MCP can simply put out the desired max bank angle so that if it ever changes in the future it will simply be an interface amendment rather than a re-flash of the MCP code. It's a shame we can't get hold of the source for the CrgSim PFD display so that I could split up the FD crosses so that each side of the MCP has control of it's own display but ho hum. One of these days I'll have to sit and write a new set with this functionality. Would be so much easier to just amend the CrgSim code. FSUIPC logging is very useful in discovering what does what. I use it all the time as well as FSI. You've saved me loads of time writing tools. I can see everything on the CAN bus with a CAN scanner and I use a TTY emulator (Tera Term) to see what is being passed on the USB so with that and your brilliant tools the job is relatively easy. I am using STM32 processors in most of the modules and they provide a fairly good configuration application. Way back when I started programming we had to do it the proper way and most of it was in assembler including the IBM mainframes but I digress.. I took some photos of the MCP and Quadrant interface but this site won't allow me to upload more than .02Mb and the pic from my camera are around 6Mb so it won't allow it and re-saving for the net is also way to big. Is there any where else I could post them for you? Next module up is the EFIS which is mostly done on the hardware department. That uses offsets mostly in the 0x7800 range to connect to CrgSim. Everything is done in house here. We have laser engraving and cutting and a small machine shop so we can modify switches etc and do bits of turning and milling. Phil

Hi Pete, This will all be for sale commercially when done. Should make building a Sim very easy as it will all be plug and play. Just one CAN bus linking everything. The quadrant board has a CAN USB pass through. Just one piece of software on the PC and everything goes through that. Uses your WideFS for MIP displays and our software will either talk across WideFS or sit directly on the FS PC. The quadrant board also takes inputs from the main flight controls and drives steppers for the quadrant etc. Will keep you posted on progress as other folks may be interested in not having to bother with the nuts and bolts part of creating a Sim. The object of the exercise is to keep the costs to a reasonable level and the realism as high as we can get it.There are a few niggles with FSX in that the Flight directors aren't individually enabled and I haven't yet got the Bank angle variable working, but generally I can overcome most things software related. Your documentation is good so not a lot of need to ask too many questions but that bank angle (0x2E04) has me scratching my head just now. The MCP has the proper concentric 5 position switch with an encoder in the center as per the real thing. The switch puts out the 10,15,20,25,30 but the sim doesn't seem to acknowledge it and the variable appears to clear after a second or so. I did see that it is a "partly" Sim E so maybe it doesn't work as it should. Not a show stopper though as it doesn't seem to work on the default aircraft's panel either. Your FSUIPC SDK was great in getting comms working with very little effort. Thank you for that. Will post you some pictures as we go along. Phil

Sorry Pete, I fixed my own problem. The Aircraft was set to Metres not feet. All working as should now. I realised my error when I started CrgSim and discovered that the Altitude setting above the bar was correct. I then went into the setting on the main panel and set it to feet etc. I'm only a simple programmer you know. The aircraft is the default FSX 737-800 flavour. I have not added any of the other flavours yet. That will be future work Now that the default is set to feet etc it is all working very well. This little DUH has cost me almost a day's work. What tricked me was that it starts in feet but as soon as one gives it a value it converts it to metres. I was sure it was a data type problem at first but then I have been programming C on ARM for many years and am awake to data type errors. The only cast I hadn't quite got to was the one where it gets cast out into the yard. You might be quite interested in this setup as everything is stand alone and connected on CAN bus with a single common interface to FSUIPC. Uses ARM 32 bit processors in most of the modules. Thanks again and sorry to have interrupted you. Best regards Phil

Hoping for a solution. The project is a new set of units for the 737NG etc. The module I am having a spot of bother with is the MCP and in particular the Altitude and V/S encoding. The MCP is connected via CAN bus via our own interfaces to FSUIPC. The problem I am having is that the altitude sent to offset 07D4 does not produce the correct value to FSX. The calculation in the MCP is ((height * 65536) / 3.28084) which produces the correct value which is fed to FSUIPC as a uint32. The utility in FSUIPC shows the correct value being received and stored and validated via FS Interrogate is correct but the FSX MCP shows an entirely different value. The SIM MCP shows 30 for 50ft input and then 91 for 150 (skips 100ft). I have checked submitted values all the way up to 40,000 ft and using (val * 3.28084) / 65536) returns very nearly the right numbers but not on the FSX display. Am I right and FSX is wrong? I very much doubt that. A similar thing is occurring with the V/S (50ft shows up as 61ft in FSX). Converting to Mtrs doesn't work either. 50ft in FSx interrogate is hex 0xA4. (ft * 3.28084) in the MCP produces that value but when it is fed via FSUIPC to the Sim it produces a value 0xC8. There is something going on internally methinks. I can not see anywhere in FSUIPC where the value fed to FSX can be manipulated. I have pulled the calculation around all ways in an attempt to correct it. Am I just barking up a gum tree? I have just about pulled all my hair out over this and have checked what FSUIPC is receiving against the values stored in FSX by the local MCP. Some help would be appreciated. Thanks in anticipation.