Thanks for the command listing, mtempsch!

Hm, interesting thought about making a software serial driver to turn some of the extra pins into new serial ports.

Arduino boards are cheap and plentiful, though, and the programming is much simpler with an arduino that has extra dedicated ports.

Maybe I'll experiment with software serial just a little bit, though.

hm, the software serial library looks really simple to use, I'll definitely experiment with that, thanks guys!

Yeah, software serial works real good and I didn't need to buy another Arduino, the one I had lying around is doing well. I even tried two different Software Serial libraries, the default one and the AltSoftSerial one.

I have a pretty good working program which will theoretically translate the AVRCP commands from the bluetooth into play/pause/next/previous on the Empeg serial port. But I only have it runnig in debug mode tethered to my computer right now: I'm awaiting an RS-232 shield for the Arduino to come in the mail to make its true functionality a reality.

My only issue with the BC127 purpletooth jamboree board is that when I send an AVRCP command from my stereo (for instance "next track" on the car stereo touchscreen or the steering wheel control), then there is sometimes a significant timing delay before the module receives it and notifies me on its serial port that it has received the command. Not sure how to fix this.

Next question:

Did anyone ever get a thing working on the empeg itself which would display MP3 track titles and artists on the serial port output? I don't recall if that ever happened. The reason I ask is that I now also know the commands and protocols to tell the purpletooth board to send that stuff up to the car stereo to display on its LCD screen. I could scrape that stuff with the Arduino and send it up.

Yes. Hugo did. Though the link in that post is dead now...

I remember it worked quite well, even though with small bit of delay, but not too bad. AFAIK, Hugo never released it though...

Cool! Maybe Hugo will post it here some time? :-)

By the way my code work in progress is here:
https://create.arduino.cc/editor/tfabris/38e25c63-7a46-4939-8d7b-b8db19bf91fd/preview

This is totally not done and I haven't even tested it against the empeg yet (my RS-232 shield arrives tomorrow). But I'll keep updating it as I go along. That link theoretically will update with all my latest code changes.

Hugo mentions in that thread that the best place for a hack like that is in the kernel. Perhaps if you asked Mark really, really nicely

cat /proc/empeg_notify

That has most stuff one might want. It's pretty simple to select/send that to the serial port.

Hmmm!!!

Next question:

Serial port data rate in car and in A/C mode.

Config.ini:
[Serial]
car_rate=9600

I know that one. What's the corresponding one for the A/C mode? Is it just...

[Serial]
rate=9600

?

I'd look it up in the FAQ, but, y'know...

Just set your Arduino to whatever the empeg defaults to? Unless there are limitations on the Arduino port but I doubt there would be any of significance. Maybe on the bit bash serial port?

That's the problem. I think it defaults to 115200 and I am working on software serial which can't reliably go that high on an arduino.

Yeah, "rate=9600" doesn't seem to have worked in my case. Can't remember how to set it without the FAQ. Someone contact the guy who wrote that thing.

It occurs to me that the player will, in the final installation, be using the DC/Car mode because it will be in a sled. So car_rate=9600 will be just fine. As I'm debugging on the bench, I can force DC/Car mode for testing. So that's fine.

But now I have what I think might be another problem. I think that the player might have serial turned off or disabled by default when in DC/Car mode. Is that true? Trying to search old threads about other serial projects talked about needing to re-enable that functionality but I'm not clear on the details. Anyone have any more data about that, for example, whether that's still true in recent versions of Hijack, and what the config.ini commands are for that purpose?

That wouldn't be an issue at all for the "send commands to the empeg" direction. Software serial should keep up just fine for that. It's the other direction (receiving track info from the empeg) that might be troublesome.

Cheers

Yeah, at 115200, all text coming in from the empeg is very glitchy. Though this page says 115200 should work, this page has a different opinion.

Do you remember anything about whether or not serial control for the player software is disabled during DC/Car mode? I think there might be some Hijack commands in config.ini related to it.

