Now I'm down a weird-ass rabbit hole with the code and the behavior.

So there's this problem where the headunit stays stuck in "pause" mode all the time now with the V6 version of the BC127 firmware. This is an issue because, not only do certain commands not work in pause mode, but also the headunit mutes the audio. So even if I decide to live with some of the other problems, I still get no sound so I can't use the Purpletooth Jamboree board as an audio-only bluetooth streamer board.

Now keep in mind that I'm trying to use the board in what they call "Source" mode right now. Meaning: It's the audio source material (ie the empeg's line audio) which streams up to the car stereo head unit. So in this case, it should never have to send AVRCP commands, it should only receive them, right?

But I found out through experimentation why it stays stuck in pause mode. It's because after it pairs up, it needs to send a "play" command to get the stereo to unmute and go into play mode. It won't allow the headunit to even send it a play command, it has to initiate that command itself. Whaaaaaat?

So here's what I'm seeing:
- Head unit pairs with BC127, at which point a few messages appear including this one:
OPEN_OK 11 AVRCP
(note: 11 is the Link ID, in this case "10" would be Link 1, A2DP, and "11" would be Link 1, AVRCP)
- At that point the headunit is stuck in PAUSE mode.
- So at that point I must send the following command to the BC127:
MUSIC 11 PLAY
- This brings the headunit instantly out of "stuck in pause" mode and it starts streaming good audio.

So I added that to my code. But then something else weird.

So now it's booted, paired, I sent the play command, I'm listening to music. Now I want to pause the music.

When I press the Pause button on the headunit touchscreen, then it goes back into "stuck forever in pause mode" again after sending the AVRCP_PAUSE command to the BC127. (Which still has a weird delay and/or never gets sent in "new" mode, but no delay in "old" mode.)

So one thing I can do, is re-send it a "MUSIC 11 PLAY" command again after that. But then my code gets the "AVRCP_PLAY" command looped back and tries to reprocess that as if the user had pressed play. Catch-22 at that point. So I'm having to swallow the inputs right after I send the "MUSIC 11 PLAY".

But here's what I'm wondering: Why the heck doesn't the BC127 do that shit AUTOMATICALLY? In fact, my recollection is that Version 5 of the BC127 firmware did indeed handle that all automatically and never got stuck in pause mode.

Then I'm getting a weirder thing. Might be bugs in my code constantly looping and sending pause/play back and forth (doubt that, though I'm double checking), but I think it's more likely that it might be a symptom of the "delay" problem under the hood. It goes like this: sometimes when I'm playing music and I press the PLAY button on the headunit, then the music turns into staccato noise, basically sounding similar to what a video game sounds like when there is CPU overloading and the game music turns crackly because it can't update the audio output quickly enough. Like this:

"la la la la lakkkkkkkkkklklklklklklkakakakakakakakakakakaka lklklklklklklklkakakakakakaka la al la la la "

So that sounds to me like, whatever is causing the delays is also causing the CPU to hang up and glitch even on the audio stream. Can't tell if it's the headunit's CPU or if it's the BC127's CPU.

Still futzing with it. Really interesting. And frustrating.

Current state of the code:
- My first Purpletooth board stopped working, stopped responding on the serial port, and I had to get another one.
- It still has the slowness problem in standard AVRCP mode.
- I can switch it to AVRCP "Old" mode, which is pre-AVRCP-1.3 without track metadata, and that makes the slowness problem "mostly" go away.
- But even with "Old" mode there are still problems...
- The Play/Pause buttons don't work, only the next/prev track buttons work.
- FF/REW are nonexistent.
- The headunit starts off stuck in "pause" mode and won't come out of it.
- I can work around it by sending the play command up to the headunit after bootup, and and then the headunit goes into play mode and then it plays.
- But then after that the pause button works... Exactly once and then it gets stuck in pause mode again until I send another Play command up the chain.
- I have coded a somewhat flaky workaround in which my code always sends up the Play command to the the head unit. This tricks the head unit into always thinking it's in "play" mode and then you, the user, can use the pause button if you want. It tries to keep track of what state the player is in (either playing or pausing) and then sends the necessary command to toggle the state. But it doesn't work super reliably.

I've finally found out how to talk to the chip people on the Sierra Wireless forum and I'm getting some response, though they don't have a Honda to test with and are unable to reproduce my problem so far.

Have you thought about trying a different module (perhaps Qualcomm CSR8645?) Maybe you could find something that's less buggy.

Perhaps you could get the Arduino module instead of a separate development board to simplify things.

