Pete Dowson

Yes. Pete

Yes, that is an interesting option for checking or setting the route followed, but I thought the requester was thinking of using the GPS "live" as an additional flight instrument. Regards, Pete

I looked at it. Yes, that's all it does write-wise at present, but I expect the author can add more. Basically it is doing something anyone with the Microsoft Panels SDK can do, by writing a Gauge. In fact there have been gauges which do something similar in the past. Converting a Gauge to a full Module is not hard, but you have to take precautions not to invoke the Panels interface when it isn't ready, like before a Panel is loaded or whilst an aircraft is being loaded/reloaded. It is easy to crash FS otherwise. Using the Atom name itself to pass the information back, rather than shared memory via mapped files, is a clever idea, though it does mean it is a bit limited in performance terms -- if you want a whole sheaf of data (for a full cockpit, say) it would mean many messages per frame, and hence many process swaps -- it could therefore be quite inefficient for that I think. Maybe he will develop this a little too. It will be interesting to watch it develop. All the variables it supports are panel tokens. I don't know why he's only supporting the position writing at present, you can write a *lot* more than that via the Gauges interface. This subset of the information and facilities FSUIPC offers will no doubt be useful to some. But I expect that if the author goes as far as FSUIPC does and spends the time needed to do this (many months full time) he'd probably wish he hadn't started (like I have several times ), or find it necessary to make some income from it to compensate for not having time to spend earning a living elsewhere! But perhaps not. We'll see ... Thanks for pointing the module out to me, in any case, I am always interested in these things. I'm sure one day I'll be able to withdraw, but maybe even then I shall have to hand over the code ownership too. Regards, Pete

Looks like it should work. Have you tried programming the Server side through FSUIPC "Keys" programming instead? Worth a try. Remove the SendKeys from WideServer.ini (NOT WideClient) and program the keys in the FSUIPC Keys option page instead. You'll find entries in the drop-down Controls lists allowing you to select KEYSEND for WideFS and give the KeySend number as a parameter -- both press and release can be programmed on the same page. To eliminate problems on the WideFS bit, you could try (just as a test), making a copy of Roger Wilco on the FS PC and seeing if the "Roger Wilco Transmit" On/Off controls in FSUIPC's Keys page work with it. If not, then it may be that the version of RW you are using doesn't support the control messages I know about. In that case perhaps you could Zip up the RW folder, or at least the EXE, and send it to me so I can work it out here. petedowson@btconnect.com. Regards, Pete

Hi Chris, Thanks for your explanations on my behalf. Yes, I will be doing a fuller explanation of everything, up top and in front, but I want that to include pricing, availability, and registration procedures as well. Actually a lot of the attacking messages are sort-of interesting in that they allow me to see where folks might be misunderstanding me in any case, and perhaps will help me make things even clearer when I do. Meanwhile, really, this week and maybe next too I'll have my head buried deep into FS2004 -- I've not got the Release version yet but am expecting it tomorrow (?). Only then will I know how much more work I have to do for the initial release of FSUIPC Version 3, which I do really want to release at the same time as FS2004 if I can. Thanks again & best regards, Pete

No way! I've not even got a version which will run with FS2004 Release version. I am hoping for my advanced copy of FS2004 to arrive soon, and then I will get to work on it. The changes needed in FSUIPC just from Beta 2 to Beta 3 of FS2004 took around 120 hours real hard work. I don't know if the differences between Beta 3 and the Release version will be more or less. The relationship between FSUIPC and FS is very intricate. It isn't using regular gauge/panel interfaces, they do not provide enough control nor data. I am pretty sure I wil be able to release an FS2004 compatible version of FSUIPC around the same time as FS2004 is released, but it may not be complete at that time. It should support the majority of applications, however. There will be a fairly frequent update rate for a few months whilst I find other stuff, no doubt. Regards, Pete

