RDDRONE-BMS772

[iaingalloway]

Please ask questions about the RDDRONE-BMS772 board and software here

[highcatjan]

We would like to use the RDDRONE-BMS772 in our drone batteries. 

My question is, if there already is a PX4 integration based on UAVCAN?

Is there any work which we can pick up?

Thanks in advance
Jan

[GeraldP]

Yes, we are currently testing the next release candidate of the open source BMS772 reference SW that includes DroneCAN support.

[lmiles-sosub]

Hi All,

I am wondering is there anyway to read the type of fault code from the CLI? I can read the state (bms get state => FAULT) but is there a way to receive the type of fault e.g. over voltage?

If not do you have some guidance on the best way to implement that in the firmware? 

Thanks for your help,

Lewis  

[lmiles-sosub]

Hi All,

We are facing an issue with the integration of the NXP BMS into our ROV system and hoping for some guidance on the changes I should make to the firmware to resolve the issue.

The problem is we occasionally will deplete a battery during an ROV flight underwater, and the vehicle becomes unrecoverable as the BMS will go into deep sleep. Following an under voltage fault the BMS will enter deep sleep to reduce any further draw on the battery, part of this means turning off the UART communications. If we apply voltage to the BMS it will remain in deep sleep until the physical reset button is pushed. The issue is that the robot is deployed under the water, so physically pushing the button won't work and we aren't able to communicate via UART as it has gone into deep sleep.

So I am seeking any advice on how I might be able to overcome this problem. The goal would be to still have the BMS enter deep sleep mode to prevent further discharge of the battery however to be able to wake the battery via a UART command or if charge voltage is detected.

I was thinking I could attach an interrupt to the UART RX pin before entering deep sleep, which will reset the fault during wake up. Is this a feasible solution and if so is it possible for you to point me in the direction of the firmware I could do this?

Thank you for your help,

Lewis

[cisvmierlo]

Hi Lewis,

Indeed, the BMS goes to deep sleep to preserve any charge left in the battery. Meaning that this will be the lowest power mode (±100uA). 
The only way that this is feasible, is to turn off the VCC_3V3_SBC, which is used to power the MCU.
Meaning that the MCU will be off. So, setting an interrupt won't help with waking up from this mode.

The only to wake up from this is mode is to either re-apply a voltage to the BMS or to pull down the SBC's (U3) wake pin (pin 12).

Maybe use J22 to pull down the wake pin (keep in mind that the voltage on this connector is between the battery voltage and 0V). For example, you could use an external switch or signal controlled from your other system to pull this low.

Another solution would be to send the "bms reset" command over de CLI (UART) when you receive the undervoltage fault and the BMS is counting down before going into the deep sleep mode. This will reset the timer.

You could also reconfigure the timeout time for the BMS to go to deep sleep and even disable it.
To do this, see t-fault-timeout in chapter 8.2.2 (page 18) in https://github.com/NXPHoverGames/RDDRONE-BMS772/blob/main/BMS772_releaseNotes_5.0.pdf 

Hopefully this will help, kind regards,

Cis van Mierlo

[lmiles-sosub]

Thank you for your reply Cis van Mierlo, that was very helpful.

I was able to get the functionality I needed by using an N-Channel, P-Channel Mosfet with and RC timer to momentarily pull the wake pin low if a charger voltage is connected. 

Another thing I am looking into is the time it takes for the BMS to wake from sleep state due to over current detection (i-sleep-oc). The issue I am facing that after a full charge the BMS output will be disabled to stop overcharging, if our robot then draws more current then the charger can supply the BMS will detect this and enable the output. However attaching the scope I have measured a switch time of the BMS of about 300-800ms. This delay is a problem as it causes a brown out for the raspberry pi. 

I am wondering if there is a way to reduce this time? Maybe by updating the frequency it checks the output current to wake? If I can reduce the time I can the look into smoothing the voltage drop.

Thanks again for your help.

Lewis.

[cisvmierlo]

Hi Lewis,

From reading your story I'm assuming the BMS is in the charge-complete state. With the power disabled to stop the battery from overcharging. 

When your system draws more current than the still attached battery charger can provide, the voltage will drop. 

In the charge-complete state, there will not be a current flowing from the battery, as the power switch is open. The BMS will check the output voltage too see if the charger is disconnected. 
When the charger has this voltage drop and this drop is low enough for the BMS to think the charger is disconnected, it will go the SLEEP state, but it will first set the MCU in very low power run (VLPR) mode and other peripherals in lower power modes as well before closing the power switch.

After this voltage drop of the charger, will the charger stay off?
Or will it have a lower volage than your battery and the charger is protected against sinking the current?

Kind regards,

Cis van Mierlo

[lmiles-sosub]

After this voltage drop of the charger, will the charger stay off?

No at this point the charger will stay on. So it would restart the charge process if the current draw stopped. In the future we will implement a controllable charger to disable upon full charge.

Or will it have a lower voltage than your battery and the charger is protected against sinking the current?

No the charger is slightly higher in voltage to achieve full charge but it is also protected against reverse current.

Would it be feasible to increase the voltage level in which the BMS determines the charger has been disconnected? This way it may prevent the brown out of the computer. Then it would go back into charge state and protect itself from overcharging.