I have certainly already thought about that. I very much want to ditch the BC127 at this point, but I also don't want to have to roll my own audio support circuitry. That's one of the reasons I went with that Sparkfun board was because it had all the audio stuff built in. It's hard to find anything else with the audio part built in. If you find something, definitely let me know.

In case the problem is the sparkfun board itself and not the BC127 chip, there's this but it's 250 Euros and no guarantee it'll fix the issues.

Like the new pic, by the way.

The old one was on a server at the company I left 9 years ago and they finally decommissioned the server. In the mean time, all the hair migrated from my head to my face.

Ah yes, the conservation of hair principle.

Yeah, great new photo!

I've nearly given up on the BC127 route at this point.

I bought one of Sierra Wireless' BC-127 DiscKit boards which is about 3-4 times more expensive than that SparkFun board.

I bought it because the Sierra Wireless guy on their forum was having no trouble with his BC127, and so I wondered if maybe it was the sparkfun board that was the problem, and using Sierra's own board would solve my problem.

It didn't: The same problems are there. I think that the BC127 is just incompatible with the Honda stereo, or vice-versa. I'm wondering if there is another different place I can source a similar board that's easy to mess with at a hobbyist level.

SparkFun has an RN-52 breakout board. I'd have to roll my own audio connection, but I wonder if the RN-52 is any better? Sigh.

According to that page, it has built-in audio, no? Would it not be sufficient to feed a line level input on the empeg?

I'm going to find out, I ordered one and I'll give it a try.

Also, because I'm curious, I was reading the comments on the RN-52 board page and there's some good info in there, especially that first comment about how to update the firmware. Just wanted to point that out.

Cool, thanks for that info. They have their "instructions" page which says how to update the firmware, but I'll also read through those user comments too and see if there's better information in there.

I think we want the other direction.. empeg feeding head unit over BT?

It has a Microphone input too. Not sure how well that will work for a line in, but I guess we'll find out.

EDIT: Apparently, the current firmware for this module doesn't work in "Master" mode to send audio to another device. It only works in slave mode to receive audio. Perhaps this is a "no go."

EDIT2: It appears that there's a different firmware RN52SRC that is designed for this, so perhaps this is, in fact, a "go". demo.

It's super helpful that you noticed those pieces of information before I ran into those same frustrations on my own. Thanks!

Regarding the audio input, I was hoping that the RN-52 inputs could be made into a stereo line-in, like the BC127. On the Purpletooth board, that part at least worked perfectly. there was a small switch on the board which switched it between mic input and line input. Stereo audio was great. I admit that I didn't look closely to be certain that this could be done with the RN-52 before I ordered it. I was hoping to dig up the docs on it after it arrived.

I'm crossing my fingers really hard about the RN-52 chip, because I think I've taken that BC127 chip about as far as I can go with it unless Sierra finds and fixes the incompatibilities. I've got all the special cases and problem workarounds coded in, and they work (I can hear the empeg through the car stereo, change tracks on it with the car stereo and steering wheel controls, play and pause, etc,), but there are still problems:

- It's only working in "old avrcp" mode without track data. So I can never get the empeg to report track titles to the car stereo with it.

- There is that really weird problem where it has the overloaded CPU issue where the audio turns into KrKrKrKrKrkrkrkrkrkrKrKrKrKrKrKrkkkkkk for several seconds. It mostly only occurs after I use the head unit to switch to another source (such as CD) and then back again. But still, that's a bug in the protocol handling, out of my control.

- The workarounds I've done are not 100 percent reliable or pretty, and have some odd behavioral quirks. Such as, the startup/connection time to the bluetooth is longer than it should be, the play/pause doesn't look right on the car touchscreen (it has to always be in "play" mode and then you use the "pause" button to toggle on/off).

- The workarounds don't handle edge cases well, in regards to timing of things connecting/disconnecting and source switching.

So I'm hoping the RN-52 is more stable and I won't have to do any kludgy work arounds, and I can just do a 1:1 translation of input to output without any special case code.

Also thanks to the link to the RN-52 demo of audio source connection. It shows me that they have a devkit board which already contains the necessary line input plugs:
http://www.microchipdirect.com/ProductSearch.aspx?Keywords=RN-52-EK

Not cheap, but still only about half the price of the corresponding one from the company that makes the BC127.

Apparently it's all the same hardware and the only difference is the firmware.

I think I found the correct firmware file and put it here.

And regarding "line in mode":



That eval kit is tempting, considering it's only $35 more than the Sparkfun breakout board and it would save a lot of soldering and figuring how to mount everything securely

Dude, so cool, thank you!

