How to properly use esPod library (minimal example request)

[petr-stety-stetka]

Hi @martinroger ,

First of all, thank you for this amazing project. I'm honestly surprised no one built something like this earlier. It looks exactly like what I need for my BMW F10 with CIC (2012), so I can display track names over USB and fix steering wheel track controls for my Android head unit (which is connected via AUX), by placing an ESP32 in between.
Connecting ESP32 with the Android unit is not a problem, but I'm having some issues with the ESP32 ↔ BMW side.

I assume I need to use ESP32 together with a PL2303HX or CP2102/CP2104 for BMW to communicate properly, right?

1. Is there any way to use only an ESP32-S3 (with native USB OTG), or is it better to stick with an external USB-UART chip like PL2303HX or CP2102/CP2104?

I tried both PL2303HX and CP2102(without DCD port). For CP2104 (CNT-003B), I changed the Vendor ID to 0x067b and Product ID to 0x2303, but I still couldn't get any communication with the car.

2. I couldn’t find any proper example or README explaining how to use the esPod library on its own.
   Would you be willing to provide a minimal working example / demo showing how to correctly initialize communication with the car?
   I have a feeling I might just be using the library incorrectly.

Thank you for your support!

[martinroger]

Hi @martinroger ,

First of all, thank you for this amazing project. I'm honestly surprised no one built something like this earlier. It looks exactly like what I need for my BMW F10 with CIC (2012), so I can display track names over USB and fix steering wheel track controls for my Android head unit (which is connected via AUX), by placing an ESP32 in between.
Connecting ESP32 with the Android unit is not a problem, but I'm having some issues with the ESP32 ↔ BMW side.

I assume I need to use ESP32 together with a PL2303HX or CP2102/CP2104 for BMW to communicate properly, right?

1. Is there any way to use only an ESP32-S3 (with native USB OTG), or is it better to stick with an external USB-UART chip like PL2303HX or CP2102/CP2104?

I tried both PL2303HX and CP2102(without DCD port). For CP2104 (CNT-003B), I changed the Vendor ID to 0x067b and Product ID to 0x2303, but I still couldn't get any communication with the car.

2. I couldn’t find any proper example or README explaining how to use the esPod library on its own.
   Would you be willing to provide a minimal working example / demo showing how to correctly initialize communication with the car?
   I have a feeling I might just be using the library incorrectly.

Thank you for your support!

Hi @petr-stety-stetka !

You pointed out the big weakness, I don't have a working example in this library repo, and the one I have is in the other repo and intimately tied to using A2DP.

In short, yes it is possible to use an S3 as the UART interface, I have a working proof of concept, but it takes more than spoofing the VID and PID. And I have noticed that spoofing on a CP2102 or CP2104 doesn't always work because of different "vintages" of chips.

I can try to write a very basic example tonight. What are you using, the Arduino IDE or PIO?

[martinroger]

Alright, so in no particular order...

1. Usage example :

#include "esPod.h"

// Declare the my_espod object. Without arguments it will just automatically set up at 19200kbps, on the default UART 1
esPod my_espod();
/* 
Alternatively you can also assign a different UART, or different pins, or a different speed. I haven't included other constructors yet with different options.
Note that some radios communicate at 19200 baud, but the iPods can in theory go all the way up to 57600
*/
// esPod my_espod(1,16,17,19200);

// There is also an experimental "autobaud" version of the syntax. It seems to work but it is better to know what baudrate you should connect with... the syntax is as follows :
// esPod my_espod(1,16,17,0);

/*
You should also declare a handler function for the playback status commands. 
The objective of this function (which is optional) is to allow the esPod instance to control something external with playback commands, but it is up to you what and how you implement it. 
The esPod just calls this functions when it determines it needs to play/pause/stop/ff/rw/next/previous etc... 
*/
void myHandler(PB_COMMAND playback_cmd)
{
    switch (playback_cmd)
    {
    case PB_CMD_STOP:
        // Do something to stop the playback, forward a stop command...
        break;
    case PB_CMD_PLAY:
        // Do something to start playback with whatever is playing music...
        break;
    }
}

