Blog-Shmog

Blog-Shmog.com explodes!!
An error in Blog-Shmog.com's auto-backup script sends its database down in flames...

One of the "gotcha's" that comes with any database-driven website such as Drupal (or wordpress or moveabletype) is that you essentially have TWO content sources to backup: your database and your webroot. Lose either and be prepared to spend lots of late nights doing emergency repairs!

Blog-Shmog.com explodes!!

5 weeks after upgrading to Drupal 6.x, I stumbled upon (got shitkicked by) a small but disastrous mistake. Back when I first started the upgrade process, I duplicated my database and set up a development environment (so I could perform the upgrade without disrupting anything). Once the update was complete and debugged, I copied everything back to my production server BUT I completely forgot to update my auto-backup script to reflect the new Drupal 6 database name. So every week, my custom backup script was backing up the old, unchanged (and outdated AND INCOMPATIBLE) drupal 5.x database!! I discovered this fatal error one day when I decided to roll back my database by 24hrs to fix a small development glitch. I unpacked my latest tar file, cleared my database and restored from backup. Oops! Blog-Shmog.com died.

I instantly lost over 5 weeks of content, comments and edits- everything since the Drupal 6.x upgrade. All thanks to a missing "_6" in my backup script. grrrr!!

Yelling, Screaming, Boozing & Restoring

After pouring myself 2, three, four stiff drink(s), I went to work rebuilding... I threw my old Drupal 5.x webroot back online, loaded up my old database and went about upgrading to Drupal 6. again.

Restoring the Drupal core and contributed modules actually went a lot faster than I expected. I guess I learned a few tricks during my first 6.x upgrade that served me well the second time around, but getting the framework back was the easy part. --- And then it hit me- Google probably cached my website!! ...Sure enough, by searching for specific keywords relating to my missing pages, I brought up Google's (only 4 day-old, by the way) cache of Blog-Shmog.com and copy/pasted everything back into Drupal. The process was simple, but reeeaaaaally slow. Each comment had to be re-entered manually. one by one. in the proper order.

I manually re-entered over 25 comments, 3 page nodes, a user profile and a custom contact form, all thanks to Google's cache! Try THAT pre-Google (sorry waybackmachine, no cookie for you.)

Lessons Learned

No0Oo0Ooo!!!

Learn from my misfortune:

Always, always, always backup your shit.
Obviously, this doesn't just apply to your website. But you alrady knew that...

Make sure to backup your webroot AND your database.
There are backup modules floating around the drupal community, but most of them either only backup your database, or have been abandoned since drupal 5.x. Choose your backup method carefully!

Once your site is backed up, CHECK THE BACKUPS!!
If I had just spent the time to go through my sqldumps more carefully, I would have noticed my Drupal 6 tables were missing. dumb-dumb.

Enjoy your backups, but don't trust them.
If for whatever reason you need to roll-back your database, do a manual backup first, just to be safe. Paranoid: probably. Worth it: definitely.

If you DO lose your data, GOOGLE-IT FAST.
Don't wait! If you wait too long to check Google cache, it might re-cache your busted-ass website!! If you need more time to do the repairs, copy/paste all the Google cache you can get your hands on and safeguard it for later.

Restore cached content IN ORDER
After restoring your content, you can manually adjust each comment's (or node's) datestamp, so you can match it to the original post date. However, you can't re-order your posts once they're created. I found this out the hard way, and had to create a custom Views block to show my recent comments block in the right order.

Manual Backup

If you have shell access to your webserver, you can easily create an instant backup of your website from the command line. sign into your webserver and cd to your webroot, then type:

tar cf webroot-backup.tar ./

This will create a compressed tar file named webroot-backup.tar in your webroot that you can then download via FTP or keep elsewhere on your webserver for safekeeping.

You can create a mysql dump of your database by typing:

mysqldump --user=[USERNAME] --host=[SQL-HOST] --password=[PASSWORD] --add-drop-table [DATABASE-NAME] > database.sql

This will create a file named database.sql. (If you don't change directories between the two backup commands, this file will also be located in your webroot!) Remember to swap in your own values into the fields: [USERNAME], [SQL-HOST], [PASSWORD] and [DATABASE-NAME] (You can find them in your Drupal settings.php file, if you need...).

It's a very bad idea to leave the backups in your webroot, so make sure to either download & delete them, or move them elsewhere, outside your webroot, mmmkay?!

Shmackup v1.0

Shmackup.sh v1.0
click to download...

After adding a stupid little underscore and a stupid little 6 to the [DATABASE-NAME] field in my auto-backup script, everything was up and running again, and my site was being backed up as it should. Here's what I use to auto-backup my site... introducing: Shmackup.sh. Shmackup will export your webroot and database and pack them both into a gzipped tar.gz file with a date-stamped filename. No selective backup features are available in v1.0, but v1.1 is currently under development and will support selective backups, allowing you to cut down on file size by skipping cache and session tables.

Configure and upload Shmackup.sh to your server (outside your webroot, dumdumb!), chmod +x it, and schedule a cron job to run it at a your desired backup interval. I usually set it to perform weekly backups for normal use, and up the interval to daily backups when I'm doing development or playing with settings. Just play with the crontab value to adjust the backup interval to suit your needs.

No matter which backup solution you decide to use, always double triple check your backups before ever blindly accepting that your website content is safe. And if you don't (yet) have any backup methods in place for your website, at the very least SSH to your server and run the command line tools (above) or sign into phpmyadmin (or whatever other mySQL front end you use) and export yourself a fresh database dump.

The single most important thing to remember is: if you DO lose your data, don't panic. Head over to Google and immediately re-download your data from Google cache. It won't do much for deleted files from your webroot, but it CAN help you rebuild your ENTIRE database!

I've recently been given the opportunity to be one of the first GPS-bloggers to get my hands on the Columbus v900 Bluetooth Datalogger. (thanks to my friends at buyGPSnow.com) I spent the last month with the v900, evaluating its build quality, battery performance, usability, functionality and data accuracy. The v900 is a very cool little unit, featuring a 51 channel MTK chipset, an internal 1000mAh Li-Poly battery, Bluetooth, a microSD card slot and even a built in microphone for recording and geo-tagging voice memos. It's all housed in a very tiny, very sleek stainless steel & polycarbonate shell.

Form, Design & Aesthetics

Columbus is gaining a reputation for exceptional industrial design and the v900 is no exception. The Columbus v900 is VERY small. Sit the v900 next to any other GPS device on the planet and you'll instantly appreciate the engineering that went into getting all its functionality into such a small, elegant package.

The front face of the v900 is cut from an almost mirror-like glossy black polycarbonate plastic, housing three status LEDs and a giant circular waypoint button. The jet-black front face matches up perfectly with the matte stainless-steel backplate and helps make the v900 a very solid and robust little device.

On the top edge of the device you'll find a mini-USB port & the power button, on the side: the voice-memo button and finally, on the bottom: the lanyard attachment and microSD card slot. The Columbus v900 scores major points from me for being by far the most bad-ass looking GPS datalogger on the planet, hands down.

Features & Functionality

Looks may be the Columbus v900's strong-point, but functionality is where it really counts -and sadly, this is where the v900 looses a few key points. Let's begin with what's missing; the v900 has two major faults. The one and only way to download your data from the (max 2Gb) microSD card is by ejecting it and plugging it into a card reader on your computer. It doesn't download over Bluetooth, but more surprisingly it doesn't even download over USB! Big miss here, Columbus!!! This is by far the biggest “oops” that should be at the top of the list for a 2.0 release of the v900.

The next major oops for the Columbus v900 is its non-standard log file format. The v900 saves its log files in a modified universal CSV format, making it illegible to both GPSbabel and GPSVisualizer. You have to convert the CSV files to KML format using the TimeAlbum software provided before use in GPSbabel. (if anyone knows of any 3rd party conversion software that works with v900 CSV log files, please let me know) The silver lining here is that TimeAlbum is java-based, so it's cross-platform and it's surprisingly not a bad piece of software!

Columbus v900 features: An impressive list of features for such a small and compact device. Image courtesy of buyGPSnow.com.

That's pretty much all I have to complain about regarding the v900, so with that out of the way, it's on to the good stuff...

The v900 logs all the right things: {lat, lon, ele, speed, heading, hdop, vdop, satelites, ...} at roughly 1Hz. It has two logging modes: basic and advanced, allowing you to control which GPS properties are logged. The voice-memo feature is really slick. If you've ever stared at a map filled with Wayponts and POIs and forgotten what each of them meant then you know how valuable of a feature this is. If you do a lot of hiking, this feature is especially handy. The v900 saves each voice-memo as a .wav file on the microSD card and makes a link to it in the log file as a special waypoint. The audio quality isn't half bad, either!

TimeAlbum 1.5: The Columbus v900 conversion software is java-based and runs on Windows, Mac & Linux.

If you're running mapping software on your laptop or PDA, then you'll be able to make good use of the SPP Bluetooth connection. As I mentioned before, you can't download log files via Bluetooth, which is a little unfortunate, but if you're in the market for an all-in-one device, then the v900 does offer GPS-mouse ability through NMEA format over bluetooth. If you're on a mac, you can use gps2gex to pipeline the NMEA data directly into Google Earth, or any other mapping/navigation software. It's pretty basic, but its free.

The Columbus v900 has a fairly unique feature, called “SPY mode” which allows continuous standby logging for up to a month! The device will go to sleep for a user-configurable amount of time before turning back on, re-establishing a signal, dropping a waypoint and shutting down again. Smart stuff.

The v900 also offers a few other minor features, such as auto-on/auto-off car mode, overspeed alarm and USB charging. Its internal 1000mAh battery holds a 24-hour charge and recharges via USB in roughly 4 hours. All told, it's an impressive set of features, and puts the Columbus v900 right up in the league of some of the pricey Garmin loggers, but at a VERY competitive price.

MTK vs. SiRF III

The Columbus v900 is the first MTK-based GPS logger I've been able to spend any decent time with, so I couldn't resist a few head-to-heads with my other SiRF III loggers.

head-to-head: MTK & SiRF III-based data loggers @ 1Hz-interval logging through the Songshan district in Taipei, Taiwan on Google Earth.

The v900's MTK chipset uses an active (amplified) antenna, which seemed to give it a very slight advantage in TTFF over other passive devices, such as the SiRF III (time-to-first-fix), especially in urban environments.

In open sky, both MTK and SiRF III chipsets achieved a near-perfect 30-35 second TTFF (as expected), but in the most extreme situations (such as indoors, aboard trains or driving around in the middle of downtown Taipei) the MTK device performed slightly better, achieving its first fix (from cold start) an average of 7-8 seconds faster over the course of 5 extremely rigorous tests in challenging urban environments. The SiRF III chipset, however, appeared to handle signal reflections and position drift slightly better, and would stay an average of 2-3 meters truer during a sample set of 5 extreme urban situations.

Conclusions

I've come to greatly enjoy the convenience of the v900's internal battery over the rechargeable batteries I've become accustomed to dragging around with me for all my older GPS data loggers. The v900's 1000mAh internal battery is more than enough for a full day of logging and its USB charging is plenty fast. You can recharge your v900 in the car, using the 12v car adapter that's included in the box or if you have a solar USB charger or a mintyboost, you can even recharge on the go. Either way, you'll never have to worry about depleting the internal battery away from home.

The Columbus v900 is the only GPS logger that I actually prefer to keep safely tucked away in my pocket instead of bouncing around on a carabiner, clipped to my bag. It's by far the smallest GPS logger I've ever used, and it feels solid in the hand. At first, it seemed a little frustrating to have to eject the microSD card every time I wanted to download the log files, but it became easy to rationalize, as at least I wasn't fumbling with rechargeable batteries like I was with my old GPS units; besides, I keep a keychain microSD card reader attached to the v900's lanyard, so I always have a card reader nearby.

Overall, I'm very impressed with the Columbus v900. It quickly replaced all my old GPS devices as my primary GPS unit, thanks to both its feature-set and stunning design. You can order your Columbus v900 (+ free 1Gb microSD card) from http://www.buyGPSnow.com/ for a little under $100 US.

For more information, you can download the v900 manual (English) and TimeAlbum (v. 1.6, English) from the Columbus website (Chinese, simplified), or you can contact the folks at buyGPSnow.com for any product questions. They have been incredibly supportive with all of my questions during my evaluation of the v900.

And lastly, if you have any questions about the v900 or if there's anything I've missed in this review, you can always drop me a line in the comments section.

It had been a long while since I'd given any thought to browser trending or user stats, but a recent gander into the google analytics' visitor trends for blog-shmog.com tells me that A. 54% of you are using Firefox and B. less than 5% of you are using IE 6. (woohoo?)

54% Firefox,
23% Internet explorer,
19% Safari,
4% Opera, Camino, etc.

Now- being someone who earns his livelihood from internet-related technologies, a few short years ago, figures like that would have come to me like music to my ears, but as I sifted through my analytics stats, I found myself very underwhelmed and -in fact- a bit indifferent.

I've kept close tabs on browser trends since the hay-day of NN vs IE, but I completely lost what little interest I had left the day I discovered javascript toolkits and conditional CSS selectors. -Well, now we're at Firefox 3, Internet Explorer 7 and Flash 9... The web is a whole different place, so it begs the question: Do browser usage stats really matter anymore?

Facts and Figures

First and foremost- my stats come from google analytics' trending of blog-shmog.com visitors. They don't really paint an accurate picture of global browser trends. For more accurate numbers, turn to things like w3 schools' monthly browser stats. Blog-shmog.com is a technology blog, and it's visitors tend to be ahead of the curve when it comes to web technologies. W3schools places firefox adoption at 42% and IE 6 use at 25% (compare that to the 5% I recorded on blog-shmog.com) - The difference is real.

Tools and Technologies

Browser wars: the epic NN vs. IE battle. old school.

The reason browser trending matters to any of us (creators and consumers of the web alike) is because it can be a challenge to build websites and web applications that look and function identically across all platforms and systems and many developers fail to rise to this challenge.

Organizations like WaSP and the W3C create comprehensive standards that all browsers should follow in displaying the sites they visit- but most browsers bend the rules, and others completely ignore them. Even 5 years ago it wasn't uncommon to see websites load two completely separate javascripts- one for Netscape and one for Internet Explorer! But things are improving...

Now developers have tools at their disposal, such as javascript toolkits like jQuery and mootools that will do all the heavylifting and cross-browser juggling for us. We have conditional CSS comments, PNG hacks and countless resources available to help us iron out those other pesky IE bugs. Yes, the world is a friendlier place!

So does browser trending really matter anymore?

Good question, lets break it down:

Should browser trending have an impact in determining the design/IA/usability of our web apps?
NO. Sadly it once did (remember IE's proprietary <marquee> tag?), but it should never, ever, ever, ever be a factor again. ever.

Does browser trending still have an impact on determining whether or not the desired functionality of our web apps are feasible?
No. Nowadays, after relatively minor fiddling, every browser can do pretty much the same thing. Sweet.

Okay, well does browser trending still have an impact on the development strategies used in building our web apps?
No. Thanks to javascript toolkits and frameworks, we can ignore browser incompatibilities and focus entirely on building functionality.

Unless you're building some crazy shiznat that uses bleeding-edge unimplemented technology, what browser your users choose doesn't matter anymore- and if you are, then you're obviously choosing not to target a mass audience anyway, so it shouldn't matter what users you exclude. I'm not saying that web development has reached a state of perfection... far from it! Browser incompatibilities still suck, but at least things have reached a level now where we can iron out the development kinks in a matter of hours, not days.

A responsible web author knows that it doesn't matter what browser is the most popular. A successful web app needs to work in ALL browsers, for ALL users. The difference being that now more than ever, this IS possible. So who cares about browser trending? Bite the bullet and make your damn website work in all browsers. I'm tired of seeing websites that say: "We are sorry, but this site can only be used in Microsoft Internet Explorer.".

Wake me up again when less than 2% of the population use non PNG-enabled browsers... In the meantime, go download Firefox.

I'm definitely anal when it comes to coiling my cables. I take great pride in my wicked awesome technique as I carefully twist each coil over the other to make the most tidy, perfect bundle. Recently however, despite my best efforts in ninja coilery, my Apple 65W Powerbook Power Adapter bit the dust- a cable short in the pull relief, right where the cable exits the brick. Tragic!

With nothing to lose, I cracked, smashed and pried 'er open and managed to hack together a pretty decent repair job. A few hours and a few screwdriver-induced injuries later, she's uuuuh-gly but working again!

Here's how:

Apple designs their power adapters to be disposable. They're not only friction-sealed like their iPods, they're physically glued shut. If you want in, you're going to have to work for it! Get a flathead screwdriver, 2 old butter knives, a few band-aids and get cracking. It also helps to have a handy girlfriend who shares your passion for breaking things, but those can be notoriously hard to come by!

The culprit: a cable short in the pull relief.

The easiest place to start prying is near the physical power plug, opposite the 24v output cable; You should be able to see where the two halves meet. I'd also recommend leaving it unplugged for a few hours before you start sticking any conductive objects into an unknown power supply!

Now might also be a good time to say that I take NO LIABILITY WHATSOEVER for screwdriver injuries or electrocution, nor any lost/damaged property arising from a poor repair job. This is only to be attempted if you KNOW WHAT YOU'RE DOING! ok? ...good.

Cathy Wang:. Mighty destroyer of Apple products.

Apple really crams a lot into these little power bricks. BE CAREFUL. If you're using a knife to wedge the two shells apart, watch that you don't damage any components- they're closer to the plastic shell than you'd expect! You might also want to amputate the cable before you begin, it'll make it easier to fumble with the brick. Update (06/12/08): After breaking open a second power adapter, I learned that a simple handsaw is MUCH faster and safer than a screwdriver... Skip the flat-head and grab a hacksaw!

Something else to note: Between the outer plastic and the goods inside is a very thin metal shell. When you start getting the thing to open up, make sure you don't pry off the metal shell. (see picture.)

The pull-relief. Slowly cut away the soft plastic to expose the knot inside. Be careful!

Getting it open is 70% of the work! Once she's cracked, the rest is easy!! Find the soft plastic pull-relief. It's the small blob that stops the cable from ripping out when you yank on your power cord. Buried inside you will find the cable is tied into a small knot. Get a pair of clippers and carefully start cutting off the soft plastic, making sure not to cut into the cable. CAREFULLY!!! Use small snips! It will take a few minutes, but once it's free, untie the knot and you'll find you have more than enough free cable to start stripping off insulation and finish the repair. Update (06/12/08): SLOWLY, dammit. If you aren't very careful, you WILL slice into the cable. I can't stress this enough...

The rest is straightforward. Strip off enough insulation to work with, and twist & solder the brick back onto it's amputated tail (no hard feelings, right?). Tape up the joint and make sure you have no shorts. Carefully inspect the adapter to make sure you didn't damage any components when you pried it open and you're done! Seal the two halves back together, get out the electrical tape and start taping!

Tada! Ugly, but functional. (Hey, just like me!)

You may also want to zap-strap a twist of cable around the body for extra pull-relief, just to make sure you don't have to do this all over again. It will shorten the adapter a bit, but it's worth it in the long run! It's also a good idea to give the thing a quick test before you tape it all up, but be careful, you've got household current buzzing around inside!

If you want to read a bit more about the procedure before attempting it (a wise choice, pancho), there are plenty of good articles out there to be found.

Good luck!

update: I may have a strange obsession with coiling cables, but this guy takes it a bit too far! Enjoy.

I've recently had the opportunity to test-drive the AMOD AGL3080 GPS Logger. For the past three weeks I've been within 15 feet of the AGL3080 at all times. It's sat in my pocket, on my car dash, in my backpack and I've even carried it around the house in my hand- Just to get a feel for it.

And... I'm impressed.
My DG-100 has a serious contender for pocket-space in my future photowalks.
Here's why:

History

AGL3080 Front. 3 status LEDs: memory full, satellite lock, low battery... yummy.

AMOD has recently relaunched the AGL3080. Their first-gen release was sadly flawed and suffered from susceptibility to RF interference, making the GPS module very inaccurate. AMOD seems to be pretty actively chasing down owners of their first-gen device, and offering upgrades, so if you own an old AGL3080, you should get in touch with them! The new version works flawlessly.

Drivers & Formats

The AGL3080 is a driverless GPS logger, which means it mounts as a USB external drive. If you read my blog post about the DG-100, you know that driver issues with many GPS devices can be a #*$@!'ing nightmare, especially if you're on a Mac!

The AGL3080 saves each GPS track in NMEA format (although oddly enough, it gives each file a .log extension, so make sure GPSbabel doesn't mislabel it as a Geogrid file!)

Convert your file into GPX format to use with GPS Photo Linker or HoudahGeo, or convert it to KML or KMZ to throw into Google Earth.

The device uses the SiRF III chipset, which, personally, is the only chip I trust for good reliability & accuracy- especially in urban environments. (Recently, I've heard good things about the Nemerix chipset used in devices like the iBlue, but it still doesn't have the sensitivity of the SiRFstar III chipset, so no cookie for you.)

This puts the AGL3080 as a front-runner among the small handful of GPS loggers worth considering.

Form & Function

AGL3080 Back. 3 AAA batteries for 15 hours of continuous use. No USB-charging, though.

The AGL3080 takes 3 AAA batteries for about 15 hours of use per charge. It's very sleek & solid and it fits perfectly in my hand or in my pocket, however it's not as flat as the DG-100, so it doesn't stay put on the car dash quite as nicely. The front is smooth & glossy and the The battery-compartment door (frequently the first part to break on many of my devices) is rugged and easy to open. It has a built-in carabiener hoop, à la Sony GPS-CS1. (Similar to the Sony, the provided carabiener and strap are shite, replace ASAP.)

As I find myself slowly adapting to life in Japan, the carabiener hoop is begging me for a cute dangling cell-phone toy. Update on that to follow.

The device logs position, altitude, heading, speed, acquired satellites, hdop & vdop every 1 second and saves it to its 128mb of flash memory. It creates a new log file for every time the power is cycled, so it's fairly easy to identify tracks if you're looking for a particular day's data.

Sample GPX output. The AGL3080 logs: lat, lon, elevation, heading, speed, satellites, hdop & vdop @ 1Hz. Impressive. Textmate screenshot using skitch.

Richard Akerman has identified an interesting quirk where the log files are missing the standard filesystem created/modified datestamps, though it doesn't seem to affect the data.

While 1Hz logging may be a tad on the excessive side, it provides very good resolution (although I would recommend using a quick GPSBabel filter at download to strip out excess track points within 5m. You can chop your GPX file size by about 2/3 with no reduction to your precious data.)

The AGL3080 won't recharge your batteries over USB like many other devices. Instead, go buy a good wall-mount battery charger. Your rechargeables will charge faster and stay healthy for much longer. Still, it's a feature that many will find important in chosing their first GPS logger and sadly the AGL3080 doesn't support it.

Bottom line

AGL3080 & DG-100. Both devices use the SiRF III Chipset for near identical results. Shown: Route 38 - Takikawa (滝川) to Ashibetsu (芦別), Hokkaido, Japan on Google Earth

Okay- here's the verdict. The AGL3080 hands down beats the DG-100 for one reason and one reason only. Data.

We geocoders are interested in collecting quality GPS data to tag our photos, videos, blog posts, etc. My DG-100 logs only a small subset of available GPS data. (position, altitude and speed) The AGL3080 logs position, altitude, speed, heading, acquired satellites, hdop and vdop (Dilution of precision... look it up.) USB-charging and logging frequency are one way to evaluate a device, but if it doesn't log every single piece of available GPS information, why bother carrying it around with you?

This, of course, is extremely subjective. Some people don't place as much importance on maximum GPS data; they want the smallest device possible, or USB charging- and that's all fine; there are plenty of other GPS devices on the market that are better suited for those criteria. But for me- it's all about the data.

Oh- and the fact that it will work on my Mac without spending a few dozen hours hacking around with a C script is pretty cool too. =)

You can get your hands on a AMOD AGL3080 through semsons, amazon.com or you can contact AMOD directly.

Review & Photography © Kevin Jaako, 2008. All rights reserved.

A few months ago, Cathy & I bought a Globalsat DG-100 Data Logger straight from the local distributor in Taiwan. I was pretty thrilled with it until I tried hooking it up to my powerbook and learned that Globalsat only wrote their lousy, buggy software for PC.

An exhaustive web search turned up a few surprise results from friends Boris Mann and Richard Eriksson (neither of whom had luck with the device either) and unfortunately not much else. There was talk of coming support for the DG-100 in GPSBabel, but the "coming soon" tag had been up for months with no results. Update (09/03/08): GPS babel has recently released a new version with DG-100 support!! (skip this hack, and go download the new version!)

Recently I stumbled across a beautiful C script written by Mirko Parthey that had it pretty much figured out. I hacked together a GPX output function and my DG-100 and my Mac are now very good friends!

First, you will need to grab the PL2303 USB to serial driver from sourceforge. Then download (or install from CD) Xcode from Apple.

Once you're done, grab my revised copy of Mirko Parthey's dg100.c which includes several small bug fixes and GPX output mode and you're ready to go. Compile the program with gcc dg100.c -o dg100read and run it from terminal using ./dg100read > myGPSfile.gpx to redirect output to file. To change device functions (read/delete/etc), uncomment the desired lines from the script and recompile.

Its pretty unglamorous, but it's simple, reliable and it works on a mac.

A few things to note:

- Don't fall into the trap of only installing Xcode gcc! you need the header & library files. Install it all!

- The DG-100 mounts on my system as /dev/cu.PL2303-3B1. If this is different for you, cd to /dev/ and find the appropriate device name and stick it in the C script.

- The PL2303 drivers are a little strange. The USB port you have the DG-100 connected to will affect it's device name. "3B1" is the address of my powerbook's right-side USB port. You'll either have to keep using the same USB port, or recompile if you ever need to change ports.

- sometimes port_close() doesn't end the session with the DG-100 properly. If the program stops responding normally, just reboot the DG-100.

This is Blog-Shmog.

Born today, the Shmog is soon to become the creative playground for Kevin Jaako. Thoughts of photography, interaction design, user interface theory, web technologies, social networking, the internet, software development, hardware schematics, japan and happiness.

Coming soon?

KJ