Yes, but I expect they might slave the antennae signals, or at least use a more convenient (to them) signal protocol than NMEA 0183. It's worth checking into I suppose, but I have strong doubts. Okay. Let me know what you find out. Well, between two PCs it has to be a "null modem" cable, though in truth all it needs is three wires -- ground (1-1) then Tx-Rx and Rx-Tx (2-3, 3-2). For a GPS it would be the appropriate cable to link that GPS, bidirectionally, to a PC -- they all tend to come with their own specific plug arrangements so no standard cable would do. Regards, Pete

Yes, but I expect they might slave the antennae signals, or at least use a more convenient (to them) signal protocol than NMEA 0183. It's worth checking into I suppose, but I have strong doubts. Okay. Let me know what you find out. Well, between two PCs it has to be a "null modem" cable, though in truth all it needs is three wires -- ground (1-1) then Tx-Rx and Rx-Tx (2-3, 3-2). For a GPS it would be the appropriate cable to link that GPS, bidirectionally, to a PC -- they all tend to come with their own specific plug arrangements so no standard cable would do. Regards, Pete

That part is right. When running FS with GPSout the output on the COM port looks, to any GPS-compatible software (or device) like the output from a real GPS. In other words, it turns FS into a "GPS simulator" as far as that external program or device is concerned. That is its purpose, so that all those GPS-compatible mapping programs can be used with FS. No, because I have never found a GPS which could receive the output from another GPS and act as if this was the signal coming from the satellites. Basically what you are asking for is your GPS to stop being a GPS, to throw its satellite receiver signals away, and instead connect to another GPS (in this case FS+GPSout) to get its positional data from. Now *maybe* there are GPS's that can do this (why they would put such a facility in I do not know), but I don't know of one. Many GPSs do have facilities to receive signals from external aerial or positional update systems, to more accurately determine their position. I think these use additional ground-based transmissions (beacons) and, together with the GPS's own satellite reception, can, in some parts of the world (probably only parts of the USA) determine positions to something like one centimeter accuracy or better. I think these are used in surveying. The protocol these use is RTCM SC-104 or similar, which deals with differential GPS beacons. Even my little Garmin Etrex can receive these, but I don't think they are of any use to me here. Well if you find that your GPS 176 can be set to ignore its receivers and accept data in standard NMEA 0183 sentences on a serial connection, then configure it so and try it out with GPSout. I'm not saying that isn't possible, it's just that I've never come across a GPS device which will do this. Maybe it will have it as "simulation mode" or something like that, intended for training/classroom use. Please let me know in case others ask. If you succeed I can tell others which GPS unit they'd need! Ah, then you can't try it after all. Shame. Perhaps you can get the handbook off the internet and see if it says it is possible? Regards, Pete

Glad you fixed it, but ... ... "FSpauser"? There wasn't a DLL by that name in your FS modules folder, or at least it wasn't running. Or is this an external application? Are you saying it overwrote part of the WideServer DLL file itself? Pete

No, all recent versions of Wideclient use a pair of Registered messages which RW responds to. It doesn't use KeyStrokes at all when you use the keywords RWon and RWoff. There are two different pairs of Registered Message names I found in the copies of RW I looked at (Mark 1 and Mark 1c). I try both sets. The allocation of the PTT key in RW is actually irrelevant. Regards, Pete

That's great! So I can stop work on FSUIPC and go do something else? At last! This saves me a *lot* of painful work! Pete

Well, you shouldn't actually need to shut down and restart FliteMap - that sounds very odd - but framing errors are normally due to incorrect (mismatching) baud rate or parity. Try the Test mode in FliteMap, see what this shows. If things are sometimes okay, sometimes not, I can only think that either your cable is rather suspect, or there's problem with one of the COM ports -- perhaps a conflicting IRQ. With my copy of FliteMap I have the baud rate set to 19200, and the device selected happens to be "Garmin GPS 95 NMEA 0183" (but I think many of the others will do). In the GPSout.ini file the sentences selected are RMC, GGA and GSA. Regards, Pete

Not till an FSUIPC for FS2004 is released, and then I'll probably release an updated PFC as well. PFC.DLL depends intricately upon FSUIPC. Regards, Pete

