(Posting here since the empeg connection is ancillary to my problem.)

I've been developing an empeg XM radio interface, and I've got all the basics working, but there's one snag I've run into that I was hoping for some insight on.

The problem has to do with getting the artist and title of the currently-playing song. The serial protocol for the XM receiver I"m using has "regular" and "extended" versions of the commands to get this artist/title information, the extended versions being the ones that give you 32 characters instead of 16. Unfortunately, these extended commands are not working the way they're supposed to.

Here are the basics of what I'm up against:

• The regular get artist/title commands work properly, and seem to always give me back the correct first 16 characters of the artist/title.
• The extended artist and title commands both contain the full artist or title -- there is no truncation of the data except when it's too long for the field.
• When the artist/title is under 32 characters, the remainder of the field is full of junk data.
• There's no terminating character such as a NULL that I can look for to separate the real data from the junk.
• There's no length field I can look for to know where the real data ends.
• The "data valid" field that comes back from these commands is worthless -- it always says the data is valid, but it isn't.

Now, with the above stipulations, normally we'd be screwed whenever the data is 17 <= n <= 32 characters, but the "junk" data is just recognizable enough that I think I can make this work. The thing I've noticed about it is that the junk data appears to be, for both artist and title fields, a portion of the title of the song. That normally wouldn't be enough to go on, but, specifically, it's a portion of the title that starts at index 17 of the buffer, except for the portion that's overwritten with the actual data.

It's probably easier to illustrate. Here are a few of the fields I pulled off of my serial console during testing last night. The green characters are legit data, the red data is junk that's left in the buffer, and the white lines are what the buffer looks like when I get it.


1 character overlap:

01234567890123456789012345678901
One O'Clock Boogie
                 One O'Clock Boogie

One O'Clock Boogiene O'Clock Boo

6 character overlap

01234567890123456789012345678901
Jenny Take a Ride ('66)
                 Jenny Take a Ride ('66)

Jenny Take a Ride ('66)Take a Ri

11 character overlap

01234567890123456789012345678901
Back on the Chain Gang ('83)
                 Back on the Chain Gang ('83)

Back on the Chain Gang ('83) Cha

Title completely fills buffer (degenerate case)

01234567890123456789012345678901
Did You See Jackie Robinson Hit
                 Did You See Jackie Robinson Hit

Did You See Jackie Robinson Hitc

So, armed with the above knowledge, can anyone figure out how I'd go about reconstructing valid artist/title data beyond 16 characters? It seems like it should be doable for at least some cases, if not most -- I just can't quite figure out the magic incantation to make it work.

In your first two examples, you claim to get 32 characters of data, but in the latter two, you claim to only get 31. What's in that 32d position in those cases?

Oh, good catch. I'll update my post to fix that.

Okay, updated.

You using "Get Extended Channel Info" or "Monitor Channel Data" and "Monitor Channel Extended" data?

What happens if you do successive requests for the data? Does the garbage at the end change at all?

Whatever algorithm is used is probably going to be pretty easy to break since detecting overlaps isn't going to be easy not with the wide variety of names out there.

Something like this:

In English: Compare the last character to the character 17 positions before it. If it's the same, assume it's been duplicated. Now check the prior positions for duplication. Keep moving back until there's not a duplication. This is the last valid character; chop everything else off.

There are definitely places where this will break, where there happen to be matching characters in the data:

01234567890123456789012345678901
Really long song titles break only in odd cases

Should be "Really long song titles break on" but will get corrupted to "Really long song titles break ". Worse things have happened.

Won't that hit on any match, repeat or not?

Honestly? This just looks like a flat-out bug in that serial protocol API. This looks like Not Your Bug, and you just need them to fix their bug.

Yeah, updated to point that out. Took me a while to come up with a sufficiently degenerate string.

I'm sure it's a bug in the firmware, not in the API.

Also, if you're doing it in C, you can probably hack something using strstr() and playing with string pointer offsets. Probably less efficient and more obtuse, though.

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.

Whoever programmed the firmware for this radio didn't do much testing. They must have had some device that only displays the first 16 bytes or by chance it uses the sequence you mentioned so from their point of view it works fine.

Good that you've managed to get the full data anyway.