Mark, I am responding to your earlier message in this thread that somehow I missed in the scrollback.

If you can get option 2 working (the “no Arduino at all” version) that would clearly be the best option. I just don’t have any experience coding for Linux or coding on the empeg, so I went for a system that I knew I could develop and iterate on quickly. Also, having multiple independently addressable serial ports made it easy to see everything all at once for debugging (not sure how you’d handle monitoring and debugging that if you were developing directly on the empeg with only the single serial port). But if you felt like tackling the “everything on the empeg” version, I’d offer any knowledge and help I can give.

Regarding your other question: Right now my Arduino sketch does not yet interpret strings coming in from the empeg serial port, but it certainly was my intent to make it do so, and the code is already structured in such a way that I could add it easily. It already reads and displays the text from the empeg serial port without parsing it, and it would only take a small amount of parsing code to start making use of any specially-formatted strings which appear on the empeg serial port which contain track data.

If going for the “Arduino Middleman” approach, the best option would be, as you said, to have the empeg periodically spit data out on the serial port about the current track and leave it up to the Arduino to interpret it continuously. I think the empeg already spits out regular data about the currently playing track, it just doesn’t have any track metadata in that output yet. In any case, I had planned on that scheme in my Arduino sketch: it would keep in memory the most recent information it saw from the empeg about the current track, and then when the Bluetooth module requested that information from the empeg, then my sketch would supply that information in response to the query.

If you decide to try to go the “Arduino middleman” route, i have some ideas about how the track titles should be formatted on the empeg serial port for easiest parsing.

By the way, the things that the query can respond to are already stubbed out in my Arduino sketch example code. They include the usual track title stuff, but also the current song position in MS, the total song length in MS, the current track number and the total number of tracks. It remains an open question as to what the correct answer is for the track number and total tracks. Do you give it the track’s canonical position in its album (ie the MP3’s tracknr field), or the track’s current position in the playback order (ie the playlist position or the running order position)? That’s a personal choice I guess.

Finally, I think that whatever we do, it should use the track titles as they appear in the empeg database, rather than trying to re-parse the MP3s for their tags. That would ensure all file formats work the same and ensure the titles on the car touchscreen match the empeg VFD screen.