rickalty
-
Posts
163 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by rickalty
-
-
If you're building a hardware cockpit, don't worry about interfacing the hardware light / switch to FSUIPC or MSFS - simply have the switch turn on the light on the panel.
Richard
-
Lol, I live in USA, NYC. The only thing I know about trains and railways is amtrack :oops: and that is just a train line :lol:
Go and ride the New York, Susquehanna & Western Railway - especially in the fall the ride up through the forests behind an old steam loco is wonderfull.
Richard
-
Just an update..... I've gotten the "GPS Master" freeware program to connect with the GPSOut function of MSFS.... sort of :-(
The moving map moves, the track seems right, waypoint, routes etc are all working, but the displayed speed is all over the place - flying straight and level at 100 knots it bounces around from 40 kts to 250 kts.
I'll keep playing and let you know how it goes.
Richard
-
Arthur:
Dim Master as Boolean Call FSUIPC_Read(&H2E80, 4, VarPtr(Master), dwResult) Call FSUIPC_Process(dwResult) If Master = True Then MasterLightOn.Caption = Format(Master, "Master ON") Else Master = False End If
Try this...
Dim Master as Boolean Call FSUIPC_Read(&H2E80, 4, VarPtr(Master), dwResult) Call FSUIPC_Process(dwResult) If Master = True Then MasterLightOn.Caption = "Master ON" Else MasterLightOn.Caption = "Master OFF" End If
In the 'Else' condition, instead of setting MasterLightOn.Caption to "Master OFF" if Master was False, you were just setting Master to False if it was already false - ie doing nothing.
Richard
-
Thank you very much, CaptainGPS. I found that site last night, and have installed "GPS Master" and it's related BMP - Raster map converter, but I'm having trouble getting it to connect to MSFS, so I'll give mininav a try.
PETE....
In the GPSout.ini fle, the default sentence info includes "GPRMZ", but in the info below, it lists "PGRMZ". I assume one of these is a typo? which should I try?
Richard
-
Hi... I see that you've been able to get GPSOut to work with serial port PalmPilots.
I have a Palm IIIxe with a serial cable.
Can anyone recommend a GPS application for the Palm that will take the GPSOut signal? Freeware would be preferred of course :-)
Richard
-
One last question - is the chip(s) that makes a joystick "do its thing" something easily purchased and wired? I cannabalized a couple of joysticks. One of them wasn't too trivial a task, but the other one was. What chip(s) is the "heart" of the joystick system? If that's an easy question to answer, please do. If it starts getting complex, either steer me in an appropriate direction, if possible, or just smile and I'll go away!
Art
May I suggest you go to http://www.betainnovations.com and look at the section for the "Plasma MiniMe"? All the schematics, parts list, Hex code for the PIC etc, to build a control board for a 5-axis/12-button/1-HAT USB controller for less than $10.
Richard
-
The more I read about .NET, the more convinced I am I should stick with Legacy VB as long as humanly possible. In my case I have little choice anyway - my video editing hardware has no drivers available for anything after Win98, so I can't shift to .NET for my own usage.
To be honest, I really can't understand why anyone has already shifted to writing in .NET - as long as there is still a large Win98 / Win95 user base out there who can't use .NET based software I would think anyone who wanted to write widely distributable software would stick to a language that all OS's can run.
Richard
-
PetDoc:In the fsuipc VB.net sdk writing an offset is done via a Write followed by a ProcessPete:Really? For every individual read and write? That is GROSSLY inefficient! Each "Process" call does a Process change to get into FS, activates FSUIPC's offset scanning, processes your changes, then needs another process change back to your program! The whole reason the FSUIPC_Read and FSUIPC_Write procedures were split from the FSUIPC_Process procedure was to allow EVERY read and write you needed to do to be performed in one process.
No, the SDK just looks like that because the example only has one Write, so it's Write then Process.
My VB apps go Read, Read, Read, Write, Write, Write, Process.
Richard
-
And, no, Windows C/C++ programmers don't have to define things like VK codes. That's the point. They use the names, they don't have to remember the numbers. The names are pre-defined, just as the API procedures are. That's why I couldn't give you your example without looking the values up. I don't use the values that you seem to need.
Actually, nor do you in VB. To read a keystroke in VB - assuming you want to know what 'key' was pressed, rather than what letter, etc, was returned, you use the KeyUp or KeyDown events, and the predefined key names.
Private Sub Control_KeyDown(KeyCode As Integer, Shift As Integer)
This will return two values when a key is pressed - KeyCode for which key is pressed, and Shift for which of the Shift, Ctrl or Alt keys are down at the same time.
While KeyCode does return an integer, you don't actually use it. To decide what to do with the input, you usually then just use the pre-defined key names in a case list.
Select Case KeyCode Case vbKeyF1 strKey="The F1 key was pressed" Case vbKeyF2 strKey="The F2 key was pressed" ...... etc, etc, etc
Richard
-
I gave you that factor of 55/16384 (or 298) in an earlier post. That's why the needle seems to skip around - it only displays when a value of 289 x the pressure happens to fall within the displayed range.
The reason the needle duplicates is in the code I sent you - you need a '.cls' command before every time you draw the needle.
After drawing the needle, you need to get rid of it again before you redraw it, otherwise you'll end up with a white arc - every position the needles ever been in, all showing at once.
Richard
-
Hi Cali - Actually, FSinterogate's not by Pete, but it's included in the SDK. Rather than going into all sorts of details in here, drop me an email at rickalty@aol.com.
Richard
-
OK, I didn't actually check the address, and that's wrong. The Oil Pressure is at 8BA not 8B8 (which is the oil temp)
55 psi is equal to a reading of 16384 and 220 psi is a reading of 65535, so it is linear - each one psi is 289 on the scale, so after doing
Call FSUIPC_Read(&H8BA, 2, VarPtr(OilPress), dwResult )
you can say
OilPress = OilPress / 289 CaOIL.Caption=Format(OilPress, "0")
You should also be able to then use OilPress to calculate OilPressAngle to put into the trig for the needle.
Richard
-
Hi Arthur.
Looks like the problem is up at the beginning here....
Call FSUIPC_Read(&H8B8, 2, VarPtr(OilPress), dwResult
Call FSUIPC_Read(dwResult)
OilPSI = (OilPress / 65536)
CaoOIL.Caption = format(OilPress)
If OilPress < 60 Then
First, your brackets don't match up, you must have the same number of opening and closing brackets - I can't figure out why it didn't crash in fact :-)
Secondly, you've got the call wrong - you have a second Call FSUIPC_Read that doesn't call anything, and you have no process.
Here's how I think it should read.
Call FSUIPC_Read(&H8B8, 2, VarPtr(OilPress), dwResult) ' Added a final bracket Call FSUIPC_Process(dwResult) 'You had no Process call OilPress = (OilPress / 65536) ' There was an OilPSI variable here undefined CaoOIL.Caption = format(OilPress, "0") ' If you want to use Format, you have to give it a format If OilPress < 60 Then
Looks OK from there down.
Richard
-
To convert the FS value from 2A0...
Dim Variation As Long
Call FSUIPC_Read(&H2A0, 2, VarPtr(Variation), dwResult)
Call FSUIPC_Process(dwResult)
Variation = (Variation / 65536) * CLng(360)
For 0C50 it's exactly the same.
For 0C40 the ame but ignore the correction, it reads straight out in degrees.
Richard
-
I would point out that in the real world, if you fly from one time zone to another, you have to reach out and manually adjust the local cockpit time. (GPS etc, of course, is generally kept on GMT)
Richard
-
I know nothing about writing in C, but that ever increasing program size is a giveaway - somehow, variables are using up more and more space instead of being overwritten each time around - a "memory leak". I don't know enough C to know how to track that down, but that's the problem.
Richard
-
Making too much read every second lead that? (Although I don't think that is too much, around 20 reads?!) May be I am doing something wrong. I am gonna recheck my code, by the way any suggestions will be accepted :?:
20 is a small number of reads. I don't remember the actual possible read buffer max off the top of my head, but it's fairly big. I have over 40 reads per process in my FSPanel, and that's on a timer that fires every 50ms.
Richard
-
Yes, there are significantly more added functions in 3
-
The people to ask this to would be PMDG - they'd know what FSUIPC functions they used when the wrote the app.
Since a lot of the stuff that a plane like this might get from FSUIPC would be strictly in the background - ie invisible to the user - even another user of the aircraft wouldn't know what comes from FSUIPC.
Sorry, it's just not something that even Pete would probably know. Once software's out there, there's really no way to know what other developers are using it for.
Richard
-
Contact SimMarket. They'll get you sorted out. It may mean generating you a new FSUIPC key from your new email, but they can do that quickly.
Richard
-
Incidentally, if what you meant was being able to write to it through the FSUIPC interface, the short answer is 'no'. You could set a key to send a parameter to it, yes, but since ou have to choose a value, and type it into the FSUIPC interface when you select which key to use, it would be kind of pointless.
Richard
-
It's stored at 07CC as "AP Heading Value"
Richard
-
For a program to read MSFS values through FSUIPC, one of two things must be true.
1) The copy of FSUIPC is registered. On paying for FSUIPC (through http://www.simmarket.com) you'll be issued an FSUIPC key. Once this is entered, any program can read values through FSUIPC, plus you have full access to all the additional FSUIPC functions Pete has written.
2) The program trying to read through FSUIPC provides an FSUIPC key internally. If the program is freeware, Pete will provide that key to the program author for free. If it's a payware product, the author negotiates a license agreement with him. In this case, the program can read through FSUIPC, but you don't have access to the additional functions.
What it sounds to me has happened is that the version of FlyByWire you've got doesn't inclue an FSUIPC key. Since it's freeware, you could just drop a line to Vadim and ask him if he has a newer version. If he doesn't, then he can ask Pete for a freeware key, put it into his program, and you'll be good to go.
Richard
seatbelt signs
in FSUIPC Support Pete Dowson Modules
Posted
Since you have the physical panel, and the seat belt / no smoking signs switches have no actual function, simply wire the switches, not to PM to activate the PM sounds, but just to something that makes a 'dong' noise when you flick the switch. Modify a door chime, maybe?
Richard