-
Notifications
You must be signed in to change notification settings - Fork 13.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Battery Smbus enhancements #15369
Battery Smbus enhancements #15369
Conversation
Looks good so far. I don't really have anything on hand to test this code. Any suggestions? Bigger picture architecturally we really need to do something to split the messages for simple analog power modules and smart batteries. The existing |
Do you want to merge those changes, and further work to be done on other pr?
I have tested it with mine BQ40Z80 based battery. @limhyon @dakejahl do you have setup to test with BQ40Z50?
@dagar I have the next proposal (That I have already implemented on my repo...).
leave it there. the only thing that isn't there is the warning, but look at that, you have the "errors_count1" on SYS_STATUS which doesn't being used at all..... can we put the warring there? only publish smart battery data on "BATTERY_STATUS", I have actually made new "SMART_BATTERY_STATUS_EXTENDED" that combine "BATTERY_STATUS" and "SMART_BATTERY_STATUS", if that something worth doing on master, tell me and I will make new pr for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, please see suggested changes.
edit: I do not have hardware to test this against btw
367dca9
to
e68b4ac
Compare
@themcfadden you might want to review this as well. |
Thanks all for the comments! |
@dagar I see now a build issue for linux builds, because of using crc8ccitt() function, which is a nuttx function. |
@BazookaJoe1900 I would like to get some feedback from @themcfadden as he's using a BMS with the Texas BQ40Z80, which required also some mods on this driver. |
Well this needs some support added, but a workaround is use some prepocessor directives. |
great, looking for @themcfadden notes about current pr. but pay attention that the BQ40Z80 related code has not yet merged, I didn't want to mess this pr with much more changes that are pending in my repo... |
Add back the CRC calculation code and wrap it in preprocessor directives for not __NUTTX |
@@ -55,7 +56,7 @@ BATT_SMBUS::BATT_SMBUS(I2CSPIBusOption bus_option, const int bus, SMBus *interfa | |||
_batt_topic = orb_advertise(ORB_ID(battery_status), &new_report); | |||
|
|||
int battsource = 1; | |||
param_set(param_find("BAT_SOURCE"), &battsource); | |||
param_set((param_t)(px4::params::BAT_SOURCE), &battsource); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, maybe we should leave this alone until we can take a dedicated look at C++ param usage separately. The px4::params
enum is really only meant to be used with ModuleParams, however I don't see why we shouldn't use it directly with along with a few other new helpers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dagar Done
} | ||
|
||
if (lifetime_data_flush() == PX4_OK) { | ||
// Flush needs time to complete, otherwise device is busy. 100ms not enough, 200ms works. | ||
px4_usleep(200000); | ||
px4_usleep(200_ms); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Be careful here if this is executed from the WQ thread (I2C bus). This is long enough to cause magnetometer or barometer timeouts if sharing the same bus.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that actually is simple refectory, so if there was problem before, it will be still a problem.
I am not sure how to handle that comment....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll take a closer look when I have some appropriate hardware on hand.
I was actually only talking about
I'm not sure of the exact details here, but in general to me it's a question of it being useful/actionable. Does an operator actually need that information for preflight or during operation? |
Thanks @TSC21 for pulling me in. We are using the the BQ40Z80 in our battery design. |
I've had a chance to dig into this a bit more. As I said before I think the changes are good and don't want to hold anything up any longer. The reason we designed a battery with the BQ40Z80 was to support 6S, which we need to meet a flight time requirement. What are the plans for this driver moving forward? Will it support the additional cells in the future? We have it working with 6S, and I can help out with code submissions, reviews, and/or testing. |
I am working with the BQ40Z80 too, and there is a bit more of just adding the extra cells due to compatibility differences.
@dagar do you want me to add the Z80 code? or maybe to do some branch to the branch? *EDIT - I have added basic code to use with Z80, for review and notes |
If this has been and can pass CI I'm happy to merge other than 2 minor thing.
|
src/drivers/batt_smbus/parameters.c
Outdated
* @value 1 BQ40Z50 | ||
* @value 2 BQ40Z80 | ||
*/ | ||
PARAM_DEFINE_INT32(BAT_MODEL, 0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BAT_MODEL
is a bit too generic. Maybe something like BAT_SMBUS_MODEL
?
I'd also consider just skipping it entirely if the battery is easy to identify.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will be happy to make it auto-detect, and I am sure it possible, but didn't had time to do it.
any way, I only have the Z80 to check it with, so I will need someone with Z50 to check it too
@dagar anyway, don't merge before @themcfadden review, and functional tests please |
Otherwise it looks good. |
I don't seem to have access rights to push. Here's the patch It is super simple.
|
A couple more comments:
|
- added support for BQ40Z80 based battery - added performance counter for interface errors - added SMART_BATTERY_INFO mavlink message - general code cleanups and optimization - fixed: void flooding the log in case of interface error - fixed: using _batt_startup_capacity instead of _batt_capacity for discharged_mah - update: read manufacture_date - update: get _cell_count from parameter and not const 4 - update: avoid re-reading data that has already been read and stored on class already - currently the battery type defined by BAT_SMBUS_MODEL parameter and not by auto detection
b661af1
to
1ca689e
Compare
@themcfadden - thanks for testing! I rebased, fixed more small staff and also fixed the cell issue you noted. |
@dagar this pr ready to merge. can you do that? |
Let's take a look at that separately. It's harmless, but I would like to get rid of it. |
Describe problem solved by this pull request
The sbmus driver has many fixes and functional updates that can be done.
Describe your solution
This PR is WIP to start and update the driver. it just cleanups before the "real work".
it can be merged, so the real work will be done on next step
Test data / coverage
I am working with BQ40Z80 only, and not BQ40Z50. (the code for the BQ40Z80 has not been pushed on first commits)
so if there someone that can test the code with BQ40Z50, to ensure nothing has break, that will be helpful
Additional context
Pr batt smbus stability #14409
SMBus battery (a.k.a. smart battery) enhancement. #14496