I will also intergrade a UPS as an alternative solution to the problem.

Thanks for your help  

[lmiles-sosub]

Hi All,

We are testing the use of the BMS in an ROV system with a charger that constantly supplies power to the ROV and the battery will provide power for peak loads above the chargers power capacity. 

We are having some issues when the battery reaches its under voltage protection (enters fault mode) and are trying to recover the BMS from fault state to be able to charge the battery. 

Ideally the BMS would shut off output but would still allow a charge current to enter the battery, without needing to be reset. Currently we are resetting the BMS remotely through the CLI to remove the fault however to power the system we must have the charger on, which then results in the self test failing and suggesting to remove the charger.

My question is around the functionality of the charger having to be disconnected for the gate self test. What is the purpose of it and would there be a critical issue if I were to disable it in the firmware?

Thanks for your help.

Lewis

[cisvmierlo]

Hi @lmiles-sosub,

The purpose of the gate check is to make sure the gate driver is able to turn off the power. It there would be something wrong with this or other components and it is not able to turn off the power, this could result in a safety issue, hence the self-test. 

I get that for your purpose, this is not ideal. Feel free to disable this check in your software for your purpose if you think this is safe.

Keep in mind that it will not check if the power can be switched off.

Plus I would advise you to still turn off the power in that part of the code, you could either replace the part with the below piece of code or add compile switches (#ifdef #else #endif) so you could easily go back to the original state.

This part needs to be replaced or put in an compile switch: https://github.com/NXPHoverGames/RDDRONE-BMS772/blob/main/src/batManagement.c#L608-L672 

This is the piece of code I would advice you to still add:

// still turn off the gate
batManagement_setGatePower(GATE_OPEN);

cli_printfWarning("SELF-TEST GATE: TURNED OFF!\n");

I hope this answers your question, kind regards,

Cis van Mierlo

[lmiles-sosub]

Thank you that solution worked well for us.

[Prince1]

Hi,

Tera term is throwing few errors when connected with BMS as shown in images attached herewith.

"Couldn't do measurements and also Failed to update measurements"

Please help in resolving them?

Thanks,

Prince

[cisvmierlo]

Hi @Prince1,

Have you tried rebooting the MCU with the "reboot" command?

Another thing you could try to reset the communication errors (as they are remembered) go to DEEP_SLEEP and back to NORMAL state?

Otherwise you could try to re-power the BMS power to solve the problem.

Kind regards,

Cis van Mierlo

[Prince1]

Hi @cisvmierlo,

I tried rebooting and re powering the BMS it didn't help. I will try going into DEEP_SLEEP.

Thanks for your help.

Regards,

Prince

[suvasis]

hi,

I am trying to redesign the PCB to a smaller form factor for my drone. The following document

https://www.nxp.com/design/designs/smart-battery-management-for-mobile-robotics:RDDRONE-BMS772

generally provides schematic and fabrication files but those link does not contain the source file of the PCB. can anyone include the source file for the PCB?

Can anyone help me?

thanks.

suvasis

[cisvmierlo]

Hi @suvasis ,

The .brd layout file of the RDDRONE-BMS772 has been added to the design files and could be downloaded.

Please see https://www.nxp.com/design/designs/smart-battery-management-for-mobile-robotics:RDDRONE-BMS772

Kind regards,

Cis van Mierlo

[cisvmierlo]

Hi @suvasis, 

I've asked the team if they could upload the board file (.brd) as well to nxp.com.
Be aware that this could take a couple days.

The schematic file (.DSN) is already included.

Kind regards,

Cis van Mierlo

[DaveNXP]

Hello,

The PSMNR70-30YLH MOSFETS that are recommended by NXP documentation unfortunately are not available to buy in the sites I tried. This is an issue because I can not test with safety the board.  I read in this community I can find it in Nexperia but the minimun quantity to order is 1500. I tried to look for another equivalent one but I cannot find it with the same characteristics. I don't know the tolerance or how much the MOSFET can differ.

The MOSFET characteristics recommended by NXP are below. What other characteristics are tolerated or what other suitable characteristics can you recommend, please? 

N-channel 30 V

0.82 mΩ,

300 A logic level

MOSFET in LFPAK56 using NextPowerS3 technology

Thank you very much

[DaveNXP]

Does anybody know how to factory reset the RDDRONE BMS board(or awaken it)?

The board may be in deep sleep or in a state I cannot get it out.

At first I could connect to the core (Cortex-M4 identified) but after this, when I tried to flash the firmware, I cannot connect to the target anymore(log copied in previous post). So I cannot send any command with J-Link Commander. The voltage of the J-Link debugger is 3.3V. I pressed the physical button while board powered but nothing changed and it does not wake up.

This happened to the two RDDRONE boards I bought.

Please, any help would be really appreciated.

Thank you! @cisvmierlo @iaingalloway 

[cisvmierlo]

Hi @DaveNXP ,

Could you check de reset line of the debugger? If it is correctly connected to the MCU?

Or if J2 is placed, maybe use this 2x5 connector to program the board via that programming header?
If J2 is not placed, maybe you could solder a 2x5 pin header in to program the board via that route.

Kind regards,

Cis van Mierlo