I don't recall anything about that. But easy enough to suss out: just connect the empeg to a PC over serial, verify that serial commands are working in AC/Home mode, then force (Hijack) the empeg into DC/Car mode and try again!

Cheers

Indeed, tried that. Serial commands are not being received by the player in DC/Car forced mode, but are being received in AC/Home mode. Both cases with the rate at 115200 bps.

There's some discussion of it here:
http://empegbbs.com/ubbthreads.php/ubb/showflat/Number/144723
http://empegbbs.com/ubbthreads.php/ubb/showflat/Number/173872
http://empegbbs.com/ubbthreads.php/ubb/showflat/Number/183322

I *think* what these are telling me is that I need to enter Config.ini settings like this:
[Hijack]
suppress_notify=0

[Output]
notify=1

Hm. I put in both of those settings into config.ini, along with car_rate=115200, and indeed I see more stuff coming out on the serial port in DC/Car mode but it's still not accepting the N, P, W and C commands when in DC/Car mode.

To be more specific, I have tried it both with suppress_notify=0 and suppress_notify=1, and in both cases the player doesn't respond to my serial commands when in DC/Car mode.

FOUND IT:

http://empegbbs.com/ubbthreads.php/ubb/showflat/Number/237094



I had to change that to "Player uses serial port".

Works perfectly now!

Well done! I had a search earlier and couldn't come up with the right mix of search terms to find that thread. Your search-fu is strong.

Well it was right under my nose in the hijack settings and I should have known it and remembered it.

Well, don't feel too bad. Mark wrote it and didn't even remember it

Current status:

The Sparkfun Purpletooth Jamboree board with the BC127 bluetooth chip is being a pain the ass.

It's primary problem at first was that, when I would press a control on the car stereo, such as "next track", there would be a long delay before the command would get sent to the BC127 chip and show up on its serial port. For example "AVRCP_NEXT" would arrive on the BC127 serial port anywhere from 5-30 seconds after I press the button on the stereo.

That's problematic. Especially since I'm sure the problem isn't the car stereo: It does fine when I pair it with a smartphone, commands are instantaneous then.

I tried digging through all the docs on the web, about commands for the BC127, and tried adding a bunch of commands which disabled features that I wasn't using. I trimmed it down to just using an A2DP and AVRCP profile only, and yet I still had the same problem.

After getting confused about how some commands in the docs worked and some commands didn't work, I realized it was because the BC127 chip that ships on that Sparkfun Purpletooth Jamboree board has a way old firmware version on it. It was an old 5.x release candidate from four years ago and they're up to version 6.x now. There are multiple places to get docs on the BC127 on the web, some are PDF and some are interactive web sites, and they're all contradictory because they all refer to different versions. Once I realized that, things started to make more sense.

So I set out to upgrade the BC127 chip to the newest firmware, in hopes that it would fix the slowness problem. This turned out to be a bit of a pain because the sparkfun board does not contain a USB-to-Serial interface. I first tried making the Arduino be a direct-pass-through program that just exchanged data directly back and forth between the BC127 software serial port and the Arduino hardware serial port. Essentally using the Arduino as a USB-serial converter. However that didn't work: The firmware updater initially connected to the board, reported the version, and started the update, but shortly thereafter would die with an error message, no matter what I did to fix it.

So I overnighted an FTDI Basic Board to connect to the Sparkfun board, so I could update it directly. Initially it didn't work and failed to connect to the updater program at all, and displayed nothing on the serial port. I thought I had done something wrong, or that it was just never going to work at all. But then as a last ditch effort, I reflowed the solder on some of the chip mount points on the FTDI basic board and then boom it worked! I could update the BC127 with the latest firmware!

So now I was able to get the BC127 upgraded to the latest firmware, which is version 6.1.5 from this site: https://www.bluecreation.com/firmwareupdates.php - The commandset is different than the 5.x command set, but I dug through their docs and learned the new commands and updated my Arduino sketch with the new commands.

However, now the slowness problem is actually *worse* than before. If I press a command on the car stereo, it's many seconds before those commands show up on the BC127 serial port. Sometimes now they don't even show up at all.