Sorry, no. There's no way FSUIPC can stop FS loading up panels, if that's what it should be doing. Sounds like something else is wrong in your FS configuration. By default FSUIPC just sits there, doing almost nothing at all. Pete

If you mean the keycode values used by FSUIPC and WideFS, then they are listed in the Advanced User's Guide, a document you'll find inside the FSUIPC ZIP. If you mean something for PM specifically, not using FSUIPC or WideFS, then I'm not sure. You'ld need to check with PM support. Regards, Pete

Ahthat's what I like to hear! Pete

Good. None of the entries in the Joystick Button programming section are generated by default. Anyway, the PollInterval thing is a bit technical and has the potential for wrecking FS performance if taken to extremes -- I didn't really want folks playing with it without good reason. To be honest, I never thought that some bug in some panel programming would make a change in this parameter necessary. It was really aimed at EPIC users who have to be pretty technically minded in any case! Regards, Pete

Ah .. the "default" actions are those which occur if there's no parameter to tell it otherwise. Possibly the parameter was left in from a previous version, when IPX/SPX was defaulted? WideFS doesn't generate an INI file, unlike FSUIPC. Or possibly the initial default INI files I supply in the ZIP have this parameter? They shouldn't -- I'll have to check that! Thanks! Pete

This just means exactly what it says. Your TONY PC does not know another PC in the same setup with the name Aston. Why, or how you fix it, I'm afraid I don't really know. Does the Aston PC show up in the Windows Explorer window (probably under "My Network Places" somewhere)? If not, then that's the first step -- get both PCs seeing each other properly. For IPX/SPX under NT, Win2000 or WinXP each Client needs the ServerNode explicitly provided (see the WideFS document) -- it seems only in the Win98/Me operating systems is Windows clever enough to find a server connection automatically when using this simple protocol. Regards, Pete

At present Heathrow local time IS +1 hour from UTC! I think you are confusing the terms slightly? GMT is the old name for the time now called UTC. i.e. UTC = GMT. But in the UK in Summer we use BST (British Summer Time) which is UTC+1. This is what FS is calling, correctly, "local time". Regards, Pete

Have you asked the FS Real Time author? I think when you install this program there are replacement BGLs installed which are supposed to correct time zone problems already in FS. It sounds like those BGLs got corrupted or something, but I'm sorry, I don't know which ones they are. Pete

I can implement automatic selection of some parameters based on something like the aircraft name, but I think it would still be better to keep them central, in the FSUIPC.INI, possibly with sections named after the aircraft. Folks do chop and change aircraft and exchange them, so parameters relating to one person's control kit could get imposed on another's, which could cause problems. Another consideration is that, although, in FS2002, I can actually derive the correct AIRCRAFT.CFG file path, this currently isn't the case for FS2004 and may not always be feasible in any case. All this will have to wait until I'm in a position to start thinking about new facilities in any case, and would probably go hand in hand with proper axis selection and assignment facilities (instead of relying on the FS CFG file as at present). We'll see. Maybe you'll want to remind me in a few months? Regards, Pete

There are NO password protected zipped versions of any of my modules, at least none supplied by me. I do not make a program called "FSWide", but if you really mean WideFS, then the current version of WideFS is still free and most certainly not password protected. There is no way to pay for anything until the new versions are released, probably at the end of July, and then this will be by access keys not ZIP password protection. If you are having problems getting a good download you need to contact the support for the web site you are using. Pete

This has ALWAYS meant simply that the protocol specified (IPX/SPX or TCP/IP) is not installed. Version 4.65 is pretty old now. It only supports IPX/SPX. I think you'll find IPX/SPX is not installed by default on XP. In any case I really cannot support old versions of WideFS. The performance of version 5 of WideFS is markedly superior to version 4. Since version 5.50, the current version, TCP/IP has been the default protocol as this is easier to set up with XP. Er, it is absolutely no use specifying "UseTCPIP" for version 4.65 as TCP/IP was not supported until version 4.70 at the earliest (but buggy then -- full support was version 5.00). Please go download the current version and use that. Pete