Battery firmware

[notsolowki]

i notice the battery firmware is not encrypted. i wonder what could be done to the battery controller so aftermarket batteries could be connected

[pawelsky]

Keep in mind the the battery controller keeps some historical information about the previous battery. Some of that will be eventually adjusted after a couple of charge/recharge cycles, some will stay. Be aware of that.

[prefer-to-repair]

Thanks pawelsky I will keep that in mind.

[prefer-to-repair]

By chance I came across a rather unsuccessful video on you tube about resetting a dead P2 battery, in that video I think the guy jumpers, GND (ground?) to RES (reset?) then GND to TEST then GND to VCC. Point with the same names can be seen in my photos above. This did not reset the battery but I am curious about what EACH jumpering is supposed to achieve, can any one tell me please? Thanks

[pawelsky]

Haven't seen the video but GND to VCC will cause short circuit so I'm not sure if it can be treated seriously...

[0r10nV]

DJI P2 and P3 batteries absolutely different in BMS schematic. P2 batteries has unknown Gas Gauge IC (it's marking is erased at the factory to prevent replication and reverse engineering). As of my knowledge this IC has not PF latch. To clear safety events it was sufficient to short-circuit GND and RST pads on the PCB (step 1 according to your previous post) thus clearing RAM of the IC. Regarding step 2 not sure whether it required at all. Step 3 is quite stupid as it would short circuit 3.3V LDO (Could assume if it not damage anything else on the PCB it will surve as Power-On-Reset?;)).

As a rule these steps not clear PFF on DJI P3 batts except knock-off PCB as was mentioned before.

[0r10nV]

If we talking about youtube, more or less correct way to fix locked DJI Phantom battery is shown here (sorry, it's in Romanian Language).

https://www.youtube.com/watch?v=vzc_zV50HQw&t=1s

[pawelsky]

If we talking about youtube, more or less correct way to fix locked DJI Phantom battery is shown here

Assuming one knows the unseal/full access keys :) But indeed I was able to clear the PF and do other manipulations on my Mavic battery using EV2300.

[0r10nV]

Sometimes job could be done even without ev2300. bq30z55 TRM describes in detail programming commands and they could be sent in manual mode even using budget i2c-lpt adapter. (That's what freelancers doing when unlocking DJI batteries remotely).

[pawelsky]

Sometimes job could be done even without ev2300. bq30z55 TRM describes in detail programming commands and they could be sent in manual mode even using budget i2c-lpt adapter.

Sure, but you realy have to know what you are doing and I would not recommend it to anyone who did not deal with the Gas Gauge ICs before.

[0r10nV]

Of course, it's only for guru in TI battery gas gauges. But when it comes to remote unlocking using TeamViewer, all is required at the client-side is to connect smbus adapter to appropriate pads on the pcb and provide remote access to desktop which is not too difficult.

[prefer-to-repair]

Pawelsky, just as well I asked about the video lol. Here is its URL https://www.youtube.com/watch?v=x8irB0ij14g

0r10nV, I think google translate is going to get a bit of a hammering, thanks for that. Do you happen to know if the Romanian? subtitles are accurate? I know the automatic? English subtitles can be .......hilarious.

[d51r3verse]

Almost 2yrs digging with BQ series when I have a time.

Still doubt that 'Is really exists unknown BQ's SHA1 vulnerabilities or un-documented master cmd?' Here is another cheaper(probably/not launched yet) HW/SW variants. https://www.youtube.com/channel/UCMAwFRaGzLrhi9G8f4x3Udg Still confused that they using 0day flaws or not( using known passwords bruteforcing )

If someone has licensed UBRT, please share BQ30xx or 90xx's SMBUS dumps when GETKEY/FAS/UNSEAL

[0r10nV]

@d51r3verse

SHA1 has replaced SHA0 when the latter was broken and considered vulnerable (although vulnerability was never published). Now we have similar situation with the former. https://www.computerworld.com/article/3173616/the-sha1-hash-function-is-now-completely-unsafe.html https://www.schneier.com/blog/archives/2005/02/sha1_broken.html

But it mainly concerns SHA1 itself, not the SHA1-HMAC which used in BQ's.

Regarding UBRT, it has cheap enough 1-day license so you can easy dump what you want.

@prefer-to-repair Romanian not my native language, it was just single video me found on the tube about professinal repair of DJI batteries using TI HW&SW with third-party SW for unsealing. Author promised to make english subtitles in future video releases.

[pawelsky]

Do you happen to know if the Romanian? subtitles are accurate? I know the automatic? English subtitles can be .......hilarious.

The subtitles are actually not important. The video itself explains what needs to be done clearly enough.

[rufiooo]

I'm wondering if this soft could break the password on TB47/TB48 or is it just a scam.

https://www.youtube.com/watch?v=_y-CWu3oyLY

[0r10nV]

Yes, it could, but rather then breaking it looks up pass on their servers then use it for Unseal and reset. Those guys are experts in smart batteries but software is not cheap.

[Egho9]

is any know about TB50 and TB55 protocols.

I find some info from internet https://www.ti.com/lit/an/slua707/slua707.pdf . In this battery us BQ76925 +MSP430FR5870 + BQ34Z100 + BQ76208. I want make device which can read information from original TB55 or TB50 and send same information to drone for simulate battery such here https://github.com/sin5678/mavic_bat I make device from this source https://github.com/czipis/mavic-mini-battery-info but that device can not read information from TB50

[akhilzid]

is any know about TB50 and TB55 protocols.

I find some info from internet https://www.ti.com/lit/an/slua707/slua707.pdf . In this battery us BQ76925 +MSP430FR5870 + BQ34Z100 + BQ76208. I want make device which can read information from original TB55 or TB50 and send same information to drone for simulate battery such here https://github.com/sin5678/mavic_bat I make device from this source https://github.com/czipis/mavic-mini-battery-info but that device can not read information from TB50

Have a look at this, i wrote this 3 months before for arducopter https://github.com/ArduPilot/ardupilot/pull/14045/files

[Egho9]

is any know about TB50 and TB55 protocols. I find some info from internet https://www.ti.com/lit/an/slua707/slua707.pdf . In this battery us BQ76925 +MSP430FR5870 + BQ34Z100 + BQ76208. I want make device which can read information from original TB55 or TB50 and send same information to drone for simulate battery such here https://github.com/sin5678/mavic_bat I make device from this source https://github.com/czipis/mavic-mini-battery-info but that device can not read information from TB50

Have a look at this, i wrote this 3 months before for arducopter https://github.com/ArduPilot/ardupilot/pull/14045/files

but I try connect , I cannt . can you help me wrote code for arduino to read info from that battery

[mefistotelis]

When you connect to the BQ chip directly using EV2300 and start TI chip evaluation software, it uses some strange messages to detect the chip and FW version (I sniffed them using Pi):

 [16+22+3E-]
 [16+20+3E-]
 [16+22+3E-]
 (wait 350 ms)
 [16+2F+] [17+0D-[[0A-[[00-[36-[[00-[68+00+06-[[00-[02-[00+[C5-]

So x16 means read (cause bit 0 not set) from device 0xb (the I2C address of BQ chip), then there's command/offset x22 (which is a valid SBS command - DeviceChemistry()). But then it sends x3E?? at this point we've requested read of DeviceChemistry() and we should wait for answer, but instead we're sending x3E which is not accepted (hence the "-") - because that breaks the protocol. Even if EV2300 wanted to end the message here, it should end it with PEC checksum - x3e is not a valid checksum of that packet. Is that something to try detect another type of BQ chip, which doesn't work with the one I use? Or is it some undocumented command which triggers something?

Anyway EV2300 tries similar packet 3 times, each ending with NACK. Then waits 350 ms, and then is reads command/offset x2F. The x2F has two documented functions - Authentication() and ManufacturerInfo(). But at this point we've not met requirements to use any of those functions - so we're using another, undocumented function. Here we're getting a response - 10-byte block. The packet still doesn't end with proper PAC checksum. The data seem to contain 5 16-bit integers.

I wonder if I can trigger the same response myself, using Pi..

[pawelsky]

I think you read it wrong. 0 for the R/W flag means write not read, and what you see at the beginning is actually a sequence of 3 writes required to receive the firmware version

P.S. Not all the messages contain PEC, there are multiple formats.

[mefistotelis]

Yup, looks like you're right. I misinterpreted some stuff.

[0r10nV]

Here we're getting a response - 10-byte block. The packet still doesn't end with proper PAC checksum. The data seem to contain 5 16-bit integers.

Looks like you captured not full packet. That's why PEC is looks wrong. TI chips use hardware registers to calculate the PEC byte, so they are normally quite fast and reliable with it.

The response of ReadFwVersion() function normally contains 11 or 13 bytes of payload, which length in the Smbus BlockRead() normally goes as first byte on the 2WIRE just after repeated start and 0x17 ReadAddress. In your case it's 0x0D = 13, so 3 bytes looks missing in the capture.

[16+2F+] [17+0D-[[0A-[[00-[36-[[00-[68+00+06-[[00-[02-[00+[C5-]

[pawelsky]

As I said there are no PECs in this communication. A PEC-less protocol format is used here.

For write EDIT: attached correct screenshot

For block read

[mefistotelis]

Thank you; I am now able to correctly receive that response through Python:

[13, 5, 80, 0, 54, 0, 52, 0, 3, 128, 0, 1, 0, 3, 197]

That final packet does contain PEC(=197); only the 3 short ones are missing it, as they're terminated by NACK.

[0r10nV]

Yes, all Smbus TI gauges have PEC enabled by default according to the AppNotes, and this specific packet is not exclusion.

[svarteld]

Hi,

First, thanks; my Inspire 1 WM610 is running custom FW thanks to your bright minds. I'm rebuilding three of them now to make them lighter and more efficient (about -800g).

I've got 5 TB47 with bad cells that I want to rebuild, if possible. Once I was an engineer (physics/code/math), but since 20 years a photographer, so I can only partially understand this discussion.

My question: does the TB47 board need a reset to accept new LiPo cells, and can that possibly be done by simple board connections? See image; there seems to be measuring/control points (yellow), the one called RES (cyan) looks tempting to connect to GND. Bad idea?

Cheers /Peter

[mefistotelis]

does the TB47 board need a reset to accept new LiPo cells

Yes. Disconnecting / re-connecting the cells will set an error flag in TI BQ gas gauge chip.

can that possibly be done by simple board connections?

You definitely need to connect something to your board to reset the flag, but it's not simple shorting. You need to connect SMBus/I2C controller to proper pins, and execute a series of instructions.

the one called RES (cyan) looks tempting to connect to GND. Bad idea?

I doubt that will reset the flags. But who knows? It sounds like something which just sets the uC into reset state, but maybe it does more.

[pawelsky]

Yes. Disconnecting / re-connecting the cells will set an error flag in TI BQ gas gauge chip.

As far as I remember this will not happen immediately - there is a delay defined (can't remember how long), so if you are quick, and the permanent flag has not been triggered yet due to other reasons, then you may be lucky.

@mefistotelis you may check the delay threshold in one of your batteries, just to give @svarteld some idea.

[svarteld]

@pawelsky @mefistotelis many thanks for your info.

4 of 5 boards has been disconnected for days, so I guess speedy change is not an option. Cells are completely discharged.

From this discussion, seems Phantom 2 boards responds to RST to GND; removes error flag after cell replacement. Will try with one TB47, even if it's not likely working. Phantom 3 seems not to respond to this.

One thing puzzles me; the videos claiming TB47 can have cell replacement or external charging done after just disconnect balance wires for like 12 hours. This should set an error flag, right?

In the craft WM610 FW there's an option to accept non-DJI batteries; I'll add that the next time I build a new FW. The auto land behaviour on weak battery is concerning; if this happens over water all is lost, not just resulting in a bad battery. I think DJI engineers made some bad decisions, not only concerning the high weight of WM610 (the movable arms cost almost 1kg (!) of shorter flight time and sluggish response: mass is high and decentered. But it's a different thread).

Thanks again /P

[pawelsky]

4 of 5 boards has been disconnected for days, so I guess speedy change is not an option. Cells are completely discharged.

Then indeed you may be out of luck

In the craft WM610 FW there's an option to accept non-DJI batteries

Other DJI drones have this option as well.

One thing puzzles me; the videos claiming TB47 can have cell replacement or external charging done after just disconnect balance wires for like 12 hours. This should set an error flag, right?

Not necessarily, it is flagged only after a delay. Don't remember what the delay was for the Mavic battery I've checked, could be 12h.

[mefistotelis]

@svarteld if you'd like to clear the 'permanent fail' flags on a budget, you've chosen a right moment - I'm now working on a tool which does that using any I2C bus device (testing it on Raspberry Pi). I'm writing it for my Mavic batteries, but is should work for most BQ chips.

[svarteld]

@mefistotelis That would be of great help :-) If you'd like me to try your tool on TB47/TB48, let me know. Will it be similar to the other FW tools? I use macs, limited programming knowledge, but will read up and buy necessary hardware.

@pawelsky thanks for the info.

[0r10nV]

@svarteld TB47/TB48 batteries have PF_Lock feature disabled at the factory same as Phantom 2 batteries. So disconnecting the cells should not trigger any locks. It does not matter for how long power is off. You could read thread in the middle where someone just bought TB48 boards only and hooked up new cells. Battery started Ok. But you could probably will need to reprogram FCC(Full Charged Capacity) which is last learned actual cells capacity value stored in the non-volatile memory. Otherwise chip will use value from old cells and report wrong SOC% to the drone. As a workaround you could make some relearning cycles to the battery to let the chip calculate new capacity but it has some limitations in respect to max increment mAh per cycle which is just something about 200 to 500mAh.

@mefistotelis DJI Mavic Pro batteries uses bq30z55 chip so it's programming method is different from bq78350 which is the gauge for Inspire battreries.

[mefistotelis]

Right. I just compared them in "Technical References", the unseal algorithms are completely different in bq30z55 vs bq78350.

[pawelsky]

@mefistotelis One thing you could do though it to prepare a script that reads the PF configuration/flags/alerts for various DJI batteries/gauges to at least have an indication of the state the battery is in. That would be useful for troubleshooting and fairly safe to execute.

[svarteld]

@mefistotelis that eventual script would be interesting.

@0r10nV good news, I'll try the same with LiPos of standard size, 4000-5000mAh.

I don't need to use larger LiPos than the standard size, since there's additional LiPos added after the BMU, so BMU can't cut power and ground the bird, at least not instantly. After the HW mods, there's place inside the middle section where the arm mechanics used to be, so at the same weight AC will carry additionally 4000-5000hAh, meaning double air time. Also means BMS will not tell AC to slow down even with custom FW allowing 60° tilt and 100+ km/h sustained speeds, which is not really sustainable even with a single fresh TB48. In my tests, custom 60° tilt FW allow 100+ km/h until BMS reduces power output (I've kept those safety checks intact).

Successful flights done with arm HW removed, standard AC FW do not care/know arm position, it's one-way servo PWM control. Now using Inspire 2 props; 1550T instead of 1345T, since 1550T measures more efficient. Carbon props I've used measures the least efficient; DJI did well here. I2 prop mounts are easily moved to I1. Old I1 ESCs/3510 motors with lower KV fits larger 1550T perfectly.

(sorry, off topic)

[svarteld]

@mefistotelis @pawelsky @0r10nV an update if you're curious:

4 TB47 boards desoldered from cells, balance and main leads to set of LiPos total 4200mAh, board starts up without problems, reports 100% via LEDs even though LiPos are half full; guess a couple cycles full-to-empty will recalibrate, we'll see.

I1 WM610 craft powers up, spins motors, takes off (without props;-)). One issue though: one of the crafts with standard FW will report "disconnected" in DJI Go even if take off is allowed. The craft with modified FW, likely allowing non-DJI batts, reports battery needs to be updated: perhaps power cycled, perhaps FW update. Craft takes off regardless, reports voltage etc.

Question: I cannot see battery FW version in log files or DHI Go, only craft FW. Is there a good way?

Will report back after power cycles. Thanks for the info guys, appreciated!

[0r10nV]

by the way, which cells you connected instead of used? TB47 and TB48 batteries are designed to use LiPoHV 3.80V rated cells with 4.35V at full charge. If you plan to replace them with standard 4.20V LiPos then DJI Standard Charger with 26.1V output will definitely overcharge them to unsafe level. At least they could be degraded fast.

regarding battery firmware revision it's not displayed nowhere in the app neither assistent in any of Dji drones. For some drone models though it could be read directly from the battery using additional hardware and scripts but for Inspire UART decoder still is not available. So if you have a logic analizer or sniffer you could capture communication packets between drone and battery and we could try to parse and decode it together.

[rufiooo]

TB47 and TB48 batteries are designed to use LiPoHV 3.80V rated cells with 4.35V at full charge.

TB47 are standard 3.7V, only TB48 are lipo HV.

[svarteld]

Thanks for the info,

I understand the LiPo/LiHV TB47/TB48 variants, so no worries there. I use 4x 1050mAh 6s LiPo for the TB47, so pretty close to a standard TB47 (4200 mAh vs 4500 mAh).

Question: do you know the least mAh that the TB47 BMS accepts after a couple of power cycles? As stated, I'll have extra LiPos after the BMS, so I don't need to increase energy in the modded TB47; less will be easier to fit. Something like 3000mAh will fit nicely in the basket; 3x 1050mAh 6s will fit, for instance.

[0r10nV]

TB47 are standard 3.7V,

They are marked as 3.7 but handled as LiPoHV. TB47 battery label max charge voltage states it's 26.1V, so 26.1 / 6S = 4.35V. The Charger Output is even more 26.3V. And this screenshot is made directly from TB47 battery management chip profile, it's preprogrammed to 3.80 (4.35V) So BMS Charge MOSFETs will be ON until pack reaches 26.1 common voltage. Also here is replacements cells for TB47 and there are 4.35V as well.

Question: do you know the least mAh that the TB47 BMS accepts after a couple of power cycles? It could accept any capacity at learning cycle but no more then DesignCap+10%, so relearning downwards should not be an issue. You only should follow Texas Instruments recommendations for relearning of their battery management chips otherwise capacity could not be updated. Main of these,

• Fully Charge till Charge FET is OFF and FC bit is set in Battery Status register (SBS[0x16)
• Allow chemistry relaxation period at least for 2 hours
• Make discharge cycle at rated load until FD bit is set
• Allow chemistry relaxation period at least for 5 hours
• Recharge the battery, now capacity should be updated (with respect to MAX_CAP_INCREMENT)

For more details you could refer their AppNotes.

[svarteld]

@0r10nV, good info, many thanks.

And strange; basically all internet says TB47 is normal 3.7, but this says HV, all over; BMS, label, charger, replacement cells (saw those too before; thought TB47 was just a misprint).

Also, DJIs TB batteries have really high energy density, very difficult to reach with other LiPos. Makes me wonder if DJI engineers ended up with a too heavy bird (arm linkage is crazy heavy), needed more energy without weight, and then overcharges standard LiPos but monitoring them carefully with BMS in each battery, and accepts short LiPo life.

Anyone ordered those HV replacement cells? That special dimension is really hard to find. Might try standard 3.7 LiPos, if you don't discourage me for safety; bad idea? I've managed to keep BMS temp sensor intact.

Good thing I can make light small TB's now; there's some TB46's coming up :-)

[0r10nV]

And strange; basically all internet says TB47 is normal 3.7, but this says HV,

It looks like cells are LiPo in fact but TB47 bms is not properly configured at the factory. Have rechecked some additional parameters there to confirm battery set up for LiPoHV. First, is Chemistry Profile (OCVa, OVCb and Ra,Rb-tables) which could be checked by OpCode 0006 to 0x44 register.

It returns 0x3283 for TB47 and 0x3273 for TB48.

Let's check for which cells those profile designated, go to bqStudio->ChemistryUpdater.

While Cells in fact produced by ATL who has hundreds of dedicated profiles there, DJI engineers selected LGC and SONY cells profiles respectively instead. They are both for 4.35V.

But the main settings in respect to cells safety and service life are located in the Protection profile, which is directly responsible for MOSFETs control both in charge and discharge activities. Here is for TB47, where CUV and COV (Under and Overvoltages setpoints) are set to 3000 and 4430mV respectively which are general LiPoHV values.

And last point is the Charger, which is common for both TB47 and TB48 models and has 26.3V output.

So me would not say 'They control cells carefully', it's rather negligence in design or market racing between drone manufacturers for better flight time. If TB47 would be configured for standard LiPo cells and charger then about 15% drop in energy reserve would be expected.

Anyone ordered those HV replacement cells?

Me have ordered some time ago Mavic Pro, Air, P4 and P4P cells from that supplier. While cells dimensions are the same as of original, their performance is worse because those are replica cells and they are produced on different factories so not so good as genuine ATL cells used typically in most of DJI batteries. Cells impedances observed to be higher as well as voltage drops under the working load. The only P4P cells were found to be authentic but marking code was erased by solvent. Luckily under magnifying glass bar-code and cells wattage were visible and turned out to be the same as on genuine P4P cells as well as cells performance.

[svarteld]

Great info, thanks!

LiPo model codes, if anyone wants to order, seems to be: TB47: 5534A6, 5534106 TB48: 6034A6, 6034106, 6135A6

Image from one of my TB47. As you said, it's ATL cells, code 5534A6. Note that DJI puts cooling alu plates between each cell, and then wraps them all externally in alu, thermally connected to inner plates.

The more I study DJI hardware, and the Inspire 1 in my case, the more impressed I get. Except, the cardinal selling point of the Inspire 1/2; movable arms. My three I1 crafts will be rebuilt similar to the images, leaving space for 4x 1050mAh 6s cells in the cavity where arm mechanics were. Airfoils covers in light foamed 3D-printed plastics. The large foil will follow wind direction. Round tubes are not great aerodynamics.

LiPos after BMS system works great; less voltage sag, more time, rescue power if BMS shuts off power, less risk for forced landings, etc. If you start battery first, then connect external LiPos, and in reverse when posering down. The opposite order will upset BMS, and mark battery as needing a power cycle.

[svarteld]

...one more thing: TB48 cells (2850mAh) are almost the same price as for TB47 (2250mAh), but will require me to write new max capacity to the TB47 boards, I guess. Question, if you've got time: with bqtools and an usb-to-I2C, will I be able to? Do I need keys to get access? Trouble might be I'm on deep water; not a programmer anymore, use mac/parallels, and are not as smart as you. It's OK to tell me go buy TB47 cells :-)

[0r10nV]

Of course, the easiest way is to use TB47 4.35V replica cells. Alternatively you could use TB48 cells and to make some relearning cycles under light load so to allow TB47 board chip recalculate for higher capacity. Without reprogramming it will allow to relearn up to (DesignCap + 10%). Having in view your boards are like a new with quite high FCC stored from previous usage then 1 to 3 cycles could be enough for relearning.

About reprogramming, this area requires additional software and hardware which is quite expensive for one-off usage.

[svarteld]

Thanks, makes sense, no reprogramming then. If DesignCapTB47=4500mAh, then +10%=4950mAh < 5700mAh (DesignCapTB48?), so if those numbers are OK, TB48 cells with a TB47 board might not be relearnable enough. I'll get TB47 cells if I've not misunderstood things.

[mefistotelis]

I thought SLUU852A.PDF is the documentation for bq30z55, but the document doesn't fully match what I see in the chip. So it looks like that document is only for bq30z55-R1 (and bq30z50-R1). Anyone happens to know document number for the bq30z55?

For the differences I see to SLUU852A.PDF:

• ManufacturerAccess.PFStatus() works as described in the document
• ManufacturerAccess.OperationStatus() refuses to read the value (probably requires some additional conditions, as I can see EV2300 using this command with success)
• ManufacturerAccess.ChargingStatus() returns 24-bit value instead of 16-bit

EDIT: After changing I2C baudrate to 66 kbps, the OperationStatus() started working. No idea why other commands were working fine at 100 kbps, but OperationStatus() requires 66k ...

[0r10nV]

There is also SLUU852.pdf dated 2012, it's earlier or even initial release TRM for same chips. Both bq30z50 and bq30z55 considered to be custom designed devices unlike bq30z554 (SLUUA79.pdf) so TI does not officially provide their documentation as well as accompanying evaluation software. There are numerous firmware revisions within each device from v0.xx to v9.xx with different features and memory layouts. DJI uses v0.36, that's why you could find some discrepancies with basic TRM.

No idea why other commands were working fine at 100 kbps, but OperationStatus() requires 66k ...

Is it 100kbps here is equivalent to 100kHz clock frequency typically used for Smbus devices? Does ev2300 use 66k to read those registers?

Me have used different hardware like Cypress EZ-USB and Silabs CP2112 as usb-to-smbus adapters at 100kHz and they work with bq30z55 just fine. Any registers are read properly.