Showing posts with label GPS. Show all posts
Showing posts with label GPS. Show all posts

ICAO To Airlines: Watch Where You're Going (Every 15 Minutes)

online engineering degree/engineering degree online/online engineering courses/engineering technology online/engineering courses online/engineering technician degree online/online engineering technology/electronic engineering online

Once in a great while, I have the satisfaction of making a prediction or calling for a certain action in this blog, and then seeing the called-for event actually come to pass.  Last month, the International Civil Aviation Organization (ICAO) issued a new set of tracking requirements for airlines in participating countries, which means just about every airline that flies in more than one country.  While a formal vote on the requirements won't happen till later in the year, the slow-moving machinery of the United Nations—of which the ICAO is a part—has finally creaked into action.  So it may not be too much to hope that the kind of situation that has kept the destiny of Malaysia Flight 370 a mystery to this day can be avoided in the future, or at least that such incidents will produce data that will make the plane easier to find.

Flight 370, which disappeared a year ago March 8, was supposed to stay within range of ground-based tracking radars.  But when it veered way off course toward the open ocean for reasons that are still unknown, the limited-range ground radars lost contact with it, and an onboard satellite-tracking system was not working, possibly because it was intentionally disabled.  The upshot was that once the flight disappeared, investigators had to use some arcane technical tricks to estimate the flight's last known location, and the resulting poor accuracy and long gaps between known locations have left searchers stuck with many thousands of square miles of ocean to cover.  The plane may never be found.

Back in January, I blogged on this tragedy and noted that the U. S. National Transportation Safety Board (NTSB) was urging the Federal Aviation Administration (FAA) to adopt improved flight-location technology.  I also noted that while this move would help us to find international flights operated by US carriers, a truly international solution would have to await action by the ICAO, which has now begun to act.

As reported in a recent Associated Press article, the ICAO rules would require each airline to get location updates for all their flights every 15 minutes.  How they get the updates is up to the airlines.  Deep-pocketed operations such as Air France already have automatic satellite-location systems in place, and probably either already meet the requirements or can change their operations slightly to comply.  Less well-funded airlines can fall back on having their pilots look at their pocket GPS they mail-ordered from Walmart and use their shortwave radios to report their position.  Any way will do, says the ICAO, but you have to update your flight locations every 15 minutes.  If the rules are approved, this requirement will go into effect in 2016, which is by UN standards almost instantaneously. 

A second part of the ruling pertains to automatic flight-location technology, typically a satellite link.  By 2020, all new airplanes carrying more than 19 passengers will have to go into a minute-by-minute location transmission mode if an emergency occurs such as a steep dive or significant deviation from the flight plan.  The five-year delay from now would give airframe manufacturers and their customers time to ready the technology and the money to pay for it, respectively. 

By specifying in the 15-minute rule the desired outcome rather than the technology required to achieve it, the ICAO has done a clever thing.  Each airline can tailor its response to its own circumstances and adopt an approach that doesn't place an undue burden either on the flight crew or on the airline's budget for new equipment.  For reasons that are not clear, but may have to do with relationships between large avionics companies and the federal government, FAA rules tend to be much more prescriptive of exactly how certain goals are to be achieved technologically.  Historically, the FAA owned and operated much of the technology itself, so naturally the agency got in the habit of telling the airlines what matching equipment they needed.  But nowadays, the central-control model is pretty old-fashioned and is being superseded by distributed technologies that rely upon a combination of public, private, and open-source resources to work.  Safety-critical technologies are a breed apart, and a certain level of standardization and certification is reasonable.  But I wonder if things might move a little faster in domestic aviation technology if the FAA took a hint from the ICAO, and moved toward simply telling airlines what is to be achieved, and let the firms themselves figure out how to achieve it.

All this comes too late to help those on the ill-fated Flight 370, which is probably—but not for sure—somewhere at the bottom of the Indian Ocean.  The death of a loved one is always a tragedy, but there must be a special pain associated with not knowing anything about the person's final hours, and what mischance caused their demise.  Sooner or later, someone will probably find the wreckage, and if enough evidence can be recovered it may be possible to reconstruct what happened.  But in the meantime, I hope that the proposed new ICAO rules will make it much less likely that airlines will simply lose track of a plane while someone runs off with it, and can even prevent such incidents from occurring in the future.

