Packet Radio, Part 7 (Raspberry Pi reinstall)

As of my last post, I had a working packet install, able to do APRS and Winlink.  My routine (for a couple of days at least, hardly a routine) was to power the RasPi down between sessions.  I'm scattered enough, and have enough other hobbies, that I never know if I'll be back on-the-air in hours or months; I am who I am :/.

But after a few days of this, RasPi refused to boot.  Power light came on, but the screen didn't come out of sleep.  That had happened once before, because (I'm guessing here) HDMI cable wasn't plugged in, when I powered up.  But resetting power and plugging in with HDMI connected had worked.

But not this time.  I'm still a bit suspicious that some of my homebrew wiring is lacking something, e.g. proper grounding or similar, but the first thing that I knew I could try was a reinstall of the hard drive.  The Pi 3B+ has a 32GB micro-SD card, and I could remove it, put it into the USB adapter than came with it, and see if I could read it on Win10.  Nope, appears dead; not sure if I could read it when it was good, i.e. read its Linux filesystem under Windows, but oh well.

So I reformatted.  Raspberry Pi provides a new installer these days.  IIRC, last time I used Balena Etcher to write the SD card, but now the new installer just does the job itself.  So I did that, and it booted just fine.  Whew, glad that I didn't fry the Pi ;).

Reinstall from that point wasn't difficult at all, following the prompts on-screen.  VNC is a bit of a pain, requiring me to add a 'Authentication=VncAuth' line to /root/.vnc/config.d/vncserver-x11, to be able to reconnect.

But then I couldn't find Direwolf.  I had installed a binary version of 1.6, but no Googling could turn up a download site.  (I could probably find it right away, now that I've got it working, but oh well.)  To get it working, I followed the instructions in the docs to clone the 1.6 git repo and build from source.  10 min of bash hacking, and it was up and running.

I did try going with the 1.4 version from the Raspbian repo, but that didn't work, in a couple of ways: 1) the screen output blinked (highly annoying), and 2) while Winlink would connect, and PTT'd the radio, it wouldn't connect.  Turns out #2 was my fault, but #1 was also annoying, and 1.6 fixed that, so I don't regret upgrading.  Fixing #2 was a matter of including the right ADEVICE line in my direwolf.conf file.  My entire file is:

MYCALL KC3LZY
PTT GPIO 25
ADEVICE plughw:2,0

So all of this, and turning the volume down in alsamixer (to remove the "high output volume" messages that Direwolf was giving) got me up and running again.

One last footnote, though, and that's that I would like to try to get an external HD running on RasPi, and run everything off of that, and boot RasPi in read-only mode, just in case it was having the RasPi power off incorrectly that corrupted things and made it necessary to reinstall.  We'll see what I manage to do there.

Packet Radio, Part 6 (Antennas, and Winlink)

A couple of months later, and I'm getting back to packet, in various ways.

First way was realizing that I'm really getting tired of lugging antenna the 5-6 steps out of shack closet to master bedroom.  It's time to get that sucker up to the attic, and into a more permanent setup.

My first thought and attempt was to run a cable up through the ceiling of a closet off my shack.  No luck; a hole I poked apparently went up just beyond the reach of the upstairs attic.  Talked to a neighbor, who suggested trying to run a hole at an angle, to reach into the attic, but that ran into a stud or similar.  He also suggested finding the top of the wall frame, and run the cable down into the wall, to an outlet, which I still might do.

But what worked was poking a hole in the ceiling above the shack, but slightly concealed behind the door.  This was about mid-attic, easily spotted, and the RG8X run down through it.  First problem solved.

Second problem was reconnecting to a socket.  First try there was to solder the braid to the socket, but whether my soldering pencil wasn't hot enough, or the socket frame not prepared properly, it just didn't work.  Google was my friend, though, and suggested solder lugs, which oh yeah I did that before, and had several spare lugs sitting handy.  Soldered the cable lead to the socket center pin, and taped it up.  Second problem solved.

