mobile

You are currently browsing articles tagged mobile.

In my recent reflexions about the new potential for hybrid radio based on FM I identified RDS-TMC as an incentive to maintain and even expand the FM (RDS) infrastructure in Canada. While speaking about that at a meeting last week I learned that Corus Entertainment was deploying RDS-TMC traffic for Garmin devices in major cities in Canada. I’m not sure how long it has been there but I think it is quite new. And now that I’m aware of that, I see traffic enabled Garmin devices advertised everywhere… and prices are very reasonable.

So last week I ordered a Garmin model 265WT from Tigerdirect.ca (170$). The “T” at the end of the model number indicates that the FM RDS-TMC is included in the box. With such package, traffic information seems to be included for free for the whole life of the device. I’m not quite clear about that but for some reasons, Garmin also sells lifetime traffic information for 50$ on their website. Maybe some devices have to be activated before traffic information works?

Anyways. I received the device yesterday and was eager to try it. That’s what I did on my way home last night. It was very simple to install. In fact, nothing special has to be done. The lighter power cord must be plugged into the device and the car (the FM RDS receiver is part of that cord) and that’s it. When I launched the device, it took just a few seconds before I could see a little “traffic icon” on the maps.

Pressing on that icon revealed two types of traffic information. I took a picture (shown below) of the traffic situation last night at around 7pm in Ottawa. As we can see, there was heavy traffic on the main highway in Ottawa… and that was no surprise to me… it was perfect timing for my experiment: hockey night! And every time its the same thing: the highway gets jammed at the “Scotiabank Place”. So that’s the red segment on the map here.

IMG_3197.JPG-1.0 (RGB, 1 layer) 3888x2592 – GIMP.png

The other traffic display shows a list of the various problem zones. This is shown on the second photo I took:

IMG_3199.JPG.png

So very positive experience for me. I’m impressed. It works well and is very easy to use. The next step will be to see how real-time navigation and re-routing works considering the traffic. In the meantime, I guess canadians will want a new Garmin for Christmas because they certainly understand that traffic is a major enhancement on a GPS device.

If you wonder where exactly the service is available, have a look at this page on the Navteq website. A quick scan over the list shows following regions: Hamilton-Burlington, Montreal-Laval, Oshawa-Whitby-Clarington, Ottawa-Gatineau, St. Catharines-Niagara Falls-Welland, Toronto-Mississauga and Vancouver-Surrey-Burnaby.

! UPDATE, WARNING: I was told that the service has not been officially launched yet. I guess that this means it may be unstable or could even be stopped anytime. Please consider this if you think of buying yourself a new Garmin for Christmas.

I’m happy that my eComm talk finally got published online, 8 months after the conference. Events sponsors got published much earlier but hey, that’s fair for a professionally produced clip. I must admit that the AV infrastructure and the team at the event were excellent.

My talk was titled: “Mobile Digital Broadcasting: An Infrastructure for One-to-Many Converged Services”. We took this opportunity to officially release our Openmokast open source software framework. I was happy that my live demo worked as expected!



We had prepared a clip just in case the “demo effect” would hit on me on stage. Luckily this was not the case but the clip (which is more detailed than the live demo) can still be seen on our crcmmb Youtube Channel or here below:




And here are the slides I used for this presentation:

eComm was also for me a great occasion to meet with David Burges who presented his OpenBTS project live using the USRP as well. His demo looked incredibly like mine except he demonstrated live cell phone communications going through his GSM open source base station. There are lots of commonalities between our projects but essentially, both are about democratizing communications technologies to catalyze innovation.

There is a nice post on the Public Radio Player (PRP) blog about some challenges for Internet radio when distributed over mobile wireless networks and some strategies used in the PRP.

“A dropped stream is the nemesis of any regular Public Radio Tuner user. Nothing is worse than being caught up in a great public radio program and have it suddenly cut out….”

Some challenges can be expected:

  • loss of signal while roaming from cell to cell. Networks are optimized for voice calls but not for data yet.
  • minimal bitrate like 32 kbps is desirable but connection is still not guaranteed and sound quality is no great
  • buffers have to be implemented in receiver to mitigate signal loss.

Results of a survey made by PC World suggest that 3G coverage may not be adequate for the delivery of sustained bitrates in major cities in USA. Like this table shows, networks speeds can be impressive but their reliability vary greatly so that live radio transmissions may be hard to achieve.

There is certainly a lot of room for experimentation here in this new area but I tend to believe that it could take a while before we see 3G replace true “physical layer” broadcast networks for live transmissions.

I think that Twitter and micro-blogging in general have properties that could be exploited along with broadcasting services. I’ll write my thoughts about this later on.

As a first step in this reflexion, I’d like to estimate the total bandwidth of Twitter, that is, how many kilobits per second are being Tweeted on average.

I made a similar exercise some time ago with regards to the blogosphere in a post titled “Broadcasting the Blogosphere: 30 million voices for the price of one!”.

So I found some twitter services that provide relevant data. For example, TweeSpeed is an instant speed meter that shows the current number of tweets per minute. A graph showing the speed per hour during the last week is also available. A quick look at that graph now suggests that 700.000 tweets per hour would be a reasonable approximation for last week’s average, excluding the peek caused by the “Michael Jackson Effect”. Twitpocalypse currently reports 221 tweets per second which results in a similar value (221*60*60 =795.600 tweets per hour ). On another front, the recent HubSpot State of the Twittershpere report provides similar amounts on a daily basis instead of per hour. I suspect that this is a mistake. I’ll be pessimistic and take the largest number. The Hubspot report also informs on the distribution of actual tweet length. I’ll average the tweet length to 110 characters per tweet.

So the math goes like this:

110ch * 1byte/ch * 700k/hour = 77 Mbytes/hour

or

TOTAL TWITTER BANDWIDTH = 170 kbps !

Again, very surprising results! The current Twitter bandwidth is barely higher than a typical Internet or DAB radio station. The whole Twittershpere would only require to sacrifice a couple of off-air DAB stations in every market. I feel that very innovative datacasting/social applications could be built based on this!

As Internet radio appliances are becoming available, there is still the issue that they can’t be used in your car.

This could change thanks to so-called “in-car WiFi routers” which are designed to provide Internet access through 3G mobile telephony networks.

AutoNet Mobile offers such device and service combination:

we create a Wi-Fi hot spot that allows everyone in the car to connect multiple devices to the internet, in and around the car! it’s the next step in in-car entertainment and productvity. we make internet in your car easier than ever because we provide both the in-car router and the monthly service. our affordable monthly service plans start at only $29 per month.

This still represent an expensive proposition for radio though. One hour daily consumption of good quality Internet radio content could easily reach the 29$ 1Gb limit.