Sources:  The article "Airlines move to better track their planes" by Scott Meyerowitz and David Koenig was carried by numerous newspapers, including the Deseret News on Mar. 3, 2015 at http://www.deseretnews.com/article/765669470/Airlines-move-to-better-track-planes-a-year-after-Flight-370.html.  My post "High Time for SatelliteTracking of All International Flights" appeared on Jan. 26, 2015.

High Time for Satellite Tracking of All International Flights

online engineering degree/engineering degree online/online engineering courses/engineering technology online/engineering courses online/engineering technician degree online/online engineering technology/electronic engineering online

This coming March 8 will mark one year since Malaysia Airlines Flight 370 disappeared from radar en route from Kuala Lumpur to Beijing somewhere over the Indian Ocean.  The wreckage has never been found, although communications experts used some almost accidental satellite-transponder data to estimate the last known location of the plane.  At the time, I recall thinking that if I was an airline and owned a number of high-value mobile assets known as airliners, I would want some way of knowing where each one was every minute or so, anywhere in the world.   After all, the technology for tracking the much cheaper assets called semi-trailer trucks has been around for years.  The little white domes on truck cabs report minute-by-minute locations to a data center where operators can pay a monthly fee to any one of a number of firms to keep tabs on shipments, and truck drivers too, for that matter.  But there is no international requirement for airlines to do the same.

Last week, the U. S. National Transportation Safety Board (NTSB) waded in with a recommendation for all passenger airliners to be equipped with improved location technology.  The board admitted it was motivated partly by Flight 370's disappearance, and called both for improvements in in-flight tracking and in "black-box" technology. 

The in-flight tracking part seems to be pretty straightforward technologically.  It would operate more or less the same way as the truck-tracking system.  Every minute or so, a GPS receiver on the plane would send its location to a satellite in view, and the satellite would relay that information to a data center, where it would be logged and made available in the event of an incident of interest.  The only slightly tricky part would be identifying which satellite to use.  But there are already geostationary satellites in orbit such as Inmarsat which provide virtually world-wide coverage, and the missing bits of Earth near the poles could be made up for by linking to numerous low-earth-orbit satellites in polar orbits. 

The technology is not nearly so much a hurdle as the cost and the peculiar structure of international aviation regulations.  The NTSB's recommendations went to the U. S. Federal Aviation Administration, and if the FAA adopts them they will be obligatory for all U. S. airlines—but nobody else.  Because the U. S. operates only a fraction of international flights over large bodies of water where the technology would be most useful, the idea will not succeed without international cooperation, and that means the International Civil Aviation Organization, or ICAO.

The ICAO is a United Nations body in charge of international standards for, well, civil aviation, as you might expect.  As such, its rulings have no force of law in individual countries unless the countries' own aviation regulations require that its carriers follow ICAO rules as well, which most do.  It was a 2008 ICAO ruling, for example, that required all air traffic controllers and flight crew members involved in international flights to be proficient in English.  I'm rather surprised that it took until 2008, but after all, everything takes a while at the UN.

The question is whether and when the ICAO might follow the NTSB's lead if the NTSB prevails with the FAA to make international-flight GPS tracking mandatory.  Enough alphabet soup for you?  The whole process—from tragic accident to technical recommendations to changes in laws and regulations—is typical of how safety technology develops in coordination with regulations requiring its use.  And the regulatory part is particularly tricky when it involves spending money.  The requirement that pilots speak English can be met by changing hiring practices, but GPS tracking will involve both up-front and ongoing expenses for new hardware—which itself needs to be standardized somehow—and rental fees to the commercial firms that operate the satellite transponders used to convey the location data.  Fortunately, we are not talking about large bandwidths here—the equivalent of a single cellphone text message every minute or so would be sufficient.  But coordinating all this will take some doing, and coordination of any kind at the level of the ICAO is a challenging and slow-moving process at best.  If they took till only seven years ago to agree on a common language for radio communications from international flights, the ICAO isn't going to churn out new GPS-location rules overnight, you can be sure. 

