>100fps or so is way above the threshold of about 20 frames per second
Bullshit. Period, full-stop, boldface, italicized, and surrounded in BLINK tags.
Your corneal surface isn't equally sensitive to flicker. Rod-dominated peripheral vision is several orders of magnitude more sensitive to motion and flicker than cone-dominated foveal vision. In terms of framerate or high-contrast flicker, the magic point at which literally nobody can tell the difference between N and 2N (where "N" = "framerate in hertz") regardless of which part of the eye it strikes, its brightness & contrast, and the amount of frame-to-frame change, is somewhere around 400fps/Hz (slightly more for some, slightly less for others). Now, you don't literally have to go quite THAT high to have a satisfactory viewing experience with most content, but if you really want to split hairs and look for edge cases where people can reliably tell the difference in double-blind tests... that's approximately where it is. WAY above 20fps.
The ONLY reason why 24fps (motion picture film) presents any kind of illusion of motion is because film's analog nature encodes additional higher-order information into it in the form of motion blur and other artifacts. I can guarantee that raw, razor-sharp blur-free high-contrast 24fps video is VERY unpleasant to watch, even if you independently take care of flickering so it appears as a sequence of sequential solid images.
And yes, somewhere between 5-20% of the population (slightly lopsided towards males) ARE more sensitive to flicker. It's been studied, documented, and quantified. The number is well known to monitor manufacturers... they just don't care. The best we can hope for is some future backlight ASIC whose behavior can be tweaked by end users via I2C, even if the manufacturer of the monitor itself doesn't lift a finger to support it. Then some bean counter in management will decide he can shave 1.7 cents from the manufacturing cost by omitting the pullup resistor needed for the I2C bus to work, and we'll be fsck'ed again.
IMEI-cloning isn't "rooting" -- it's "IMEI cloning", and if convicted, it's just about the most heavily-punished illegal thing you can possibly do with a mobile phone in America without causing somebody to die. And if you're caught, you almost certainly WILL be convicted, because all the prosecution has to prove is that you did it (no need to prove criminal intent). For prosecutors, it's a hole-in-one easy victory they can assign to their summer intern and let him score a guaranteed win.
More importantly, there's NO NEED to clone an IMEI to use a non-Verizon phone on Verizon. Contrary to popular myth, Verizon WILL allow you to activate non-Verizon phones. HOWEVER, they literally won't lift a finger to help you, or even furnish you with the most trivial of information you'll need to make it work... and if you accidentally create denial-of-service conditions while trying to reverse-engineer something, or incompletely-implement something important, yes, they WILL terminate your service on the spot.
To nontechnical people, that might sound like what the OP said... but there IS a subtle shade of difference between banning something outright, vs allowing you to try, then punishing you for nearly-guaranteed failure.
Now, if you're trying to activate a phone Verizon blacklisted for being stolen or from a broken contract with unpaid ETF, that's another matter. At least Verizon, unlike T-Mobile, won't tell you that a phone's IMEI/ESN is "clean", then turn around and blacklist it anyway -- without recourse -- 3 months later. That's something T-Mobile is INFAMOUS for doing, and it's gotten them a LOT of well-deserved hate. Here's how it happens: A T-Mobile customer buys a subsidized phone, then sticks the SIM in his old phone (or a different phone) and sells the subsidized phone to someone else. The buyer calls T-Mobile, checks the ESN, verifies that it's "clean", buys the phone, and happily uses it as a T-Mobile customer (possibly prepaid) for months. Then, for whatever reason, the original buyer walks away from his contract without paying the ETF. Within days or hours, your phone quits working, and when you contact T-Mobile, they tell you that you're SOL unless you pay the ETF of the guy who sold the phone to you several MONTHS ago. Sprint/AT&T/Verizon don't do this. They won't allow you to newly-activate the phone once it's been blacklisted, but they'll grandfather you in if the phone was in use long before the blacklisting occurred.
Unfortunately, there ARE a few places where Verizon IS pretty much your only viable option for wireless data that's faster than 250kbps indoors. Most of those places have solid AT&T coverage, but only have EDGE-speed data. Sprint is nonexistent in those areas (they just let you roam on Verizon & drop you if more than 50% of your use is roaming), and T-Mobile isn't even a wild fantasy.
If I recall, the biggest area where this tends to be the case is hardcore-rural central Pennsylvania, extending down into the Smoky Mountains & Appalachia. It's not the WHOLE area, but that's the area that seems to get mentioned the most as one where AT&T decided to just let Verizon have anybody who wasn't happy with EDGE.
It goes against what most people believe, but CDMA phones actually CAN have significantly greater range than GSM (even though that's rarely the case in urban environments, especially with Sprint). Due to the way legacy TDMA-based GSM worked, it literally hits a brick wall at around 30 miles. Further than that, and the phone won't work... period, end of story. Not even with a high-gain yagi or dish on a fixed tower. Legacy GSM timing was literally carved in stone, and beyond ~30 miles, it conflicted with the limits imposed by the speed of light and just quit working. CDMA's spectral efficiency goes down the toilet in far-fringe rural coverage areas, but if push comes to shove, you can shove an 800MHz signal a lot harder & farther than an 800MHz TDMA-based legacy GSM signal.
That's why Canadian mobile phone companies (mostly) started out with CDMA, and kept CDMA as their fallback voice/data mode even after choosing HSPA for high-speed data. Legacy GSM would have been unusable in many parts of Western and Northern Canada where CDMA voice (and 1xRTT data) works perfectly well. Australia had the same problem with phone service in the outback, and rural Australians were FURIOUS when their urban overlords decreed that everyone was moving to GSM (HSPA is WCDMA and can be coaxed into working in rural areas with a fixed high-gain antenna and high power, but WCDMA is still more demanding than oldschool IS95 CDMA and CDMA2000-1xRTT).
> if Verizon catches wind of your rooting, you'll be dropped like a call on Sprint and be out the cash you spent on both devices.
No you won't. Verizon might be evil control freaks, but not even THEY will terminate you just for rooting your phone.
That said, be aware that your likelihood of getting any phone not sold by Verizon to ever be fully-functional (especially EVDO and LTE), on Verizon is close to 'nonexistent'. People have occasionally found ways to reflash Sprint identical twins of Verizon phones with Verizon radio modems, but if you ever got a completely "alien" non-Verizon CDMA phone to do full-speed EVDO on Verizon, it would make headlines over at xda-developers.com. Radio modems are an entirely different beast from Android phones (which contain radio modems, but interact with them at arm's length).
Steel has no problem with compressive strength, it's just a lot more expensive than concrete.
It's not just cost. If you formed a freeway support column from a solid block of steel having dimensions of 5x10x40 feet, it would be impossible to transport to the site or place into position, and even more impossible to join to anything comparably large. You simply couldn't get the middle part of the contact points hot enough to weld, without damaging the structural integrity of the remainder of the beam/column while doing it.
In the real world, steel beams have to be some variant of a tube, box, I-beam, or C-channel/stud to enable them to be placed. The problem THEN is that many steel arrangements can't even support their own weight until they're all fastened together, and if something pushes them far enough to kink or bend, they fail rapidly and completely. For example, a futon made from steel tubes might be very strong, but if someone heavy falls into it, the whole thing can collapse the moment the first tube gets even slightly bent. However, there's no rule that necessarily says the steel HAS to be on the inside. For example, you can mount a hollow pole, then fill it with very runny concrete grout to give it compressive strength and minimize things like buckling.
(other combos possible; though most would agree that the obvious alternative would be 10, 11, 00, and 01 (in order) for the choices above).
You can also represent all known Morse characters as 8-bit bytes by establishing a rule that 0=dit/short, 1=dah/long, and the last one is whichever value (0 or 1) differs from the least significant identical bits. Ex:
e = . = 01111111 i =.. = 00111111 t = - = 10000000 a =.- = 01000000 5 =..... = 00000111 ? =..--.. = 00110011
I believe both schemes are used in the real world... the first to represent Morse as received, the second to encode the lookup tables.
I doubt whether it would help. Since Roman concrete can't be steel-reinforced, it would just crumble if ice heaved it upwards because it wouldn't have steel inside to hold it together. It wouldn't help with cracks, because even concrete roads are still surfaced with a few inches of asphalt (at least, in Florida... maybe things are different "up north"). AFAIK, the endless annual resurfacing would still be necessary, because 99% of the potholes and cracks are in the top layer of asphalt, not the structural concrete roadbed below.
Where the Roman concrete might be MORE useful is environments like causeways, by providing a hard shell around the structural foundation that protects it from erosion. Where it might become a bit dangerous is if it ends up protecting the structural reinforced concrete from VISIBLE damage, but doesn't prevent the steel from rusting away on the inside until its tensile strength gets reduced to the point of being dangerous even though it "looks fine" on the outside.(*)
(*)For those who don't know, reinforced steel consists of steel bars + concrete because concrete has tremendous compressive strength, but terrible tensile strength. Apply force in any direction besides straight down, and concrete just breaks away or crumbles. In contrast, steel has a lot of tensile strength (it tends to stretch and bend rather than snap), but terrible compressive strength. As a matter of good luck, steel & concrete have mostly identical expansion rates when heated & cooled, and form a very strong chemical bond to each other (get concrete splattered on your car, and once it dissolves the paint and makes contact with the steel body it's NEVER coming off). The combination allows concrete to provide the compressive strength, and the steel to provide the tensile strength. Without steel, an elevated freeway would have to be built from arched vaults. With steel, you can support it with flat beams. Of course, if you approximate a "classical" form like an arch, you'll be working WITH the concrete and adding strength, but steel is what allows us to build things like a 40 foot road deck cantilevered from a single support column, or support a skyscraper like Citigroup's midtown headquarters from support columns that are located in the middle of each wall instead of at the corners.
AFAIK, yes, it can be patented. And that's perfectly OK. Roman concrete wasn't a useful art, it was a lost art. At least under the official theory of American patent law, patents exist to promote advances in useful arts, not to merely grant a monopoly over some abstract artistic right. "Prior Art" isn't just something that EXISTED... it's something that existed, with documentation that would have allowed somebody ELSE to re-create it. Without that documentation, Roman Concrete was little more than a mere idea... maybe a half-step better since it was more like a "proof of concept", but the fact that substantial effort was required to re-discover and document it IMHO does make it patent-worthy.
Now, if Cemex (or some other company that makes concrete) gets sued for infringement 14 years from now, and shows up in court with some ancient, long-lost and recently-rediscovered Greco-Roman document with the formula, they'd have a solid case for overturning a modern patent on it.
Before somebody brings up "first to file", I should point out that if I invent and document something, but someone else beats me to the patent office, I might not be able to get the patent transferred to ME, but I can certainly show up late and spoil the party for THEM. In a way, "First to File" opens the door to trolling trolls... if you invent something, but don't necessarily think it's worth patenting (or have the resources to secure that patent), you can abundantly document it (possibly via digital notarization), then just sit on your notes. If somebody ELSE gets a patent, you can demand that they give you a cut of the royalties they collect, and threaten to go public with your own prior art and spoil their party (after they've spent hundreds of thousands of dollars securing the patent) if they don't.
Ouya doesn't quite count as a "console platform", because the amount of work a developer has to do to publish a game that already exists anyway for Android to Ouya is borderline-trivial compared to the amount of work a developer has to do to publish a game for, say, Wii.*|Xbox.*|PlayStation.*|PS.*
That's part of the reason why in the long run, Android is likely to be a more lethal threat to the console ecosystem than ANYTHING Nintendo, Sony, Microsoft, or anyone else can come up with. Android games will exist regardless of whether there are zero, ten, or 300 different Android consoles ranging from Ouya++ to nameless HDMI sticks from Shenzhen.
Ditto, for Microsoft. Microsoft is hellbent on having SOMETHING in your living room, and if push comes to shove, they'll try to convince DirecTV to make them part of their new satellite boxes going forward.Microsoft has enough cash to slog on almost forever.
Sony won't abandon a cash cow, but Nintendo's the most likely of all to stick it out to the bitter end, just because they don't really HAVE a "plan B". Sony can make Android phones & Android STBs, and still feel like it has saved face. By any sane standard, Nintendo should have had a dozen Gameboy phones by now, but unfortunately they're one of the most visible casualties of Japan's mobile phone market -- a market so proprietary and closed, it makes America's look like the shining light of robust pro-consumer open choice by comparison. Nintendo has an international market, but their strong Japanese roots & closed domestic phone market have kept them from ever seeing phones as a viable business opportunity.
Anybody who thinks ARM is remotely close to matching x86 performance should try this little experiment: get a 7-8 year old notebook like a Dell D600 w/1.6GHz Pentium M, install Ubuntu on it, and compare it side by side with any ARM netbook that has a CPU of comparable nominal speed, plus comparable ram and storage, and has the same release of Ubuntu installed on it. Configure both with identical desktop settings, and run the same apps (compiled for the proper architecture, of course). The 7 year old D600 will beat the ARM laptop like an unloved child in a trailer park.
Yes, if you have the resources of IBM or Samsung, you could cobble together a pimped-out ARM that's in the same league as a low-end x86-64 CPU... 2GHz+, multi-core, lots of cache, with speculative & out of order execution. The works. And if you do, congratulations... you've just invented a CPU with the computing power of a Pentium IV, but the slightly lower power requirements of a mobile Athlon 64.
There's no free lunch, and ARM is neither holy nor magic. If you take ARM on its own terms and use it appropriately for things that don't need a lot of computing power, it works well. If you try to pimp it out and cobble together an ARM-based PC with the raw performance power of even a lower-end modern x86-64 PC and use it to run the same (but recompiled) apps you'd run on a regular PC, you end up with an abomination that has all the drawbacks of ARM with none of its benefits.
> Today's phones beat the living shit out of machines I still use.
Don't be too sure. Megahertz-per-useful-act, anything from the Pentium-M (really, a Pentium III Xeon w/power mgmt) still totally spanks ARM7, even in dualcore-for-Android form (between power management & poor handling of apps not explicitly written to be SMP, a dual/quadcore Arm Cortex almost might as well be single-core). A 1.5GHz Krait running Android is roughly comparable to a 1Ghz P-III running XP in perceived performance. Yes, you can find optimized examples that give a dualcore Krait or quadcore Exynos a sligha edge, but x86/AMD64 cpus are *profoundly* optimized for getting good performance out of mediocre software under sub-optimal conditions compared to ARM7.
HD dashcams? Nothing new. 60fps HD dashcams? New. Very, very new.
The cameras have been around for years, but up until ~18 months ago, low-cost ASICs capable of realtime h.264/mpeg-4 encoding at 720p60 just didn't exist... and flash was so expensive, nobody (AFAIK) even *bothered* to try making MPEG-2 realtime-encoder ASICs capable of 720p60, because you would have ended up with a $200 device capable of recording 10-20 minutes of video.
That said... if you look up the datasheets for the image sensors for sub-$100 720p60 dashcams, they don't have anywhere CLOSE to 1280x720 of real resolution. It's more like 540 rows of 640 green subpixel sensors, flanked by another 540 alternating rows of 640 red or blue sensors that get interpolated into a 1280x720 framebuffer for encoding as nominal 720p60. Maybe... MAYBE... 800 alternating rows of 700-1200 subpixels, giving them some headroom to implement deshaking and pretend they can do 1080p30 at anywhere close to 1920x1080.
In theory, 100base-T4 can do 100mbps over cat-3 cable with 4 pairs, using the same technology that ultimately became the foundation of gigabit ethernet. From what I recall, it was never really available commercially as a non-exotic product, but I've heard that some (or all) 1000base-T gigabit ethernet chipsets could (in theory, at least) support it with little fanfare if anybody actually bothered to include support for it in firmware. Whether any other hardware (switches, routers, or even the drivers for Windws/Linux) would have any idea what to do with 100base-T4 is another question entirely.
I am kind of curious, though, if anybody happens to know. Google has almost zero information about it, so if there's any kind of undocumented support for 100base-T4 in modern hardware, they don't even think it's important enough to mention in their spec sheets.
Where 100base-T4 could be handy: scenario where you happen to have 4 pairs of cat3 that aren't being used for anything, but can't easily pull new cat5. In theory, you could spend about a kilobuck on the equivalent of local VDSL drivers to ram the same 100mbps over a single pair, but it would be kind of cool if 100base-T4 were just a freebie latent capability of gigabit networking gear that happened to just work anyway... then again, I think gigabit ethernet can auto-negotiate and reduce speeds anyway, so it's possible that gigabit cards/switches over 4 pairs of cat3 might just gracefully degrade to 100mbps while maintaining nominal gigabit standards anyway.
I can't necessarily speak for all platforms, but iDisplay for my Thinkpad T61 and Motorola Xoom (US, Wifi) was a complete & total disappointment (roughly 9 months ago), even when connected directly via USB (Thinkpad had Vista/32).
It was actually slower than VNC over dialup, if such a thing is actually possible. It had at *least* 200-400ms latency. If it did any kind of RDP-like acceleration (as opposed to blindly scraping video memory and shoveling it over to the tablet, one painful frame at a time), it wasn't apparent. Worst of all, the way it installed its driver screwed up the way the laptop handled OTHER external monitors until I finally threw in the towel and uninstalled it.
I really wanted to like it. God knows, it was half the reason I *bought* a Xoom in the first place. Great and sensible idea, god awful implementation.
Maybe, but this is Slashdot, and users here are probably on the heavier end of data use. As a practical matter, only T-mobile prepaid is competitive with AT&T or Verizon insofar as raw speed and/or bulk gigabyte pricing is concerned... and T-mobile is *very* much "feast or famine". Where they're good, they're awesome. Everywhere else, they totally suck for data. There's no middle ground with them. You either have rock-solid 6-20mbps HSPA+ or LTE, or you're limping at 80-150kbps on EDGE (but still probably doing better than Sprint).
That said... T-mobile's coverage is now fairly decent, as long as the overwhelming majority of your use is in the 80% or so of urban America where they're good. Just don't even bother to *fantasize* about depending upon them for high-speed data when you go stormchasing in semi-rural areas, let alone western Kansas, South Dakota, or most of Alabama beyond cities like Birmingham, Montgomery, or Tuscaloosa. For stuff like that, you really need AT&T *and* Verizon... maybe US Cellular too, to avoid totally burning through your Verizon data. (Note: they don't like to talk about it much, but if you can pick up a cheap Verizon data modem or older hotspot for $10-60 on ebay, you can prepay Verizon data by the day, week, or month, and just keep the modem/hotspot around for a rainy day (ok, sorry... shamelessly bad pun).
Every time a state starts printing metric speed limits, it inevitably ends up rounding the limit DOWN.
I remember one failed experiment where FDOT (Florida) tried to be cute and put up signs declaring "44kph" to be the metric equivalent of 30mph (it's only 27mph). The signs were SO hated, most of them got vandalized beyond recognition within a month, and pretty much ALL of them had the "44" spray painted, X'ed (with black markers), or shot out (with BBs, paintball pellets, or real honest-to-god bullets) by the time FDOT took them down and replaced them with 30mph signs. FDOT later admitted that it was a mistake.
If you want the public to accept metric speed limits, roll them out with a big public campaign that emphasizes that the limits are being RAISED everywhere by up to 5mph. Instantly, metric speed limits will become popular and cool among drivers. Declare 115kph (71.45mph) to be the equivalent of 70mph, and drivers will like them. Round it up to 120kph (74.56mph), and drivers will LOVE them. Try pulling another FDOT stunt by putting up signs saying "70mph/111kph", and they'll get vandalized beyond recognition within days.
Yes, T-mobile can be a good option, except for the fact that if you subscribe to the one plan they have with 5gb HSPA+/LTE per month and nominally-unlimited calls & text, they might be a whopping $5/month cheaper after you subtract the ETF for somebody else from the retail purchase price of a $699 best of breed Android phone, divide the result by 24, and subtract it from the other carriers' monthly rates for comparable service.
The main theoretical benefit of T-Mo is the ability to buy arbitrary phones... but between 1700MHz HSPA+ (they're still refarming, and 1700/2100 support among non-American phones is still pretty rare) and LTE (in some places) that's every bit as proprietary and non-interoperable with imported phones as LTE from AT&T, Verizon, and Sprint, the benefits are mostly academic. At best, T-Mobile is more like a step sideways that's a little cheaper and not much worse (or maybe a solid step up from Sprint overall).
Now, if you're an elderly person with a Jitterbug who uses it to call for a ride to church once a week, the equation might be a bit different. But if you have a high-end phone that's permanently in use throughout the day & you treat Youtube like a free on-demand radio station in your car, or you leave the phone on your desk at work like a picture frame streaming 4 security cameras from home all day so you can keep an eye on your cats while you work, most prepaid service will be either lacking or way more expensive.
Before everyone has a European-model lovefest, I should point out that that the European model has been *spectacularly* wrong about a few hurricanes over the past 2 years with respect to South Florida landfall (or non-landfall). I remember at least one (possibly Sandy or Isaac) where it was totally out in wacky-land ~5 days out, and didn't converge back into agreement with reality until 2-3 days later.
OK, here's a hard benefit: imagine how much money it costs a company like Citibank to close offices for a day or more in anticipation of an upcoming storm. It's staggering. If it allows a company like that to make better decisions about which offices and branches are unquestionably going to have to be closed, and which ones might be able to safely remain open, the hard dollar value would be measured in millions. Ditto for concert venues, sporting events, tourist destinations (hello, Disney? Myrtle Beach?), and pretty much anything where the cost of cancelling some event planned months in advance is substantial.
It extends to small businesses, and working people, too. Many service-industry employees (waiters, waitresses, hotel maids, etc) only get paid for hours they work. If a hotel/restaurant is closed for a storm, that's money out of their next paycheck. If better forecasts allow the hotel/restaurant to remain open instead of having to evacuate the tourists early, that's a very good thing. Ditto, for those tourist families on vacation. Good forecasts could make the difference between having their expensive vacation ruined, and enjoying another day or two on the beach.
AFAIK, 256kbps frame relay at WSR88-D sites, and 128kbps ISDN at TDWR sites. I believe they're now in the process of upgrading the TDWR sites to 256kbps frame-relay, and enabling 1-minute updates for tilt-1 data as they get the backhaul updates completed.
The big, huge, immediate improvement from backhaul upgrades is basically 1-minute updates for the lower tilt. I believe they're doing TDWR now, and hoping to use it as a demonstration of value to gain support for doing the same for the WSR88D sites "really soon". That said, I think the upgrades might have fallen victim to the budget sequester, because they haven't (officially, AFAIK) said a word about them in several months, even though they were all supposed to be coming online right about now.:-(
Consumer-grade broadband is NOTORIOUSLY vulnerable to regional power outages... something that tends to happen simultaneously with bad storms. Imagine the outrage if South Florida lost its radar every time the outer rain bands of a hurricane started to knock out the local power grid, or if Oklahoma or Kansas lost their radar when an advancing squall line knocked out Comcast's power a half hour before the parade of tornadoes following it arrived?
Even if they had lower-res lower-bandwidth modes to fall back on, the fact remains that they can't have weather radar failing precisely when it's needed the most. They MUST have reliable broadband that doesn't depend upon commercial power, backed up with SLAs that have teeth and real penalties if the telco doesn't keep up its end of the deal.
You're mostly right, but you're overlooking the software limits that exist mainly due to the limited bandwidth. If they upgraded the sites to a full T1 and tweaked the software a bit, they could give us new tilt-1 updates every minute, with about 15-60 seconds of radar-to-end-user latency, without major hardware upgrades besides the T1 interface itself.
Compare that to now, where we get only a single tilt-1 scan every 6 minutes, and that scan might itself be delayed by another 6-10 minutes on top of that. There are ALREADY several VCP programs that sample tilt 1 every minute... they just can't send out that data, and only use it locally for calculating their derived products, because they don't currently have the dedicated bandwidth to send it out.
Remember, WSR88D is kind of like an Atari 2600... it has very few limits that are truly "hard" and insurmountable. Rather, they're software-imposed in recognition of other limiting factors like backhaul bandwidth, or are precautionary limits imposed to guarantee that some specific product can always be fully-derived and delivered within some specific amount of time, or in a way that won't be destroyed by random errors. Many of them could be substantially improved with even minor hardware upgrades in other areas.
There are real limits to resolution imposed by scattering, wavelength, and particle size, but from what I've read, the current level 2 scan data is still throwing away about 30-50% of the nominal max resolution, and enormous amounts of theoretical resolution that could be recovered through oversampling. At this point, NWS doesn't even *know* what they could derive offsite from oversampled level 2 data, because they've never had the backhaul resources to even *fantasize* about streaming it in its full oversampled glory, or even archiving it all on site. 20 years ago, the idea of having 64 terabytes of on-site raid storage for Amazon/Google-like raw indiscriminate archiving would have been unthinkable, and never even entered into the equation.
The current scan rates are a compromise that tries to balance their backhaul against the need to track fast-moving storms like tornadoes. If they mounted a second, fixed-tilt dish back to back with the current dish so that every rotation produced a tilt-1 sample, they could alternate the back-facing samples between slow and fast pulse rates (so every other scan would be alternately optimized for range or resolution), and dedicate the front-facing dish currently in place to sampling the higher tilts (interleaving them to sample lower tilts twice at both PRF rates). Freed of the need to dedicate at least two full sweeps out of each volume scan to tilt 1 (because the back-facing antenna would sample tilt one every time the dish rotated), they could possibly slow down the rotation rate and use it to increase the resolution.
The closest thing I've seen to my idea was a paper someone at NOAA wrote about a year or two ago, proposing a compromise between fixed-tilt back-to-back conventional radar, and full-blown (and likely to be cost-prohibitive) phased-array radar 360-degree fixed radar. Basically, their idea was to build a limited wedge of PAR modules capable of sampling 4 tilts over ~1 degree horizontal, and mount it to the back side of the existing dish assembly, so that it could sample 4 tilts per revolution, and give us the equivalent resolution of 4-tilt level 3 TDWR every 12-15 seconds. The idea is that NOAA would then have a TDWR-resolution rapidly-updating radar source for tracking fast-moving/rapidly-developing storms off the back, and could slow down the overall rotation to get more detailed ultra-hires samples than we have now off the front dish.
The catch, from what I recall, was that they'd HAVE to decrease the RPM, and use 5.8GHz (like TDWR) for the rear array, because there just isn't enough C-band 10cm spectrum available to simultaneously broadcast 5 pulse beams without creating an interference scenario that would make their current range-folding issues look downright tame. They'd
Slashdot Mirror
>100fps or so is way above the threshold of about 20 frames per second
Bullshit. Period, full-stop, boldface, italicized, and surrounded in BLINK tags.
Your corneal surface isn't equally sensitive to flicker. Rod-dominated peripheral vision is several orders of magnitude more sensitive to motion and flicker than cone-dominated foveal vision. In terms of framerate or high-contrast flicker, the magic point at which literally nobody can tell the difference between N and 2N (where "N" = "framerate in hertz") regardless of which part of the eye it strikes, its brightness & contrast, and the amount of frame-to-frame change, is somewhere around 400fps/Hz (slightly more for some, slightly less for others). Now, you don't literally have to go quite THAT high to have a satisfactory viewing experience with most content, but if you really want to split hairs and look for edge cases where people can reliably tell the difference in double-blind tests... that's approximately where it is. WAY above 20fps.
The ONLY reason why 24fps (motion picture film) presents any kind of illusion of motion is because film's analog nature encodes additional higher-order information into it in the form of motion blur and other artifacts. I can guarantee that raw, razor-sharp blur-free high-contrast 24fps video is VERY unpleasant to watch, even if you independently take care of flickering so it appears as a sequence of sequential solid images.
And yes, somewhere between 5-20% of the population (slightly lopsided towards males) ARE more sensitive to flicker. It's been studied, documented, and quantified. The number is well known to monitor manufacturers... they just don't care. The best we can hope for is some future backlight ASIC whose behavior can be tweaked by end users via I2C, even if the manufacturer of the monitor itself doesn't lift a finger to support it. Then some bean counter in management will decide he can shave 1.7 cents from the manufacturing cost by omitting the pullup resistor needed for the I2C bus to work, and we'll be fsck'ed again.
IMEI-cloning isn't "rooting" -- it's "IMEI cloning", and if convicted, it's just about the most heavily-punished illegal thing you can possibly do with a mobile phone in America without causing somebody to die. And if you're caught, you almost certainly WILL be convicted, because all the prosecution has to prove is that you did it (no need to prove criminal intent). For prosecutors, it's a hole-in-one easy victory they can assign to their summer intern and let him score a guaranteed win.
More importantly, there's NO NEED to clone an IMEI to use a non-Verizon phone on Verizon. Contrary to popular myth, Verizon WILL allow you to activate non-Verizon phones. HOWEVER, they literally won't lift a finger to help you, or even furnish you with the most trivial of information you'll need to make it work... and if you accidentally create denial-of-service conditions while trying to reverse-engineer something, or incompletely-implement something important, yes, they WILL terminate your service on the spot.
To nontechnical people, that might sound like what the OP said... but there IS a subtle shade of difference between banning something outright, vs allowing you to try, then punishing you for nearly-guaranteed failure.
Now, if you're trying to activate a phone Verizon blacklisted for being stolen or from a broken contract with unpaid ETF, that's another matter. At least Verizon, unlike T-Mobile, won't tell you that a phone's IMEI/ESN is "clean", then turn around and blacklist it anyway -- without recourse -- 3 months later. That's something T-Mobile is INFAMOUS for doing, and it's gotten them a LOT of well-deserved hate. Here's how it happens: A T-Mobile customer buys a subsidized phone, then sticks the SIM in his old phone (or a different phone) and sells the subsidized phone to someone else. The buyer calls T-Mobile, checks the ESN, verifies that it's "clean", buys the phone, and happily uses it as a T-Mobile customer (possibly prepaid) for months. Then, for whatever reason, the original buyer walks away from his contract without paying the ETF. Within days or hours, your phone quits working, and when you contact T-Mobile, they tell you that you're SOL unless you pay the ETF of the guy who sold the phone to you several MONTHS ago. Sprint/AT&T/Verizon don't do this. They won't allow you to newly-activate the phone once it's been blacklisted, but they'll grandfather you in if the phone was in use long before the blacklisting occurred.
Unfortunately, there ARE a few places where Verizon IS pretty much your only viable option for wireless data that's faster than 250kbps indoors. Most of those places have solid AT&T coverage, but only have EDGE-speed data. Sprint is nonexistent in those areas (they just let you roam on Verizon & drop you if more than 50% of your use is roaming), and T-Mobile isn't even a wild fantasy.
If I recall, the biggest area where this tends to be the case is hardcore-rural central Pennsylvania, extending down into the Smoky Mountains & Appalachia. It's not the WHOLE area, but that's the area that seems to get mentioned the most as one where AT&T decided to just let Verizon have anybody who wasn't happy with EDGE.
It goes against what most people believe, but CDMA phones actually CAN have significantly greater range than GSM (even though that's rarely the case in urban environments, especially with Sprint). Due to the way legacy TDMA-based GSM worked, it literally hits a brick wall at around 30 miles. Further than that, and the phone won't work... period, end of story. Not even with a high-gain yagi or dish on a fixed tower. Legacy GSM timing was literally carved in stone, and beyond ~30 miles, it conflicted with the limits imposed by the speed of light and just quit working. CDMA's spectral efficiency goes down the toilet in far-fringe rural coverage areas, but if push comes to shove, you can shove an 800MHz signal a lot harder & farther than an 800MHz TDMA-based legacy GSM signal.
That's why Canadian mobile phone companies (mostly) started out with CDMA, and kept CDMA as their fallback voice/data mode even after choosing HSPA for high-speed data. Legacy GSM would have been unusable in many parts of Western and Northern Canada where CDMA voice (and 1xRTT data) works perfectly well. Australia had the same problem with phone service in the outback, and rural Australians were FURIOUS when their urban overlords decreed that everyone was moving to GSM (HSPA is WCDMA and can be coaxed into working in rural areas with a fixed high-gain antenna and high power, but WCDMA is still more demanding than oldschool IS95 CDMA and CDMA2000-1xRTT).
> if Verizon catches wind of your rooting, you'll be dropped like a call on Sprint and be out the cash you spent on both devices.
No you won't. Verizon might be evil control freaks, but not even THEY will terminate you just for rooting your phone.
That said, be aware that your likelihood of getting any phone not sold by Verizon to ever be fully-functional (especially EVDO and LTE), on Verizon is close to 'nonexistent'. People have occasionally found ways to reflash Sprint identical twins of Verizon phones with Verizon radio modems, but if you ever got a completely "alien" non-Verizon CDMA phone to do full-speed EVDO on Verizon, it would make headlines over at xda-developers.com. Radio modems are an entirely different beast from Android phones (which contain radio modems, but interact with them at arm's length).
Sprint is probably the least-interesting to the NSA. Their data service is so dysfunctional, not even criminals and terrorists will use them anymore.
Steel has no problem with compressive strength, it's just a lot more expensive than concrete.
It's not just cost. If you formed a freeway support column from a solid block of steel having dimensions of 5x10x40 feet, it would be impossible to transport to the site or place into position, and even more impossible to join to anything comparably large. You simply couldn't get the middle part of the contact points hot enough to weld, without damaging the structural integrity of the remainder of the beam/column while doing it.
In the real world, steel beams have to be some variant of a tube, box, I-beam, or C-channel/stud to enable them to be placed. The problem THEN is that many steel arrangements can't even support their own weight until they're all fastened together, and if something pushes them far enough to kink or bend, they fail rapidly and completely. For example, a futon made from steel tubes might be very strong, but if someone heavy falls into it, the whole thing can collapse the moment the first tube gets even slightly bent. However, there's no rule that necessarily says the steel HAS to be on the inside. For example, you can mount a hollow pole, then fill it with very runny concrete grout to give it compressive strength and minimize things like buckling.
^^^ Argh. Bitten by preview-blindness after major editing. Ignore this line in the post above:
(other combos possible; though most would agree that the obvious alternative would be 10, 11, 00, and 01 (in order) for the choices above)
or pretend it says:
(other combos possible; though most would agree that the obvious alternative would be 00, 01, 10, and 11 (in order) for the choices above).
> SOS = ... --- ... = 101010001110111011100010101
I'd say it's more like:
10101000 11111100 10101001
Morse requires two bits to encode each symbol:
10 = dit (short)
11 = dah (long)
00 = character-marker
01 = word-marker
(other combos possible; though most would agree that the obvious alternative would be 10, 11, 00, and 01 (in order) for the choices above).
You can also represent all known Morse characters as 8-bit bytes by establishing a rule that 0=dit/short, 1=dah/long, and the last one is whichever value (0 or 1) differs from the least significant identical bits. Ex:
e = . = 01111111 .. = 00111111 .- = 01000000 ..... = 00000111 ..--.. = 00110011
i =
t = - = 10000000
a =
5 =
? =
I believe both schemes are used in the real world... the first to represent Morse as received, the second to encode the lookup tables.
Not only that, they're digital communication with the first known implementation of Huffman coding as a form of data compression :-D
I doubt whether it would help. Since Roman concrete can't be steel-reinforced, it would just crumble if ice heaved it upwards because it wouldn't have steel inside to hold it together. It wouldn't help with cracks, because even concrete roads are still surfaced with a few inches of asphalt (at least, in Florida... maybe things are different "up north"). AFAIK, the endless annual resurfacing would still be necessary, because 99% of the potholes and cracks are in the top layer of asphalt, not the structural concrete roadbed below.
Where the Roman concrete might be MORE useful is environments like causeways, by providing a hard shell around the structural foundation that protects it from erosion. Where it might become a bit dangerous is if it ends up protecting the structural reinforced concrete from VISIBLE damage, but doesn't prevent the steel from rusting away on the inside until its tensile strength gets reduced to the point of being dangerous even though it "looks fine" on the outside.(*)
(*)For those who don't know, reinforced steel consists of steel bars + concrete because concrete has tremendous compressive strength, but terrible tensile strength. Apply force in any direction besides straight down, and concrete just breaks away or crumbles. In contrast, steel has a lot of tensile strength (it tends to stretch and bend rather than snap), but terrible compressive strength. As a matter of good luck, steel & concrete have mostly identical expansion rates when heated & cooled, and form a very strong chemical bond to each other (get concrete splattered on your car, and once it dissolves the paint and makes contact with the steel body it's NEVER coming off). The combination allows concrete to provide the compressive strength, and the steel to provide the tensile strength. Without steel, an elevated freeway would have to be built from arched vaults. With steel, you can support it with flat beams. Of course, if you approximate a "classical" form like an arch, you'll be working WITH the concrete and adding strength, but steel is what allows us to build things like a 40 foot road deck cantilevered from a single support column, or support a skyscraper like Citigroup's midtown headquarters from support columns that are located in the middle of each wall instead of at the corners.
AFAIK, yes, it can be patented. And that's perfectly OK. Roman concrete wasn't a useful art, it was a lost art. At least under the official theory of American patent law, patents exist to promote advances in useful arts, not to merely grant a monopoly over some abstract artistic right. "Prior Art" isn't just something that EXISTED... it's something that existed, with documentation that would have allowed somebody ELSE to re-create it. Without that documentation, Roman Concrete was little more than a mere idea... maybe a half-step better since it was more like a "proof of concept", but the fact that substantial effort was required to re-discover and document it IMHO does make it patent-worthy.
Now, if Cemex (or some other company that makes concrete) gets sued for infringement 14 years from now, and shows up in court with some ancient, long-lost and recently-rediscovered Greco-Roman document with the formula, they'd have a solid case for overturning a modern patent on it.
Before somebody brings up "first to file", I should point out that if I invent and document something, but someone else beats me to the patent office, I might not be able to get the patent transferred to ME, but I can certainly show up late and spoil the party for THEM. In a way, "First to File" opens the door to trolling trolls... if you invent something, but don't necessarily think it's worth patenting (or have the resources to secure that patent), you can abundantly document it (possibly via digital notarization), then just sit on your notes. If somebody ELSE gets a patent, you can demand that they give you a cut of the royalties they collect, and threaten to go public with your own prior art and spoil their party (after they've spent hundreds of thousands of dollars securing the patent) if they don't.
Ouya doesn't quite count as a "console platform", because the amount of work a developer has to do to publish a game that already exists anyway for Android to Ouya is borderline-trivial compared to the amount of work a developer has to do to publish a game for, say, Wii.*|Xbox.*|PlayStation.*|PS.*
That's part of the reason why in the long run, Android is likely to be a more lethal threat to the console ecosystem than ANYTHING Nintendo, Sony, Microsoft, or anyone else can come up with. Android games will exist regardless of whether there are zero, ten, or 300 different Android consoles ranging from Ouya++ to nameless HDMI sticks from Shenzhen.
Ditto, for Microsoft. Microsoft is hellbent on having SOMETHING in your living room, and if push comes to shove, they'll try to convince DirecTV to make them part of their new satellite boxes going forward.Microsoft has enough cash to slog on almost forever.
Sony won't abandon a cash cow, but Nintendo's the most likely of all to stick it out to the bitter end, just because they don't really HAVE a "plan B". Sony can make Android phones & Android STBs, and still feel like it has saved face. By any sane standard, Nintendo should have had a dozen Gameboy phones by now, but unfortunately they're one of the most visible casualties of Japan's mobile phone market -- a market so proprietary and closed, it makes America's look like the shining light of robust pro-consumer open choice by comparison. Nintendo has an international market, but their strong Japanese roots & closed domestic phone market have kept them from ever seeing phones as a viable business opportunity.
Anybody who thinks ARM is remotely close to matching x86 performance should try this little experiment: get a 7-8 year old notebook like a Dell D600 w/1.6GHz Pentium M, install Ubuntu on it, and compare it side by side with any ARM netbook that has a CPU of comparable nominal speed, plus comparable ram and storage, and has the same release of Ubuntu installed on it. Configure both with identical desktop settings, and run the same apps (compiled for the proper architecture, of course). The 7 year old D600 will beat the ARM laptop like an unloved child in a trailer park.
Yes, if you have the resources of IBM or Samsung, you could cobble together a pimped-out ARM that's in the same league as a low-end x86-64 CPU... 2GHz+, multi-core, lots of cache, with speculative & out of order execution. The works. And if you do, congratulations... you've just invented a CPU with the computing power of a Pentium IV, but the slightly lower power requirements of a mobile Athlon 64.
There's no free lunch, and ARM is neither holy nor magic. If you take ARM on its own terms and use it appropriately for things that don't need a lot of computing power, it works well. If you try to pimp it out and cobble together an ARM-based PC with the raw performance power of even a lower-end modern x86-64 PC and use it to run the same (but recompiled) apps you'd run on a regular PC, you end up with an abomination that has all the drawbacks of ARM with none of its benefits.
> Today's phones beat the living shit out of machines I still use.
Don't be too sure. Megahertz-per-useful-act, anything from the Pentium-M (really, a Pentium III Xeon w/power mgmt) still totally spanks ARM7, even in dualcore-for-Android form (between power management & poor handling of apps not explicitly written to be SMP, a dual/quadcore Arm Cortex almost might as well be single-core). A 1.5GHz Krait running Android is roughly comparable to a 1Ghz P-III running XP in perceived performance. Yes, you can find optimized examples that give a dualcore Krait or quadcore Exynos a sligha edge, but x86/AMD64 cpus are *profoundly* optimized for getting good performance out of mediocre software under sub-optimal conditions compared to ARM7.
HD dashcams? Nothing new. 60fps HD dashcams? New. Very, very new.
The cameras have been around for years, but up until ~18 months ago, low-cost ASICs capable of realtime h.264/mpeg-4 encoding at 720p60 just didn't exist... and flash was so expensive, nobody (AFAIK) even *bothered* to try making MPEG-2 realtime-encoder ASICs capable of 720p60, because you would have ended up with a $200 device capable of recording 10-20 minutes of video.
That said... if you look up the datasheets for the image sensors for sub-$100 720p60 dashcams, they don't have anywhere CLOSE to 1280x720 of real resolution. It's more like 540 rows of 640 green subpixel sensors, flanked by another 540 alternating rows of 640 red or blue sensors that get interpolated into a 1280x720 framebuffer for encoding as nominal 720p60. Maybe... MAYBE... 800 alternating rows of 700-1200 subpixels, giving them some headroom to implement deshaking and pretend they can do 1080p30 at anywhere close to 1920x1080.
In theory, 100base-T4 can do 100mbps over cat-3 cable with 4 pairs, using the same technology that ultimately became the foundation of gigabit ethernet. From what I recall, it was never really available commercially as a non-exotic product, but I've heard that some (or all) 1000base-T gigabit ethernet chipsets could (in theory, at least) support it with little fanfare if anybody actually bothered to include support for it in firmware. Whether any other hardware (switches, routers, or even the drivers for Windws/Linux) would have any idea what to do with 100base-T4 is another question entirely.
I am kind of curious, though, if anybody happens to know. Google has almost zero information about it, so if there's any kind of undocumented support for 100base-T4 in modern hardware, they don't even think it's important enough to mention in their spec sheets.
Where 100base-T4 could be handy: scenario where you happen to have 4 pairs of cat3 that aren't being used for anything, but can't easily pull new cat5. In theory, you could spend about a kilobuck on the equivalent of local VDSL drivers to ram the same 100mbps over a single pair, but it would be kind of cool if 100base-T4 were just a freebie latent capability of gigabit networking gear that happened to just work anyway... then again, I think gigabit ethernet can auto-negotiate and reduce speeds anyway, so it's possible that gigabit cards/switches over 4 pairs of cat3 might just gracefully degrade to 100mbps while maintaining nominal gigabit standards anyway.
I can't necessarily speak for all platforms, but iDisplay for my Thinkpad T61 and Motorola Xoom (US, Wifi) was a complete & total disappointment (roughly 9 months ago), even when connected directly via USB (Thinkpad had Vista/32).
It was actually slower than VNC over dialup, if such a thing is actually possible. It had at *least* 200-400ms latency. If it did any kind of RDP-like acceleration (as opposed to blindly scraping video memory and shoveling it over to the tablet, one painful frame at a time), it wasn't apparent. Worst of all, the way it installed its driver screwed up the way the laptop handled OTHER external monitors until I finally threw in the towel and uninstalled it.
I really wanted to like it. God knows, it was half the reason I *bought* a Xoom in the first place. Great and sensible idea, god awful implementation.
Maybe, but this is Slashdot, and users here are probably on the heavier end of data use. As a practical matter, only T-mobile prepaid is competitive with AT&T or Verizon insofar as raw speed and/or bulk gigabyte pricing is concerned... and T-mobile is *very* much "feast or famine". Where they're good, they're awesome. Everywhere else, they totally suck for data. There's no middle ground with them. You either have rock-solid 6-20mbps HSPA+ or LTE, or you're limping at 80-150kbps on EDGE (but still probably doing better than Sprint).
That said... T-mobile's coverage is now fairly decent, as long as the overwhelming majority of your use is in the 80% or so of urban America where they're good. Just don't even bother to *fantasize* about depending upon them for high-speed data when you go stormchasing in semi-rural areas, let alone western Kansas, South Dakota, or most of Alabama beyond cities like Birmingham, Montgomery, or Tuscaloosa. For stuff like that, you really need AT&T *and* Verizon... maybe US Cellular too, to avoid totally burning through your Verizon data. (Note: they don't like to talk about it much, but if you can pick up a cheap Verizon data modem or older hotspot for $10-60 on ebay, you can prepay Verizon data by the day, week, or month, and just keep the modem/hotspot around for a rainy day (ok, sorry... shamelessly bad pun).
Every time a state starts printing metric speed limits, it inevitably ends up rounding the limit DOWN.
I remember one failed experiment where FDOT (Florida) tried to be cute and put up signs declaring "44kph" to be the metric equivalent of 30mph (it's only 27mph). The signs were SO hated, most of them got vandalized beyond recognition within a month, and pretty much ALL of them had the "44" spray painted, X'ed (with black markers), or shot out (with BBs, paintball pellets, or real honest-to-god bullets) by the time FDOT took them down and replaced them with 30mph signs. FDOT later admitted that it was a mistake.
If you want the public to accept metric speed limits, roll them out with a big public campaign that emphasizes that the limits are being RAISED everywhere by up to 5mph. Instantly, metric speed limits will become popular and cool among drivers. Declare 115kph (71.45mph) to be the equivalent of 70mph, and drivers will like them. Round it up to 120kph (74.56mph), and drivers will LOVE them. Try pulling another FDOT stunt by putting up signs saying "70mph/111kph", and they'll get vandalized beyond recognition within days.
Yes, T-mobile can be a good option, except for the fact that if you subscribe to the one plan they have with 5gb HSPA+/LTE per month and nominally-unlimited calls & text, they might be a whopping $5/month cheaper after you subtract the ETF for somebody else from the retail purchase price of a $699 best of breed Android phone, divide the result by 24, and subtract it from the other carriers' monthly rates for comparable service.
The main theoretical benefit of T-Mo is the ability to buy arbitrary phones... but between 1700MHz HSPA+ (they're still refarming, and 1700/2100 support among non-American phones is still pretty rare) and LTE (in some places) that's every bit as proprietary and non-interoperable with imported phones as LTE from AT&T, Verizon, and Sprint, the benefits are mostly academic. At best, T-Mobile is more like a step sideways that's a little cheaper and not much worse (or maybe a solid step up from Sprint overall).
Now, if you're an elderly person with a Jitterbug who uses it to call for a ride to church once a week, the equation might be a bit different. But if you have a high-end phone that's permanently in use throughout the day & you treat Youtube like a free on-demand radio station in your car, or you leave the phone on your desk at work like a picture frame streaming 4 security cameras from home all day so you can keep an eye on your cats while you work, most prepaid service will be either lacking or way more expensive.
Before everyone has a European-model lovefest, I should point out that that the European model has been *spectacularly* wrong about a few hurricanes over the past 2 years with respect to South Florida landfall (or non-landfall). I remember at least one (possibly Sandy or Isaac) where it was totally out in wacky-land ~5 days out, and didn't converge back into agreement with reality until 2-3 days later.
OK, here's a hard benefit: imagine how much money it costs a company like Citibank to close offices for a day or more in anticipation of an upcoming storm. It's staggering. If it allows a company like that to make better decisions about which offices and branches are unquestionably going to have to be closed, and which ones might be able to safely remain open, the hard dollar value would be measured in millions. Ditto for concert venues, sporting events, tourist destinations (hello, Disney? Myrtle Beach?), and pretty much anything where the cost of cancelling some event planned months in advance is substantial.
It extends to small businesses, and working people, too. Many service-industry employees (waiters, waitresses, hotel maids, etc) only get paid for hours they work. If a hotel/restaurant is closed for a storm, that's money out of their next paycheck. If better forecasts allow the hotel/restaurant to remain open instead of having to evacuate the tourists early, that's a very good thing. Ditto, for those tourist families on vacation. Good forecasts could make the difference between having their expensive vacation ruined, and enjoying another day or two on the beach.
AFAIK, 256kbps frame relay at WSR88-D sites, and 128kbps ISDN at TDWR sites. I believe they're now in the process of upgrading the TDWR sites to 256kbps frame-relay, and enabling 1-minute updates for tilt-1 data as they get the backhaul updates completed.
The big, huge, immediate improvement from backhaul upgrades is basically 1-minute updates for the lower tilt. I believe they're doing TDWR now, and hoping to use it as a demonstration of value to gain support for doing the same for the WSR88D sites "really soon". That said, I think the upgrades might have fallen victim to the budget sequester, because they haven't (officially, AFAIK) said a word about them in several months, even though they were all supposed to be coming online right about now. :-(
Reliability is a *huge* issue.
Consumer-grade broadband is NOTORIOUSLY vulnerable to regional power outages... something that tends to happen simultaneously with bad storms. Imagine the outrage if South Florida lost its radar every time the outer rain bands of a hurricane started to knock out the local power grid, or if Oklahoma or Kansas lost their radar when an advancing squall line knocked out Comcast's power a half hour before the parade of tornadoes following it arrived?
Even if they had lower-res lower-bandwidth modes to fall back on, the fact remains that they can't have weather radar failing precisely when it's needed the most. They MUST have reliable broadband that doesn't depend upon commercial power, backed up with SLAs that have teeth and real penalties if the telco doesn't keep up its end of the deal.
You're mostly right, but you're overlooking the software limits that exist mainly due to the limited bandwidth. If they upgraded the sites to a full T1 and tweaked the software a bit, they could give us new tilt-1 updates every minute, with about 15-60 seconds of radar-to-end-user latency, without major hardware upgrades besides the T1 interface itself.
Compare that to now, where we get only a single tilt-1 scan every 6 minutes, and that scan might itself be delayed by another 6-10 minutes on top of that. There are ALREADY several VCP programs that sample tilt 1 every minute... they just can't send out that data, and only use it locally for calculating their derived products, because they don't currently have the dedicated bandwidth to send it out.
Remember, WSR88D is kind of like an Atari 2600... it has very few limits that are truly "hard" and insurmountable. Rather, they're software-imposed in recognition of other limiting factors like backhaul bandwidth, or are precautionary limits imposed to guarantee that some specific product can always be fully-derived and delivered within some specific amount of time, or in a way that won't be destroyed by random errors. Many of them could be substantially improved with even minor hardware upgrades in other areas.
There are real limits to resolution imposed by scattering, wavelength, and particle size, but from what I've read, the current level 2 scan data is still throwing away about 30-50% of the nominal max resolution, and enormous amounts of theoretical resolution that could be recovered through oversampling. At this point, NWS doesn't even *know* what they could derive offsite from oversampled level 2 data, because they've never had the backhaul resources to even *fantasize* about streaming it in its full oversampled glory, or even archiving it all on site. 20 years ago, the idea of having 64 terabytes of on-site raid storage for Amazon/Google-like raw indiscriminate archiving would have been unthinkable, and never even entered into the equation.
The current scan rates are a compromise that tries to balance their backhaul against the need to track fast-moving storms like tornadoes. If they mounted a second, fixed-tilt dish back to back with the current dish so that every rotation produced a tilt-1 sample, they could alternate the back-facing samples between slow and fast pulse rates (so every other scan would be alternately optimized for range or resolution), and dedicate the front-facing dish currently in place to sampling the higher tilts (interleaving them to sample lower tilts twice at both PRF rates). Freed of the need to dedicate at least two full sweeps out of each volume scan to tilt 1 (because the back-facing antenna would sample tilt one every time the dish rotated), they could possibly slow down the rotation rate and use it to increase the resolution.
The closest thing I've seen to my idea was a paper someone at NOAA wrote about a year or two ago, proposing a compromise between fixed-tilt back-to-back conventional radar, and full-blown (and likely to be cost-prohibitive) phased-array radar 360-degree fixed radar. Basically, their idea was to build a limited wedge of PAR modules capable of sampling 4 tilts over ~1 degree horizontal, and mount it to the back side of the existing dish assembly, so that it could sample 4 tilts per revolution, and give us the equivalent resolution of 4-tilt level 3 TDWR every 12-15 seconds. The idea is that NOAA would then have a TDWR-resolution rapidly-updating radar source for tracking fast-moving/rapidly-developing storms off the back, and could slow down the overall rotation to get more detailed ultra-hires samples than we have now off the front dish.
The catch, from what I recall, was that they'd HAVE to decrease the RPM, and use 5.8GHz (like TDWR) for the rear array, because there just isn't enough C-band 10cm spectrum available to simultaneously broadcast 5 pulse beams without creating an interference scenario that would make their current range-folding issues look downright tame. They'd