I find the project interesting, so I was doing a little reading (at 2am...I'm going to be hating life when the alarm to get the the kids ready for school goes off tomorrow.)

But yeah, it can be difficult to find some of this info. The hope is that if you succeed, there's an upgrade path somewhere in my future too

I had to take a break from the project for a week to GOH at an SF convention in Dallas, but I'm back at it this week a bit. Before having to leave for the trip I was successfully able to DFU it onto the RN-52 but haven't had a chance to play with it yet. I'm concerned about that firmware, though, because it's version 1.00. In your research did you notice whether the 1.00 was the only available version of "Source" mode firmware for that RN-52?

I plan to do a lot of googling about it when I dig into it this week.

I am now watching this thread with more interest than before. My Impreza got destroyed this past Saturday morning by another car whose driver didn't notice his red light until wayyyyyyyyy too late.

I've retrieved the empeg from it, but fitting it into the latest vehicles looks much more difficult than it was in the 2013 Impreza.

It's likely to end up under a seat, and having a BT connection might make it easier to access for the driver -- passenger can of course just use the Android empeg app from a smartphone.

EDIT: Say.. I wonder if "Android Auto" can run/display the empeg app on the in-car display?

Cheers

I'm so sorry your car got crunched! Sad to hear we ended up in the same boat. I hope you're physically OK.

I certainly had thought of the idea of going with an app-only way of getting to the empeg's display. I even considered writing an iOS version of my old "EmpegFace" utility.

But it would have meant:
- Getting ethernet+wifi working inside the vehicle.
- Writing the app.
- Using the Apple Car Play and/or Android Auto features. Though I haven't tried Android Auto, I have so many problems with the way the car UI handles Apple Car Play with my phone, that I've disabled it and I'm going bluetooth-only for the phone and I find it much better than Apple Car Play. One day I'll try out Android Auto and see if it's any better.

Ouch. Sorry to hear that -- I hope everyone's okay!

All good. The rear end of the Impreza got completely destroyed, and the bumper got torn off a second car that was in the lane beside me. The guy who hit us pretty much wrote off his own vehicle too.

But.. no injuries to speak of -- I have a very small hicky from either the seat-belt or the side-curtain airbag, but that's pretty much it for everyone involved.

Thinking about maybe the Subaru Crosstrek as a replacement, as it appears to have space for the empeg in the dash. Unfortunately, it is model-year changeover time, and they're in extremely tight supply. As in, waiting for another ship to arrive from Japan. Might take months if I go for that.

The only other small-ish vehicle with ground clearance, AWD, sunroof, and canoe capability seems to be the Mazda CX-3. That one ticks all of the boxes nicely, and is extremely well equipped for the price.

No place for an empeg though, very little in the way of storage within the passenger areas, and it has a rather annoying touchscreen which disables its touch interface when the vehicle is in motion --> they'd rather I have to switch my eyes back and forth between a combination of joystick and buttons, and the screen, and the road, instead of just touching the screen directly. Duh. Clueless.

Cheers

Or maybe not. I googled and found a youtube video showing how to enter the factory menus and "fix" that mis-feature. Gotta go try it on the demo car now.

EDIT: The video's method no longer succeeds, but a more flexible USB-stick procedure still works like a charm. All kinds of tweaks possible!

Mmmm... there appears to be a whole multiverse of hacks for the Mazda (and similar) touchscreens. It runs Linux internally, and has built-in wifi but also supports USB ethernet dongles.

Getting the empeg interface onto the touchscreen looks perfectly doable in those vehicles!

Current status of project:

- BC-127 chip: Great sound, AVRCP commands not working due to the slowness/lockup bug.

- RN-52 chip: Perfect AVRCP implementation with instantaneous command transmission. Iffy/buggy pairing that requires some custom software fiddling in order to make it work reliably. Iffy UART command interface which only accepts commands intermittently. Worst of all: Tons of static and ground loop noise on the line inputs, regardless of which devboard I use or how everything is connected and grounded.

So I've tried two bluetooth chips and run into show-stopper problems with both of them. Anyone know of a third bluetooth A2DP/AVRCP chip I can try? :-)

Try the Broadcom module. From my experience, they are the only one that actually works.

Would love to try one. Any suggestions on a particular one to use? Trying to find one in a form factor with a breakout board.

Something like any of these?
http://bluetoothgpsmodule.wholesale.coquegalaxyfr.com/pz6d427e8-broadcom-bluetooth-module-a2dp.html
http://bluetoothgpsmodule.wholesale.coqu...n-low-cost.html

That first link is the one I found as well.