Jump to content

Andrew Wolcott 814793

  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. Because text data takes up so much bandwidth from the year 1999 Seriously question from someone who doesn't know..., how much bandwidth would 500 aircraft position (lat/long, heading, track, altitude, vertical rate, horizontal speed, pitch/roll ) updates use, per second? How large would each packet be per aircraft and what would be the bandwidth needed for both I/O operations at the server AND the client level? I'm sure it doesn't work like this, but I made a text file containing 500 rows of data representing aircraft positions. The file is 28KB. If you transmitted this data to one
  2. I'm doing some testing regarding multiple radars. The idea essentially is to define multiple radars with differing ranges, elevations and slopes to create the radar deadzones. Basically it's creating blackholes between radar sites. While this functionality will work in vERAM, it will only work on vSTARS using multi-site mode, which changes the datablock and tag representation. Comparing aircraft position to a digital terrain model (these are free) should not be that difficult I would imagine. I've been a proponent of Ross developing "Stock Radar Types" which can be selected by
  3. UPDATE: Turns out this was a Windows DPI issue. I returned it to the default (100%) and all is working normally. I've no idea what is wrong. I updated to the latest vERAM version and now I receive this error upon selecting which facility I want to load. It doesn't matter which facility I try to load. Specs: vERAM Version: 1.0.5901.33343 Operating System Windows 7 Ultimate 64-bit SP1 CPU Intel Core i7 3770K @ 3.50GHz 38 °C Ivy Bridge 22nm Technology RAM 16.0GB Dual-Channel DDR3 @ 666MHz (9-9-9-24) Motherboard ASUSTeK COMPUTER INC. P8H77-V LE (LGA1
  4. Average closure rate across the ground between JBU412 and N420 is Mach 1.8! Average closure rate across the ground between JBU412 and MT277 is Mach 1.65!
  5. Nothing wrong with attracting pilots, and the action in and of itself is not damning the controllers. However, how about not being so pilot centric? Or, in better terms, why is there no impetus to require training for the pilots? It's one sided, and THAT is the reason controllers complain. "We have to do this, so why not the pilots?" When something like this proposal comes along Brian, we as controllers have the tendency to feel we are not as important as the pilot numbers. Okay, so this is an attempt to address retention of C1s. I'm not sure how that works in the long run honestly. But as
  6. Umm.. that was done, by the founder who proposed this in the first place, without the knowledge, notification, heads-up or consent from the ARTCCs involved. Go read the entire thread, seriously. Unless I've misunderstood your idea of making a test, it seems like you may have missed that this was being tested, by a founder, on his own, with no one but himself and maybe one or two others knowing about. The ARTCC Staff were NOT involved.
  7. Callum, Open you eyes. Read the other threads so many of us have posted in. The main reason we have a problem with this proposal is that once again the founders believe they know what's best to serve PILOTS on this network, and damn the controllers. Sure, we give reasons for why we do not agree with the proposal, such as realism, confusion, etc... But the fact remains that this is yet again something that is wholly pilot centric, limited to a handful of people of the controlling side, and the negative aspects such as a system to oversee the training and administration of the "super cen
  8. And for those who don't read the VATUSA forums, here is the proposal: http://forum.vatusa.net/index.php?showtopic=3213
  9. I just want to point out two things I consistently see in this thread: Pilots, pilots, pilots, pilots, pilots, pilots, pilots, pilots, pilots, pilots and Founder, founder, founder, founder, founder, founder, founder, founder
  10. Just throwing this out there... Draw up an agreement with your neighboring ARTCCs to allow your center rated controllers to work the adjacent ARTCC airspace FL240 and above. Have it be an LOA between participating facilities. I'm not sure how it would be decided that ZOB gets ZAU over ZMP, but I would rather keep this agreement between ARTCC staff. There are nights that I'm working MSP_CTR and CLE_CTR is open, but CHI_CTR is closed. I'll have an overflight through ZMP landing in DTW that I could just keep on frequency. But, if a ZAU controllers sees me tracking in ZAU airspace,
  11. There is actually a thread regarding this proposal in the VATUSA ATM/DATM forums. To show that realism is not the only issue being discussed I am reposting my initial reply to the thread in the VATUSA forum:
  12. If ever there was a proposal that I thought I could get behind this would be it. Barring network limitations I think a discussion on this would be interesting. But again, training standards across the ARTCCs may become an issue, and I could only see this work if a controller were fully certed on each ARTCC (including majors) he/she was logged in as.
  • Create New...