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: 31565
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: 31565
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: 31565
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: 31565
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: 31565
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: 31565
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: 31565
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: 31565
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: 31565
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: 31565
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
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Supplying power to the external circuit from the tuner plug connection (through a 5v power supply of course) works fine. The amount of noise is unchanged, but I much prefer the idea of my assembly connecting to this existing connector instead of trying to manage additional power connectors, so I'm going to roll forward with that. Thanks!
Okay, I might pursue using the Tuner serial port for the BT module connection then. This way would leave the empeg's primary serial port available for the usual troubleshooting etc. without any conflicts or special handling needed.
The Tuner port is (I believe) 5V TTL logic, which will need to be voltage adapted for the 3.3V CMOS on the BT module. I expect just a couple of resistors will do the trick, but will find out when I do it here.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
The noise is pretty faint so it's hard to be sure. It's at the level where you can't hear it unless the song has a really long faint fade-out.
The BlueGiga's ADC seems to have a "floor" or a "noise gate" where extremely quiet sounds don't get sent to the ADC at all and there's just digital silence. So for example, songs with long fade-ins or long fade-outs might have a very small bit of the quietest part of the fade cut off. The amount of noise I'm hearing is just barely on the edge of that noise gate's sensitivity level, so what I get is an intermittent thing where occasionally I hear a faint bit of noise floor appear for a second or so, then it drops below the sensitivity threshold of the noise gate then it fades out again. It's only audible if I turn up the volume on the head unit really loud. But my goal is to eliminate it completely so that even that's not a problem.
Side note: I've also looked through the commandset looing for a way to bring that noise gate's threshold setting down even further, so that it doesn't cut off even the quietest fadeouts. But I can't find any command to adjust the threshold of that noise gate. I'm already controlling the gain and the preamps and the mic bias voltage, and those are set correctly in my code, I can't find any other settings related to that.
I'm using an SSD so I can't tell if it's spinup/spindown related.
I haven't tried switching back to the 7805, I'm going to try switching forward to that isolated voltage converter instead, it comes in the mail tomorrow. If that doesn't solve the issue, I'll try comparing the three power supply types.
This implements the proper responses to the head unit's queries for track metadata, in cases where it attempts to query for multiple pieces of metadata in the same query line.
I haven't gotten a chance to see if this fixes the problem with my roommate's Kenwood stereo yet. Crossing my fingers!
The noise is pretty faint so it's hard to be sure. It's at the level where you can't hear it unless the song has a really long faint fade-out.
Rush, "Red Barchetta"?
Play the track on some other device to be sure the problem isn't in the track itself, and experiment with different tracks as well. I suspct you have already done those things, but that's the limit of my technical competence so is the only suggestion I can make.
tanstaafl.
_________________________
"There Ain't No Such Thing As A Free Lunch"
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Thanks for that suggestion. Unfortunately it’s not that simple. I’m using a large variety of tracks to test this, and I also have the ability to A/B with other playback systems and also with the pure digital versions via A2DP with my phone, so I’m certain I know the difference between noise floor extant in the track and noise added by external electronics.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
OK weird.
I got the new isolated power supply and hooked it up and tried it out.
It seemed to work but it made a faint humming/whining noise during operation. Not noise in the audio chain, but I mean physical noise when I put me ear up next to it. I've heard power supplies that whine a bit before, so I thought maybe this was normal operation and kept trying it out.
The ground loop noise on the bluetooth/arduino/empeg assembly audio chain was even less than with previous power supplies. Not 100 percent gone, but definitely much much better. Prior versions of the noise were a combinaion of an electronic hum as well as a rushing-wind kind of static noise floor, but with the new power supply it was only the static noise floor, and that was pretty quiet.
Unfortunately I noticed that the bluetooth and arduino were a bit unstable, as if maybe it wasn't supplying the right voltage. Example of what I mean by "unstable" is that the bluetooth connection would drop occasionally, or the reset button that I implemented on the arduino would not function sometimes.
So I unplugged the new power supply and went back to the pololu power supply. And then I plugged in my USB debug cable into the Arudino to work on the programming side of things and... nothing. Nothing comes out on the debug cable.
What's interesting is that things go IN on the debug cable just fine. And the communication between the arduino and the bluetooth board are fine. I know this because of the behaviors I have programmed into my code. I can press the reset button and my blue LED connected to the arduino lights up and it erases the bluetooth pairing on the bluetooth chip, exactly as it is supposed to. I can do all the actions that I normally can do and they all work. I just don't see their output logs on my arduino serial debug monitor any more.
I can SEND commands to the bluetooth module by typing them into the arduino debug console and they get there, they arrive and do the correct thing. For instance if I type BOOT 0 into the arudino debug console then the bluetooth chip correctly reboots (it disconnects form whatever it was paired with and then reconnects after a moment). So SENDING text to the Arduino works.
But I don't see any serial ooutput coming BACK from the arudino. And I know that my program outputs stuff back (regardless of echo on or echo off), it's got specific logging commands that my program has said to put there, and those commands are in there pretty constantly from power-on. For instance, I can press my reset button and my blue LED lights up to indicate it's in paring mode, and I know at that moment I'm echoing a bunch of messages to the arduino debug serial port, but I'm not seeing them on the console.
I tried reloading a program onto the arduino, it times out because it can't get a serial signal back saying that it is receiving the code.
I tried fully unplugging the arduino from the entire assembly and connecting it solely to the computer just from the USB cable. Same thing.
I tried plugging it into an entirely different computer and different operating system (going from Mac to Windows), which entailed installing the arudino development software and device drivers from scratch on the new computer, same thing.
It's not a baud rate thing, because (a) the program sets the baud rate and I know the program is working, and (b) I tried different baud rates on the monitor anyway. Same thing.
Wow this is weird. I don't see how the new power supply could have done this to the arduino but I suppose it could? I don't know. Why would it fry only one direction of the arduino serial port while the rest of the thing works perfectly for everything else? Weird.
This makes it so that the same set of notification commands is always sent to the bluetooth chip every time a track changes or the playback status changes. This was an attempt to fix the bug with the Kenwood headunit where it only ever got the first track title on its screen and never got subsequent ones.
It didn't fix that bug, but it fixed another previously-unmentioned bug where I had a bluetooth headset which wasn't successfully pausing/unpausing when I pressed its pause button. Something about the change in the last set of code fixed that bug, and now the headset correctly pauses and unpauses.
Here's what was going on with the Kenwood bug (from my code comments in the update above):
// Final fix for the "Kenwood Bug". Description of the Kenwood Bug: // The AVRCP NFY CHANGED commands work on factory car stereo in // Honda Accord 2017 model no matter what the transaction label is. // This led me to believe that the transaction label was only important // when performing an immediate response to a state query (i.e., when // sending an "AVRCP NFY INTERIM" response), and that if I was the one // who was indicating the state change (i.e., when I was sending an // "AVRCP NFY CHANGED" statement to tell the host that something had // changed), that the transaction label was arbitrary and that I was // the person choosing the transaction label at that time. This was // fine for the Honda stereo: When those commands are issued to the // bluetooth chip, then the car stereo head unit immediately reacts // by re-querying for more new track metadata from the bluetooth chip. // // However, when using those commands on a Kenwood bluetooth-equipped // car stereo, then nothing happens when the messages are sent up // with arbitrary transaction labels. The Kenwood stops sending new // queries for track information and just "sits there" blindly // playing the audio stream without getting any new track data. // // It turns out that the transaction labels aren't arbitrary if // you received a "REGISTER_NOTIFICATION" message for the // "PLAYBACK_STATUS_CHANGED" or the "TRACK_CHANGED" messages. // Yes, you need to immediately respond with an "INTERIM" // notification, but then if you send a "CHANGED" notification // yourself later, then the transaction label still has to match. // The Kenwood stopped querying for new track data because the // transaction labels didn't match when I sent it "CHANGED" // notifications. The fix is to match the transaction labels // by storing them in a global variable.
As far as the noise goes, I think I'm going to attempt to make a first pass at a PCB and see if all I really need to eliminate the noise is to simply get things more solid with better ground traces and everything, instead of jerry rigged on a breadboard.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Now that the software and my breadboard prototype are working well, I've just ordered a PCB from Pad2Pad. Should have a video of the assembled version of that in the next 10 days or so.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Current status:
- I have a working car installation, with the breadboard prototype and the attached empeg velcroed to the floor of my trunk, Eutronix remote display extender is installed and working in the sunglasses holder in the ceiling up front. Works well and sound is good.
- I have a PCB on the way from Pad2Pad that should allow me to turn the prototype into a single nice little box that I can mount better and well protected in the trunk, while still allowing me to pull out the player and dock it to load tunes indoors.
- There is a bug in the software, such that high-ascii characters are displayed as an inverted question mark on the car stereo screen. So Béla Fleck and Blue Öyster Cult look funny, for example. Will work on fixing that soon.
Questions for Mark Lord and Stu:
Stu's digital interface does I2S, and its instructions seem to show some simple I2S connection pads on the empeg motherboard. There are some I2S pins on the BlueGiga development board, and there are instructions in the BlueGiga docs which say how to route the audio from the I2S pins (you have to issue a particular couple of commands to the BlueGiga chip).
Question 1: Is it as simple as a couple of wires to connect the I2S on the empeg motherboard to the I2S pins on the BlueGiga board? Or is some buffer circuitry needed or what?
Question 2: If I am getting my audio from I2s instead of from the audio out jacks, what features will be lost if any? Or will these all work as expected even through I2S? - Left right time alignment? - EQ? - Bass/treble boost? - Auto volume adjust? - Volume control from front panel?
The I2S pads come more or less directly from the empeg's DSP chip, so that would be AFTER pretty much everything has been done to the audio. I haven't tried it yet, but all of the adjustments should "just work" through I2S.
However.. it is not entirely clear to me whether the I2S outputs use 5V or 3.3V. The datasheet for the DSP seems to indicate 3.3V, but I'd like to see it on an Oscilloscope just to confirm. Stu would already know this too, so if he chimes in..
EDIT: The schematic indicates 3V on the IIS header, so it should be good.
That's important, because 5V could fry the BT module. So you really want 3.3V logic there. Easy to convert 5V to 3.3V with a 10Kohm and 20Kohm resistor ladder, if it is needed.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
So should we try it with just some wires? Do we know what the pinouts are for that header? Stu's instructions also have a connection to a timing crystal, would that be needed as well?
I don't know what Stu needed the connection from the side of that crystal for. No schematic of Stu's device here, so you'll have to ask him what that was all about.
But here is the layout of the I2S (aka. IIS) header inside the Mk2a, along with the nearby 3V power source.
Stu appears to be using IISC, IISW, and IISD1 from the header. Ground is also available there, so no need to go hunting elsewhere for it. Those are the same pins we'll want to connect to header J12 on the BT dev board (SCK, WS, SDIN, GND).
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Wow that looks really straightforward. Thanks! Maybe I'll get a chance to try it later this week or this weekend. If you try it first, let me know!
According to the docs, you have to issue these commands to get the dev board to route from the I2S connector:
SET CONTROL AUDIO INTERNAL I2S EVENT 32 SET CONTROL EXTCODEC PRE 30 18 0200918000008A1037000100008000000FF07C7C787C7C78 30 04 25C01400 30 0a 28C00000000000008000 30 03 330F00 30 05 3F00800F00 30 04 6500A200 RESET
In the meantime, I'm having a devil of a time trying to find out how to get high-ASCII characters to appear on the car stereo screen. I can't find the bluetooth specification information for how to handle non-ASCII characters in the strings sent up in the AVRCP metadata.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Hm, I misread those commands in the docs. The "EXTCODEC" command is for setting up an external TI codec included on the dev board. I think that perhaps you might only need the first command to use the empeg I2S:
SET CONTROL AUDIO INTERNAL I2S EVENT 32
And mayyyybe a "RESET" after that. Might be that simple.
Also the number might not be 32. The docs say "...configures I2S to use 32 bits per sample to suit the clocking requirements of the TI codec" so I don't know if the empeg needs that or if it needs 16 in that slot or what.
- Adds an aggressive reconnection retry so that once you've paired up with your car stereo, then after that, each time you start your car, the empeg tends to be the device that connects to the car stereo first, rather than playing tunes from the phone in your pocket. On my car now, when I start it, it connects the music to the empeg and the phone/voice to my cell phone. Nice.
- Fixes the issue with High ASCII characters in track titles by converting high ASCII to UTF-8 before sending it up the bluetooth link. Works well, now my Blue Öyster Cult and Béla Fleck tracks look correct.
Last night, my friend Fishy used his expensive high tech mill machine to clean up the edge cuts on the sunglasses holder where I mount the remote display. I'm really pleased with the way it's looking so far. I should also hopefully receive my PCB from Pad2Pad and I should be able to solder up a much better attachment box without having to use the breadboard. If I get that all working I'll post another demo video with everything in place.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Regarding the I2S connection on the Empeg motherboard - Would you expect that the GND for that is the same as the GND for 12V on the tuner connector?
I'm thinking of hijacking more wires on the tuner connector to run I2S out the back of the sled (disconnecting all existing tuner connector wires from the empeg motherboard except for the 12v power and ground).
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Holy shit it works. THANK YOU!
Since the IIS header on the empeg motherboard is not labeled, I'm going by your earlier post regarding the pinouts of the IIS header, and the photo of the connected wires from Stu's digital interface installation instructions.
Yellow wire in Stu's instructions: Assumed to be PL8 - Pin 1 - IISC Orange wire in Stu's instructions: Assumed to be PL8 - Pin 2 - IISW Not connected in Stu's instructions: Assumed to be PL8 - Pin 4 - GND - (I have added a blue wire here). Red wire in Stu's instructions: Assumed to be PL8 - Pin 4 - IISD1 Not connected in Stu's instructions: Assumed to be PL8 - Pin 5 - IISD2
I am connecting (based on the assumptions above and your earlier post):
Yellow wire connected to BlueGiga board SCK pin. Orange wire connected to BlueGiga board WS pin. Blue wire connected to BlueGiga board GND pin. Red wire connected to BlueGiga board SDIN pin.
Note: Don't usually need that blue wire except when I've got everything split out on the workbench and the empeg and the bluetooth module are getting their power and ground from two different places.
The final version of the secret command you have to issue to the BlueGiga module to make it work turns out to be:
Code:
SET CONTROL AUDIO INTERNAL I2S_SLAVE EVENT KEEPALIVE 16
And at some point in my setup code, the device eventually gets this command: RESET
The format of the command, according the iWrap 6 command reference, is:
SET CONTROL AUDIO - The preamble for the command INTERNAL I2S_SLAVE - The input and output audio routing. It doesn't seem to matter what I set the first one to, as long as the second one is set to "I2S_SLAVE" because that's the one we're using in A2DP "Source" mode. The other one is unused by our configuration. EVENT - To receive audio routing events. KEEPALIVE - Prevents DSP from powering down between A2DP streams. Removes possible clicks and pops from the beginning of the analog audio stream. Might decrease also A2DP latency. Increases power consumption when not streaming audio. 16 - Unused since we are in slave mode, it specifies the number of bits per sample when using I2S master mode. Can be 16/20/24/32 (default 24). I'm stuffing a 16 in here just for something to put in there.
Stu's instructions say something about how the audio volume on the empeg might need to be set to one notch down from 0db to keep the audio from clipping. I'm going to experiment with that.
I think you should really go for using the Tuner's serial port too, instead of the primary empeg serial port. Just two pins on the tuner connector (RX,TX), plus (exising GND).
The RX (to tuner/BT-module) pin requires a resistor ladder to step down the voltage from 5V to 3V logic. the TX (from tuner/BT to empeg) can connect without modification.
The resistor ladder on RX should consist of a setup like this:
Connect the RX (BT module) to the (+)point in between the 10K/20K resistors. No MAX rs232 chip required.
The two resistors function as a voltage divider, converting the 5V RX output from the empeg into (20/(10+20) * 5.0V == 3.3V) suitable voltage to not fry the BT-module.
EDIT: Oh, I keep forgetting you have the Arduino in-between right now..
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Thanks! Maybe someday I will indeed try to do it sans Arduino and get it working fully internal to the player. But now that I have it working as an external box with all the features I want, I'm going to refine this for now and finalize the current design. In the meantime I'll give you any support you need for doing the internal version yourself.
Here's my thinking at the moment...
If anyone besides you or me ever wants one of these for themselves, then they can have three different ways of doing it:
1. Fully external box which requires no player modifications, uses analog audio plugs. Requires an Arduino and one of the WT32i dev kit boards.
2. External box like 1 above, which can also work with digital I2S connection, but you have to be willing to open up the empeg and solder to the I2S pads and hijack some wires out the back of the docking connector (I'm currently using three of the tuner module wires successfully for this).
3. Fully internal to the player, using the tuner serial lines for command/control of the bluetooth and the I2S pins for the audio, but requires additional connections and soldering internal to the player, and takes up a drive bay slot for the assembly.
I currently have a working implementation for either/both Way 1 and Way 2, and I'm designing my second revision of the printed circuit board already. Once I get that second PCB made and tested, I could be set up for manufacturing these things as complete modules, or selling them as kits. The second revision of the PCB will allow the module to be used in either Way 1 or Way 2.
For way 3, I think that you should totally run with that. You know so much more about programming for the Empeg and you know so much more about EE than I do, I think you'll be totally successful at that. Your version would be smaller, simpler, and MUCH cheaper to manufacture.
I'm pretty excited about this. I know the software is going to need a lot of tweaking though, so there will still be updates to the example code. If anyone else wants one of these, I'll bet that it won't pair up perfectly with their stereo and will need additional code tweaks. Each time I try this thing on a different bluetooth device, I discover some other little thing that doesn't work and I have to update the code again.
Still, having a lot of fun (and stress) with this project. I've been through so many twists and turns with the circuitry, most of which I haven't mentioned on here. Last couple of days it was weird thing with the serial connection failing on the PCB from Pad2Pad which turned out to be just traces grounding out when they weren't supposed to be, and I had to jumper around some shit. Next design from Pad2Pad will have bigger clearance around the traces than their recommended settings. Live and learn.
I'm super grateful for you and for the other folks on this BBS for the suggestions and the help. The initial idea for doing this was from two people: FieroSTI for having made a bluetooth input board for the empeg (the opposite thing of what I'm doing now), and Elperepat for pointing out the original BC127 breakout board at Sparkfun.com. From there it just snowballed. You all have been super helpful with all sorts of great suggestions related to the bluetooth stuff and for the electrical circuits. It's just been amazing. Thanks all!
I am not likely to "manufacture" anything for this. My plan is just to get my own setup going (after Christmas), and share whatever it takes to do so.
The first rev will be the external BT dev board, connecting to the tuner connector on the empeg, most likely with I2S also hooked up through the tuner connector. The empeg CPU will do all of the control etc..
If I ever do a second rev, it will be to replace the large/expensive BT dev board with just the BT module instead, and that is tiny enough to be mounted inside the empeg (probably in a drive bay). I had been shying away from doing this, because of the difficulty (for me) of keeping clean audio paths. But with pure digital audio interconnects (I2S), that all becomes a non-factor. Thanks again, Tony!
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Makes sense!
When your code uses the tuner internal serial port, it'll be accessing to the RX/TX lines internally on the empeg, correct? So you don't need those RX/TX pins to be connected externally on the tuner connector out the back of the sled, correct? So you could do like I did and disconnect those pins from the wiring header that connects them to the sled harness inside the empeg and then those can be used for running some of the I2S pins out the back of the tuner connector, like I did. Right?
If we use the same pinouts on the tuner connector, then both of our designs will be compatible. Would that work for you?
Here's the pinouts I'm using on the 8-pin molex tuner connector. Let me know if these work for you. Note that the colors listed are the externally visible wire colors on the tuner connector outside the player. The colors are different on the internal wiring header that connects to the motherboard.
1 - Pink - originally "tuner level", now disconnected from internal wiring header inside the empeg and soldered to a jumper wire which is solodered to I2S pin "IISD1" inside the empeg. This is pin 4 of the IIS header on the empeg motherboard, the 4th pin from the "notch" on the silkscreen outline. On my external board, this is connected to the SDIN pin of the BlueGiga module.
2 - Grey - tuner signal - left unchanged - No connection on my external board
3 - Blue - Power Ant - left unchanged - No connection on my external board
4 - Black - Empeg Ground - Connected to the ground on my external board, which is connected to several ground pins in various places on the BlueGiga board and the Arduino board. In particular it's connected to the GND pins on the I2S header on the BlueGiga board.
5 - Brown - originally TX, now disconnected from internal wiring header inside the empeg and soldered to a jumper wire which is soldered to I2S pin "IISW" inside the empeg. This is pin 2 of the IIS header on the empeg motherboard, the 2nd pin from the "notch" on the silkscreen outline. On my external board, this is connected to the WS pin of the BlueGiga module.
6 - Red - originally RX, now disconnected from internal wiring header inside the empeg and soldered to a jumper wire which is soldered to I2S pin "IISC" inside the empeg. This is pin 1 of the IIS header on the empeg motherboard, the pin next to the "notch" on the silkscreen outline. On my external board, this is connected to the SCK pin of the BlueGiga module.
7 - Purple - unused - left unchanged - no connection on my external board.
8 - Blue - 12v - Connected to my 12v input on my power supply regulator on my external board.
For the dev board, the TX/RX pins on the tuner connector will be needed. So let's leave those intact. Also, the empeg has 5V available internally, so if we feed that out the tuner connector, then there's no need for any extra voltage conversions.
Code:
1 - Pink - level
2 - Grey - signal
3 - Blue - Power Ant (not connected on wiring harness)
4 - Black - 0v
5 - Brown - TX (from tuner)
6 - Red - RX
7 - Purple - no connection (not used in PCATS tuner nor in factory tuner)
8 - Blue - 12v
So, referencing the above, pins 1,2,3,7 are all available for our use. We should keep 4 (GND), 5(TX from tuner), and 5(RX to tuner).
There are enough leftover pins to use one of the remaining pins for +5V in addition to keeping +12V, and still have three pins for I2S (SCK,WS,SDIN).
So, how about you decide the final assignments within those constraints? If for some reason we end up needing another pin, then we could put +5V in place of the +12V on pin 8.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
OK, I'll change which pins I'm using. :-)
In the meantime I have another code update with some more bug fixes and minor behavioral changes. I'm trying to get the initial boot-up and connection procedures to behave as cleanly and quickly as possible.
Once you guys get all the wrinkles worked out, I will definitely be doing this. I'm not in any hurry, but at some point in the next 18 months or so I'll be in the market for a vehicle and would love to have the empeg running again (right now we only have the one minivan and I've been warned not to fool around with the built-in DVD system). Until then, I'll be lurking and collecting parts and having them brought down to Mexico. I've just been waiting to purchase until Tony found a board that was actually viable.
I also travel quite a bit when in the US as I visit churches all over the country. It would be great to have an empeg that I could just carry into a rental car, plug into the lighter and connect via bluetooth (ie...the fully internal option above).
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Cool. We'll have the kinks worked out soon and hopefully make it into a very simple kit. :-)
An example of a kink that I have to work out (well, a bug in the empeg player that I must work around) that I just discovered:
N serial_notify_thread.cpp: 116:@@ N10 serial_notify_thread.cpp: 117:@@ F0xf8b0 serial_notify_thread.cpp: 118:@@ TAquafin serial_notify_thread.cpp: 119:@@ ATony Levin serial_notify_thread.cpp: 120:@@ GInstrumental Rock
N serial_notify_thread.cpp: 116:@@ N11 serial_notify_thread.cpp: 117:@@ F0x10640 serial_notify_thread.cpp: 118:@@ TWhere the Streets Have No Name serial_notify_thread.cpp: 119:@@ AU2 serial_notify_thread.@@ GRock
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
And now it's not reproducing consistently. It reproduced perfectly before (only on the U2 track and not any of the others) and now it's not reproducing and... GRRR.
Wait, no, now It's sometimes reproducing differently. Now I see it like this:
N serial_notify_thread.cpp: 116:@@ N11 serial_notify_thread.cpp: 117:@@ F0x10640 serial_notify_thread.cpp: 118:@@ TWhere the Streets Have No Name serial_notify_thread.cpp: 119:@@ AU2 serial_notify_thread.: 120:@@ GRock
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Now I'm starting to suspect my own code even though the examples above are straight character-in-character-out on the serial port.... More research is needed...
So, what I see there is that it sometimes drops the "cpp" part of the string? That part alone is easy enough to ignore and deal with.
Oh, okay.. second example dropped a few more chars. Really looks like it ought to be the receiver (Arduino) at fault, but I suppose it could be a buffer overrun on the empeg TX path too.
I do seem to recall having to fix the Arduino library here for one of my projects: it had WAY too small of a serial RX buffer for my needs. Increased the buffer size, and problems went away.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Thanks for that tip about the serial buffer!
I was already sure it wasn't a serial buffer problem because my code handles single characters in and out in a fast loop, and my repro was only on that one U2 song going back and forth across it. But that tip is really useful and I will keep that in mind just in case I need it later.
I have traced it down to memory overwrite problems in the Arduino program's string handling which surrounds the processing of of track metadata. To make the bug go away, I can either skip the UTF-8 conversion step, or I can skip the logging that says "Artist changed to xxxx", either way the bug disappears. So it's some sort of bug related to the way those strings are handled. I'm going to poke at it some more and get the code updated to fix the bug.
I spent this afternoon writing a script to convert (most of) the Arduino C++ sketch into plain POSIX C, in preparation for trying to run it on a Linux laptop or empeg. The idea is that I just re-run the script with minor mods whenever you update the sketch.
Still poking away at it, but perhaps 75% of the way there now. The variable numbers of arguments for things like .substring and the like are giving me the most grief.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Wow, that's kind of awesome and crazy.
There are updates to the sketch today but I'm still kind of in-process on parts of it.
Then today, the BlueGiga dev board flat out stopped working. It's like it's not getting any power or something any more. And I tried it bare with just its USB cable into the UART port which used to work, but now it doesn't. I don't see any burned out components on the thing. Some time perhaps tomorrow night I'll start looking for things like bad solder joints.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Originally Posted By: mlord
It could well be (1) running too low on RAM, or (2) running out of stack space (too many nested calls, too many local variables).
Indeed, I have had that happen before in Arduino sketches. But why it would hit that condition only on that U2 album is weird. I think there's a pointer bug in some of the String functions in their compiler, and it was only triggered because the Artist string was only two characters long. I'll look through and see if it happens for other bands on my empeg which have two-character artist names. I think there might be a few of those to try, or I could edit a tag on a test song.
Quote:
Using String types instead of char * for strings results in lots of added memory usage and overhead. Arduinos don't have much to burn.
Totally understood, but the reason I was trying to use the String type was precisely because I didn't trust myself not to create memory-overwrite bugs when using char*. Literally the thing that happened was specifically the thing I was trying to avoid. Is that Morissetian irony, or just plain irony?
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Originally Posted By: mlord
So, how about you decide the final assignments within those constraints?
When I get the bluetooth dev board working again, I will try to go with this (jury is still out until I actually implement it for sure though):
Code:
1 - Pink - Originally level - Now IISD1 (empeg) <-> SDIN (bluetooth)
2 - Grey - Orignially signal - Now IISW (empeg) <-> WS (bluetooth)
3 - Blue - Power Ant (not connected on wiring harness)
4 - Black - 0v (unchanged)
5 - Brown - TX (unchanged)
6 - Red - RX (unchanged)
7 - Purple - Orginally no connection - Now IISC (empeg) <-> SCK (bluetooth)
8 - Blue - 12v (unchanged)
Quote:
Also, the empeg has 5V available internally, so if we feed that out the tuner connector, then there's no need for any extra voltage conversions.
But since I'm still leaving 12v, ground, TX, and RX unchanged, that leaves only one wire left for that 5V run:
Code:
3 - Blue - Power Ant (not connected on wiring harness)
... And that one isn't connected to the wiring harness. There's no pin on the docking connector for it. And I can't hijack the existing 12v blue wire because that's the one that comes out the dock connector for the Amp Remote wire. So I think we're stuck with our own power supply.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Originally Posted By: mlord
I spent this afternoon writing a script to convert (most of) the Arduino C++ sketch into plain POSIX C,
By the way, I've done that sort of thing with the Roslyn library features, converting an entire company code base of Nunit 2.x and MSTest unit test cases into Nunit 3. It was painful but I did it!
There's no pin on the docking connector for it. And I can't hijack the existing 12v blue wire because that's the one that comes out the dock connector for the Amp Remote wire. So I think we're stuck with our own power supply.
I was wondering about stuff like that. Okay, so let's steal something else from the main docking connector? The microphone, perhaps? Or one of the main serial port pins (since they're all on the back of the case as well as on the docking connector). DCD perhaps?
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Quote:
Or one of the main serial port pins (since they're all on the back of the case as well as on the docking connector). DCD perhaps?
Nope, only RX and TX and Gnd are connected to the serial port plug, and it would be a bad idea to get rid of those, a worse idea than getting rid of the tuner module serial connector. There are some things you can only do on the player if you've got that main serial port available. I personally know that I wouldn't give it up on my player.
There are a couple other pins coming out of that part of the serial connector, but they're being used for Cell Phone mute and Headlight Dimmer Sense instead of things like DCD and such.
Oh hey. Cell phone mute might be good for that. I think I already talked about that wire earlier. Since we're doing a bluetooth project that connects to a head unit that will have cell phone mute inherent in the bluetooth connection, a physical wire is no longer needed for that.
So are you suggesting to get another male pin for the empty one on the Molex tuner plug, and wire the docking connector pin which USED to be the cellphone mute wire and then adding that to the tuner connector instead, and then make that the 5v supply? That seems like a lot of surgery to go to just so that we don't have to build a power supply into our design. I think it's better if we just bite the bullet, do the power supply, and simplify the connector down to just that one tuner plug and three wire modifications inside the empeg. That Pololu supply I got is working fine and is super easy to wire up.
Yeah, okay. Simple enough to just use the existing 12V for power.
I just find it a bit weird to be going through so many contortions to get voltages that already exist in fine form from the empeg.
The BT module REALLY wants 3.3V. But it doesn't have a suitable input on the dev board for that. So we feed it 5V, and it has an onboard power supply to make that into what it wants: 3.3V. The empeg has both of those available, but instead we're feeding it 12V. Just seems peculiar, though convenient.
But yeah, let's have just one voltage out for now, and the existing 12V is probably it.
I didn't realize that the tuner molex has only 7/8 pins populated -- I have replacement connectors for it here, so mine have all 8 pins. Perhaps I'll use the "spare" unpopulated pin for my own purposes..
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Originally Posted By: mlord
I didn't realize that the tuner molex has only 7/8 pins populated -- I have replacement connectors for it here, so mine have all 8 pins. Perhaps I'll use the "spare" unpopulated pin for my own purposes..
The problem isn't the missing pin on the molex connector, the problem is that there's no corresponding position coming out of the sled docking connector for that spot. So it's more than just "not populated", it's literally not available at all for connecting the inside of the player to the outside world. So you'll have to hijack a different wire from somewhere else on the docking connector for that purpose. The cell phone mute wire is a great candidate for that, I think, it just requires more complicated surgery.
Found another copy of the sled wiring diagram in the BBS history to help illustrate. It shows the cell phone mute wire as a light green wire that is connected to serial plug pin 1, and the headlight illumination sensing wire as a gray wire (actually white in reality) connected to serial plug pin 8.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Totally separate thing now...
I think my BlueGiga dev board started malfunctioning in terms of its internal power conversions circuits yesterday.
It stopped working entirely, and I got no output from its serial ports.
Tonight I measured the voltage on several of its pins, and I did this measuring both with it hooked into my assembly and getting its voltage from there, and also when it was disconnected from my assembly and getting its voltage directly from the serial port. For places where it was supposed to be getting 3 volts, such as "VDD_IO" it was only getting 1.5 volts. And for places where it was supposed to be getting 5 volts, such as "VDD_CHG" it was only getting 4.5 volts. All other voltage test points were similarly lower than expected.
I verified that my assembly was putting out exactly the expected voltages: 4.95-5.00v on the 5v pins.
However when I connect my assembly to the BlueGiga board, the voltage on those pins drops to 4.5v.
If I take the 3v pin from the Arduino and jumper it to the 3v pin on the BlueGiga board, then suddenly it all works again. I wasn't using that pin because I had previously been using the 5v input ("VBUS") pin on the BlueGiga board. Do you think I should change that so that I use the 3V pin coming out from the Arduino exclusively instead? Or maybe both Vbus (5v) and 3v simultaneously (since Arduino outputs both)?
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
I think the chip seems to work correctly whether I connect the 5V rail or the 3v rail either way. Can you tell if there's anything on that dev board that truly needs the 5 volts besides the battery charger (that we're not using)?
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Hm. When I connect that 3V rail and the board is working again (regardless of whether I have the 5v rail connected, then this chip on the BlueGiga board gets quite hot.
This occurs without any of the I2S pins connected. All that's connected are jumper wires from the Ardunio on these pins: - 5v (either connected or not) - 3v - Gnd - RX - TX
This worries me. What has gone wrong with my BlueGiga board I wonder?
And I wonder if that chip or any of its supporting circuitry is the problem and if I can disable it easily?
When I connect up the board with just the 5v rail connected, the chip doesn't get hot, but also the BlueGiga doesn't work and I get no serial output from it.
Whereas if I connect up the board with the 3v rail connected, the BlueGiga works and I see serial output, but the AIC32I audio codec chip gets real hot and I'm afraid to leave it that way for any length of time.
This is with all I2s connections disconnected by the way. Just the power, ground, serial.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
And even when I briefly supply the 3v rail to get the board working again and pair it up with a bluetooth device, I no longer get the I2S audio out any more.
I think that circuit is fried. I sure wish I knew whether it was something I did or if it was just a bad chip or something else bad on the dev board.
Mark, how tough do you think it would be to do the WT32i chip bare, without the dev board? How much supporting circuitry do you think we need for: - Serial RX/TX - Line in - I2S in.
Even willing to drop the line in at this point, even though my whole idea was a fully external box so that folks don't have to mod the inside of their empeg.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Attached is a screen shot of the relevant portion of the schematic of the WT32i development board where they have that external codec plugged in. It's part of their zip file of the full design documents for the development board at this link: https://www.silabs.com/documents/login/reference-designs/DKWT32i-v2.2.zip
I wonder if I have blown one of the caps in that ladder that connects to its power inputs. I don't see anything visibly physically wrong, everything looks OK there.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Originally Posted By: mlord
I do seem to recall having to fix the Arduino library here for one of my projects: it had WAY too small of a serial RX buffer for my needs. Increased the buffer size, and problems went away.
Look for "#define SERIAL_BUFFER_SIZE" and make it bigger.
I thought I'd try this, even though I had convinced myself it wasn't the root of the issue, I'm having trouble locating the root of the issue so I'm going back over my previous assumptions and I'd like to try this. My problem is that I can't find the file in question. I'm doing the development on Mac OS X and the file just isn't showing up anywhere that I look for it.
Searching for this information on Google isn't giving me any valid answers, unfortunately.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
I found the file - Macs have something that looks like a single application file (in this case "Arduino") but it's actually like a zip file. The USBAPI.h was in there. I am not 100 percent certain that I edited it correctly or that the compiler will "take" the file or not, but I tried it.
I think the best place to connect external 3.3V power to the BT-dev board would be at the (white, 2-pin) battery connector (or to the "Battery Current" jumper). That input will accept up to 4.4V, and it gets internally regulated to what the various parts of the dev board want.
Connecting it directly to the 3.3V (OUTPUT) on the top-left header isn't ideal, and could be why parts of the board want to overheat.
Now, why the external USB power wasn't working: this should just be due to the 5V-to-3.3V conversion chips perhaps having failed. There are two chips in series for this: U14, and then U1 (labelled photo attached).
U14 (on the right) converts the 5V from USB down to 3.6V ("battery level"). U1 (on the left) converts the 3.6V from U14 down to 3.3V ("logic level").
You can check for correct operation of each of those with a voltmeter. Power the board from the USB connector (or possibly the UART connector, but I'm using the USB connector here).
The top left pin of each chip is its output. Measure voltages using either of the USB shells as GND. The chip on the left (U1) should be outputting 3.3V, and the chip on the right (U14) should show 3.6V.
If either chip doesn't show the correct output, then check the input to each chip, on the bottom left pin (magenta dots in the photo).
Did some continuity testing, and the SCK pin on the BlueGiga chip has continuity with the 3v rail. Maybe that's the root of it.
From reading the datasheet, it appears that SCK (and SWS) are bidirectional. The Wt32i can be programmed to have those as inputs (what we need), or as outputs. If the latter, then you'll see 3.3V on them (bad).
I like the look of that. Cheap-ish at only USD$10+shipping (without WT32i). And it takes care of converting the pin spacings to something more usable for us. Ordered one!
If you look at the schematic for it, it shows what extra circuitry is needed to run a standalone wt32i: not much, just a 5V to 3.3V power supply, and it also provides a USB-UART for easy programming. That, with a WT32i module on it, looks darned near perfect for our needs when using I2S.
I am not 100 percent certain that I edited it correctly or that the compiler will "take" the file or not, but I tried it.
I changed it to 256 but it didn't fix the issue.
There were two lines with that setting in mine here, with an #ifdef deciding which one to use. You can test whether or not your mod gets picked up by inserting a #error line there for testing. Eg.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Originally Posted By: mlord
There were two lines with that setting in mine here, with an #ifdef deciding which one to use.You can test whether or not your mod gets picked up by inserting a #error line there for testing. Eg. #error "it works"
Mark, you are brilliant, thank you. My change isn't getting picked up.
I inserted the #error "it works" , both with and without the quotes (the file has an example of it without the quotes right below there) and tried putting it both before and after some of the #if statements surrounding the SERIAL_BUFFER_SIZE stuff in that section of the code (including placing it before the #ifndef SERIAL_BUFFER_SIZE statement so it should definitely have been hit). The compilation step never blows up with an error message, either when using the installed local Arduino compiler or their online compiler.
So if my issue really is a serial buffer size issue, then this change isn't helping because it's never hitting the change. That's so awesome that you suggested putting an error into the compilation to see if it even hits the code. Super helpful!
I've been googling around trying to find the correct way to do this, and all the answers say either "make sure your code doesn't ever let the buffer fill up" or they suggest changing the exact same line that you already suggested changing.
If the serial buffer does turn out to be the root of the issue, then I would want to rearchitect the code to fix the issue, but before I do that I need to know if that's even the issue at all, so I want to try to get this buffer size experiment working. I'll keep poking at it.
By the way, the file in question was located in this place on the Mac: Macintosh HD -> /Applications/Arduino (which, once you're inside it, gets listed as "Arduino.app" in the directory tree) (then you have to open the contents of the "Arduino" App, then) Contents/Java/hardware/arduino/avr/cores/arduino/USBAPI.h
When compiling I have tried both the "AVR ISP" programmer option and the "AVRISP Mk II" programmer option, and the compiler output says that at least it's hitting the right folder, though I don't see that particular file in the list:
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
And of course you were right. The bug goes away if I increase the serial buffer size. I feel terrible for rejecting your suggestion when you first made it.
I have to really rethink some things if I want to work around this issue, or, I could just depend on a bigger buffer. Hm.
My apologies for not specifying the correct file first time around.. I was looking at an older version of the Arduino stuff. Of course in the latest (which I also have and use) it is in the file you found.
The problem you face, is that the empeg bursts a ton of stuff rather quickly on track change. The buffer has to be big enough to hold all of that, or you have to be polling insanely too often.
Bigger buffer is probably best, if you can spare the RAM. This will be a non-issue for me when I do it all internal to the empeg.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Originally Posted By: mlord
Bigger buffer is probably best, if you can spare the RAM. This will be a non-issue for me when I do it all internal to the empeg.
Agreed. I can easily spare the RAM, but I'm trying to make this thing easy for third parties to put together themselves. Editing the Arduino compiler header files (and having to maintain that after Arduino compiler upgrades too) is a pain that I don't want to have to put anyone else through.
But at the moment it's all I've got, for the reasons you cited.
I wish I could just put "#define SERIAL_RX_BUFFER_SIZE 256" into my own code and be done with it, but of course that doesn't work.
I could look and see if rearchitecting my code to use "serialEvent()" works, i.e., if it still calls that routine even if I'm deep inside another routine. In other words, make it truly event-driven instead of polling. I could constantly build up and regularly drain a stack of completed string lines from the Empeg serial port. That might be possible if that function works the way I think it should.
In the meantime, I'm going to put a pre-check step into the Arduino sketch to print a warning message if the buffer size isn't big enough.
And then I will move on to the power supply debugging you suggested earlier - Thanks again so much for that too, that is super helpful.
Track titles are much more reliable now. I fixed multiple bugs that would cause the track titles to sometimes not be parsed properly. Some of those bugs were new String/memory bugs that I induced when I made attempts to work around what I had incorrectly thought were String/memory bugs in the first place.
There is also now the check routine in there to confirm at program startup that the string buffer size is big enough, and will print an error on the serial port if it isn't big enough. Considering whether or not to do something like halt the program and make the LED blink if the string buffer isn't big enough, but I haven't gone that far since the worst thing that could happen is the track titles don't always work.
Yes. That's a weakness in the Arduino library. The buffersize should be a parameter to each instantiation of a Serial object, rather than a hardcoded value that is applied to each and every serial port.
Eg. Right now, if you change that define to 128, this means that all THREE of your serial ports are going to get the same large buffer, wasting a fair bit of precious RAM (on some chips anyway).
But for now, if you can spare 3X whatever the buffer size, then just go with that.
With the smaller WT32i breakout board you found (mine will be here later in the week), I suspect that board will be the one that anyone else here might choose to use. And it is a natural for placement inside the empeg. In which case, the eventual port of the Arduino sketch to native-empeg might end up being what is wanted.
And it will have no such buffer issues, not least because Hijack already captures the notify strings and maintains the latest of each in /proc/empeg_notify for app use.
So probably not worth fussing further over for now, at least. Heck, the Arduino library might even get fixed by the time you need a "simpler" solution. Or you could clone the serial library and distribute a fixed version for installation by others. Or just provide a pre-compiled binary of the sketch. Etc..
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Originally Posted By: mlord
U14 (on the right) converts the 5V from USB down to 3.6V ("battery level"). U1 (on the left) converts the 3.6V from U14 down to 3.3V ("logic level"). So, check those and report back.
U14 on the right: 3.54v output on upper left output pin, source voltage on lower left pin: 4.39v U8 on the left: 3.28v output on upper left output pin, source voltage on lower left pin: 3.54v
Additional voltages from the current jumpers in the middle of the board:
3.29v VDD_IO CURRENT 3.54v VDD_BAT CURRENT 1.15v VDD_CHG CURRENT (battery switch is off and no battery is installed) 0.00v BATTERY CURRENT (battery switch is off and no battery is installed) 4.39v USB CURRENT
Something I haven't tried yet... Now that I've removed that TI codec chip, I'm going to see if powering it on its 5v VBUS pin works again.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Indeed it works just fine now, powering from either USB or from my board assembly with the tuner connector, using the 5v "Vbus" pin to power it like I was doing before the malfunction. And now, with that TI codec chip removed, nothing is getting hot any more. I still don't have I2S any more and I have to fall back to analog, though. Which works, but I really miss the cleaner sound that the I2S connection gave me.
I wish I knew which component was the failed one and whether or not I caused it.
I have high hopes for that other breakout board. I ordered one too. Once I get that smaller breakout board, what's your recommendation for which pin to power it from?
I have high hopes for that other breakout board. I ordered one too. Once I get that smaller breakout board, what's your recommendation for which pin to power it from?
There's a contact hole/pin labelled "5V" on a corner of the board at the same end as the USB connector. The schematic shows that pin being connected directly to the 5V contact from the USB mini connector, so that's the one to use.
I wish I knew which component was the failed one and whether or not I caused it.
I am wondering about that external I2S codec chip. If the Wt32i firmware isn't careful enough, or if perhaps the settings being used result in it enabling its outputs, then that chip could be driving voltage onto the I2S pins. Fighting the empeg voltages. Uh oh.
That could result in a very hot chip, a fried chip, or perhaps fried I2S outputs on the empeg too.
I think I'll just cut the I2S traces to/from that chip on mine before hooking them up to an empeg. Or do what you did and just get rid of the darned thing.
Kinda surprising the dev board lacks jumpers to disable/bypass the chip.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Hypothetical question.
Let's say someone had previously modified the interior of their empeg according to my older wiring scheme of:
- Pink "Tuner Level" wire connected to "IISD1" pin - Brown "TX" wire connected to "IISW" pin - Red "RX" wire connected to "IISC" pin
Now let's say that person happened to have a home dock on their desk, one they'd made themselves out of an extra sled several years ago. And let's say that, hypothetically, behind their desk, they had hooked up an actual tuner module there to that home dock, one they hadn't made use of in years and had forgotten was there.
If, hypothetically, that person then docked their empeg into that dock to use emplode to modify some playlists, what might happen to the I2S/DSP circuits of that empeg in that case? And then later, if that same empeg was then reconnected to the BlueGiga dev board after that, what might happen to that dev board?
If, hypothetically, that person then docked their empeg into that dock to use emplode to modify some playlists, what might happen to the I2S/DSP circuits of that empeg in that case?
Outputs fighting outputs. Something's gonna get fried.
I'll see if I can figure out a way for you to test whether or not the empeg I2S is still working or not -- an oscilloscope or logic analyzer would be ideal, but perhaps other means might work here.
EDIT: Okay, volt meter on pins 1,2,4,5 of the I2S header. On my empeg, they all average out to about 2.4V while playing Pink Floyd.
If your empeg board is no longer outputting I2S, then it's strictly limited to the DSP chip -- replace that, and all would be good again. But more practically speaking, if you don't have a spare empeg or two laying around, we (you and I) could just do a mainboard swap via the post. Let me know. We have at least six of them laying around here.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Cool, thanks very much for that check information! My "friend" will do that voltage check on those pads when he gets home tonight.
I do have a couple of spare Rio Car units, which I bought specifically for part situations like this, so I could do a mainboard swap for my "friend" if necessary. I'm hoping it won't come to that.
In the meantime, on your copy of the BlueGiga development board, what does your continuity tester say for continuity between the SCK pin on the BlueGiga chip and the 3v rail? The 3v rail is the upper-left-most pin on the dev board, and you know where the SCK pin is. Since you have a working undamaged board+chip, I'm wondering if you see the same continuity between those as I do. If not, then I know that it's that part of my BlueGiga chip that's fried.
what does your continuity tester say for continuity between the SCK pin on the BlueGiga chip and the 3v rail?
In the ballpark of 0.6 to 6.0 mega-ohms, but with some obvious large capacitance in there making an exact reading somewhat variable and dependent upon which way around the leads are connected.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Things bode well. My, er, my friend's, values are different than yours, but I'm getting voltages in the 1v-2v range on the SCK, WS and SDIN pins, and those voltages change depending on whether the empeg is paused or playing. The SDIN pin fluctuates on voltage as it's playing and is pretty steady when it's paused. It's a low voltage in the range of 1.4v when paused, and closer to 2v when it's playing. I think that tells me the empeg might be fine, and all my, er, my friend's, problems are entirely on the bluetooth chip.
Phew.
OK, now this raises the question of our design. What can we do to prevent other people from making the same mistake and frying their stuff too?
Or maybe we won't need to worry with our new pinout scheme. I wonder if the frying happened only because I, er, my friend, was using the old scheme with the RX/TX wires being used for the SCK and WS pins. Maybe with the new scheme this won't be a danger (maybe we'll luck out)?
The new scheme will have IISC on the originally unused purple wire, so there's no danger there for that one. IISW and IISD1 will be on Tuner Level and Tuner Signal. I wonder if that might fry the tuner but not the empeg if they did that? Dunno.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
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:
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:
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.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
The AVRCP specification states there should be either a REJECTED and/or a NOT IMPLEMENTED response available for these. However I can't find any documentation of the syntax for either of those commands in the iWrap command language.
What can we do to prevent other people from making the same mistake and frying their stuff too?
Its not just I2S, but also the serial RX/TX pins in my case.
We can add circuitry inside the empeg to tristate the I2S outputs when Bluetooth is not connected. This would consist of some MOSFET transistors and a resistor or three, plus a signal to enable those outputs when needed. The tricky bit is, from where do we get that signal? It can be software controlled once I find a spare output pin somewhere, or manually controlled with a switch/button.
Or perhaps something more passive might work, such as diodes to prevent reverse current on those pins. That's easy enough for the empeg, but something similar should be done for the tuner as well: perhaps inline diodes on the tuner's half of its wiring harness. Nice and safe then, just need to ensure the voltage drop (from the diodes) isn't excessive.
Quote:
The new scheme will have IISC on the originally unused purple wire, so there's no danger there for that one. IISW and IISD1 will be on Tuner Level and Tuner Signal. I wonder if that might fry the tuner but not the empeg if they did that?
Could fry either/both. I think diodes might be the way to go.
Or, just put the new/smaller BT breakout module inside the empeg, so that it doesn't need I2S connections on the tuner wires. Will still have to do something similar for the serial connection though, either MOSFETs or diodes to prevent the same issues on those wires.
I'll be on Christmas break starting three weeks from now, and hope to take a really good look at things then. Perhaps there may be a feasible way to add another dedicated serial port to the empeg for just the BT module.
One crazy scheme bouncing around in my skull is to stuff an ESP8266 module inside there, and perhaps connect to the the empeg via a 4/8 bit parallel connection by plugging into the IDE cable. That would give enough bandwidth for comms between it and the empeg, and then it could easily manage most of the BT housekeeping duties on its own.
If you haven't yet discovered the ESP8266, well.. it's a nice fast micro-controller with built-in WiFi-N, 14 I/O pins, tons of RAM and flash memory, and can be programmed using the Arduino tools/libraries. It's also about the size of a small postage stamp, though it gets larger once soldered to a breakout board (similar to the BT breakout you found).
A nice side effect of embedding one of these, is that we could also use it to give the empeg a WiFi interface.
Or sometimes I wonder about slightly more invasive surgery.. such as installing a USB host controller chip inside the empeg. With that, once could then just plug-in all manner of things, including the BT-module, an ESP8266 module, etc..
Except the empeg's base kernel is WAY too old, and lacks the device drivers needed for anything other than a keyboard or mouse.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Originally Posted By: mlord
Or, just put the new/smaller BT breakout module inside the empeg, so that it doesn't need I2S connections on the tuner wires. Will still have to do something similar for the serial connection though, either MOSFETs or diodes to prevent the same issues on those wires.
No you wouldn't, you'd just disconnect the tuner RX/TX wires from the interior plug on the empeg and problem solved.
Quote:
We can add circuitry inside the empeg to tristate the I2S outputs when Bluetooth is not connected. (...) It can be software controlled
That wouldn't help, the bluetooth doesn't connect instantly when you dock it, and software wouldn't run instantly at bootup. you'd fry stuff before things got connected or software got running.
Quote:
Or perhaps something more passive might work, such as diodes to prevent reverse current on those pins.
Not sure about the directionality of the current in each case: Empeg connected to tuner module, we don't want to damage the empeg or the tuner module, but then when the same plug is connected to the bluetooth interface box then we need the current to flow to the interface box.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Originally Posted By: tfabris
Things bode well. My, er, my friend's, values are different than yours, but I'm getting voltages in the 1v-2v range on the SCK, WS and SDIN pins, and those voltages change depending on whether the empeg is paused or playing. The SDIN pin fluctuates on voltage as it's playing and is pretty steady when it's paused. It's a low voltage in the range of 1.4v when paused, and closer to 2v when it's playing. I think that tells me the empeg might be fine, and all my, er, my friend's, problems are entirely on the bluetooth chip.
I just realized this doesn't bode well.
If the empeg is functioning OK (won't know for sure until the other bluetooth chip arrives in a few days, but let's assume that it is for now) then what caused the bluetooth dev board to fry? I thought originally that perhaps it was my docking the empeg to the tuner that broke something, then the act of reconnecting it to the dev board broke the dev board. But if the empeg wasn't damaged by the tuner docking, then that theory doesn't hold.
We can add circuitry inside the empeg to tristate the I2S outputs when Bluetooth is not connected. (...) It can be software controlled
That wouldn't help
Sure it would. It just has to default to "not connected" (MOSFETs turned off), and then they get turned on after the empeg determines what is actually hooked up.
Diodes could work too, without need for control, so long as the voltage drop isn't too much. The diodes on I2S inside the empeg would be oriented to only let current flow outward, and the diodes on the tuner's stub would be oriented to only let current flow in the direction the tuner expects. Very compatible.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Good points.
Since we'll be using "level" and "signal" wires on the tuner connector, and radio/tuner stuff is an iffy thing related to signal path cleanliness, would diodes or MOSFETs cause those things to not work as well?
Also, if doing diodes, do you know what directions-of-current are expected for the various parts?
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
By the way, Peter Betz (the maker of that BlueGiga Breakout board) sent me a DXF file with the pin layout and board dimensions. Dropped into Pad2Pad perfectly so that I could begin designing my next PCB version in advance. Let me know if you need it.
Cool! My board (with WT32i) just shipped today, so it won't be here until Monday. Not that I need it right away -- planning to use the dev board as much as possible to get things running, just in case I fry something.
- Now needs both TX and RX serial buffers for Arduino increased. - Amount of increase is now only 128 instead of 256 because I had other weird problems at 256. - Experimental reject responses to messages I don't want registered (though I couldn't test this much because the issue stopped happening on my system so I don't have a repro any more). - Other small tweaks.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Another update which works around some other bugs I found, some of which pertain to you (such as not screwing up when the track has a single quote in the track title) and others which don't pertain to you (austerity measures for memory/string usage on Arduino).
I'm still totally stumped by the need to reject certain PDU_REGISTER_NOTIFICATION messages, I thought I had a working solution but it didn't actually work the way I thought it did. There's a really teriible crappy workaround in place for it right now that I really need an answer from Silicon Labs support to fix properly.
Cool. Well, Christmas is coming. I'm hoping I'll be able to adapt this to C on a Linux laptop over the holidays, and then just replace the laptop with an empeg afterwards.
Still no sign of the new breakout-board -- last logged in Edmonton, which at least is within the same country, if not thousands of miles from here.
The player application also spits out play/pause state and current playback position when those change:
Code:
serial_notify_thread.cpp: 170:@@ S0 (state, 0=paused 1=playing)
serial_notify_thread.cpp: 180:@@ #f4f0 0:00:12 (fid and current playback position of song)
This is missing the following data that the Bluetooth wants in its queries for information: - Total tracks in current playlist - Album title - Total time length of currently playing track
Is there any way to do a Hijack hack, so that when the track metadata appears on the serial port, you use Hijack to go fishing for that information and then append that information to the serial port in the same type of format? For example, you could output it right after the Artist or the Genre. My code currently monitors for all of those things and constantly logs them, then triggers to send that data up to the host stereo in the following situations: - Play/pause state changes. - Track current playback timestamp changes. - Genre message is received (at which point it sends all of the track information up).
Though if your version of the code will not be monitoring the serial port at all and will instead be retrieving that information directly then I could understand why you might not want to waste the time on it. However there are some advantages to monitoring the serial port for this information... It means that you wouldn't have to do any detection logic to determine when any of that stuff changes and could just wait for the player application to tell you about it via the serial messages.
Hijack already does monitor the serial port for exactly those bits of information, and it stores them in /proc/empeg_notify for use by other apps. When I do the BT stuff within the empeg, that's where I'll read it back from.
But /proc/empeg_notify has only what the player feeds it via the serial port today. It is missing the same stuff you need. So it follows that I will have to run off and look up at least some of it (eg. Album title).
The place to get it from is the tag file in the fids directory. Here is a sample tag file:
Code:
type=tune
length=2532155
title=Now And Then
artist=Arlo Guthrie
genre=Folk
source=Alice's Restaurant
codec=mp3
bitrate=vs140
offset=0
samplerate=44100
duration=144157
tracknr=04
Anything in there is doable. Anything beyond there is getting a bit complicated. There is no "Album" field, but "Source" appears to be more or less equivalent, so that's one item down. The track "duration" is also available (yay!).
Those two are relatively "easy" to get, and Hijack could indeed inject them into the appropriate place within the output stream on the serial port. Since I will need them anyway, most of the work in obtaining them has to get done regardless.
Beyond that, things get fuzzy: tracknr is not useful, as what we really want is track position within the current playlist, which is already there (whew!).
Which leaves just the number of such tracks in the playlist. That info is more difficult to come by. We know where it is, and how to read it though, but it will require more than a bit of work to obtain.
Okay, this should do for starters: I am inserting two new lines into the serial output, just after any 'F' (fid) line. My lines are numbered 191 and 192 for now. 'Z' is the 'source(album)', and 'D' is the 'duration'. These are straight from the tags file. I think 'duration' is in milli-seconds.
Hmmph. My first attempt at getting the length of the current "playlist" was a dismal failure.
The player used-to keep the current playlist number in the flash savearea, but the value there never seems to update (shown on Hijack Vital Signs screen).
Fine, the current running order is stored in /dev/hda3, so I figured I could use that. Except it doesn't get updated for some time after starting a new bunch of tracks from the menu. As in, not for 20-40 seconds.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Mark, you are a scholar and a gentleman, and an all around cool guy.
I can't wait to get home tonight and try this out. That is so very awesome.
The playlist length is not particularly important right now, I don't know how many headunits display that information. My headunit requests that information but does not display it anywhere. My code currently puts something like "99999" in that spot as a placeholder, and it doesn't seem to hurt anything. I know that information is in the empeg somewhere though, because one of the display modes on the empeg screen displays it. But I wouldn't knock yourself out trying to find it right now.
Crazy idea: At some point in the future you could have the serial port spit out a different (new) set of variables which are the true track number and the true length of the album (aka "source") on the serial port. Those values are something that you can potentially get out of the FIDs. Then we could have a flag in the BlueGigaEmpeg code where the user gets to choose which of those things their headunit displays: Either the playlist position and playlist length, or, the album tracknumber and album length (which, if you're shuffling the whole player, the album track/length would seem to change randomly but would still be accurate to that particular album while it's playing). Ooo. Or maybe this! If the player is shuffling, put out the playlist position/length information in the regular spots, but if the player is not shuffling then put out the album track/length informaion in place of them. But that's for the future, right now what you've got is perfect already, and I plan to implement it tonight.
Very excited about this. Thank you so much.
And I see my inbox has a response from Silicon Labs. Really excited to go look at that.
So, the player doesn't dump the current running order to disk until AFTER it has finished all of its read-ahead and is then about to spin down the drive. That's why it takes so long to show up there.
I can grab the track count at that point though, perhaps half a minute or so after the playlist begins.
The whole problem here, is I don't have a way to know what playlist is being played.
One other thing I tried, was checking to see if the player used a static buffer for it, which Hijack could then memorize and inspect directly instead of waiting for a disk write. No such luck, or at least not on my first attempts.
I think I'll just leave it for now.
A different thing: if you were to ensure that the Arduino sketch doesn't care about the "serial_notify_thread.cpp: " prefixes -- as in, they might or might not be present -- then I can update Hijack to suppress them, and that would probably solve your serial buffer woes.
EDIT: Or Much better for both of us: I'd like to get rid of everything before the "@@" characters, leaving just this type of stuff:
Code:
Prolux 4 empeg car - 2.1485 Jul 25 2005
Vcb: 0x40772000
@@ N41
@@ F0x169e0
@@ ZCelery Stalks at Midnight
@@ D215816
@@ TDon't Make Me Sing Along
@@ AAl Simmons
@@ G
@@ S1
@@ #169e0 0:00:10
@@ #169e0 0:00:04
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
That's an interesting idea about the serial port messages: Shorten the messages to make the serial port less crowded.
At the current time I don't need that change, since your excellent tip about increasing the buffer size has things working well for me at the moment. As long as things are working correctly right now, then I don't see a need to change it. Also, for any situation where we're interpreting a data stream, having strong positive identification of a particular piece of data in the stream is a good thing, even when it takes up extra bytes.
However let's keep that idea handy just in case we need it later. :-)
In other news: The Silicon Labs reply was a non-reply, they just said "look at the bluetooth specs" which I already did. They didn't understand that my question was a question of syntax in their iWrap command language that isn't fully documented. I'm still trying with them. :-)
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
I have another reason I'm not super keen on getting rid of the "SerialNotifyThread.cpp" portion of the messages unless absolutely necessary: Doing so would require a particular recent Hijack version to be on the player before the BlueGiga code works at all. If we don't change the root messages, then the code would continue to work with nearly any Hijack version, and the only major thing that the user would lose is the Album title with older Hijacks.
Also, I don't know if anyone else is using those "SerialNotifyThread.cpp" messages at the current time. Changing them might break other people's software, potentially, if anyone else is interpreting those messages. Not sure though.
However, if you're still really keen on doing that for your own reasons in your own version of the code, then I will happily update my code to parse for just the parts you've spec'd there. Either way works for me.
if you were to ensure that the Arduino sketch doesn't care about the "serial_notify_thread.cpp: " prefixes ... Or Much better for both of us: I'd like to get rid of everything before the "@@" characters, leaving just this type of stuff:
Code:
Prolux 4 empeg car - 2.1485 Jul 25 2005
Vcb: 0x40772000
@@ N41
@@ F0x169e0
@@ ZCelery Stalks at Midnight
@@ D215816
@@ TDon't Make Me Sing Along
@@ AAl Simmons
@@ G
@@ S1
@@ #169e0 0:00:10
@@ #169e0 0:00:04
Implemented. If you re-fetch http://rtr.ca/hijack.zImage now, it has this change, conditional upon setting suppress_notify=2 in the config.ini file. Otherwise you still get the old serial buffer overflow style of output.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Originally Posted By: mlord
Note that we now already require "a recent Hijack version" in order for Album title and duration to be shown.
Already noted in my earlier post, but you're right, we might as well just say "hey, you need the latest hijack".
Quote:
And that is much easier than having to hack the core Arduino serial library, especially for folks with other sketches that also use serial.
Good point. I'm not sure whether the shorter strings will fix the issue enough so that I don't need the buffer size fix at all, but they'll certainly help!
Quote:
conditional upon setting suppress_notify=2 in the config.ini file
Nice way to maintain backwards compatibility! Cool!
Can't wait to get home tonight and implement all this.
I've added a 'R' line now, with the number of tracks in the current running order. It begins with 99999, but is updated later when the information becomes available.
An empeg with an SSD will get the update much more quickly than one based on spinning rust.
Getting this part working took ages.. eventually figured out the compiler bug that the code was tripping over.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Sorry you had to wrestle with the compiler!
I'm really excited to try it out. I'll get right on it as soon as I get home in a couple hours.
I'll need to rewrite my parser, which used to base itself on the number which fell before the @@ signs but now will have to base itself on the letter which falls after the @@ signs. Should theoretically not be too hard. On the timestamps, I'll be looking for "@@ #" and then parsing for the timestamp that falls after the FID number after that, right?
Question: Under what conditions does "R" come up? - In the middle of the track data blob of output? - Also when it changes later on? - When R does change later on, is a whole new track data blob spit out, or is it just the R line (doesn't have to be, just want to know which to expect)?
R pops up pretty much randomly, usually by itself. in the middle of a bunch of # reports typically, and NEVER when the player is paused.
It will pop up as 99999 initially when the player is booted (along with the other first track data), and then later show up with the real number. When a new playlist is selected via menus/whatever, it will pop up again at some point with the new value, but never until the drives finish read-ahead and then spin-down.
EDIT: You may be able to "force it" sooner by putting the empeg into suspend/sleep mode.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
All working. So far I'm getting all the data on the serial port that I expect and my new parsing code is working as expected.
My parsing code will theoretically be successful with old and new Hijack versions but just won't get the new geegaws with the old versions.
I'm going to spend a little time validating that everything really works perfectly, make sure my code is updated, and then save a new version to the Arduino site for you to grab.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
The Betztechnik breakout board is giving me some trouble that I'm trying to figure out. Note: This is all *after* I have already successfully updated its firmware to the same/latest version
1: The BlueGiga development board, when powered up, comes up already in command mode with the serial terminal already communicating and accepting commands. The Betztechnik breakout board does not. When it first powers up it is in some kind of other mode and I must physically press its reset button before the serial communications will work.
2: Even after I reset it and serial communications are working, my commands to set up the board and configure it don't seem to "take" all the time. For instance SET BT NAME EMPEG CAR doesn't always work. I don't know why. Maybe related to 1, above.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
I think that #1 was merely not setting the little switch on the board to the correct direction. With the switch set into the left/up position, it boots correctly when power is applied.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
I think that #2 is caused by a thing where the chip resets itself when I send it too much serial port data all at once quickly. There is something in the documentation about how the chip can be reset with certain stuff related to serial port, but I'm not sure where the root of the issue lies yet. I continue to investigate.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Yeah there's something going on with the UART configuration of this Betz board which causes the chip to reset itself at random points during serial communications.
Whenever I issue a large series of commands to the thing all at once, it almost always resets itself, meaning that most of the commands don't get through at all.
On rare occasions it resets itself even if I type a fairly short innocuous command in the serial debug terminal, for example:
SET CONTROL BATTERY 0 0 0 0 WRAP THOR AI (6.2.0 build 1122) Copyright (c) 2003-2017 Silicon Labs Inc. READY.
I can't simply "delay" my commands to the thing because some of the stuff will need to be very fast responses.
None of this happened with the BlueGiga development board, I could send commands as fast as I wanted and there was no problem.
My first try was to disable the feature that puts it in and out of data mode via DTR signaling: SET CONTROL ESCAPE - 00 0
.. are those the same ones also being driven by the USB serial chip on the board?
I just had a look at the schematic, and yes, they are. You will need to cut the trace at JP4 to be able to use the WT32i serial port directly (non-USB).
Just run a very sharp knife between the two solder blobs there to cut the thin copper trace. This will deny power to the USB-serial chip.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Yep, that fixed it. NICE!
Note: This means that whenever we get one of these breakout boards we will have to make sure to flash it with the latest firmware BEFORE cutting that trace. And remember to reconnect the trace if we need to flash it again.
I was already on my way there, having noticed that the BlueGiga dev board schematic has special circuitry which disconnects its UART if no cable is plugged in to its USB port. You beat me to it!
I has also found this in the BlueGiga docs and was trying this but it didn't help: "The hardware flow control is enabled by default. HW flow control can be disabled in HW by connecting UART_NCTS to GND and leaving UART_NRTS floating."
I had also tried ENABLING the RTS/CTS lines to the UART by soldering their jumpers (which are disconnected by default). Also didn't help and actually prevented any serial communication from working at all.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Quote:
I had a good look through it all and actually understood all of it.
Cool! Now you can rewrite it properly instead of all hacky like I did! :-)
I've saved my latest code to that site just now, to pick up a couple more small tweaks I did.
I now have the new BetzTechnik board working equally as well as the original BlueGiga dev board. And my empeg is correctly outputting I2S and I'm getting digital music over the bluetooth. So all is well! Now I just have to print a new PCB board for the new design with the BetzTechnik board.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Originally Posted By: mlord
ARRRRrrrrrgggghhhhhh!!!!!
Which of the four firmware files is the one I want for this?
[EDIT] 1122_aptxll <<<<--------- this one! [/EDIT]
That's been in the example code for a while, in the section that describes how to update the firmware. I admit, though, that the example code file is a little bit dense and a lot of the code comments in there should be turned into a proper instructions document which looks better and has things like a table of contents. Some time!
I don't know if there will ever be a newer firmware for this chip or not. :-)
Now you can rewrite it properly instead of all hacky like I did! :-)
Hey, I resemble that remark! Hacky is a Hijack specialty, out of necessity.
I'm now having visions of using your code as-is, compiling it with g++, after a few macros to fill in for the arduino-ish bits. Hoping those visions go away soon, as otherwise I'll have to confess them to my GP.
Note: This means that whenever we get one of these breakout boards we will have to make sure to flash it with the latest firmware BEFORE cutting that trace. And remember to reconnect the trace if we need to flash it again.
Would it be possible to solder some sort of switch or jumper pins between the two solder blobs, so that you can just switch the circuit off and on if you need to update the firmware?
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Originally Posted By: JBjorgen
Would it be possible to solder some sort of switch or jumper pins between the two solder blobs, so that you can just switch the circuit off and on if you need to update the firmware?
Yeah, totally possible, but a pain to assemble. I'm trying to design everything for quick and easy assembly, should this be something that others want to buy.
Mark's point about making my own PCB to accept a bare chip instead of the BetzTechnik breakout board is a good idea, maybe that is something Mark can do in his version. :-)
-- some IDE driver tweaks for better SSD compatibility.
-- BlueGigaEmpeg support as discussed in this thread, including new /proc/empeg_notify and serial port output for track "Source", track "Duration", and "Running order length".
-- in-car Hijack menu now includes the "Serial Port Assignment" entry.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Originally Posted By: mlord
Originally Posted By: tfabris
my empeg is correctly outputting I2S and I'm getting digital music over the bluetooth.
Woo-Hoo!!!!! Happy Daze is here again!
Also, a reminder about my final wiring scheme for the I2S pins and how they relate to the tuner connector. I carefully disconnect three wires from the white connector inside of the empeg that is closest to the ethernet port on the empeg motherboard, and then solder them via jumpers to the IIS header as described in my source code, screenshot below.
I was just now reading the hardware notes in the sketch, and it sounds like you are directly connecting the Arduino 5V TTL serial pins to the WT32i 3.3V CMOS serial pins.
If so, then you really should fix that. The datasheet for the WT32i clearly indicates that 5V is TOO MUCH INPUT VOLTAGE for any of its I/O pins.
So specifically, the TX line from the Arduino to the WT32i should get stepped down by 33%. The other line (TX from WT32i) is fine as-is.
Two resistors are needed for this: ideally 20K and 10K ohms, but lower K values will work so long as the 2:1 ratio is maintained (Eg. 10K and 5K). Or heck, even two resistors of the same value will work (Eg. 10K and 10K).
Connect the 10K to TX from the Arduino, connect the 20K to GND, and connect the other leads of each resistor to each other. The RX-input of the WT32i also gets connected to that same point (where the two resistors are tied together).
I've now ordered an Arduino Mega clone board for getting started with this. That way I can work on car compatibility using Tony's exact code and feed back any changes required for the Harmon head unit in my new Subaru.
After that's all working, I'll work on eliminating the Arduino, and move the code to the empeg's main CPU.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Originally Posted By: mlord
I was just now reading the hardware notes in the sketch, and it sounds like you are directly connecting the Arduino 5V TTL serial pins to the WT32i 3.3V CMOS serial pins.
Interesting. That's exactly what I have been doing all along. Thanks so much for noticing this and raising the red flag. I am so grateful for your expertise on this.
Strangely, this part of it has been working perfectly all along. Of all the things I've had fail in the electronics, the serial connection between the Arduino and the WT32i chip was not ever one of those failures.
On the other hand, all the other stuff that failed could have been secondary effects from my mistake. I'll make the correction that you suggest right away.
I'm planning on ordering another sandwich board from Pad2Pad. It's the in-between board that mates the Arduino with the bluetooth dev/breakout board. I had one working for the big BlueGiga board and I'm currently refining one for the Betz board. Thanks for letting me know about this before I finalized it and placed the order with Pad2Pad.
When I get that board it printed, do you want one?
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Also, please let me know if you notice any additional inconsistencies or weirdness in the hardware connection information in the code comments. I have been using that as a catch all place for my own notes and have been intending to rewrite it more clearly and/or draw up a proper schematic for this thing. It's possible that there might have been a transcription error or an omission in there somewhere.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
I have a question about the voltage divider circuit you're suggesting.
You say that it isn't needed on the arduino RX pin, only on its TX pin. Is that because the voltage is truly directional for RX and TX like that (i.e., the voltage is always driven by the sender on that pin)?
In other words, tx from a 5v device is always 0v for either not transmitting or for bit 0, and then always +5v for bits? And then RX is always an input and never outputs any voltage?
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
I answered my own question about the 0v/5v thing (example here: https://www.sparkfun.com/tutorials/215 - the whole reason we need a Max232 is because the signaling is 0v/5v for the line-level and +13/-13 for the RS-232 level).
But does that mean the chip connected to the TX is always the one supplying the voltage? So for example if I accidentally connect a TX to a TX then it's two voltage suppliers competing?
does that mean the chip connected to the TX is always the one supplying the voltage? So for example if I accidentally connect a TX to a TX then it's two voltage suppliers competing?
Yes, and yes.
And having two sources of 5V logic trying to drive the same wire results in them driving each other.. and perhaps frying each other.
When they are both at 5V, no problem. When they are both at 0V, no problem, but when they are toggling bits (alternating 5V and 0V in some pattern), then there are many instances where one is 5V, the other is 0V, and so the 5V is driving current backwards into the 0V line. Fried chips! [EDIT: because they are drivers, they have very little resistance to current flow, which means when 5V gets connected to 0V in this way, near infinite current will flow (Ohm's Law), and something will suffer. Badly.]
TX lines are always "drivers", and RX lines here are always passive receivers. So in the case of the Arduino TX-out going to the WT32i RX-in, the Arduino will be toggling between approx 5V and 0V for its bits, exceeding the voltage limit on the WT32i RX pin. Thus the need for the voltage divider.
The other way around, from the WT32i TX-out to the Arduino RX-in, no problem. The most the WT32i will output might be around 3-3.3V, and the Arduino is built to tolerate up to 5V there without issue. The important thing here is that the "1" voltage has to meet the Arduino's minimum spec for a "1", and that is usually between 1.8V and 2.4V (minimum) for 5V logic. So no problem there either.
On a related note, I haven't yet checked the voltages on the breakout board when it is powered from +5V. I got slightly lost trying to grok their schematic to see what voltage it was actually supplying to the WT32i. No guarantee they got it right.
The bluetooth module wants 3.3V, but it wasn't clear to me if the breakout board was respecting that limit or not. I plan to power my own breakout board with 3.3V from the Arduino initially, and from the empeg itself eventually. This may require changing one of the "jumpers" on the breakout board. TBD.
Okay, I just dug out the voltmeter, and measured 2.5V between VDD_IO and GND on the WT32i module itself, when supplied with 5V over the USB cable. On re-review of the schematic, this makes sense, as there is a honking 2.5V regulator onboard for this purpose.
So if one plans to supply the board that way (5V to the 5V pin, resulting in 2.5V at the VDD_IO pin), then the resistors for the serial port will need to be different than what I suggested above: just make them equal in value. So a pair of 10K resistors, or 15K resistors would be ideal. This would split the 5V logic levels in half, to 2.5V. Perfect.
The idea of a large K value here (as opposed to say, 1K-1K) is to prevent wasteful current draw (Ohm's Law), thereby saving power and keeping the Arduino and WT32i cool.
If powering the WT32i with 3.3V, then the 20K/10K pair is still correct.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Cool, my design powers the Betz board with 5v at its 5v input pin (the one you suggested), and since I'm already doing stuff with 10k resistors and so I have a big bag of them, I'll just use a pair of those for the voltage divider. Perfect! Thanks so much!
Changes in this version: - Additional code comment cleanup, fixing typos, clarifying new Hijack information such as V522 and suppress_notify=2, add the new voltage divider circuit description, etc. - New section in the code comments about possible special needs for powering the empeg car with this configuration (should probably read it). - New section in the code comments about special needs for connecting the Arduino debug cable and startup order when debugging (you'll need these tips soon). - A couple new functions to handle situations where the bluetooth chip gets reset - attempting to work around some behavioral bugs I encountered surrounding disconnect/reconnect situations.
To make the breakout board easier to use with a PC for s/w development, today I moved the honkin 470uF capacitor (C16) to a better location on the board, so that it doesn't totally block the analog audio-in jack. Duh. WTF lays out a board that poorly??
Then I found a relatively slim profile 1/8" audio cable and trimmed enough vinyl from the side of one connector end so that it can actually mate with the zero clearance jack on the board. Another major design fail that!
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Cool!
I have not tried to use that analog audio connector because I noticed that it was connected more or less directly to the chip. Whereas on the BlueGiga board, it had a bunch of capacitors and other interesting circuits inbetween the line in connector and the chip. I didn't want to have to figure all of that out so I just have been going pure I2S with this board.
If I were in your shoes I would have just soldered my own pigtail female jacks to the line input pins on the board, instead of trying to move stuff around on that board.
Ha. I'm not quite at that point yet. However, the Arduino clone just arrived here a few minutes ago, and I'm pondering whether or not to hook it all up and rush out to the garage immediately!
EDIT: Well, the sketch compiles and loads onto the Arduino without any fuss.
There doesn't seem to be much in the way of verifying that the BT module is there and working (?)
Yup. No pairing, and not even an attempt to pair according to the head unit. No error messages from the sketch, no indication that bluetooth is working or not working from its point of view.
I guess I'll have to add some error-checking to the code or something to get this working. Later. MUCH.
EDIT: The only clue: my smartphone did not see the WT32i "on the air" during the entire time it was hooked up to the BGE setup.
Now, with the BT module standalone, it sees it. So, something for me to go on over the holidays!
Mmmm.. back in the house, it does spew some BT output, and even offers to pair "empeg-car" with my Android phone! I wonder if I just have to figure out my car's head unit a bit more then.
In the car, I see: INQUIRY 30 and then a big long pause and nothing really useful. But back in the house, talking to my phone rather than the car, there's all of the nice diagnostics I was expecting, like this:
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Something worth trying. This may not work, but it is something I had to do with my car stereo.
Don't invoke the pairing routine on the Arduino. (If you wired up a button, don't press the button.)
I've found that with some devices you don't do the pairing from both devices. For devices with interactive touchscreen UI's, you just do the pairing from the touch screen and don't touch the device you're pairing with.
With my bluetooth headset, I have to invoke pairing mode on both devices because neither one has a touchscreen UI. But on the car stereo, I just do everything from the car stereo screen.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
More specifically, the "pair" button that I wired up does a few things:
- Turns on the external LED (if you wired one up). - Clears out any existing paired devices. - Resets the entire thing to defaults. - Looks for something to pair for 30 seconds. - At the end of those 30 seconds it turns off the Pair LED and goes back to normal mode.
For some devices, you have to initiate pairing with the other device while the LED is on. For some other devices, you can pair only when the LED is off, i.e., when the board is sitting there in normal mode doing nothing special.
The car in this case wants the device to initiate things. No menu to pick an unpaired device from.
The documentation claims that it supports SSP, but I'm guessing now that's just plain incorrect. It most likely REQUIRES the PIN. So I'll hack around that and see where it leads.
I'm beginning to suspect that this very new Harman head-unit only really works with BT 4.x compliant devices, those which implement BR/EDR.
The WT32i is a BT 3.x device. Their newer model is the BT121, which does have all of the BT 4.1 bells and whistles. But does the latter do audio profiles? Dunno.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
I would be very surprised if someone implemented a BT4 device which wasn't backward compatible with BT3. I thought that backward compatibility with BT3 was a requirement of BT4 or something.
My guess is that it's more likely that my Arduino software is simply not setting the right thingys for it to pair correctly. I was suspicious that I wasn't necessarily doing all the right things in that procedure. I'll bet if you poke at the docs and the commands enough you'll find the secret.
This is why I wanted to test it on more devices. :-)
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Related to the 5v/3v thing...
We already covered the topic of the I2S signals, right? We don't need voltage dividers on the I2S connections, correct? Those are already at 3v coming out of the Empeg?
Yes, the I2S lines from the empeg use 3.3V logic, so all good there.
For pairing, there really are no other parameters or options when using Simple Secure Pairing (SSP) protocol. But that protocol has been supplanted in BT 4.x with a "new improved" secure pairing method. I'm suspecting that Harman abandoned the old one, since the normal device that it pairs with is a smartphone, and most all of them have supported 4.x for years now.
One good clue is that the verification PIN it shows on the touchscreen is 8 digits long, not the old-style 4 digits.
I suppose I might have a notebook here with an older BT module inside.. so I could install bluetooth software on it and see if it will pair with the head unit.
tfabris carpal tunnel
Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Yeah, I see the "HCI_ERROR_AUTH_FAIL" in your output, so that would indicate it has something to do with the security.
Maybe simply selecting a different security type would work in your case. Maybe it's not a BT3/BT4 problem, but merely finding a way to get the WT32i and your headunit to agree on a security protocol.
By the way, you wanted to know what the "760408" string was in your output. I think that's the bluetooth Class Of Device bitmask for your headunit, in hexadecimal, based on the docs (section 7.12 of the iWrap 6 command reference).
Look up the references for pairing and security in the iWrap 6 command reference. Look at section 6.38 ("PAIR"), 6.66 ("SET BT SSP"), and 6.51 ("SET BT AUTH").
In particular, I suggest trying SET BT AUTH with a specific PIN code. It says that the PIN can be 0-16 characters, so I think that your suspicions about the 8-digit PIN are unfounded.
If it helps, below is the onscreen output from a successful pairing process with my bluetooth headset. Yours is the same except that your gets an authentication error instead of OK. I suspect you merely need to poke at the commands I referenced above to find the exact combination of magic words to get it to pair.
Previous Topic
Index
