Bitt's solution worked for awhile, but eventually I started seeing fields that were screwed up in new and unpredictable ways. The pattern I observed (artist and title field both having extraneous data from the same track's title) didn't always present itself. Sometimes, I'd see extraneous data from the artist field in the title, and a few times, I even saw data from the track playing on another channel instead of the one currently playing. Not at all helpful.

At that point, I thought I was pretty much screwed, but in a last-ditch attempt to get something working, I stumbled upon a solution.

As Trevor alluded to up-thread, the XM receiver supports two commands for getting extended channel info. The "Get Extended Channel Info" command returns data immediately, while the "Monitor Channel Data" command will return the extended track info in the background whenever it changes. Except, every time I'd tried the "get" version, I only got the first 16 characters, and the XM PCR protocol docs indicate that this is a known issue, so, I started using the monitor command instead, and ran into the crazy data corruption issue that spawned this thread.

So, last night, seeing on way to get the monitor command working right, I tried the "get extended" command again, and, again, it only returned the first sixteen characters. Then, just for kicks, I tried sending the monitor command, waiting for it to return its garbage data, and then sending the "get" variant. Voila! Pristine track data, with all 32 characters of both fields.

So, it's not a convenient solution, but it works -- presumably, what's happening is the extended data takes a while to receive, so the monitor command lets me know when it's ready. But, the data that comes back from the monitor command itself is garbage, so I need to send the "get" command, where the data isn't corrupted.

Anyway, thanks for all of the help, guys. Now I can move onto implementing presets, signal strength indication, etc.