Interoperability

Sunday September 20, 17.43.18

A curious interoperability protocol, wherein the address for some weird place in Seoul has been found on an iPhone and must now be entered into the GPS of the taxi. A simple affair, with minimal bumps often enough, particularly because the map on the iPhone shows the address and streets in Korean, which is great for the taxi cab driver, but miserable for the the traveler who can only hope that the locale on the map is actually where he would like to be.

Why do I blog this? This are useful moments to capture, where language, culture, objects, data come into conflict and must work their way around one another. I am told the iPhone isn’t available in South Korea at the time of this photo, so you have this foreign object — one that is probably quite legible as the iPod Touch was spotted around the city — and a baroque assemblage of devices, machines, transaction mechanisms, remote controls, identity stickers, car controls, radios, etc. I would have to contrast this with the notion of seamless perfection and interoperability that is often the image of the future transportation dashboard.

One thought on “Interoperability”

  1. as an electronic engineer / automatic test system developer, i keep up on what’s going on in the industry. one area that has been on the scene but not tapped due to complexity is the use of FPGAs in end product design(FPGAs consist of very large arrays of configurable logic blocks). such devices offer on-the-fly reprogrammability, which implies that one h/w device could be used many different ways; perhaps your gps and many parts of the cellphone could be implemented in s/w on the fpga. but also, let’s say that after user is done with the gps, the taxi driver needs to connect his boss on the cellphone to a two way radio; in this scenario the fpga then is reprogrammed to connect those two items together. currently, it is possible to perform such operations via two way radio using ‘back room’ equipment. some common applications here are accounting managers for vehicle fleets, or perhaps the boss needs to have several different conference connections via the wireless connection.

    there is something called Software Defined Radio (SDR) which comes into play here. keep in mind, some components have to remain h/w while others are in s/w. there is a trade off.

    in order to make use of the fpga by larger portions of the design community, there is a company that designs a development product for fpgas that make this possible. check out these guys; http://www.altium.com – they design this system for radid prototyping so that the developer of a new product can focus on the design task at hand, instead of being hung up on development issues, syntax issues, tool issues and the like. i will be getting this system as soon as i get back to being employed again; i’m one of the recently unemployed. this system costs about $400 – they give a pretty extensive video describing the system development components, i’m pumped to getting mine!

    also too, with this h/w and associated control gui software on pc, the lines between h/w and s/w become fuzzy. this path is what microsoft wants to happen; connect everything everywhere; its part of what is called the ‘distributed computing model’. i focus my design efforts in automated test systems this way to push certain functionalities off to various device targets whose resources can handle said functions while leaving other functions appropriate to ‘enterprise’ based pcs there. the degree of ‘scalability’ of such systems has grown to the point that it is possible to implement your system in a very efficient and custom manner.

    my two cents.

    have a good day

    Ron H.
    Everett, WA

Comments are closed.