The other part of the NTSB recommendations concerns the nature of the onboard flight data recorders.  Now that video cameras and recording equipment are so inexpensive, the NTSB says we should have cockpit video as well as audio recorders, and that controls for the entire system should be inaccessible from the cockpit.  (There is some suspicion that the radar-transponder system of Flight 370, which works only within range of ground-based tracking radars, was intentionally disabled by the pilot.)  Also, the NTSB floated the idea (so to speak) that the flight recorders should be housed in buoyant housings and ejected upon impact so that they can remain on the surface, where their radio signals could be more easily received than the limited-range and limited-time sonar emissions that the units currently send out underwater. 

All these are good ideas, and if the FAA adopts them they will make an already safe U. S. air-travel system even safer, or at least increase the likelihood of finding any flights that go down in deep water.  And the information from such accidents is always valuable in preventing the next one, whether it was caused by mechanical failure, human error, or evil intent.

Nevertheless, I am not going to be holding my breath until the ICAO follows suit.  You would think that the international carriers themselves would have adopted something similar to the truck-tracking systems years ago, but there may be a mentality in place that makes such a system seem unnecessary because of the vanishingly small number of incidents in which it would turn out to be useful.  But once GPS tracking for international flights is in place, I bet folks find other uses for it, for things like fuel-economy efforts and even weather tracking.  But first, the ICAO has to get in gear, so stay tuned.

Sources:  The article "NTSB:  Planes Should Have Technologies So They Can Be Found" by Joan Lowy of the Associate Press was carried by numerous outlets, including ABC News on Jan. 22 at http://abcnews.go.com/Politics/wireStory/ntsb-planes-technologies-found-28409934.  I also referred to Wikipedia articles on Malaysia Airlines Flight 370, Inmarsat, and the ICAO.

Addendum Feb. 1:  Edwin Doetzal wrote me on Jan. 31 as follows:

"Your analysis of MH370 contained a couple issues:
Airliners do often have SATCOM tracking 'like trucks'.  On MH370, this system was turned off along with the radio transponder.
ADS-B is the new satellite based air traffic control system that will replace the radio based air traffic control system and is already being implemented through efforts by NAVCanada and ICAO.
What is currently in discussion are new systems such as AFIRS that would stream amounts of data automatically or by trigger in an emergency as well as explosive jettisoned FDR/CVR units.  Knowing where an aircraft was is of course not enough without the detailed DAQ information that might explain why the emergency happened and what action was taken by the flight crew.  A truck's limited DAQ can be retrieved from the ditch.  Please be assured that an airliner is a much more sophisticated system than a truck.
It was somewhat troubling to see such an article on an 'engineering ethics' blog.  With respect, it would seem that you are speaking outside your professional scope.  A retraction would appear appropriate.
Regards,

Edwin Doetzel

Lay Person"


It was careless of me to imply that airliners had no such tracking systems, and I apologize
for leaving that impression.  In the space I had, I meant to concentrate not so much on the technology as on the international coordination that would be needed to implement it uniformly so that flights such as MH370 would not slip through the cracks.  My thanks to Mr. Doetzel for the correction.  

Raspberry PI CarPC September 2014 updates

online engineering degree/engineering degree online/online engineering courses/engineering technology online/engineering courses online/engineering technician degree online/online engineering technology/electronic engineering online
Hello!

I have made some progress on my CarPC project and here are the main changes:
- support for Raspberry PI Model B+
- update XBMC to 13.2 stable
- update kernel to 3.16.0
- reworked radio(rds is available but not yet enabled because of some high cpu usage - will fix this shortly)
- update system available(only ~150MB for download instead of a whole image)
- file system restructuring
- new skin
- forum released(Engineeryng-Diy Forum)

