Okay, my next issue is a software issue, and I'm stumped.

Usually when my car boots up and my bluetooth chip makes its initial connection to the head unit, I get PDU_REGISTER_NOTIFICATION's from the headunit for the following events:

"PLAYBACK_STATUS_CHANGED",
"TRACK_CHANGED",
"GET_PLAY_STATUS",
"GET_ELEMENT_ATTRIBUTES",

I have no trouble responding to those, and they work well. I find each of the transaction labels from the headunit registering those messages, respond with an AVRCP NFY INTERIM command, and squirrel away the transaction labels for later use. Then later I can send a message up to the headunit saying "hey the playback status changed" or "hey the track changed" using those lablels, and it correctly either changes the play/pause indicator, or it queries me for the track metadata. All is well.

Except...

Lately it's been doing a thing where suddenly at initial connection it's begging for a whole bunch more NEW transaction types that I never saw it request before. I think this is because I improved the unit's initial connection speed and now it's more efficient, so it's coming into the process sooner and now my head unit has different behavior at connection time. I can't just "not respond" to these new messages. If I don't respond to them, it behaves badly, not issuing queries for track metadata, being slow with key press responses, etc. So I have to fix this and respond to all of these messages now somehow.

The new messages that it's registering so far are:

"TRACK_REACHED_END",
"TRACK_REACHED_START",
"PLAYBACK_POSITION_CHANGED",
"BATT_STATUS_CHANGED",
"SYSTEM_STATUS_CHANGED",
"NOW_PLAYING_CHANGED",
"AVAILABLE_PLAYERS_CHANGED"...

There may be more than that coming up later, but I could only get that far in responding before it started hanging. Basically once I got a response to say "TRACK_REACHED_END" then it would start trying to register "TRACK_REACHED_START" then I'd have to respond to that, etc., and it's a vicious circle.

The problem is I can't find any docs on their parameters for their responses! I'm having to guess! The AVRCP command reference here has detailed docs for responding to PLAYBACK_STATUS_CHANGED, TRACK_CHANGED, GET_PLAY_STATUS, and GET_ELEMENT_ATTRIBUTES just fine, but for all the others I only have their event IDs listed in section 6.3.3 of that Silicon Labs document. No details on how I respond with parameter details.

I tried responding to all of them with a single 0 parameter, for example for "TRACK_REACHED_START" I tried responding with "AVRCP NFY INTERIM e 4 0"
where:
AVRCP NFY INTERIM - the response preamble.
e - is the transaction label which changes with each query.
4 - the event ID for the event I'm responding to, in this case 4 means "TRACK_REACHED_START", which I got from section 6.3.3 of that document
0 - another parameter which is a total wild guess as to what the heck I'm supposed to respond with because there's no docs on it.

That seemed to work for most of them, up until the last two (so far):
"NOW_PLAYING_CHANGED"
"AVAILABLE_PLAYERS_CHANGED"

That response pattern doesn't work for those and I can't figure out how to respond to them in the BlueGiga command language. Everything I try results in SYNTAX ERROR and a badly-behaving headunit.

Googling hasn't helped me find the parameter set for those two commands. And I expect when I finally get those responding with parameters it's going to start asking me for more, possibly all the other events listed in that table in section 6.3.3 of that Silicon Labs document.

What I really want to know is how to REJECT some of those registration notifications. And I can't find how to REJECT in the BlueGiga command language. I know it can be done because I see other bluetooth software out there which does indeed do rejections to these commands. For example, search for "AVRC_RSP_REJ" here and you'll see that there's a way to do it, but I can't find out how that's implemented in the BlueGiga command language. I've tried various random syntactical things but they all produce SYNTAX ERROR when I try them.

Hm. I'm getting SOME inforamation from here but not all of the info I need, and of course not in the BlueGiga language.

Still digging.