Sorry that I had the volume turned way down on the music, so you can barely hear the songs playing. Audio is quite good in general.
Existing bugs:
- Empeg serial notifications don't always notify when unpausing the player from the player's own front panel. Though everything works, sometimes the car's touchscreen will display that the player is paused even when it is playing.
- Empeg serial notifications do not include Album name, only track title, artist, and genre.
- Empeg serial notifications can sometimes stomp on themselves, causing parsing errors. Example: Quickly switching tracks on the empeg's front panel with the next/prev buttons can sometimes make a new notification message appear right in the middle of the message that would otherwise be sending one of the track titles. So sometimes if you switch tracks really fast on the empeg's front panel, it will occasionaly "miss" getting the new track info for the current track.
- Now that I'm powering this thing with its own power supply so that both the empeg and the BlueGiga are getting their power from the same 12v source, I have a small (faint) amount of ground loop noise. It's nearly inaudible but it's bugging me and I'm trying to get rid of it completely by fiddling with the routing on the development prototype.
Next step:
- PCB for sandwiching the Arduino to the BlueGiga board, mounting in a nice box, perhaps 3D printing a custom box.
- Actually mount the empeg in the trunk, with the remote display up front via the long ribbon cable.
So.. now that you've rolled your own RS232 level converters, perhaps think about using that to interface the BT board directly to the empeg, rather than having an extra processor (Arduino) in the middle?
I expect to catch up to you within a few weeks perhaps, using such a setup, blatantly stealing ..re-using.. your code/ideas to run directly on the empeg.
Pretty awesome demo, by the way!!
EDIT: I'm not sure that the empeg really has the concept of an "Album" (or does it?). It knows about "playlists" though, and those have names which could be made available.
If the pause/play status is being lost somehow, you can still detect it in your middleman by noting that the timecodes either stop or stop increasing.
Now that there's a DKWT32i dev board in front of me, I finally appreciate just how tiny the actual WT32i BT module is. And it really needs hardly nothing to hook it up directly to something like an empeg.
I'm thinking of perhaps using the empeg tuner serial port for it, to remove the need for RS232 level conversions -- would still need to deal with 5V vs. 3.3V logic there, but that's much simpler than adding a MAX chip and stuff. And using the tuner port removes all conflicts with the main empeg serial port, freeing that up for debugging/programming purposes.
If the WT32i board were mounted inside the empeg, say onto a drive bay, then it could draw power from the empeg itself, and even use digital audio input (I2S) from the empeg (no hum!).
There is the small issue of a low powered RF device tucked inside an all-metal shell, but that could be dealt with in a number of ways. Eg. a replacement empeg lid made of a different material, or perhaps just a strategically located hole in the lid.
EDIT: The tuner serial port is available outside of the empeg as well, so it could be used regardless. I'll probably start with that and see how things go. And I'll use the 12V output from the empeg to the tuner as the source for powering the BT module.
For now, I'll just use a MAX chip to the main empeg serial port and try get Tony's stuff replicated inside the empeg.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
Thanks, Mark!
You make a lot of excellent points!
Quote:
I expect to catch up to you within a few weeks perhaps, using such a setup, blatantly stealing ..re-using.. your code/ideas to run directly on the empeg.
It's not stealing if I *want* you to take it. Of course, you're going to have to rewrite it significantly to get it working on the empeg. There are some things you'd have to do quite differently on the empeg.
I'm really hoping that you'll catch up and surpass me, so that either one or both of us are successful. I can envision either you completing something that works before I finish mine, and I just drop what I'm doing and use your project instead, or I get my project working well now, use it for a little while, and then eventually switch to using yours later.
Quote:
So.. now that you've rolled your own RS232 level converters, perhaps think about using that to interface the BT board directly to the empeg, rather than having an extra processor (Arduino) in the middle?
I clearly see the advantage to doing it that way. To be successful at that, I'd need to level up in a couple of areas that I don't have enough experience in right now: Code development on the empeg itself, and the necessary EE knowledge to get the bluetooth chip working directly on my own board. Both would require that I get outside help that's a little bit higher level than what I've had so far. Right now, the solution I'm building is within my power to complete soon, and I'd like to try to get that working first, even if only for better debugging the code and understanding all the bluetooth communication tricks. In any case, whenever you get something working with your method, I'm happy to take your design and your code and roll with it.
Quote:
I'm not sure that the empeg really has the concept of an "Album" (or does it?). It knows about "playlists" though, and those have names which could be made available.
Yes, the empeg has a field for the album name and displays the album name on its screen just fine. That's just one of the fields that wasn't included in the serial port output at the moment.
Quote:
If the pause/play status is being lost somehow, you can still detect it in your middleman by noting that the timecodes either stop or stop increasing.
Indeed! I thought about doing just that very thing as soon as I saw the root cause of the issue. However there is a problem with doing it that way: If you are fast-forwarding or rewinding when the player is paused (something that it possible to do on the empeg from its front panel), then it might falsely tell the host stereo that it's playing when it's actually not. Still, that might be better than what it's currently doing.
By the way, that's another bug in the current code: It does not implement fast forward and rewind from the car's front panel or steering wheel controls. This is because my car doesn't do that and so I have no testbed that implements the feature to get that working. My car is weird in this regard. It has several things where you might expect FF/REW to work, and it simply doesn't work this way at all. There are no independent buttons for FF/REW, and holding down the Next/Prev buttons does nothing in most cases. What's interesting is that it does implement FF/REW in one particular specific case, but its absence in other cases is puzzling:
- Honda stereo connect to smartphone with bluetooth to play music: No FF/REW. - Honda stereo connect to smartphone in "iPod" mode via USB cable: No FF/REW. - Honda stereo built-in CD player (this is where I expect it to work most): No FF/REW. - Honda stereo connect to iPhone Apple Car Play with USB cable: FF/REW works.
The bluetooth AVRCP commands that I receive from the module have a "button down" and "button up" message (a press and a release) so you'd think that I could implement it by having my own code detect the time span between AVRCP PLAY PRESS and AVRCP PLAY RELEASE commands. You'd think that. But the Honda stereo doesn't split them out. If you hold the button on the Honda stereo, it waits until you release the button then sends both of those messages simultaneously after your release. Sigh.
Quote:
I finally appreciate just how tiny the actual WT32i BT module is. And it really needs hardly nothing to hook it up directly to something like an empeg.
Like what? I haven't been able to decipher all the specs on the datasheet yet. It's a lot of information to get through.
Quote:
If the WT32i board were mounted inside the empeg, say onto a drive bay, then it could draw power from the empeg itself, and even use digital audio input (I2S) from the empeg (no hum!).
Yes yes yes! This! I have thought about this many times as I have been working on this. I have no idea where to even begin implementing something like this. Stu might know. I wonder if it's as simple as connecting some wires from the empeg to the I2S inputs on the BlueGiga chip, or if a ton of circuitry is needed? That BlueGiga dev board has a ton of digital audio interface pins.
Quote:
There is the small issue of a low powered RF device tucked inside an all-metal shell, but that could be dealt with in a number of ways. Eg. a replacement empeg lid made of a different material, or perhaps just a strategically located hole in the lid.
I wonder if it would "Just Work". The empeg shell isn't a proper faraday cage to begin with, is it? And the BlueGiga chip has a really decent range (I tested it out to be approx the width of my entire house the other day) so maybe having it in the car trunk inside the empeg would be fine? Dunno.
The other option is an external antenna of course. The chip has provision for that, I'm sure. Run it out the back somewhere. Perhaps replace one of the pins on the dock connector that you won't be using any more, such as the cell phone mute wire (won't be needing that wire any more since the bluetooth handles all the cell phone muting now).
Anyway, exciting times!
Thanks Mark, and to everyone else on the BBS, who has been offering tips and answering questions as I go along with this project. You've all been so great!
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
Mark,
I've got a question about how you intend to develop the code for this on the empeg... This is probably me not understanding how that kind of development works...
While developing on the Arduino, I needed three serial ports:
1. The serial port that talks to the empeg. 2. The serial port that talks to the bluetooth chip. 3. The debug/monitoring/command-issuing serial port (in my case, via the Arduino USB port).
The empeg doesn't have that many serial ports. How would one do the debugging and monitoring during development on the empeg?
Okay, this is just so exciting! I'm writing empeg code again!
Okay, so not very quickly, but I remembered how to cross-compile programs for the empeg, so it's a start anyway.
I wrote a modest program to talk to the BT adapter whilst it is connected to the serial port. This part, I actually just did on my (Linux) notebook, and tested/debugged it all there. Then I recompiled it for the empeg, FTP'd it over, and it works there too.
Happy Days!
My plan is to continue development/testing on the laptop as much as possible, because it is quicker and more accessible than the empeg. Then once in a while bump the program back over to the empeg just to make sure it's all still good.
This could be quick, or a very long time. So don't wait around for me, Tony: you have been doing an excellent job serving yourself (and I) here, so please keep on doing so.
Long term, when(if) this gets close to parity with Tony, I think we both might agree that the Arduino is redundant: running on the empeg gives better access to more features. Eg. "Album Titles", or possibly even browsing the empeg playlists from a cooperating head unit.
I do plan to do this, but.. I have lots of plans, and so.. don't wait for me.
Cheers
EDIT: Note to self: When working from the laptop, don't use the built-in USB-UART of the Dev board, as it suffers badly from buffer bloat and consequently loses data if I so much as sneeze. Instead, use either the built-in serial port on the laptop, or a USB-serial adapter, connecting to the RX/TX pins on the board through a MAX chip.
The empeg doesn't have that many serial ports. How would one do the debugging and monitoring during development on the empeg?
I am doing most of the debugging on a laptop, so the code pretty much "just works" when flipped over to the empeg.
But.. the empeg, courtesy of Hijack, has a very large number of things resembling serial ports for debug purposes: telnet sessions.
So I just telnet into the empeg over ethernet to run/debug there when needed. stdout/stderr/stdin are all directed to the telnet session when running code such as this. The serial port has to be opened manually: /dev/ttyS1
So you need one serial port for the BT board. And a telnet session for debugging. No need for a third one (the code is already on the empeg). Use /proc/empeg_notify for player status/state -- some enhancements required and forthcoming!
For player commands, I forget exactly how, but there is a way to inject those to the player even when "Apps use Serial Port" is enabled.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
Originally Posted By: mlord
I think we both might agree that the Arduino is redundant: running on the empeg gives better access to more features. Eg. "Album Titles"
Totally agreed. The Arduino is in the mix right now merely because I have experience with it, it's an easy coding environment, and there is a lot of handholding with a ton of reference material on the internet, and I can iterate quickly on it.
Quote:
or possibly even browsing the empeg playlists from a cooperating head unit.
Oh wow yes. There is a detailed specification for the BlueGiga chip on how to handle that kind of thing. It's all detailed in this document and it's quite complicated, but I think it's do-able.
I know that my car head unit has a "music search" option but I think it only was implemented in iOS Apple CarPlay mode and/or Android Auto mode. I haven't looked closely to see if it's implemented in Bluetooth mode or not, but I know the chip at least supports it.
Quote:
Note to self: When working from the laptop, don't use the built-in USB-UART of the Dev board, as it suffers badly from buffer bloat and consequently loses data if I so much as sneeze. Instead, use either the built-in serial port on the laptop, or a USB-serial adapter, connecting to the RX/TX pins on the board through a MAX chip.
Interesting. The only time I ever used that port on the dev board was to use it to install the latest firmware onto the BlueGiga chip. By the way, if you encounter problems with the functionality of my code, you might want to make sure you've updated your BlueGiga chip to the latest firmware to make sure that we're all talking to the same back end code. I don't know how much has changed in the command set from version to version. Instructions for updating the firmware are in the code comments at the top of my example code.
Just realized: One other note that I foresee being a potential problem with my example code. When the host stereo queries for track titles and other metadata, it could do it in one of two possible ways: 1. Separate queries for each individual piece of metadata, i.e., one query for Title, another query for Artist, another for Genre, etc. 2. A single query for multiple combinations of the metadata, such as querying for all of them, or a subset of them, all at once with a single query statement.
I have noticed that there is support in the BlueGiga command set for both of those methods. I noticed that my Honda only ever uses the "one at a time" query method (though it does query for all of them in quick succession), so my code only knows how to answer that type of "one at a time" individual query. I have not implemented parsing and response of the second "all at once" query method, since that's more complicated code-wise and I don't have a device which performs that kind of query to test it against. Your car stereo might possibly implement that latter query type, so you might have to implement a parser and a response method for it. Keep an eye out for that.
Yeah, thanks for the easy firmware update instructions. I used my work laptop to do that earlier today.
I've been poking around Hijack and the empeg more, gradually remembering how the serial port stuff all works. It looks like some surgery is needed there to enable full use of the serial port for the BT module. Currently, any input from the BT goes right to the player, causing all kinds of weird things to happen at high speed.
I think I'll create a special fake serial device, and redirect everything for the player to that on startup, when directed so by a suitable config.ini entry (eg. btmode=1). That would get the player completely out of the way, while still being able to capture its output (for /proc/empeg_notify), as well as still being able to inject commands back into it.
I wonder if anyone out there is still using "apps" on the empeg? Probably, so will try and keep that working. The code will get a bit messier than necessary for that, but c'est la vie.
What do you guys think? Would that power supply at least work in my prototype?
Looks very expensive. Which audio output are you noting the noise on, the Home-mode RCA jacks, or the car-mode outputs: docking connector jacks? or Home-Dock jacks?
The docking-connector jacks appear to have isolated signal grounds, whereas the RCA jacks use the main earth/chassis ground. I think.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
Originally Posted By: mlord
Looks very expensive.
Yes, true, but do you think it will work at all? In other words, do you think that part that I linked will successfully take the car 12v power as it source, and correctly output 5v that the Arudino and the Bluegiga can run off of?
Quote:
Which audio output are you noting the noise on, the Home-mode RCA jacks, or the car-mode outputs: docking connector jacks? or Home-Dock jacks? The docking-connector jacks appear to have isolated signal grounds, whereas the RCA jacks use the main earth/chassis ground. I think.
All of the above. I'm hoping that it's noise from the power supply specifically, and not anything the empeg's audio outputs are responsible for.
The reason I'm thinking that it's the power supply is because I don't have any noise as long as I am powering the arduino and the BlueGiga board from a separate 5v power supply that is not the same power source as the Empeg, i.e., the empeg gets its power from either the car 12v or a home AC adapter, while the arduino+blueGiga get their power from the USB port of my laptop in battery power mode. As soon as I power them all off the same 12v supply (the empeg directly off the supply and the Arduino/BlueGiga off of the pololu 5v converter off of the same supply), then the noise appears. So I'm hoping that an isolated power supply will do the trick.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
Excellent question about where the power is coming from.
I am testing in the following conditions. There's enough variables to make this list kind of big, so I'm PRETTY sure about all of these, but not 110 percent sure:
- Empeg powered by AC Adapter, Arudino+BlueGiga powered by laptop USB port on laptop battery: No noise.
- Empeg powered by AC Adapter, Arudino+BlueGiga powered by laptop USB port with laptop plugged into AC power: No noise.
- Empeg powered by Car 12v from Cig Lighter adapter into Empeg Home 5.5mm barrel plug, Arudino+BlueGiga powered by laptop USB port on laptop battery: No noise.
- Empeg powered by Car 12v from Cig Lighter adapter into Empeg Docking Sled power wires, Arudino+BlueGiga powered by laptop USB port on laptop battery: No noise.
- Empeg powered by AC Adapter, Arudino+BlueGiga powered by the same AC adapter through the Pololu 5v power supply: Small amount of noise.
- Empeg powered by Car 12v from Cig Lighter adapter into Empeg Home 5.5mm barrel plug, Arudino+BlueGiga powered by the same Cig Lighter adapter through the Pololu 5v power supply: Small amount of noise.
- Empeg powered by Car 12v from Cig Lighter adapter into Empeg Docking Sled power wires, Arudino+BlueGiga powered by the same Cig Lighter adapter through the Pololu 5v power supply: Small amount of noise.
For the noise, my theory is that perhaps the hard drive motor(s) of the empeg are back feeding some noise. Feel free to blow away this theory by stating you are using SSDs (or CFs) instead of mechanical drives!
Somebody really clever (like Patrick or some others on the BBS) could probably point out a simple array of capacitor values to use to filter out such unwanted noise. Eg. my untrained mind might attempt just stuffing all of these in parallel across the 12V/GND lines in front of the BT power supply: 1000uF 100uF 10uF 1uF 0.1uF 0.01uF. But then I have bins on hand here with all of those.
I wonder if it might help to instead draw 12V source power for the BT board from the 12V on the tuner connector?
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
I did switch to an SSD recently.
I do a have bin of capacitors here that I could try bridging the 12v/Gnd line, I'll see if that works. I could also try drawing the power from the tuner connector as well, that's a good suggestion!
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
Going back to the debug question...
Originally Posted By: mlord
So I just telnet into the empeg over ethernet to run/debug there when needed. stdout/stderr/stdin are all directed to the telnet session when running code such as this. The serial port has to be opened manually: /dev/ttyS1
So, in my Arduino code, there is a place in the code that reads input from the serial port connected to the BlueGiga chip. In addition to processing those characters, it also echoes those characters to the Arduino's debug/monitor serial port. And anything I type into the debug/monitor serial port, conversely, is echoed to the serial port connected to the BlueGiga chip, so that I can issue commands directly to test them out.
The corresponding version of that for coding on the empeg itself would be that any characters received from /dev/ttyS1 would be echoed to ... what? dev/tty<something else>?
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
And speaking of the tuner connector...
When the tuner module sends its audio data back to the empeg so that it can output the audio to the speakers, does it do so as analog or as digital?
In other words, in addition to a second serial port existing on the tuner connector, is there by happenstance an unused digital audio connection of some kind on that tuner connector? And if so, does it have the potential to be a two-way digital interface, receiving digital audio from the player instead of sending digital audio to the player?
When the tuner module sends its audio data back to the empeg so that it can output the audio to the speakers, does it do so as analog or as digital?
It appears as some weird analog multiplexed thing, for which the empeg DSP includes special processing to extract L/R audio from. Those pins on the DSP appear to be single purpose: strictly expecting an FM Level as input (or an AM Level).
The corresponding version of that for coding on the empeg itself would be that any characters received from /dev/ttyS1 would be echoed to ...
Standard Output (stdout). Aka. File Descriptor number 1. Aka. The default destination of printf() or putchar(). This is open and available on program startup, without the need to explicitly open() it, and normally maps to whatever "terminal" (tty) session (serial, ssh, telnet, an xterm window, etc..) from which the program was launched.
So, like this:
Code:
int read_and_echo (void)
{
char c;
int fd = open("/dev/ttyS1", O_RDWR);
if (fd == -1) {
perror("/dev/ttyS1");
exit(1);
}
while (1 == read(fd, &c, 1)) {
putchar(c); /* stdout: could be anything, and we don't care! */
fflush(stdout);
}
close(fd);
}
In the case of a telnet session, here is where the kernel (Hijack) sets this up in ktelnetd:
Code:
// set up stdin,stdout,stderr to all point at the socket
sockfd = get_fd(parms->clientsock->inode); /* 0: stdin */
dup(sockfd); /* 1: stdout */
dup(sockfd); /* 2: stderr */
So in this case, stdout/stderr (and stdin for reading) point at the "socket", which is a handle for the remote connection (the telnet client running on a PC).
The important bit is that the program itself doesn't need to know this. It just reads stuff from stdin, and writes stuff to stdout (and/or stderr). And it all works. Whether running locally on a serial port, in a window on a desktop GUI, or at the end of some remote network connection (ssh, telnet.. ).
EDIT: So, while we're on this topic: Anything that has been "opened" on a Linux system has a file descriptor associated with it. A file descriptor is what you get back from calling open(). Or socket().
These begin with 0 for the first thing opened, and each new thing gets the lowest number that is not currently in use. So stdin=0, stdout=1, stderr=2 .. is the most commonly seen order, though it is not guaranteed to look like that.
The numbers are simply indexes into a kernel table describing each open "object" and the state of reading/writing on that object. Aka. the File Descriptor table. There is a unique file descriptor table for each process.
In the /proc/ directory on Linux (including the empeg), there is a subdirectory for each process, as well as one called "self" for the current running program. If you telnet to the empeg, and do cd /proc/self, you will see a lower level subdirectory called fd. This is a view of the process's file descriptor table. Look into it like this: ls -lF /proc/self/fd/
Code:
ls -lF /proc/self/fd/
total 0
lrwx------ 1 0 0 64 Aug 3 12:07 0 -> socket:[8]
lrwx------ 1 0 0 64 Aug 3 12:07 1 -> socket:[8]
lrwx------ 1 0 0 64 Aug 3 12:07 2 -> socket:[8]
lrwx------ 1 0 0 64 Aug 3 12:07 255 -> socket:[8]
Doing the same thing when logged in via the serial port gives this instead:
Code:
ls -lF /proc/self/fd/
total 0
lrwx------ 1 0 0 64 Aug 3 12:12 0 -> /dev/ttyS1
lrwx------ 1 0 0 64 Aug 3 12:12 1 -> /dev/ttyS1
lrwx------ 1 0 0 64 Aug 3 12:12 2 -> /dev/ttyS1
lr-x------ 1 0 0 64 Aug 3 12:12 3 -> /proc/35/fd/
Note that the fourth entry in the second case is the file descriptor for reading from /proc/self/fd/ at that point in time, when "self" was process id (PID) number 35.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
Thanks very much for the tutorial about how stdout/stdin/stderr works on linux, that will be very useful to me if/when I start digging into this in the "everything on the empeg" mode at some point. It is also good general knowledge to have about linux coding.
- Implemented your suggestion about making the playback state change if it detects that the track timestamp has been changing recently. It does indeed do the thing I feared: Making it look like the track is playing if you FF while the track is paused. But this is not a big deal and is better than the alternative.
- Implemented fast forward and rewind for car stereo headunits that support FF/REW over Bluetooth. My Honda factory stereo doesn't, but my roommate's aftermarket Kenwood stereo does, so I was able to get something working in that area.
- More details about track playback position indication are now in the code.
In other news:
I realized that my roommate's car stereo was an aftermarket Kenwood unit with a bluetooth input and track titles on the screen. So I could test out my code with a second stereo finally!
To my surprise, almost everything worked correctly. And his stereo can do FF/REW over bluetooth (something my Honda inexplicably refuses to do at all) and so I was able to implement FF/REW in the code now.
However there is one interesting thing about his stereo that is different from my Honda. And it's a pretty big bug that I am stumped by and now I need to know how to fix. Googling for it isn't helping yet, so I'm not sure about how to handle this. Here's the issue...
The bluetooth code depends upon the host car stereo headunit to query us for the track metadata. In other words, we can't "push" track titles up to the car stereo screen until the car stereo asks us for them. They are implemented only as a response to the query.
I have been using the following command, sending this up to the car stereo to make it turn around and re-query us for the new track titles. This command works on the Honda stereo:
Code:
SendBlueGigaCommand(F("AVRCP NFY CHANGED 1 2 1"));
// Where:
// AVRCP NFY - The notification command to send to the head unit.
// CHANGED - Indicate to the head unit that there was a change to the track.
// 1 - Send this message with transaction label 1 (an arbitrary sequence number).
// 2 - The notification message we will send contains event ID 2, which is "TRACK_CHANGED".
// 1 - The sole parameter value for the TRACK_CHANGED, with a "1" indicating that there is indeed a track selected.
When I issue that command to the bluetooth chip when it is paired with the Honda stereo, it responds instantly and re-queries for new track metadata. Unfortunately, on the Kenwood unit, the command does nothing and the Kenwood unit doesn't re-query for new track metadata.
I know that sometimes the Kenwood unit successfully queries for track data. Immediately after first connection to the bluetooth chip, it does query for the track information and my code responds as expected. The track titles appear on the screen of the Kenwood, and all is well. Then when I go to change to another track on the Empeg, and it issues the "AVRCP NFY CHANGED 1 2 1", nothing happens, and the Kenwood keep displaying the same song title, though now a different song is coming out of the speakers.
I know that there must be a standardized way to make this work, because all the cell phones that we pair up with this Kenwood unit correctly display track titles when tracks get changed. But I don't know how to sniff their communications to find out how this is done.
Anyone have any ideas of how to kick the headunit to make it re-query for new track metadata?
I don't know how to sniff their communications to find out how this is done.
For an Android handset, enable Developer Mode, and then go to Settings --> Developer options --> Enable Bluetooth HCI snoop log. Stuff should then be written to /sdcard/Android/data/btsnoop_hci.log which one can pull off later and feed into Wireshark (on a PC) for analysis.
I have not actually tried this, but others have. The exact pathname may vary, but the file itself is always called btsnoop_hci.log
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
Cool, I should be able to do that. I don't have an android phone but others in my household do, and that might give really interesting information.
In the meantime, I have a suspicion about what might have caused it. Looking at my own transaction logs from the session, I see that there was a moment during the first query for track data (the one which succeeded) where my code failed to respond to one of the queries in the group of metadata queries. The conversation looked like this:
The first of those queries is doing a multi-query, it's asking for two items at once: 02 = Number of attributes being queried for 05 = Attribute code for the total number of tracks in the album. 04 = Attribute code for the current track number.
My code doesn't yet know how to respond to a multi-query. It only knows how to respond to single queries where the first number in the query is "01". The Honda stereo only ever sent single queries, never a multi-query.
I think what happened (this is just a hunch that I haven't tested yet) is that since I didn't respond to that first query in a timely fashion, its parent routine for making track metadata queries is hung waiting for a response and it won't ask again. It managed to get that one group of queries but now it won't do it again.
So I guess I have to write the full parser for the "GET_ELEMENT_ATTRIBUTES" responses that I was putting off writing.
the 8 way Molex 'tuner' connector is wired as follows:
1 - Pink - level
2 - Grey - signal
3 - Blue - Power Ant (not connected on wiring harness)
4 - Black - 0v (ground)
5 - Brown - TX (from tuner)
6 - Red - RX
7 - Purple - no connection (not used in PCATS tuner nor in factory tuner)
8 - Blue - 12v
Previous Topic
Index