No you wouldn't, you'd just disconnect the tuner RX/TX wires from the interior plug on the empeg and problem solved.



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.



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.

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.

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.

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?

Dunno if the diodes would work for the FM level/signal pins or not. The MOSFETs should work though. Dioes, yes we know the directions.

For now, I guess we'll just all have to be careful, including your Friend.

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.

Updated:
https://create.arduino.cc/editor/tfabris/4c5eea9a-1462-45d7-908d-81a5bb6b0d90/preview

- 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.

Thanks!

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).

https://create.arduino.cc/editor/tfabris/4c5eea9a-1462-45d7-908d-81a5bb6b0d90/preview

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.

Mine is supposed to come tomorrow. :-)

I've updated the code again, only slight changes so far.

The number of "to do" items in the code seems to be increasing. :-)

Something else I'm hoping that you can look at sometime. Don't know if this is even within your power, but...

The player application spits out certain pieces of track metadata on the serial port like this each time a track is changed:


The player application also spits out play/pause state and current playback position when those change:



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:

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.

I suggest just faking that for now if possible.

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.

Code:

Prolux 4 empeg car - 2.1485 Jul 25 2005
Vcb: 0x40772000
  serial_notify_thread.cpp: 116:@@ N41
  serial_notify_thread.cpp: 117:@@ F0x169e0
  serial_notify_thread.cpp: 191:@@ ZCelery Stalks at Midnight
  serial_notify_thread.cpp: 192:@@ D215816
  serial_notify_thread.cpp: 118:@@ TDon't Make Me Sing Along
  serial_notify_thread.cpp: 119:@@ AAl Simmons
  serial_notify_thread.cpp: 120:@@ G
  serial_notify_thread.cpp: 170:@@ S1
  serial_notify_thread.cpp: 180:@@ #169e0  0:00:10
  serial_notify_thread.cpp: 180:@@ #169e0  0:00:04
  serial_notify_thread.cpp: 180:@@ #169e0  0:00:07
  serial_notify_thread.cpp: 180:@@ #169e0  0:00:08
  serial_notify_thread.cpp: 180:@@ #169e0  0:00:09
  serial_notify_thread.cpp: 180:@@ #169e0  0:00:10
  serial_notify_thread.cpp: 180:@@ #169e0  0:00:11
  serial_notify_thread.cpp: 116:@@ N42
  serial_notify_thread.cpp: 117:@@ F0x4830
  serial_notify_thread.cpp: 191:@@ ZTime to Say Goodbye
  serial_notify_thread.cpp: 192:@@ D188273
  serial_notify_thread.cpp: 118:@@ TIn Pace
  serial_notify_thread.cpp: 119:@@ ASarah Brightman
  serial_notify_thread.cpp: 120:@@ GClassical
  serial_notify_thread.cpp: 180:@@ #4830  0:00:00
  serial_notify_thread.cpp: 180:@@ #4830  0:00:01
  serial_notify_thread.cpp: 180:@@ #4830  0:00:02
  serial_notify_thread.cpp: 180:@@ #4830  0:00:03

If you want to play along, then grab the test version of Hijack from http://rtr.ca/hijack.zImage

Cheers

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.

So.. not sure how to proceed for that one.

Peter ? Roger ? Anyone there?

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

Cheers

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. :-)

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.

Thanks!

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.

Note that we now already require "a recent Hijack version" in order for Album title and duration to be shown.

And that is much easier than having to hack the core Arduino serial library, especially for folks with other sketches that also use serial.

Already noted in my earlier post, but you're right, we might as well just say "hey, you need the latest hijack".



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!



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.

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)?

This is awesome, thanks so much!

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.

Cheers

Yes, you should just be looking for "@@ " followed by a single character that you recognize from this set: "#ADFGMRSZTNVL"

Cheers

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.

This is fscking amazing. You are awesome, Mark!

Updated code here:
https://create.arduino.cc/editor/tfabris/4c5eea9a-1462-45d7-908d-81a5bb6b0d90/preview

Now, to work on that new breakout board and see if it fixes my "fried I2S" problem.

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.

Looking for more information.