void setup()
{
    // Attach the playback handler so the esPod knows where to find it and use it
    my_espod.attachPlayControlHandler(myHandler);

    // Rest of your setup... the esPod automatically manages starting its UART and setting it up, so you don't need to do it before (and actually it might break things if you do... I haven't tested that yet.

    // IMPORTANT : Enable the esPod when you are ready to get it to start ! Otherwise it just ignores any traffic coming in.
    my_espod.disabled = false;
    // You can always inhibit it later if you need it to go mute, just set this flag to true.

    /*
    The esPod instance has some "friendly" methods so you can feed it information. 
    It uses those to assert if there are track changes (for instance) and typically this is fed from something like the bluetooth AVRC notification system, but it could also be from another source. 
    Some usage examples :
    */

    my_espod.resetState(); // Resets all the internal values but does NOT disable the instance. It will keep looking for, and responding to UART traffic.
    my_espod.updateAlbumName("Some album name");
    my_espod.updateArtistName("Some cool artist");
    my_espod.updateTrackTitle("Cool song too");
    my_espod.updateTrackDuration(120000); // Total duration in milliseconds
    my_espod.updatePlayPosition(60000);   // Playback position in milliseconds
    

    // These metadata are fed back - when requested - to the head unit via UART1, but in "iPod" lingo
}

void loop()
{
    // Do your things in your loop. The esPod instance has its own tasks so there is no ticker to call or anything like that.
}

2. Regarding your setup...

Well I'm not entirely sure it is what you need.
In theory this was developed for communicating with the OEM and untouched BMW/Mini head units of the time, and I would tend to say that as long as your car had the iPod option "coded in" with the CIC head unit, it should work normally.

Now if you have an Android head unit that replaces totally whatever head unit was in the car, I don't think it's going to do any good for the steering wheel controls or the track info...
On the other hand, if your Android HU is just something that is added on top of the original head unit, it can somehow work like so :

• The ESP connects to the CIC core and pretends to be an iPod, via that UART1 mentioned in the code above
• The playback handler for the esPod instance sends basic playback control commands via whatever protocol is adequate, to the Android part of the head unit. This effectively covers relaying steering wheel controls inputs, to the CIC part of the radio, through the ESP, to the Android HU (which I assume is the source of the playback)
• In return the Android head unit should also feed track information to the ESP so it can feed something to the CIC if it requests it. It may be optional but it's cleaner if you can have that in... if not the esPod will just feed placeholder data, so functionality shouldn't suffer...

Regarding communicating with the car, you have multiple options :

• If you can find a PL2303HX with the DCD pin available, ground it, connect the UART pins you have selected when you declared your esPod instance to the RX and TX pins of the PL (remember to connect TX to UART_RX, RX to UART_TX...), maybe check if the correct baudrate is 19200 or more, and it should work... if you increase the verbosity of the core debug messages, the esPod actually translates them over UART_0 so you can monitor things...
• If you struggle to find a PL2303HX, which is very probable... you can try the route of spoofing VID and PID on a CP2104 (one time only) or an old CP2102 (non N, non GM, manufacturing date prior to 2021). In which case it may work but may need a couple restarts to take on...
• Using the USB-OTG stack of an S3, or more specifically the CDC-AM TinyUSB implementation will not work out of the box with just a simple VID and PID spoofing, because the PL2303 uses some magic vendor commands and a weird architecture that makes it not directly work with the default CDC-AM implementation....
  However I have written a small implementation of the PL2303 vendor commands and architecture for an S3 to emulate it and operate as a dumb USB<->UART converter, and it's good enough to fool the Mini (or Linux and MacOS, to an extent).
  Theoretically you could run the esPod instance concurrently to this converter code and just "pipe" the UART1 from the part acting as the transceiver to the part doing the iPod. I haven't tried but it's technically feasible.
  The trick with this PL2303 emulator stack is that it's still quite a bit messy, and more importantly it's all done under ESP-IDF, so it needs efforts to see if it can be ported to the Arduino framework (or alternatively the esPod library needs to be used as a component in ESP-IDF... haven't tried but it should be easily possible, it's just missing a couple configuration files and declaring sub-components).

Let me know if you have more questions or if I misunderstood something !