First of all the installation process(this is only for a fresh install, update coming soon):
- write a fresh image with the latest Raspbian from http://www.raspberrypi.org/downloads/
- copy the carpc folder in /home/pi/ on the SD card(gt this folder from my Downloads page/updates)
- plug the image in RPI and start it
--- use the auto menu to expand file system
--- change password to 'a'
--- enable boot into desktop-> Desktop Log in as user 'pi' at the graphical desktop
--- enable ssh, disable overscan, disable serial messages
--- Change Internalisation Options -> Locale and Timezone to your country
- connect a keyboard and open the terminal or connect using ssh
- change user permissions for pi: sudo chmod -R a+rwx /home/pi
- type cd /home/pi/carpc/ and then ./carpc-install.sh and then wait for the system to install
Note! If you get Cannot mkdir: Permission denied running this script then you should type sudo chmod -R a+rwx /home/pi/carpc/ and then run the script again.
- after this, you should reboot(sudo reboot)

Calibrate the touch screen
Forget about xinput-calibrator and X11 calibration metods.
If you have calibration file(/home/pi/touchscreen_axes_calib) from a previous installation you can use it.
If you don't, then use the touch screen calibration plugin. This plugin works if you set correctly the Raspberry PI resolution in /boot/config.txt. Follow the steps in this video.

Add a map for navigation
Go to Navit Planet Extractor and download a .bin file for your area.
Copy the .bin file in your RPI card in /home/pi/.navit/ folder. Rename the .bin file to map1.bin, map2.bin, map3.bin or map4.bin.

Setup the GPS receiver
  1. For USB devices. After plugging the device into the usb port type dmesg and you should see somewhere that a new device was mapped on /dev/tty... Most probably the file name would be /dev/ttyACM0.
  2. For Serial(UART) modules. The device will have the file name as /dev/ttyAMA0.
You can test that the device is connected to a file name by calling cat/dev/ttyAMA0, for example and you should see some NMEA output.
Now, copy this file name and put it in the file /home/pi/StartCarPC in the section:
    # Start gpsd
    # /dev/ttyAMA0 - RPI serial port
    # /dev/ttyACM0 - usb port
    sudo killall gpsd
    gpsd /dev/ttyAMA0

Voice configuration for Navit
Each time a road indication has to be made, Navit will execute the file /home/pi/.navit/speech.sh with the indication text. This file will play a sound and the speak the indication, through speakers.
    aplay -r 44100 /home/pi/.navit/notification3.wav & sleep 0.7 && espeak -ven+f4 -s150 -a 150 -p 50 "$1" --stdout | aplay
    /home/pi/.navit/notification3.wav - the sound that will be played each time before an indication
    -ven+f4 - female voice number 4
    -s150 - speed 150 words per minute
    -a150 - amplitude
    -p50 - pitch
You can find more settings in the espeak manual
If you don't want the voice guidance you can press the speaker button in Navit and it will be turned off.

Configure the Controller
The controller can be easily used with Steering wheel controls or other physical controls in your car.
You can set the configuration file like in this post.

Change the car logo in the Home screen
The car logo is a png file in /home/pi/config/logo.png.

New skin
Thanks to Doru, a new skin is available: CarPC-touch_carbon.

