Jump to content


  • Content Count

  • Donations

  • Joined

  • Last visited

Posts posted by PeteP

  1. Is this topic what your question is about?Destination Airport not Served by Approach on page 47 of the RC 4.3 user manual already implemented?Are you talking also about aircraft inter communications where an airport controller is not present such as CTAF aircraft position reports in the IAP and traffic pattern under VFR and IFR conditions?
    No, his question is about neither of those situations. IFBP is the "In-Flight Broadcast Procedure", an IATA procedure for use in the AFI region - i.e. Africa - where, in parts, en-route ATC provision for IFR flights varies from minimal to non-existent. The procedure consists of pilots transmitting their own position reports and level change intentions in English on a common frequency (126.9) for the benefit of other pilots in the vicinity to enable them to provide their own separation.

  2. I don't have that file - mine is "m4.csv".
    Oh, silly me! Of course, for Radar Contact version 4, it is m4.csv. Thanks for pointing that out, Ken - I'll edit my original post.PeteEdit: looks like I can't edit my original post - I think that happens once it's been replied to. Maybe if jd has the required privileges, he can make the necessary changes, otherwise for m5.csv please read m4.csv..PP

  3. On March 10, the Transition Altitude in the Birmingham CTA/CTR and the East Midlands CTA/CTR changes from 4000ft to 6000ft. Those of you wishing to update RC4 to use these new values automatically should do the following:

    1. Locate your m5.csv file - you'll find it in the data folder (directory) of your root RCV4 folder on whichever drive you installed it - and make a back-up (just in case);
    2. Open the m5.csv file using Notepad or a similar text editor - DO NOT use Excel or a similar spreadsheet - and scroll down until you find the data line for EGBB;
    3. The line should look like this - 'EGBB,561,4000,B'. Change the value of 4000 to 6000 so that the line now reads 'EGBB,561,6000,B';
    4. Scroll down and make the same change from 4000 to 6000 for EGBE and EGNX;
    5. Save the file.

    That's it. It's very straightforward but it's worth reiterating, though, that you must use a text editor and not a spreadsheet to edit and save the m5.csv file.If you're not confident about doing this, you can also change the value of the TA manually when you load your flightplan into RC but, you've got to remember to do it and what the value is - changing the m5.csv file means RC will do it automatically.Also, if you haven't previously made the amendments for EGFF, EGHH, and EGHI which have already changed from 4000ft to 6000ft you could take the opportunity to do that as well. Finally, whilst looking through the m5.csv file I notice that EGNM is incorrectly shown as 4000 - it should be 5000 so you might like to change that too using the method detailed above.Pete

  4. Now that's a question that's set my old grey matter whirling! Dave. It's so long since I designed the non-US altimetry system used by RC4 - at least 6 years ago, possibly longer - that I honestly can't remember what, if anything, I did about it. I clearly remember explaining to jd the possibility of that situation occurring and suggesting the phrase "adjust to FLxx" or "QNH xxx adjust to altitude x thousand ft" but I don't think we implemented it. I think the consensus was that the amount of work to be done on the program to deal with it was out of all proportion to the number of times it was likely to happen, so, the en-route phase was left 'as-is' and the 'problem' was dealt with, as you found, in the approach phase. Maybe jd can check the code but I think that's the situation.In the real world, it's much simpler to handle with the controllers involved issuing the appropriate pressure setting and initiating the level/altitude adjustment. You'll also find there's usually transition areas (or buffer zones) either side of a boundary where these changes take place. Simple to handle in real life - much more complicated in a computer program.Pete

  5. Is there any scope for doing this for personal use with RC?
    There certainly is' date=' John - in fact, knowing your expertise in this area, I've been tempted to contact you through CBFS on several occasions about this very thing. One of the former RC beta team members, Graham Jackson, has released several sets of additional call signs and airport names for RC4 with, by his own admission, varying degrees of success depending mainly on the quality and suitability of the wavs used to produce the new call sign file.The process itself is very straightforward and involves just 2 stages - editing existing wav files to produce the new file in the appropriate format (11KHz, 8-bit, mono if my memory serves me correctly) and adding a data line to the c4.csv file. You'll find this file in your RCv4/data folder. If you want to have a look at it, please note that despite its .csv suffix, it's a simple text file and should be opened (and edited) in a text editor such as NotePad and [u']not[/u] a spreadsheet! The main problem with the process is the sheer number of wavs that need to be edited to produce just one new call sign set because it has to be done for each of the pilot and controller voices but, as Graham has shown, it can be done - it just depends whether or not you have the time and inclination. :( If you want to know more or have any other questions about RC why not PM me via CBFS.BestPete

  6. This is kind of important to me since I belong to Thompson Virtual Airline and I fly as Thompson (sic) all the time, I just bought RC4 yestearday and I found that my airline is not there which was a litle anoying I must say.
    I'm sorry you're annoyed at the omission but, as has already been pointed out, the Thomson call sign did not exist when RC4 was released so it's hardly surprising it's not there.It is perfectly possible to add new call signs to RC4 - however, as it involves modifying and combining existing .wav files in sound editing software and adding new entries for all the controller and pilot voices in the c4.csv file, it's not something that can be done in a few minutes. The zip you mention, "uk_airports_and_callsigns_2.zip", was produced by Graham Jackson who was a member of the Radar Contact team at the time he made the new files and he's done all the hard work for you. As I mentioned above, the new call signs have been produced by combining parts of existing wav files so don't expect perfection - the end result depends on the suitability of the original files and the results can vary from voice to voice. That said, I find the "Thomson" wavs at the very least acceptable and often, very good.As this call sign seems important to you I suggest you download and install the file as it's your only real option for RC4. If you follow Graham's instructions, everything will be put in the right place for you. One small point that Graham doesn't mention in the readme file, though, is that the unzip process installs a new c4.csv file. It would be a sensible precaution to back up your existing c4.csv before installing the new files.PP

  7. if you were on a collision course, the ai would be vectored away from you. in rc, you don't have to do anything.
    Excellent, you learn something new everyday. I could have sworn you dropped the ai vectoring routines ages ago but, obviously not. Thanks for putting me right. Pity you replied so quickly though - I was hoping to be entertained by some amusing answers along the lines of those posted in the current "250kt speed limit" thread. I see even CAP393 got a mention there! :(

  8. But on that note, I was wondering if there is a table of values somewhere. So that if RC says something like 1016, I know exactly what the inch value should be. It seems the rounding of those values somewhat follows its own rules, hence the need for an aviation source. Does anyone know of such a thing?
    I certainly do. Here's a hectopascals/millibars to inches of mercury conversion table I did some years ago. I think it's exactly what you're looking for.Pete

  9. I sometimes get a little irritated by RC ATC when it keeps giving me traffic advisories for traffic that is one or two flight levels above or below me. Do I really need to know this? Does this happen in real life or is it just an RC thing?
    Iain, I can understand your irritation and no, you really don't need to be given that sort of information on correctly separated aircraft - regardless of whether or not you're in RVSM airspace - in level flight or even climbing or descending to correctly separated levels provided that separation will not be lost at any stage. This applies in the real world on this side of the Pond for aircraft operating in regulated airspace where all traffic is known and notified and is in receipt of a control service (there are other types of service available from ATC, of course) which is what RC4 and earlier versions assume for the en-route stages of the flight which is when you'll get these messages. The only reason we would give a "traffic advisory" to properly separated aircraft would be if there was some specific advantage in doing so - otherwise it is just a waste of valuable RT time! It might, of course, be different in the States - and you have to remember, here, Radar Contact's American origins. Although it's made great strides towards internationalism (if I can put it that way) in versions 3 and 4, there's still an awful lot in it that's "pure Doug"! :( In the interest of balance, I should mention that what I said about not giving traffic information on properly separated traffic only applies in the real world to the type of regulated airspace I described and which RC assumes for its en-route phase. In other types of airspace (not simulated by RC4) where not all traffic may be known or notified or operating under a control service, it may well be appropriate to pass traffic information on separated traffic which, of course, may well not remain so. I can also mention that the phraseology used by RC4 differs from that used in the UK, for example, in as much as - for safety reasons - we never state the actual level of the traffic but use a relative description such as 1000ft above, 2000ft below and so on. Again, the US may well be different.It would, of course, be improper for me to reveal information that's been discussed in the private beta team forums but I don't think it'll be breaking any confidences to say that this difference in procedures and phraseology has been "flagged up" several times but it has to be allocated time and priority with all the other changes/improvements being considered so it may well be a while before it floats to the top. Will it be important enough to make it into V5? Only jd can answer that.To finish, just a little fun. If you can tell me exactly what the phrase "traffic ten to eleven o'clock" means, I'd really love to know! :( Pete

  10. How come in RC after FL410 it starts going up 2000 ft at a time? ie FL410, FL430, FL450,FL470 etc etc ... is this an error or something that has to do with real world procedures
    It has everything to do with real world procedures. In RVSM (Reduced Vertical Separation Minimum) airspace, which RC assumes by default, standard vertical separation up to and including FL410 is 1000ft. Above that level, it becomes 2000ft so the next available levels are FL430, FL450, FL470 etc. RC was just following the rules. Incidentally, outside RVSM airspace, standard vertical separation is 1000ft up to FL290 then 2000ft above that so the next available levels above FL290 would be FL310, FL330, FL 350 and so on.Pete

  11. Essentially, Iain, it comes down to the fact that there are only 4096 codes available for all uses and a significant number of those are reserved for special purposes, further reducing the number available for general use - i.e. there are more aircraft flying around at any one time than there are codes for them to use.To help with this problem, ICAO has set up a scheme called the Originating Region Code Assignment Method (ORCAM) which divides the world (other than the US which does not participate in ORCAM as far as I know) into regions, each of which has its own allocated block of codes. There are so few codes and so many regions that codes have to be repeated in different regions but, wherever possible, adjacent regions have different codes for their own use. So, in theory, you can make a flight within a single region and, often, in 2 adjacent regions without having a squawk change but for longer distance flights which take in 3 or more regions, at least one squawk change may be necessary.There are occasionally other (usually ATC operational) reasons for a squawk change becoming necessary even for a flight within a single region but, in essence, it all comes back to my opening statement that there are more aircraft around than codes available under the present Modes A and C system. With introduction of Mode S, which has 16,777,214 individual 'addresses' as they're known, this problem will disappear.Pete

  12. I'm with you there! I've never understood the joke! :(
    It's not really a joke, more a barbed comment. It's along the lines of the controller has saved the pilot from the extreme embarrassment of making an "arrival" with the wheels up so the least the pilot can do in return is to buy the controller dinner. It's not a very professional thing to say - it's what's known in the beta team as a "Doug-ism" - and would certainly have been frowned upon by my former employer but we're all human and there can't be many controllers who've not made some sort of similar caustic comment about a piece of pilot idiocy.Incidentally, I'm not sure what went out with version 4 but when these wavs were first recorded, beta team members were permitted to ad-lib their choice of reward so there were a number of variations on the steak meal.Pete

  13. You're right, Chris, it has been raised on the forum before (and by me in the beta team) and Phil, you're correct when you suggest RC's giving of traffic information is based on US-practices. The reason, of course, is that RC started life as an American ATC program with more and more "internationalisation" being added to each subsequent release. However, these changes have to take their turn with all the other new and improved aspects of RC - ground taxi instructions, SIDs and and STARs etc. - and this particular improvement has not reached the top of the pile yet. I'm sure it will at some time but only jd can tell you when. :( As far as the real world goes, I can't comment specifically on US procedures but, certainly, in the UK, the amount of traffic information issued depends on the type of service (and ATC services are many and varied) that you're receiving. Outside controlled airspace, providing, say, Radar Advisory or Radar Information Service (those names and services are changing soon but the principle remains the same) passing traffic information is the name of the game for the controller but on an airways flight where all traffic is known and notified it's much rarer to pass traffic information. As RC doesn't know about these different types of airspace and services, all flights are controlled on the basis of being on airways under Radar Control which does, indeed, mean that far too much information is passed for UK/European practices.As an airways controller, I only ever gave traffic information when I felt there was a worthwhile advantage to be gained from doing so. Usually, this involved safety - for example, a "belt and braces" check that climbing and descending aircraft knew why they had to stop off at a particular level if they would be in close lateral proximity to the conflicting traffic and, latterly, to (attempt to) prevent the nuisance RAs caused by high rates of climb and descent in crowded areas which has already been mentioned. There is no requirement (in the UK) to pass traffic information on separated traffic as our American colleagues seem to do - to me that's just a waste of valuable RT time - but, if it is passed in this situation, we always avoid direct mention of the actual levels - FL120, FL290 etc - but pass them only as relative positions - 1000ft above, 2000ft below etc - to avoid any possibility of a misunderstanding.Pete

  14. What am I doing wrong? Am I just too slow? Should I acknowledge only after having set the parameters on the autopilot?
    No, you're not doing anything wrong - it's RC that's at fault here. As ratata has already posted, the workaround is to start your descent/begin the turn before you acknowledge the instruction. Not real world, I know but it keeps RC's over-zealous "watchdog" quiet as the timer doesn't start until you acknowledge.As far as I know, if it hasn't already been put right in v5, it's on the list to be fixed but I'm sure jd can give you the definitive answer on that.Pete
  • Create New...