DSRC devices for vehicular networks will be used for V2V communication and V2I communication (with roadside stations). DSRC works in 5.9 GHz band with bandwidth of 75 MHz and approximate range of 1000m
The challenges of autonomous car communications - and the very different reaction times of autonomous and human driven cars, make me predict that dedicated lanes will be used to achieve the greatest benefits of autonomous cars. I could imagine cars driving at high speeds and very close together if they were all following the same "rules of the road" and the lead vehicle could alert the trailing cars of hazards ahead. With the long cycle time to deploy new automotive technology (and the very long life of legacy cars), I suspect that the initial deployments will be in repurposed High Occupancy Vehicle (HOV) lanes. Use of a qualified vehicle will result in dramatic reductions in travel time.
The way I see it, Junko, responding to your DSRC comment, this is indeed a viable and credible approach for V2V, which in some more futuristic reality could be replaced with optical systems in cars. There's no way that DSRC is replaceable by cellular schemes, though. You don't want to rely on a fixed cellular infrastructure for the immediate comms between adjacent vehicles. A WiFi-type of protocol is instead a good fit.
As to the cellcos, all of the existing telematics systems, like GM's OnStar, do use cellcos as their infrastructure. So at some level, they are playing with the automakers already. Maybe they aren't designing the road sensors and message transfer protocols required for V2I, but then again, I'm not sure I'd expect them to.
What will more likely transpire is, road information system designers will develop their schemes and then use existing cellcos as their transmission medium. Sort of the same as these telematics systems did. Verizon didn't create OnStar. It was just the choice of the OnStar system designers, when analog cellular went off the air. They could have picked any other cell company.
Honestly, I think the auto companies are busy selling cars, know that real self-driving cars would require collaboration and endless series of meetings with a zillion private and government organizations, and consequently do NOT see any urgency in this matter. Car companies know that cup holders and LCD displays are where the real action is, not fully self driving cars. That's because they know their customers.
Whereas Google is looking for free advertizing from the press, and getting it.
Don't get me wrong. It would be more fun to be a Google engineer playing with these algorithms, than to be an auto company engineer who is told to stop spending time on that, and make a cheaper windshield wiper system instead. Realistically, as many, many articles have said, this self driving car thing is going to be a gradual evolution, where driver assistance will be the main thing for a very long time.
I don't see the huge urgency either, Junko. Driver assitance systems are infinitely easier to design. And RF-based V2X systems are also more credible for the near term, than would be V2I and V2V optical systems that will reliably read road signs and see traffic lights, brake lights, or turn signals from other cars. IMO.
I am not sure even the short range communication will be reliable enough? It will be beyond acceptable that due to lost in signal or noisy channel car was not able to right decision leading to an accident...
V2X should take a lot of different "communication" forms. And yet, the mandate that's been discussed in the U.S. right now is abouthe use of Dedicated Short Range Communication (DSRC) tech operating at the 5.9 GHz frequency based on 802.11p.
I do understand that DSRC is useful and effective; but look, the auto industry sat on that spectrum for more than a decade now?
More importantly, LTE should definitelly become a part of the mix of V2X discussions. And yet, that hasn't exactly happened. US cellular operators are NOT part of the ongoing V2X trials and sitting on the sideline.
Blog Doing Math in FPGAs Tom Burke 2 comments For a recent project, I explored doing "real" (that is, non-integer) math on a Spartan 3 FPGA. FPGAs, by their nature, do integer math. That is, there's no floating-point ...