But here's something funny. If I issue the following commands:
SET MUSIC_OLD_AVRCP=ON
WRITE
RESET

Then it's really interesting because the commands are now instantaneous! If I press Next Track, the command instantly shows up on the BC127! Unfortunately there are still problems:

1. The car stereo's user interface changes so that the track metadata (artist/title/etc) are not displayed any more. The metadata is not supported in the "OLD_AVRCP" mode.

2. The car stereo is permanently stuck in "pause" mode. Pressing the "Play" button on the car stereo does not work and does not send the AVRCP_PLAY to the BC127.

3. No sound comes out of the audio because it's stuck in pause mode. The audio is muted.

So I'm really stumped here. Anyone have any ideas?

I'm going by this manual:
https://www.bluecreation.com/MelodyAudio6/docs/melody_commands.html

In particular, the configuration section here:
https://www.bluecreation.com/MelodyAudio6/docs/melody_configuration/general_configuration.html

Anyone see anything in there that might allow this thing to work correctly with my Honda?

One guess (without reading the docs) is that the board (in "new" mode) is expecting a command termination character of some kind (eg. a '\n' or ';' or something), and the head unit is not sending it. So it sits there until a timeout, and then processes what it has seen to that point.

Interesting guess. Though I would think that the AVRCP protocol would be extremely specific and would preclude that simple of an error. But it's certainly worth investigating.

Other factors that might be relevant:

1. The amount of delay is variable. Could be a couple seconds, could be 30 seconds.

2. In "new" mode there is an on-screen indication on the car stereo's touch screen that gives a hint that it has something to do with the handshaking. Here's my rough description of why I think that:

When I use the car's touchscreen to play and pause, the car has two icons on the screen: A play icon and a pause icon. This is different from most user interfaces where there is a single icon that toggles between play and pause. On this car, it's two separate icons.

Its user interface tells me whether it's in play mode or pause mode by *highlighting* the corresponding icon. For instance, if I press the play icon, then when it goes into play mode, the play icon becomes highlighted. And if I press the pause icon, then when it goes into pause mode, then the pause icon becomes highlighted.

Normally that process is instantaneous. If I have my cell phone paired with the car stereo, if I press pause, then two things happen instantly: The music pauses instantly and the pause icon becomes highlighted instantly.

However, with the BC127, there is a significant delay in *both* actions: When I press the pause icon, it does *not* highlight right away. There is a pause of a few seconds before it becomes highlighted. And at the exact same instant which it *does* become highlighted, that is the same instant that the "AVRCP_PAUSE" message appears on the BC127's serial port!

In other words, there is some reason that the car stereo think that the BC127 hasn't received the pause command yet, and it doesn't update its UI until it gets confirmation back that the BC127 received the command.

So there is something going on here where the handshaking with the BC127 itself is being slow and problematic

Perhaps the two devices are re-pairing on each command?

Excellent guess. I would have thought something similar.

But the results of pairing and unpairing are clearly seen in the serial debugging output screen from the BC127. I can tell when it pairs and unpairs because there are immediate open and close notifications on the screen, and I can get a pairing state report any time.

In fact, you made me think to try something.

Ever since I upgraded the firmware on the BC127, it has had a new problem:
- In either "new" or "old" mode both...
- It always is stuck in pause mode forever, and pressing the Play button on the car stereo does nothing.
- Also presing the pause button never sends the pause or stop command (probably because of the above).

However...
- in either "new" or "old" mode both...
- When I unpair the device from the car stereo using the car stereo's touchscreen controls to perform the unpairing...
- An AVRCP_STOP command is sent to the BC127 instantly with no delay, and then the unpairing occurs instantly thereafter.

So the stereo itself, and the handshaking system, actually have no compunctions about sending AVRCP commands at their core. It can do it.

So the delay is introduced somewhere else for some other reason. Something about the BC127's configuration or protocol is confusing the car stereo. Not sure what, yet.