Jump to content

Adam Lagoda 827397

Members
  • Content Count

    10
  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. What is funny in some of the last posts on the topic, most of them are the one "to sit and cry" rather than to sit and laugh. People making stupid mistakes all the way... Well, to stay on target and bring a little of fun there. It happened to me once over German airspace, I was heading towards Warsaw on shortcut. Bremen CTR (I guess it was Florian) gave me a standard traffic info. I answered "in sight, p[Mod - Happy Thoughts]engers waving". And I thought it was quite funny, so when receiving handoff to Warsaw a few minutes later, I answered again in the same manner: "Going over to 13
  2. Callum, I get the point and I get the point in properly painting the picture before action taken. Note taken, and proper wallop on my side to use. However, the problem usually (Murphy's law here) arises when I'm really busy. Have a bunch of planes in CTR, two or three doing final for rwys on controlled (by CTR) airport. I'd like to give a proper recognition to SUP, and usually I'm not calling for help when it's not needed. But in case of large traffic, it's either traffic, or SUP I can answer. No time to answer both. What bothers me much, is that choice I have to make. When it's easier
  3. I'd love to point out two things as a sidenote. I think the whole network would benefit if there was a bit more understanding for controllers calling the Sup. I've had a call lately that I had to cancel myself (newbie pilot logging at rwy - reverse to runway in use - taking off with no response). It turned out he answered with delay (after pausing plane 3nm from rwy, sic!), and I had to release SUP I called before. Easy to judge it was not needed, but on the other hand - how much do I wait? 30minutes? And other side note - I was lucky to be TWR mentor. Trainee took the time controlling
  4. This cut in quality is exactly the same as was in telephony, or old ISDN telephony systems. There's some math behind this, but the voice quality you transmit with digital channel depends on two things: dynamics (how many levels of membrane move in speaker are allowed), and frequency range you want to transmit. The more you expect from both, the more bandwidth it takes. Typical telephony is cut at 256levels (1 byte per sample) and 4kHz (8000 samples per second), equalling to 8kBytes per second. If you wanted to change that to DVD quality, you put 2 bytes per sample, and 44.1kHz (let's forget ab
  5. I'm not familiar with way Vatsim makes coding/decoding, BUT there is always one option. It's more difficult (or actually time consuming) for the developers, but the only one to make smooth transition. I [Mod - Happy Thoughts]ume, that vatsim is working like every other voice room - it [Mod - Happy Thoughts]igns the port to connect to, mixes the streams from all connected and sends back (simplified). So, the only other solution would be to take more modern technology (actually, same voice coding technology with higher bandwidth I believe - you can't do much if bandwidth stays the same,
  6. I know it shouldn't. I also know it does (last Warsaw Overload an example). I also did some tests with both E and W, and it takes a lot of movement to the east (or to the west from Poland) to interfere. That's why I opted for leaving things as they are, and asked my fellow controllers to check once we have that sort of interference again, to see if it's a problem of setting vis1..4 to the East. Adam
  7. Miguel, your guess was right Yesterday I managed to run some checks. On standard, both stations do not interfere (with quite a margin, I moved my vis2 from Mofdlin to Poznan, by nearly 200nm with no effect). However, if station Bremen A serves as B as well (to provide ATC on all areas of ATC zone which is more-or-less rectangular with width twice as big as height), it's quite usual for them to set up another visibility point over eastern Germany, and that's most likely causing the problems. We'll work together with German ATCs to see whether it can be solved by small steps. Thanks every
  8. Ross, Mike, Migues, Thanks for confirmation. Is that also centered around visibilty points? Hopefully, this is the solution then - to properly use vis1..vis4. Thanks again. Adam
  9. Thanks Neil for your answer, and sorry if my English is out of standards - I've been using this mostly with european teams, and - as you probably know - European English is nowhere near English English standards So, there are no separate ranges for scope and radio? If so, that's confusing. In Poland, there's a station at Modlin (TWR), using the very same frequency as Bremen CTR. As Modlin is more or less 300nm from the pl-de border, one would [Mod - Happy Thoughts]ume they will be completely independent. But what we learned from those few times Modlin was manned and Bremen online - they'r
  10. Hello, I have a question - on the topic, I guess. There are two types of range on client ([Mod - Happy Thoughts]ume EuroScope as it's the most popular one) - scope range and audio range. The first one is regulated by range we have set in client while connecting. The other one is - from what I've learnt from Miguel, VATEUD8 - fixed, depending on station set. Example - CTR - 400nm. Is that correct? On the other hand, the "visual" range might be otherwise regulated using vis command. Both in terms of center point, and range (using subset of vis1..vis4 - if properly set, it nearly doub
×
×
  • Create New...