Showing posts with label smartphones. Show all posts
Showing posts with label smartphones. Show all posts

Friday, September 30, 2016

"So do that with your smartphone, nerd boy!"

That was the challenge from someone who'd read the story about an auto shop in Poland still using a Commodore 64 to balance drive shafts.

The Commodore 64 had a port on the back where you got direct digital signals from a parallel I/O chip (the 6526 CIA). So it was used in a number of embedded applications back in the day in situations where customers wouldn't actually see that critical tasks were being done by a $150 home microcomputer with a whole 64k of RAM and a 1mhz processor. When I was in school, I got a couple of contracts to do embedded stuff using the Commodore 64. The one I found most interesting was the temperature characterization of a directional drilling probe.

Directional drilling probes are used to know where the drill bit is when you're doing horizontal drilling of oil or gas wells. We calibrated the probe by mounting it in a testbed that allowed moving it into various positions, and monitoring it with a Commodore 64 bit-banging a two-wire interface. This testbed was in a magnetically calibrated chamber that could be heated or cooled upon demand. The probe itself had seven sensors -- three gravitic sensors (x, y, z), and three magnetic sensors (that aligned with the Earth's magnetic field to point towards magnetic north), in three different orientations (x, y, z), as well as a temperature sensor. These sensors went into A/D converters on the drilling probe itself, and were read out via a two-wire protocol (there were four wires total that went to the probe -- +/- power, and the CLK/DATA lines -- because running wires down a drill string is a PITA and they wanted to run as few wires as possible). The problem is that everything was heat sensitive -- "true north" ( or "true up and down" ) returned a different result from the A/D converters depending upon the temperature. And the further you go down into the Earth, the hotter it gets. You didn't want your directional drill heading off onto someone else's plot of ground just because it got hot, that could be a legal mess!

So basically, what we did was bake the probe, then watch the signals as it cooled off. A test run consisted of taking the probe up to its maximum operating temperature, pressing the ENTER key on the Commodore 64, and then turning off the oven and letting it cool down. As it cooled down, the Commodore bit-banged the values in from the probe and created a table in memory as well as graphed on the console. This was done in each of the six orientations of the probe. At the end of the test run, the table was printed out onto a piece of paper to be entered into the calibrated software that went with the probe (calibrated software that did *not* run on the Commodore 64, it ran on a standard PC under MS-DOS, and yes, I wrote that software too, based on equations I was given by their chief scientist).

So do this with a smartphone? Okay, challenge accepted! Some of the things being done with APRS and Android on ham radio would work here, that's another instance where you're interfacing a smartphone with an analog system. I would use a $25 Arduino board ( https://www.arduino.cc ) to bitbang the signals. I would use an $8 Bluetooth adapter for the Arduino that presented itself as a Bluetooth UART adapter. Then I would use the Bluetooth Serial profile on the Android phone to actually retrieve the streams of data from the Arduino, process them, display them as pretty graphs on the phone's display and, since this is now the 21st century, send them to a server on the Internet where they're stuck in a database under the particular directional drilling probe's serial number.

Of course, it's be just as easy to have the Arduino do that part too, if you choose an Arduino that has a WiFi adapter, and use the phone only to prompt the Arduino to start a test run and to display the pretty graphs being generated on the Internet server. It'd be even easier to use a laptop with built-in Bluetooth. But hey, you challenged me to do it with my phone, so there. :P .

-ELG

Wednesday, October 28, 2009

The smartphone maze

Much has been made of recent improvements in Google Android phone sales. Android phones are now available (or will be available by November 1) on all major U.S. carriers except AT&T, and many carriers will have multiple Android phones. There are some who say that this will doom the Palm Pre, which along with the iPhone has the slickest user interface of all the various smartphones out there. But my own analysis is that this isn't so: The smartphone OS that Android is supplanting is not RIM's or Palm's, but, rather, Windows Mobile.

It is little secret that the development of the next generation of Windows Mobile is a disaster. Windows Mobile 6.5 has been announced for the end of this year to collective yawns -- nobody thinks anybody is going to actually ship a phone based on it. Windows Mobile 7 has been announced for next year to barely concealed guffaws. Nobody who is serious expects a viable Windows Mobile 7 to come out anytime before the end of next year. What has happened, during this era of stagnation in Windows Mobile, is that WM vendors are now migrating to Android for their new smartphones. Android supports the new features of the new smartphone hardware, while Windows Mobile doesn't. And while Android is a user interface disaster, so is Windows Mobile -- both systems embody pre-iPhone paradigms of how to do things where each application has its own unique user interface, as vs. the new multi-touch common-user-interface paradigm where all user interface coding must go through a library that enforces a common look and feel. In short, where geeks used to go to WM because it was a (relatively) open platform with a lot of capabilities such as multi-tasking that the competition did not have, now they're going to Android instead because it has those same attributes but supports newer hardware.

So what seems to be falling out of all this is that Windows Mobile is going to go the way of old-school PalmOS shortly. The current vendors of WM phones such as HTC appear to be engaged in a mass migration to Android. But this does not mean that sales of the iPhone and Palm Pre will be hurt by Android. They are simply different markets -- Android, due to its fundamental design and development processes, will simply never be able to match Apple or Palm on ease of use or consistency of user interface between applications. Like Windows Mobile, Android is a geek product. Plenty of geeks will likely end up migrating to Android, but there is a huge market for smartphones as people max out the capabilities of standard candybar/flip phones between Twittering and everything else they want to do with phones, and most of these people are not geeks. Vendors like Apple and Palm are well positioned to go after that market... but Android simply doesn't play there, any more than RIM does with their crackberries.

-E