NYC Scanner Infrastructure Mailing List
For notices and alerts about our infrastructure, including scheduled maintenances or unplanned outages, please fill out your email below to subscribe.
Interest has also been expressed for messenger groups (including separate chats for system notices, jobs, and off-topic discussion). We were about to make a Signal or Telegram or WhatsApp groups, but if you have a preference for another platform, please let us know!
We currently serve the following systems, with more to come!
NY NYC Conventional
https://openmhz.com/system/fdnyemshttps://openmhz.com/system/fdnyfirehttps://openmhz.com/system/nypd *
https://openmhz.com/system/nymac* some channels degraded or missing, looking for a suitable Staten Island site and yet another Brooklyn site
NY NYC P25
https://openmhz.com/system/nycp25uhfhttps://openmhz.com/system/nycp25131NY Westchester County TII
https://openmhz.com/system/bd021https://openmhz.com/system/bd022NY Westchester County P25
https://openmhz.com/system/a6611https://openmhz.com/system/a6612NY Nassau County P25
https://openmhz.com/system/bee001ae11https://openmhz.com/system/bee001ae12Q: so-and-so NYPD channel isn't working or sounds bad.
A: That's not a question! But if it's an NYPD channel, we probably already know about it. We don't have perfect citywide coverage yet, so some division radio zones sound bad, or we're outright missing them (especially Staten Island and some parts of Brooklyn). We're testing some additional sites but haven't found one that works for us (either too much local noise, strong RF neighbors, or doesn't have good coverage of what we're missing). So if you know a place, please let us know!
NYPD Missing:
9: CW - OCCB 1
14: MN - WTC
15: MN - 1-5-7
28: BX - 47-49
34: BK - 67-71
37: BK - 77-79
38: BK - 81-83
39: BK - 84-88
40: BK - 90-94
NYPD Degraded:
4: CW - CW 4 (squelch needs to be tuned tighter)
10: CW - OCCB 2 (squelch needs to be tuned tighter)
12: CW - CMD (squelch needs to be tuned tighter)
13: CW - IAB (squelch needs to be tuned tighter)
33: BK - 66-70 (high noise floor but acceptable)
53: TB - TBBX (high noise floor but acceptable)
Remove:
32: BK - 62-68
34: ? don't see it, double check
35: BK - 72-76-78 (low signal)
37: ? don't see it, double check
38: ? don't see it, double check
39: ? don't see it, double check
40: ? don't see it, double check
41: ? don't see it, double check
42: ? don't see it, double check
49: QN - 110-115 (overdriven?)
50: SI - 120-121
51: SI - 122-123
52: TB - TBMN
61: PB - PBSI
62: PED - PED MN
63: PED - PED BX
65: PED - PED QN
Q: How many appliances/servers/sites are you running?
A: We have physical presence (including roof access) in 2 datacenters, and regular presence in 1 more. We also have a handful of appliances (a bunch of servers, SDRs, and network equipment packaged together) in a few locations. We got really lucky with one site owner who's right next to a DoITT site in a RF quiet area, which is why FDNY EMS, FDNY FIRE, and the trunk sound great. We're thankful for the site owners at (so far) all the sites we're in, who've let us install antennas and equipment for free. Sorry about all the holes and wires, but it's all for the sake of R56! Thank you!
Q: How do you manage so many sites and appliances?
A: We try to encapsulate as much of the appliance internal environment so that sites only need to hand off power, network, and physical space to us. It doesn't matter that we're double or even triple NAT'd, since we transit management network ourselves. Servers are standardized as much as possible, which makes provisioning and continued management easy. With SDRs involved, sometimes servers will need "local" intervention, but if we had to go physically every time, we'd have no free time at all. This is why we made out-of-band remote management (iDRAC, iLO, BMC) a non-negotiable requirement in our hardware family. We're also adding cellular out-of-band network management a requirement to our network environment standard across the board at every site, regardless of site network quality and availability. This allows us to better diagnose network-only outages before bothering a site contact to reboot or unplug/replug something.
Q: How long does OpenMHz keep archives for?
A: OpenMHz archives as best-effort, which comes out to about 1 month back currently.
Q: Do you archive?
A: We do. We started the archives in about November/December 2020 and have been adding channels and systems since then.
Q: How long do you keep archives for?
A: We have no retention policy in place, which results in indefinite retention of files. We don't intend to implement one unless storage costs start to get ridiculous. We have a signed SLA with Google for a minimum of 99.9% operational availability, anything less for which we get a refund for services not provided. In practice however, Google tends to reach their design objective of 11 9's.
Q: Can I get access to your archives, and how?
A: Yes, we're happy to provide access to anyone who asks nicely. Extra points if you're working on a cool project! Subscribe with this form, and in the notes, let us know you want access to the archives. Files are accessed via Google Drive using Enterprise "Shared Drives" (or in former nomenclature, "Team Drives") so it will be best if you have a Google user or service account.
Q: Why don't you feed Broadcastify Calls?
A: We already feed OpenMHz. OpenMHz pays volunteer providers a reasonable percentage of what it receives in revenue from listeners. $0 all the way through!
