Reverse-engineering JBL flip 4

Thanks to @karl.potratz for some extra data.

Software:

User Configuration Data 51 (Device Colour)

0001 = Black

0002 = Red

0003 = Blue

0004 = Turquoise

0005 = Grey

0006 = White

0007 = Red Base with Blue chequer crosses

0008 = Camouflage

0009 = Blue with Orange chequer stripes

000a = Grey with Turquoise chequer triangles

000b = Turquoise with Blue concentric square pattern

000c = Black

000d = Black

000e = Black

User Configuration Data 61 (Custom Device Name)

004a 0042 004c 0020 0046 006c 0069 0070 0034 0020 0031 0032 0033 0034 0035 0036

J B L F l i p 4 1 2 3 4 5 6

16 Chars max. (this can also be set via the JBL app)

Hardware:

2 different hardware/housing versions are available:

• New (from 2017?): Passive radiators are mounted via 5 screws, speaker grille has 3 round standoffs inside at the top. Flex print is open/visible.

• Old (up to 2016?): Passive radiators are held by housing and can be twisted off. All flex print is covered in black foam. Rubber gasket mounted between Speakers and housing.

Note: New and old speaker grilles and passive radiators cannot be interchanged!

Flat cable (Flex print)

• 1x FFC A 13 Pin 0.5mm pitch AWM (same side)

• 1x FFC B 6 Pin 0.5mm pitch AWM (opposite sides)

Measured using REW, by analyzing the change of impedance-vs-frequency plot when adding a known mass (1.34 g) to the cone.

Thiele-Small parameters
fs 181.7 Hz
Qms 5.902
Qes 0.401
Qts 0.375
Fts 483.8
Mms 1.18 g
Cms 0.651 mm/N
Rms 0.228 kg/s
Vas 0.06 litres
Bl 3.615 Tm
Eta 0.09 %
Lp (1W/1m) 81.67 dB
Dd 3.22 cm
Sd 8.1 cm^2

When I downloaded TPA3130 datasheet, I saw power figures of 2x50 W, and thought "wow, that's some serious margin there". And even published it here. Today I suddenly realized while re-reading the datasheet, that the datasheet is a shared one for 3 ICs: TPA3116, TPA3118 and TPA3130. The difference between them is their power rating (specifically, overload current limit).

The actual IC used here is only for 2x15 W. 

Oops!

The speaker has an annoying habit of blocking aux sound when the signal is very low, causing annoying dropouts when playing quiet passages, watching movies and talking over skype. 

Guess what, the detection of audio signal is done in analog! so we can easily hack it, so that it thinks audio is always coming in.

It's just a matter of shorting out Q12 transistor's collector to emitter.

After doing this, I anticipated some problems with Bluetooth. There are, but they are minor. 

+ I can still connect to BT, and pair new devices. The speaker doesn't make pairing sounds, though.

+ whenever Bluetooth plays, aux input is inhibited automatically. As soon as BT audio stops, aux input works again.

A nice hack! A better way would be to use jack to provide the signal whenever a cable is plugged in. It can be done, but requires desoldering the connector, and adding an additional connector to the board (or just permanently soldering a bunch of wires). But this easy one is good enough, IMO.

I also notice, input stage of this audio detector circuit presents serious nonlinear load to the audio source. This may cause distortion if source impedance is high. So, consider removing 33-ohm resistors if you apply this hack.

The old graph only included standard DSP:

I remeasured it to include Connect+ button effect, and when DSP is off.

This time, I was taking signal from output of an opamp. That is, right before DC-rejection capacitor at power amplifier input. So overall response is for (DC-rejection caps on aux input) + (ADC) + (DSP) + (DAC) + (another cap) + (balanced-to-single-ended-converter circuit), and does not include (yet another cap) + (power amplifier). 

Additionally, I disabled boost converter that powers the amplifier, to reduce noise.

I've also uploaded room-eq-wizard file to the project, so if you want to inspect it, go check it out in project files.

Measuring aux-to-air frequency response remains in to-do list.

So, I have essentially scanned through just about all "User configuration data" keys of csr chip. I have not found anything that affects dsp. But I did find quite a bit of something. Here it goes.

"user0" = "User configuration data 0" aka PSKEY_USR0

"word0" = the index of word (16-bit value) of data in the key.

"0400" = bitmask in hexadecimal notation. If followed by "->" means I tested that precise value.

user0:
    word0:
       == 0010 bit -> startup sound
       == ffff -> boot-loop, self-resets to BEDF
       0400 bit set-> crash
    word3: startup volume
    word4: if >1aac -> boot loop (halfway through startup sound)

data6:
    word0:
        0001: always BT-pairing?

data7: 
    word1: change to 0011 -> no startup sound
    word6: crashy
        2000 -> crash
        1000 -> crash
        0100 -> crash
        0010 -> ok
        0040 -> ok
        00ff -> crash
    word9:
        dbd0 -> crash
        d000 -> crash
        0b00 -> crash
        00df -> crash
        0080 -> ok
        000f -> ok
data8:
    word9:
        >8bcf -> no sound
data13:
    word0: crashy
        0070->crash
        fb70->crash
user16:
    word9:
      6070 -> crash
      5070 -> ok
      logic unclear
    word10: similar to 9
    word11: other channel than word12? 
    word12:
      A060 if any of these set, boot loop with startup sound playing
      4000 : boosts volume
      001f : boosts volume, the more the value the more the boost
user20:
    word0:
        0001: exhibition mode
        0002: ?? maybe exhibition mode too?
user21: see user26
user26: similar to user21
    word0: crash if zero, otherwise no effect
    word2: if zero, next values are filled with what looks like random numbers