Comments moving to forum
From now on, a forum is available for any issues/suggestions(http://engineeringdiy.freeforums.org/). Due to this, comments on this blog will be disabled.

Have fun!
Andrei

A Tech Fix for Texting While Driving

online engineering degree/engineering degree online/online engineering courses/engineering technology online/engineering courses online/engineering technician degree online/online engineering technology/electronic engineering online

By now, almost everybody with a cellphone and a car knows that it's a bad idea to text while you're driving.  But people still do it, and some of those people die in text-related car crashes and take innocent victims with them.  What if technology existed that simply prevented people from texting from a moving car at all?  Wouldn't that solve the problem?

Scott Tibbetts thought so.  Tibbets and his company Katasi were profiled in a recent New York Timesarticle for developing a promising technology that would simply block texting from any phone that was in a moving car.  While there are several technological solutions to this problem that are already on the market, they all have various problems. 

Some text-blocking apps work by using the phone's GPS to figure out if the phone is moving faster than walking speed.  If it is, the software concludes that you're driving, and blocks texts.  This one turns out to be a battery hog, because the GPS system has to run all the time.  It also might present problems for train and bus passengers.  Another system uses the car's speed sensor and links it to the phone with a Bluetooth wireless connection.  But it costs over a hundred bucks, and there aren't that many people who are both concerned enough about texting while driving to buy it, and also willing to shell out that much money for something they could do for free with a little more willpower, perhaps. 

Mr. Tibbetts' solution is cleverer than these.  It involves connecting a wireless box to the car's OBD-II port—the on-board diagnostics socket that the auto technicians use to figure out what the "service engine" light means.  When the car's moving fast enough to be dangerous, the wireless box sends that information to the cellphone network, which then asks the phone—once—where it is.  Then, if the network is using the software developed by Mr. Tibbetts' firm Katasi, the software uses the location data to figure out things like who is driving the car.  You don't want a whole family's text service blocked just because Mom is driving to the grocery store, for instance.  That way, the GPS battery-drain problem is minimized, and the computational heavy lifting is done in the cloud, so to speak, rather than by the phone.

Mr. Tibbetts, an aerospace engineer and entrepreneur, has persuaded both an insurance company and a cellphone provider (Sprint) to cooperate in test trials, which have worked fine.  But it appears that the largest player, Sprint, has gotten cold feet lately, and has stalled further tests.  In the Times interview, Wayne Ward, vice-president for business and product development at Sprint, expressed concerns about product liability.  Currently, if a driver texts while driving and gets in a wreck, it's the driver's fault.  Mr. Ward asks what might happen if Sprint sells the Katasi system that claims to prevent such accidents, and then some glitch happens and somebody sneaks through a text and crashes anyway?  Why, Sprint could be sued!

Pardon me, but it appears that there's more going on here than meets the eye.  Any time a small independent company comes up to a big firm and offers the big guy new technology, the not-invented-here problem can raise its ugly head.  Short of buying the small upstart outright (which happens a lot, by the way), if the big firm adapts the small company's technology, they will be on the hook for royalty payments or other forms of obligation that big companies don't want to be tied down to.  And there's also the simple pride factor expressed by the phrase "not invented here"—if we didn't think of it first, it can't be that good. 

Besides, it's not clear who would make enough money to offset the expenses of the added hardware and software—and lawyers' fees, if Mr. Ward's fears turned out to be correct.  The existing GPS-based solutions for text blocking in cars aren't exactly selling like hotcakes, even after all but five states have adopted no-texting-while-driving laws of one form or another. 

One could imagine a legal solution:  make something like the Katasi text-blocking system mandatory by government fiat.  Nobody has seriously put forward that idea yet.  But it might happen.  There was a time when ordinary window glass was used in automobiles, with the result that otherwise minor wrecks turned deadly when razor-sharp knives of glass flew around and sliced—well, enough said.  But when the technology of laminating glass with a plastic inner layer was developed around 1920 to keep the shattered pieces together, auto companies adopted it, partly motivated by fear of lawsuits.  Eventually, most countries made it a legal requirement for all glass in automobiles to be laminated or safety glass, but it looks like the firms were ahead of the government in that case.

Safety glass is a different kind of thing than automatic text-blocking.  An auto company could start using safety glass and just raise the car's price incrementally, and hardly any customers would notice the change.  But as soon as you stop a person from doing something that they're used to doing, like texting while driving, you create a sharp negative impression.  And that's something that cellphone providers are reluctant to do as long as there are competitors ready to take business away.

My hat is off to Mr. Tibbetts, who put five years and millions of dollars into developing a clever technological fix for a significant problem.  But as many engineers turned entrepreneurs have learned, building the better mousetrap­—or text trap—is only part of the problem.  Convincing people to buy it and use it is often harder than coming up with the invention itself.  If everybody used something like the Katasi system on their cellphones, we would all be safer, no question about that.  We would also lose a little freedom of judgment which we can now exercise, which is whether to text while driving.  Perhaps some telecomm industry leaders will get together and agree to adopt Katasi, or something like it, but such inter-company cooperation for a non-financial thing like safety is a rarity.  It could happen, though.  I bet Mr. Tibbetts, for one, hopes that it will. 

Sources:  The New York Times article "Trying to Hit the Brake on Texting While Driving" by Matt Richtel, appeared in the online edition on Sept. 13, 2014 at http://www.nytimes.com/2014/09/14/business/trying-to-hit-the-brake-on-texting-while-driving.html.  I also referred to Wikipedia articles on on-board diagnostics, windshields, and safety glass. 

Raspberry PI CarPC April 2014 updates

online engineering degree/engineering degree online/online engineering courses/engineering technology online/engineering courses online/engineering technician degree online/online engineering technology/electronic engineering online
Hello!

I have made a lot of work on the project, with great help from Doru Ignat(idorel@gmail.com) and now the complete list of features is:

  • latest Raspberry PI firmware(which supports new models and has fixes for analog sound - no pops any more, you can use the analog out of RPI)
  • linux kernel 3.10.30 with various touch screens support and also lirc
  • reworked XBMC CarPC skin
  • XBMC 13 Gotham beta3(1080p video support, any music and picture format, support playing from archives and more)
  • reworked XBMC touch screen calibration algorithm
  • XBMC calibration plugin for touch screens(eGalax and others)
  • reworked FM Radio plugin
  • latest Navit build from source
  • fixed Navit to alllow using espeak for speech guidance
  • support for WIFI(Airplay, XBMC remotes)

The latest image can be downloaded from the right side of this blog, from the Downloads page.

Cost of the needed hardware parts: 193$
  - Raspberry PI model B: 45$
  - 7 inch display with touch screen for car reverse: 80$
  - HDMI male to HDMI male golden plated cable: 5$
  - 8GB SDHC card: 6$
  - 5V(2A) micro USB charger: 3$
  - Columbus V800 GPS module(or any other): 37$
  - SI4703 FM Radio breakout board: 13$
  - 2 rotary encoders: 4$

After installing the image on an sd card, you have to configure the system for your needs.

Calibrate the touch screen
The touch screen calibration involves two steps and you need a keyboard connected:
  1. Calibrating the touch screen for X11 applications(like Navit). Open the terminal from Desktop and type xinput_calibrator and follow the indications. After the calibration is completed you have to put the output in a file to make this permanent:
    sudo nano /usr/share/X11/xorg.conf.d/01-input.conf
Put here the output of xinput_calibrator. It will be something like:
    Section "InputClass"
        Identifier    "calibration"
        MatchProduct    "eGalax Inc. USB TouchController"
        Option    "Calibration"    "121 1917 317 1741"
        Option    "SwapAxes"    "1"
    EndSection
  2. Calibrating the touch screen for XBMC. In XBMC use the keyboard to go to Programs/Touch Screen Calibration and follow the informations on screen.
Note, that in order to make a better calibration you can move the finger on screen towards the point, before pressing enter(as can be seen on minute 0:52 in the video).
Touch each point and then press enter to go to the next one. At the end, you have to unplug the touch from usb and then plug it back(works on XBMC Gotham).
After this, he calibration is stored permanently in the file /home/pi/touchscreen_axes_calib. You can edit this file to fine tune the position of the cursor if the calibration isn't perfect.
    calib_x_d and calib_y_d - control the cursor displacement up/down/left/right
    calib_x_fact and calib_y_fact - some factors obtained in the calibration process(don't edit them)
    click_confines - defines the area that will be used for click(if the touch moves outside of this area then a drag action will occur) - this area is measured from the first touched point
    touch_mouse - if you want to use a mouse you have to set this to 0, but some touch screens behave as mouses and you have to set this to 1 in order for them to work(with single click). For the most of the touches this can be 0 if you want to also use a mouse, but if you don't want to use a mouse it doesn't mater, let it be 1.