All that, and was able to get on the air.  Somewhere over the recent past (since my last blog post), I'd installed Winlink Express, and gone through the setup, and established an account.  I'd sent email to myself, received it, and replied, but not seen the reply come back to my Winlink account.  But after that, I wandered off (because, well, that's what I do...).

So after getting antenna issue settled, I checked my Winlink mail, and hey whaddya know, I've got mail!  Presumably somebody from SPARC sent a couple of test emails.  So I crafted a reply and sent that off.

I sent off another email to myself, received it, and this time replied with a /WL2K in the subject, and that try got through.  Yay, I can talk to myself!

Then started looking around for other things to do.  Had found mention in an ARRL email of a Winlink net covering my area (the Great Lakes Area Winlink Net) and sent off an email for that.  Then saw that Virginia has a similar ("the original") net, and sent that off.  A couple of days later, I had responses from both nets, so now I have something to do on Wednesdays (I've got local club voice nets on Mon and Tue, so this is good :).

Packet Radio, Part 5 (More APRS, and a tiny bit more)

Tuesday nights are K3IR nets, and because I still haven't moved my 2m antenna up into the attic, for a more permanent setup, I pulled it over into the front bedroom a few hours early, and got YAAC running, sending out beacons.  Everything was in the "same" place, but for some reason, it behaved differently.

Initially, YAAC sent the beacon at 1 minute intervals, and APRS.fi saw them fine, but YAAC didn't.  I believe that YAAC reports what it hears over the air, which means whatever local digipeaters are echoing.  Which means I was sending but not receiving?  After maybe 15 min of hearing nothing, I checked on the radio, the feed line, the antenna; all seemed fine.  And it started working.  Did I move something just enough?  Do I have a loose connection somewhere?

My "desired" operating position is for RasPi to be in hamshack, and for me to be either on the couch downstairs, or at least in my recliner on the other side of the hamshack, with Direwolf or FT8 on RasPi, and YAAC or GridTracker (respectively) running on Win10.  So that much is working nicely so far, at least for the DW/YAAC pair, as well as TightVNC letting me poke at RasPi without having to trudge upstairs as often.

So for a few hours, I (watched TV, and) poked occasionally at YAAC.  It's mildly annoying that when you start YAAC first (before DW), it complains loudly, and doesn't appear to let you then start DW and retry the connection.  1st world problems, I suppose, to need to close YAAC and reopen, but then maybe I'm just missing a button.  (Looks like you can click the RF button, top center, and Enable Port; will try that next time I mess up ;).

And speaking of missing buttons, I'd been mostly watching the Raw Packets window last time, and did overlook the Station/Object List, but found that and like it.  I'm still trying to find a way to get DW's expanded display of individual packets, but in YAAC; raw is ok, to know what you're seeing and from whom, but YAAC doesn't display it in any humanly readable form.  Again, 1st world problems.

I've been talking about packet to club folks via our email list, and knew of one guy who typically runs APRSISCE.  Seeing him on APRS.fi, I tried sending a message, and APRS.fi heard 2 of the 3 send attempts, but I got no reply, and an hour later he was off the air.  Will try again another day.

Once club's 2m net started, I shut YAAC off and switched 8900 over to voice, but then realized that with dual operating bands, I could continue to receive digital into DW, while I listened to the net.  I flipped (from APRS on 144.390) over to 145.030, and after a couple of minutes saw K3IR's ID from WinLink, then tuned 145.010 and saw a handful of other messages and idents.  So there is packet in the area, and close enough for me to hear, which is encouraging.

Up next will be to try to connect to one of these other stations.  WinLink is on my radar, especially as club has a node already running.  I had previously mistakenly thought that WinLink was proprietary, Windows-only, and paid-only; turns out there are multiple open source implementations that run fine on Linux.  And by coincidence, the latest ARES letter mentioned a WL net that covers PA.  So yeah, I'll be looking into that some more.

Beyond that, I'm still wanting to find local BBS's, and re-learn what I used to know back in the early 90's, as far as connecting to distant stations via multiple hops.  Too much fun, not enough time! XD

Packet Radio, Part 4 (Soldering, and Sending/Receiving APRS)

Ok, time to roll up our sleeves, and get things hooked up.  Or rather, getting past my apprehension of soldering :/.

First step, getting the DIN socket hooked up to the breadboard.  When ordering, I looked around all of the various DIN sockets Jameco had to offer, and none of them looked like they were breadboard-friendly, so I kinda figured I'd be trying to solder wires to the pins.  But that didn't go very well; my hands aren't bad, but by the time I got 4 wires soldered, I had at least one solder bridge, and too much of a smell of burning plastic.

So I took a step back and reached for something a bit more doable.  I cut an audio cable in half and soldered up the wires to breadboard jumpers, tested the connections with my ohmmeter, and wrapped them in electrical tape.  Small successes are still successes.

At that point, I cut my losses with the DIN socket, cut my DIN cable in h (alf, and soldered up jumpers to those wires as well.  With that done, I could plug everything into the breadboard, wire up the circuit, plug the other end of the DIN into my FT-8900R, and try things out.

So I turned on RasPi, fired up Direwolf, and YAAC, and OMFG lookit that, I've got my icon in the right place on APRS.fi!  Now THAT is cool.

Hmm, except I can send but not receive?  Were there radio settings that affected that?  Poked around 8900, and all that looked fine; it's set (and defaults) to sending on the main transceiver, so that's good.  Looked around Direwolf settings, and that all seemed fine.  Oh yeah, audio levels really matter for Direwolf, and RasPi's were set way too high.  Or off.  Or something.  Fixed that, and packets started rolling in.

Which (given that I'm being called for dinner) is enough excitement for one session.  Will leave things running and see what I get.  Up next will be seeing what kind of fun I can have with APRS via YAAC, but then there's what got me started on this, which is connecting to packet BBS's.

Edit: who am I kidding, I'm sitting here after dinner, watching the packets roll in, and poking around all of the YAAC windows.  Edited the (Transmit tab) beacon destination, from APRS to APDW13 to indicate Direwolf (it also had APJYC1, but I missed what that meant until after I had APDW13 being sent out).

YAAC.  I like the "heard stations" display.  Direwolf's packet display is nicer (easier to read) than YAAC's raw window, but maybe there's a better display in there somewhere.  At some point, I think I hit "locate", which rather than centering the map, started sending messages out to a station I hadn't heard in an hour; confusing, but once I cleared the outgoing messages list, it settled down.

Probably time to do some reading up on APRS, as well as YAAC, before going much further.

Packet Radio, Part 3 (RasPi interface)

Jameco order arrived, and yes I was like a kid at Christmas!  Not even a little bit embarrassed...

Verified that the 6-pin DIN cable fit into FT-8900R, and got the other end into the DIN socket, (although not without a bit of fiddling; I guess it'll plug easier over time).  Got the Adafruit T-Cobbler plugged into the breadboard just fine; got the cable plugged into the T-Cobbler easily (because the notch makes it obvious which way it should go).

Now to the other end.  Huh, the RasPi 3B+ GPIO pins are just pins, no socket with a notch to know which way it goes.  Guessing the the cable should point off the Pi board, but I'm not so very fond of guessing.  Looked on the Adafruit page, but they had no pictures of the cable installed on a Pi (that I could find, anyway).  Googled it, and found this video, that made it clear that my guess was correct; thanks, vid guy!

Assembled the transistor circuit on the lower part of the breadboard.  (Slightly worried that when I get to putting the 555 on there, it's gonna be crowded, but we'll sort that out when we get to that point.)

Into Direwolf config, and added line with "PTT GPIO 25".  Direwolf started up without error, and without the message that I used to get about PTT not being configured; so that's a good sign.

Hmmm, now I'm ready to test a transmit, and realizing that I don't think I've ever figured out how to tell Direwolf to transmit.  All my previous play was just to get Direwolf to decode received signals, and that all worked easily enough (IIRC).  Looked around the User Guide, and saw mention of protocols and software, and YAAC was familiar from one of Josh's videos.

So I got YAAC fetched and installed on my Win10 laptop.  I already had Java running, from various past projects, and once unzipped, could just double click the YAAC.jar and have it launch.  Walked through the guided setup, then went into expert mode and changed the (Transmit tab) 'beacon destination' and (Beacon tab) 'beacon type' and 'enable station beacon' settings.

YAAC's (Beacon tab) lat/long setting is irrelevant for today's test, but I verified that it was set correctly from guided setup, and saw that the map display was actually centered on my house, which is cool.  I love maps :).

And then I added an entry on the Ports tab, to point Win10 to RasPi.  First try was using AGWPE mode, but while that connected to RasPi, Direwolf gave error messages on every connect.  Deleted that entry, and tried a KISS-over-TCP port, and it worked first time.

Well, at least it connected to Direwolf, which displayed an APRS beacon line.  Pretty cool, by itself.  But my circuit lights didn't blink.  What am I missing?  Time to walk through what I know is working, to where it might not be.  Direwolf thinks it's using GPIO 25, or at least isn't complaining that it can't.  Is RasPi swallowing the request to raise GPIO 25 pin?

Back to the docs, and found this page that talked about the current RasPi user needing to be in the gpio group.  But I'm logged in as the 'pi' user, and 'groups' command showed 'gpio' is already there.  So that should be good.

Went looking for sample code, to test.  Found this code in Python to toggle a pin on/off.  Quick vi edit session, and ran the code, and still no blinking lights.  Hrm.

Time to look over the circuit again.  +3.3vdc through one LED/resistor to base of transistor.  GPIO 25 through the other LED/resistor to collector of transistor.  Emitter of transistor to ground rail on breadboard.  <facepalm> ... and I forgot to connect the ground rail to a GND pin on the RasPi!  One more lead in place, rerun the Py code, and ... lights!  They are blinking!

Ok, kill the Py code (do multiple processes fight over GPIO access?), restart Direwolf, back to YAAC, and now it's not talking to Direwolf.  Went into YAAC config, edited the port, changed nothing, just resaved, and YAAC reconnected and sent beacon to Direwolf, which triggered GPIO 25, which blinked the lights!  (Guessing that "proper" operation, then, is to run Direwolf, then YAAC, and life would be fine.)

Well.  That was a wall of text.  Hoping it helps someone, in some way.  At this point, I think maybe I'm 1/3 of the way through the wiring effort.  I do still want to add the 555 chip to the circuit, and then of course hook up the DIN socket and audio lines, so that I'm actually pushing PTT on the radio and sending a signal out.  The ultimate smoke test here will be firing up YAAC and seeing a current report on aprs.fi.  And once that's working, to be able to actually connect to a packet bbs, and do other fun stuff.  But that'll be for another day (or at least another post)...

Packet Radio, Part 2a (antenna repositioning)

Parts order is on the way, from Jameco, but I wanted to do something, so I got a longer antenna feed cable (50' of RG8X coax), fixed a loose board on the base of my homebrew 2m dipole, and ran the new cable from my hamshack/gameroom/office, over to the antenna located in my bedroom (at least, until wife comes upstairs and asks what the heck is this thing doing in her bedroom :p).

Pretty minor stuff, but I learned a little something.  In the past, when I've tried to transmit from a radio in the hamshack, the speakers on my game computer hum, and hum loudly.  Sure, it might not be a serious problem, but it's a sign of RFI, right?  My first attempt to transmit today, with the new setup, also caused RF hum, and even though the antenna was an extra 15-20' away, it was as loud as ever.

But I was running 50' of feed line across 25' of space, which meant spare cable, coiled on the floor of the hamshack.  I moved that coiled feedline from the hamshack to the bedroom, and voila, transmitting causes no hum in game computer speakers.  Problem solved (or at least moved elsewhere).

The other, more significant problem that I was trying to solve was actually being able to communicate with the club repeater.  I've tried a few setups: 

• dipole in hamshack (fail)
• dipole in bedroom (success)
• Baofeng in bedroom/living room/etc. (fail)
• magmount on Jeep in driveway (success)

Only the dipole in bedroom, and magmount on Jeep, give any success.  So this new arrangement, with radio in hamshack but dipole where it's worked in the past, is an additional success, and a better arrangement for indoor operating.

The last thing I want to try is to move the dipole up into the attic, and run the feedline up through the ceiling of the hamshack closet, but that'll be an experiment for another day.

Packet Radio, Part 2 (a very simple transistor circuit)

Now, onto trying out a circuit.  The bottom-right of the diagram in Direwolf's Raspberry-Pi-APRS.pdf looks like this:

Testing this out is pretty simple.  I centered everything on a 2N2222.  I then wired the 2.7k resistor (plus an LED, to give some visual indication that it's working) to a DPST push-button switch, to +3.3vdc (coming off an Arduino, because I had one handy :).  The PTT line I ran through another LED and another resistor (4.7k, in this case) to the same +3.3vdc rail on my breadboard.  The ground line, of course, went to the ground rail.  Push the button, both lights come on, and Bob's your uncle.

The point of doing this is a) because it's easy and rewarding, at my (basic) skill level, b) it proves that I have a (working) transistor, and c) that it won't fry at +3.3vdc.  I mentioned in an earlier post that I needed some stuff from Jameco, and with their $20 minimum (at least without a hefty surcharge), I wanted to know that I have the basics.

What I'm missing, and will have on order very shortly, are:

• A GPIO breakout for the RasPi.  This device will let me connect all of the pins on the RasPi to a breadboard, and make it very easy to play with all the components.
• A 6-pin DIN cable.  The Yaesu CT-39A cable is $20; the 10' male-to-male cable off Jameco is $4, which means I'm one snip away from *two* CT-39A's, if I need them.
• A 6-pin DIN socket, to be able to connect the cable (and hence the 8900) to my breadboard.  (I hope; looking at the datasheet, it might not be as simple as plugging the socket into the breadboard, but at worst, I can solder leads to the socket pins, and go from there.)
• A CMOS 555 timer chip, which is the center of the other 90% of the circuit in the pdf (and a ceramic capacitor pack, because I don't seem to have any below 1uF).
• A breadboard, because if I get it to work, I'll likely want to not take it apart.  (Which is also me saying I'm not yet up to designing a PCB, to make this permanent, but maybe we'll get there someday... one step at a time...)

Packet Radio, Part 1 (my equipment)

So because I'm cheap frugal, I'm wanting to get this working with as much of my existing equipment as possible.  As mentioned previously, I've got plenty of Raspberry Pi's floating around, and because there are software TNC's like Direwolf, that seems like the way to go for the computer, and hopefully for the TNC as well.  I'm also pretty comfortable with either SSH or VNC, to get from any of my other computers (e.g. a Windows 10 laptop) to the RasPi.

From the other end, I've made a homebrew 2m/440 dipole antenna that seems to work fairly well.  It's connected via RG8U coax to a Yaesu FT-8900R that I've also been quite pleased with (tons of memory, fun to program, easy to toss into my car with a magmount antenna, etc).

That just leaves one last little problem: how to get the two ends connected.  And this is where it seems to get a little bit messy.  Yaesu offers a cable, a CT-39A, that goes into the data port on the back of the radio, but then ends in bare wire.  The 8900 manual gives hints on connecting that to your TNC, but my TNC is inside a computer, so that's of little help.

My first step was to look around for ... for what?  Being new to this, I wasn't even sure what to look for.  There are TNCs, like the Mobilink or the MFJ-1270, but again it seems like overkill if I've got all these little $30 boxes and open source software that will do that work for me.  So I went to the Direwolf docs and forums, and started reading there.

The forums mentioned soundcard interfaces.  Hey, I've got some of them too, already.  Little USB plugins that have audio in/out jacks on them; I've even managed to get audio out of SDR# on my laptop to audio in on the RasPi via one of these devices, and seen FT8/JS8 decoded there, just for grins.  So they work, at least in one direction; my task is to get them to work in the other direction.  And to figure out PTT.

PTT is Push To Talk.  It's how the radio knows that you want to transmit, and not receive.  When I got APRSDroid working with my Baofeng, I used VOX on the Bao, and let the radio itself realize that there was sound coming from my phone, and start transmitting all by itself (and hence no PTT needed).  That "worked" (occasionally), but to my knowledge, the 8900 doesn't do this, and even if it did, I'd like to take advantage of the fact that a) Direwolf knows enough to send PTT info, somehow/somewhere, and b) the 8900 data cable has a PTT line (pin 3).  So how do we wire that up?

The Direwolf forum, in discussing the USB soundcards, pointed me to C-Media devices, that apparently have a way to control PTT.  Step 1, remove the soundcard case; step 2, microsolder a fine wire to a pin on the SMD chip... okay sorry, when they said "advanced", they meant it; this is over my head/ability level.

But there are products available to help with this.  One set of products is available at MastersCommunications.com, e.g. the RA-42, but the price tag of that, assembled and tested and with a case, approaches $100, and scares me off, plus I didn't quite find one that looked like it had the right cables, etc.

Another such product would seem to be the Easy Digi  interface.  It even lists the 8900 as a supported radio, which is encouraging, and comes with the 6-pin mini-DIN cable that would connect it to the 8900.  (I mistakenly thought for some reason that the 8900 used a 9-pin DIN, and asked the Easy Digi guy about a custom wiring; he quickly got back to me, and politely set me right about it working for my application.  +1 for support!)  If I end up not being able to get my homebrew solution to work, that'll probably be my next path down this road.

The third route, though, that I discovered from the "Raspberry-Pi-APRS" PDF on the Direwolf site, as well as heard mentioned a few times on the forum, was putting together a "transistor circuit" to control the PTT pin.  Initially, the idea kinda scared me off; I'm pretty new to cobbling together my own circuits for things.  But once I looked over the schematic, and realized what it was doing, it now seems like the way I'll try.

By way of background, I did take a bunch of electronics courses, in high school and college, but that was 30 years (cough) ago, and I've forgotten most of it.  (Plus I was way more interested in coding back then, and probably just skated through as much of that as I could.  Oops.)  In more recent years, I've been reading Make: Electronics (that I got from one of the Humble Bundles), and that's been a BIG help in getting more comfortable with all of this.  In fact, I've only just finished the chapter on transistors, and understanding that has the transistor circuit in the above PDF making easy sense, and feeling very doable.  So yeah, highly recommended.

Which brings us up to current.  I've got most but not all of the parts I need to give it a go, so I'll be putting together a Jameco order, and start putting together some test circuits.  More details to come shortly.

Packet Radio, Part 0 (and reviving the blog)

TL;DR: I got my amateur radio license, bought radios, joined a club, and want to hook up a radio to a computer, to do packet.  These articles will document what I'm doing there, to get it all to work.

The show so far:

My club, SPARC, (or at least somebody at the club), is putting up a packet node.  I have fond memories from the early 90's of playing with packet radio, so I'm keen to play along with this setup as well.  Back in the day, I had a Kenwood 2m radio, a TNC of some flavor, all the cables connecting the two, to each other and to my computer, and was on the air.  Yay, memories!

30 years later (cough), and I'd like to figure it all out again, and see what I can do.  I have multiple computers, including a few Raspberry Pi's, and I'm of the mind that I should be able to get on the air with a software solution, instead of buying a TNC.  I'm nothing if not cheap frugal.

So there's Direwolf.  Somewhere over the past couple of years, I hooked up an antenna to my SDR dongle, to my laptop (running SDR#), to Direwolf, and was able to decode APRS packets.  Pretty cool.  I then hooked up APRSDroid to my Baofeng, and saw my base station displayed on aprs.fi, which was even more cool.  But then I wandered off in other directions, and forgot about it.

My intent is to write up details about my efforts in blog posts, and collect the overall setup in this page.

Up next: my research efforts, to figure out this brave new world.

Footnote: Yeah, after a 10-year break :-o, I'm coming back to blogging.  Like the rest of the world, I long ago headed over to "social media", and forgot about long-form posting, but over the past few years, lost my love for that as well.  And since I have a project that I'd like to document, I'm coming back here.  Maybe.  Hopefully.

The iPod Touch/Android Shakedown!

I bit the bullet and got an Android smartphone a while back, and figured I'd use this page to sort out what I like and don't like about it, as compared to my old iPod Touch.

The Prices

My Android is a Samsung Intercept. I got it for around $200, and a 300 minute/month, unlimited data plan for $25/month from Virgin Mobile. My iPT was around $200, and last I looked, Apple wanted around $200 for an iPhone, then $70/month at a minimum for the cheapest voice and data plan (through AT&T, was it?). Yeah, in this case, Virgin Mobile spanks AT&T, especially considering how little I use the voice side of my phone. Heck, AT&T's data alone was $40/month. Sheesh. So yeah, base price is about even, but Android plus Virgin Mobile beats the iPhone pretty easily.

The Actual Phone

The unfair comparison here is that the iPT doesn't have a phone. Android wins! (Wait, what?) Well, the Android let me combine two devices into one, and let me stop carrying my plain old phone. And that's been very nice.

OTOH, my old phone, low-tech as it was, was quicker to dial. Unlock the keypad, punch a couple of buttons (for speed dial) or the actual phone number, and you're talking. With Android, you unlock the screen, start the phone app, scroll around to find what you want, it's clunky. In that way, I kinda miss my old phone, but I doubt the iPhone would be much easier than Android, at least from seeing others with their iPhones.

Other Unfair Comparisons

My Android has a GPS and camera. My iPT is an older generation model that doesn't have either. Android wins! (Hey, stop that!) Actually, I've used the camera maybe two or three times, and until I feel like pretending that I'm a photographer again (it happens every two or three years), I don't really seem to be messing with it much.

The Android GPS is tolerable, I guess, but the software leaves something to be desired, (i.e. I can scroll the map to look around, but can't select a point on the map as a new destination), and it's not hard just in driving around to get it to give obviously bad driving directions. (I'm getting a stand-alone GPS for Christmas; we'll see how much better that is.)

The Hardware

Here's where Apple shines, and the fanboys can gloat. (Hi, Andre!) The Intercept has a smaller screen and thicker body, while the iPT is noticeably larger. +1 for Apple.

Also, not sure whether it's the Intercept's processor or touch screen or what, but where the iPT may be slow or pause on 1 out of 20 interactions, the Intercept is sluggish maybe half of the time. I was playing with my iPT for the first time since I got my Android, and it was VERY nice not having it lag on just about everything. While that's probably not Android's fault, Apple gets another +1 for homogeneous hardware that just works.

But the Intercept gets kudos for having a keyboard. If you're reading stuff on the iPT, it's nice, but putting input INTO one is a bit tedious. I've sent maybe a dozen emails from it in the couple of years that I've had it. I've sent that many via the Intercept in the last couple of weeks, as well as had SMS conversations with folks, and it's just NICE! +1 Intercept!

And while usually Apple just GETS hardware, my Intercept came with a wall plug USB adapter. +1 Samsung, (even though I'm actually only using the wall plug on my bedstand to keep my iPT charged).

The O/S

This gets subjective. In a nutshell, iOS is simple, Android is more powerful. And as a geek, I often like powerful over simple. But not always.

Okay, some particulars. With Android, I can connect to a machine on my network via SMB, pull an MP3 file down and have it show up instantly in Android's music player. It takes a little geekery (I probably lost some of you when I said SMB), but it's possible. It's also possible to see exactly what's on my SD card, and move things around if I want.

Neither thing is possible with iOS. With iOS, you load songs via iTunes, which doesn't run on Linux. So I need to borrow Wife's Mac to put things on or take things off of my iPT. Silly, but simple. Apple assumes A) you aren't running Linux, and B) you'll be plugging your iPT into your main computer regularly. Wrong, and wrong. I've never plugged my Android into a non-Linux computer, and only once have I actually used my Android as a USB drive. (It's not exactly simple to do, +1 Apple.) But the point is, I don't need to. The thing is wireless, why would I need to plug it into a computer?! +2 or +3 Android.

But then I sit down with my iPT, and all my apps are right there, and they're simple and they just work. Hrm. What's a geek to do?

Email

Android has a native GMail app. Yay, Android! But that app only does GMail, and you need another to check an IMAP server, while iPT has one mail client that tolerably does both. Yay, iPT! (But, as I mentioned, my Intercept has a keyboard. Yay!)

Web Browser

Android's web browser is clunky; Safari on the iPT is smooth. In particular, bookmarks on Android are weird, and I'm still trying to figure out if I can do tabs. Safari just works. +1 iPT, if only for being easier to figure out.

The Stores

Both devices have their stores to get apps. Again, Apple does simple, while Android does functional. I'm not on Mac or Windows, so none of the links to apps take me to iTunes, so simple breaks. But the Android store and web presence in general isn't as smooth, somehow. I think in both cases, I'm a bit spoiled by the search awesomeness of google.com, and hate not getting that in the device stores. But the availability of apps hasn't been a problem on either device; no clear winner.

One other thing, though. I can develop my own app on Linux, and put it onto my Android, if I want to. I can't do that with iPT. Now, to be honest, I'll probably never actually do that, so I can't factor that into a score, but the geek in me loves that I can. So there.

Twitter & Facebook

Both services have clients for both devices. I realized that I prefer Twitter's mobile clients on either device to their web client, as it's more obvious when I get replies. (Insert twitter grumbling here). Facebook's clients seem equally tolerable on either. No winner here.

YouTube

Both devices have YouTube clients, and both are frustrating in that they won't let you search for a channel or user. The Android client will let you pull up your subscriptions, but the larger ones seem to go into some other mode that just shows activity on the account, which is weird, and is not what I want. But the Android client can also do playlists, so you can go to the web site, setup a playlist, and watch in on the Android, which I've never found a way to do with the iPT. +1 Android.

Other Apps

I love GoodReader on iPT, and hate that they don't have an Android client. Adobe has an Android version of Reader, which is kinda cool, but not as easy to use. Dropbox exists on both, and OMG you can edit text files on the Android! +2 or +3 Android! And they sync back to the server (since it's Dropbox)! +2 more for being so awesome! Weather Channel exists on both, but they have real estate issues on the Android (some screens have not quite half of the already small screen being scrollable; come on!) Google Reader has an app on Android; haven't looked on iPT, but it's nicer than the mobile web app. ESPN is on both, and equally clunky on either.

Bottom line is that, for the apps I use, the two are about equal.

Other Annoyances

I've already beat up Apple for making me use iTunes for way too much with the iPT, no need to belabor that here. Intercept has its problems with the interface, and I'm also still trying to get Android to notify me exactly when and how I want. Having a separate phone was easier in that regard, as I never got email on my phone, just SMS, which I did want it to wake me for. To date, I don't keep my Android on the bedstand, which means I can miss SMS's that I'd rather not miss, but I'm still working on figuring that out.

Conclusions

So I'm actually going to punt, and not declare a solid winner here. I like them both, for different purposes, and they each have their strengths. I'm finding that for being on the go, in my car, waiting in line, etc., I'd much rather have my Android. For laying in bed and reading web pages or watching videos, it's kind of a toss up, but I like my iPT, and plan to keep using it.