user30: sounds table, 3 words per entry
    word0: event number. 4001 = startup, 4002 = shutdown
    word1: sound number. 0000-0009 = digits; 000a = startup, 000b = shutdown, 000c = pairing, 000d = connected, e = bump, 000f = chord, 0010 = connect+, 0011 = cancel connect+
    word2: bit 0002 is enable/disable, the rest seem irrelevant
   
user37:
    word0: 0x0080 - clearing this bit inhibits aux input
user43:
    word2: changing value causes either boot loop, no sound, or nothing. Hard to understand
    word4: signed word, adjusts startup sound loudness (negative for less loud) (0100 is noticeable amount)


user49:
    word0, word1 always restore themselves

user51:(thanks @karl.potratz)
    device color
    0001 = Black
    0002 = Red
    0003 = Blue
    0004 = Turquoise
    0005 = Grey
    0006 =
    0007 = Red Base with Blue chequer crosses
    0008 = Camouflage
    0009 = Blue with Orange chequer stripes
    000a = Grey with Turquoise chequer triangles
    000b = Turquoise with Blue concentric square pattern
    000c = Black
    000d = Black
    000d = Black

user53:
    change to any value -> crash (tested word0 bit 0001, word2 bit 0001) 

user61: (thanks @karl.potratz)
    Custom Device Name. 16 Chars max. (this can also be set via the JBL app)
    004a 0042 004c 0020 0046 006c 0069 0070 0034 0020 0031 0032 0033 0034 0035 0036
       J    B    L         F    l    i    p    4         1    2    3    4    5    6

Of course, this is still very far from complete. I didn't test all bit combinations for the values listed here, so the conclusion might be wrong. 

I've written random values to all unknown data, while looking for clues. Dsp was never seriously affected. Even after isolating a lot of things that cause crashes, I was still observing crashes, boot loops, and overall strange behavior. At least one crash was an unlucky combination of at least two settings in different keys; hunting that stuff down is too time-consuming.

As for "DSP configuration data" - I replaced it all with random values, three times, and it had no effect whatsoever. I'm afraid, it is simply not used at all. Other possibility might be that it checks some checksum on these settings, and reverts to default if checksum is not matched. But I doubt it, it's pointless... So my chances of disabling dsp are really slim at this point.

"User configuration data 30" (PSKEY_USR30)

Contains this:

476d 0000 3fff 476e 0001 3fff 476f 0002 3fff 4770 0003 3fff 4771 0004 3fff 4772 0005 3fff 4773 0006 3fff 4774 0007 3fff 4775 0008 3fff 4776 0009 3fff 4001 000a bfff 4002 000b bfff 4003 000c bfff 4742 000d bfff 4744 000e bfff 4116 000f bfff 4101 0010 bfff 411b 0011 bffe

... and appears to have this meaning:

// event id    sound number    flags 
     476d         0000          3fff  // "one"
     476e         0001          3fff  // ...
     476f         0002          3fff  // 
     4770         0003          3fff  //
     4771         0004          3fff  //
     4772         0005          3fff  // 
     4773         0006          3fff  //
     4774         0007          3fff  // 
     4775         0008          3fff  //
     4776         0009          3fff  // "nine"
     4001         000a          bfff  // power-on sound
     4002         000b          bfff  // power-off sound 
     4003         000c          bfff  // pairing sound
     4742         000d          bfff  // bluetooth connected
     4744         000e          bfff  // volume limit bump
     4116         000f          bfff  // some chord, dunno what
     4101         0010          bfff  // connect+ activate
     411b         0011          bffe  // connect+ deactivate

By editing this table, I can reassign and disable sounds. 

To disable a sound, set flags to zero. In particular, I've found that bitmask 0x0002 affects if the sound is played or not, the remaining bits don't seem to do anything.

If you want to swap power-up and shut-down sounds, for example, change 000a into 000b and 000b into 000a.

I'd consider it to be FIRST ACTUAL HACK! Yuppeeeee!

I looked at the files I extracted from the chip - there are two files, one small and one large. It's a simple text file with hex numbers. So I glued then together with a quick py script to have a look:

file_name = r"S:\somethingsomething\jbl flip 4.xpv"
with open(file_name, 'r') as x_file:
    with open(file_name + '.bin', 'wb') as b_file:
        for line in x_file:
            if len(line)<4:
                continue
            addr, str_hex_val = line.split(' ')
            b_file.write(bytearray([
                int(str_hex_val[2:4], 16),
                int(str_hex_val[0:2], 16)
            ]))

First, I opened them in text editor, to see if there are some interesting strings. Not that I looked very thoroughly, but I only found "JBL Flip 4" string once, and nothing else. I was hoping for some debugging strings, to give me clues.

Then, I decided to see, if the sounds are in that firmware, And yes they are:

(WARNING: VIDEO IS VERY LOUD!)

I loaded the binary file into audacity, and after some precision guesswork, picked the parameters: signed 16-bit pcm, big-endian, 1 channel, 16k sample rate.

After no luck on changing DSP, I began trying other tools from bluesuite. BlueFlash came up.

It has buttons that supposedly do what I need. But greyed out, it says "processor running". As soon as I clicked Stop Processor, it spew out an error, because the chip immediately loses power.

Using same trick to force the power to the chip again, now I got lucky. I stopped the processor and dumped the firmware, and even verified it. You can find it in project files.

I have progressively erased all data in User DSP Configuration Data XX fields. The DSP still functions as before. So either, as I erase stuff, DSP reverts to built-in defaults, which match the stored values, or it simply ignores them altogether.