New BMS for bq76PL455A based batteries

Topics concerning OEM and open source BMSes
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: New BMS for bq76PL455A based batteries

Post by Pete9008 »

I never even knew the the PIO had that capability on the pico, very, very nice and perfect for this. I can think of a few times in the past where that would have come in extremely handy. I'd wondered why you used the Pi and I guess that explains it.
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: New BMS for bq76PL455A based batteries

Post by catphish »

Pete9008 wrote: Thu Apr 07, 2022 9:05 pm I never even knew the the PIO had that capability on the pico, very, very nice and perfect for this. I can think of a few times in the past where that would have come in extremely handy. I'd wondered why you used the Pi and I guess that explains it.
Indeed - there were 2 reasons I used the Pi Pico:
1) PIO - no MCU can implement this proprietary serial protocol in hardware, so the only option is to "bit bang" it. PIO essentially gives you dedicated CPU cores for exactly this purpose.
2) Availability. I have started using RP2040 (Pi Pico) instead of STM32 because their minimal use in industry, and single SKU means they are readily available, unlike pretty much every other MCU right now!
sigdigits
Posts: 73
Joined: Sun Mar 06, 2022 12:20 am
Has thanked: 30 times
Been thanked: 7 times

Re: New BMS for bq76PL455A based batteries

Post by sigdigits »

This is awesome! I'm looking into options, and most seem very overpriced for what they are. I wanted to verify if this would work with the battery pack from a BMW 530e? I assumed yes, since its a phev with the LG cell packs, but wanted to check. If so, it seems like a way better option than the over $600 SimpBMS!
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: New BMS for bq76PL455A based batteries

Post by catphish »

sigdigits wrote: Thu Apr 14, 2022 6:42 pm This is awesome! I'm looking into options, and most seem very overpriced for what they are. I wanted to verify if this would work with the battery pack from a BMW 530e? I assumed yes, since its a phev with the LG cell packs, but wanted to check. If so, it seems like a way better option than the over $600 SimpBMS!
Thanks! You will need to check whether your particular pack has a bq76PL455A chip in each module, if so, this should work.

If you are comparing this with SimpBMS, you have to realise that Tom's BMS provides a complete, tested, supported, configurable BMS. Whereas mine, while free and perfectly effective, is quite barebones, and will likely require some basic development skills and understanding of CAN to use effectively.
Swing
Posts: 43
Joined: Mon Jan 27, 2020 2:03 pm
Has thanked: 9 times
Been thanked: 6 times

Re: New BMS for bq76PL455A based batteries

Post by Swing »

Hi, these chips are also used in the Mercedes EQC/EQVs, and those are quite interesting. We are using these modules parallel in 48v.
2 modules already give ~20kWh and given your board layout, you just hook one up to one port.

So it seems to me that your board/solution can decide to do balancing on its own and it can communicate with CAN bus chargers. However, it does not offer the full set of the aforementioned SimpBMS which controls a contactor. And can measure from a shunt to release the contactor based on current information.
So this means there should always be some kind of master device controlling this (contactor and shunt)
Is my view of the situation correct? I did not read the whole github yet.
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: New BMS for bq76PL455A based batteries

Post by catphish »

Swing wrote: Mon Apr 18, 2022 9:27 am So it seems to me that your board/solution can decide to do balancing on its own and it can communicate with CAN bus chargers. However, it does not offer the full set of the aforementioned SimpBMS which controls a contactor. And can measure from a shunt to release the contactor based on current information.
So this means there should always be some kind of master device controlling this (contactor and shunt)
Is my view of the situation correct? I did not read the whole github yet.
This is correct. This BMS board does only the following:
* Cell voltage monitoring
* Automatic balancing
* Transmitting CAN packets with voltage information
* Module temperature monitoring (though this is likely specific to the LG modules I'm using)

I have also designed this (very similar looking) companion board, which has CAN, CP/PP, 4 x 12V inputs and 4 x switch outputs. It is intended to fill in the gaps in functionality that you describe. It can be found here, but note that is has no software yet, and even when it does, it'll likely be a very vehicle-specific thing. https://github.com/catphish/ev-charge-controller
charge-controller.png
For my vehicle, I intend to program this board to do the following:
* Communicate with EVSE
* Enable/regulate my CAN controlled charger
* Switch on coolant pumps when needed
* Enable / disable the inverter to prevent driving while charging
* Communicate over CAN with ISA shunt and gauge cluster to display current and state of charge

I wouldn't describe either device as the master as they both operate independently and perform different functions.

I believe contactor control is better left to the inverter to handle, and again this will be independent of the other modules.
Swing wrote: Mon Apr 18, 2022 9:27 am And can measure from a shunt to release the contactor based on current information.
I will definitely not do this. It is a sure way to destroy a Tesla inverter if it's not already destroyed :)
Swing
Posts: 43
Joined: Mon Jan 27, 2020 2:03 pm
Has thanked: 9 times
Been thanked: 6 times

Re: New BMS for bq76PL455A based batteries

Post by Swing »

Ok in general I understand that your solution tries to be more like a master CAN module (master of information only), aggregating information and letting other entities decide.
So you are not trying to be a full fledged BMS, protecting the battery against everything.
My remark about the shunt and current measurement is more about situations where you can define the usable current, sometimes temperature related. Releasing a contactor to protect the battery would be a last resort of course. I can imagine high power inverters driving cars will not like that and so it is not an option. At least there needs to be a path to signal issues for the inverter to stop.

Our needs are a bit simpeler. They are used in electric boats. The power is not that high, and sometimes even dumb chargers are used (C rating relatively low), although CAN bus charger would be nice. Using typical blue sockets, no EVSE.
The design as such is that it should not need any active thermal management, but yes it is great to be able to do that.
There might be communication in the future between BMS and motor(inverter) but for now we don't have that. Contacter should be used to protect battery in case of problems. The design is as such that it should never happen, and everything is well below 1C.
I do agree that the full fledged solution is nicer, communicating with CAN on all devices. But we don't have that.
In fact, with some of the motor options the whole display of battery level is shown in the motor controls without CAN. It measures a shunt or you have to run the charger through the inverter/controller so it can measure it there.

Lets say I am following more the simple principle of a Chinese inline BMS, but I don't want to use that, I want to reuse the CAN bus measurements and base decisions on that.
It is the way I am running a SimpBMS on a Victron setup. Everything is dealt with in a normal fashion (with CAN communication) and the contactor normally never opens. The invertering and charging is all managed within the specs, within the operating window.
I understand that your solution tries to be something else than the simpBMS and it could in fact be used together. But than it will add up quickly in terms of costs.
catphish wrote: Mon Apr 18, 2022 10:18 am * Module temperature monitoring (though this is likely specific to the LG modules I'm using)
Why would that be specific to the LG modules? The CATL modules used in Mercedes have (of course) also some temperature sensor in them, and I am guessing the bq76PL455A is made for that and used in the same way.
I have also designed this (very similar looking) companion board, which has CAN, CP/PP, 4 x 12V inputs and 4 x switch outputs. It is intended to fill in the gaps in functionality that you describe. It can be found here, but note that is has no software yet, and even when it does, it'll likely be a very vehicle-specific thing. https://github.com/catphish/ev-charge-controller

charge-controller.png
For my vehicle, I intend to program this board to do the following:
* Communicate with EVSE
* Enable/regulate my CAN controlled charger
* Switch on coolant pumps when needed
* Enable / disable the inverter to prevent driving while charging
* Communicate over CAN with ISA shunt and gauge cluster to display current and state of charge
I think this board with be great. But I would not use any of your listed features (although I think they are great!) and just want to protect the battery in a scenario where it shouldn't be. In reality, the most likely reason to defend the the battery is against some parasitic loss of some device completely draining it. All other possible reasons should not happen at all. (battery getting to hot, overcurrent etc)
Of course, that is just our case.

I can imagine using your solution together with a very generic battery protect device. That device would have an input from your board to shutdown.
Or it could be an inverter (or charger) to let it should down through a contact/input. Letting it shut down on its own, rather than breaking the line.
User avatar
mjc506
Posts: 343
Joined: Wed Sep 09, 2020 9:36 pm
Location: Wales, United Kingdom
Has thanked: 30 times
Been thanked: 28 times

Re: New BMS for bq76PL455A based batteries

Post by mjc506 »

Nothing stopping you editing the code (or hardware) to suit your particular use case...

The pl455 'measures' temperature just as analogue inputs (and spits out the raw analogue reading). Most battery modules will have a thermistor to measure temperature, but no guarantees that the CATL modules use the same thermistor and potential dividers as the BMW modules!
Swing
Posts: 43
Joined: Mon Jan 27, 2020 2:03 pm
Has thanked: 9 times
Been thanked: 6 times

Re: New BMS for bq76PL455A based batteries

Post by Swing »

mjc506 wrote: Mon Apr 18, 2022 11:12 am Nothing stopping you editing the code (or hardware) to suit your particular use case...

The pl455 'measures' temperature just as analogue inputs (and spits out the raw analogue reading). Most battery modules will have a thermistor to measure temperature, but no guarantees that the CATL modules use the same thermistor and potential dividers as the BMW modules!

Yes I agree. Just checking the targetted purpose of the project.

And I also have the NTC information so It should just be a small fix if the temperature values are different.
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: New BMS for bq76PL455A based batteries

Post by catphish »

Swing wrote: Mon Apr 18, 2022 10:57 am Ok in general I understand that your solution tries to be more like a master CAN module (master of information only), aggregating information and letting other entities decide.
So you are not trying to be a full fledged BMS, protecting the battery against everything.
Yes, this is absolutely the case. In fact the first iteration of my firmware just acted as a slave to SimpBMS, but then I realised for my case, it was simpler to have my board act standalone and do the balancing itself.

I allow other devices to handle other protections. For example, my inverter will shut down on under-voltage, and my charger will shut down on over-voltage. I realise some BMS systems do all of this, but it seemed redundant, in my case, and potentially harmful to the inverter. It would potentially be useful to have some additional protections and warnings, but I haven't felt the need to implement them.
Swing wrote: Mon Apr 18, 2022 10:57 am Our needs are a bit simpeler. They are used in electric boats. The power is not that high, and sometimes even dumb chargers are used (C rating relatively low), although CAN bus charger would be nice. Using typical blue sockets, no EVSE.
This is absolutely why I designed the second board. Basically I ran out of IO pins on the microcontroller, so I split off the charging logic to a second board. It's pretty much independent, but through the magic of CAN, it can of course use voltage data from the BMS board to shut off the charger if required.
Swing wrote: Mon Apr 18, 2022 10:57 am Why would that be specific to the LG modules? The CATL modules used in Mercedes have (of course) also some temperature sensor in them, and I am guessing the bq76PL455A is made for that and used in the same way.
The bq76PL455A has 8 general purpose analog inputs. In my battery modules, two are used for temperature sensors on the PCB to monitor the temperature of the balancing discharge resistors. Two are used for external NTC temperature sensors, and one is (I think) used for an internal NTC temperature sensor. There is no reason to assume that a different manufacturer would have used the inputs for the same purpose.

In terms of the overall goal, unless you *just* want balancing it is indeed best to see this board as one module in a larger solution. It has IO for 3 x battery strings, 2 x 12V general purpose inputs, and CAN. It can do anything that's possible with those IOs. Anything that doesn't fit into those IOs will need the expansion board, or third party CAN connected parts, and some programming :)
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: New BMS for bq76PL455A based batteries

Post by catphish »

Pete9008 wrote: Thu Apr 07, 2022 7:21 pm Agree on the 1nF and 1k. 1nF sounds low but it's what TI specify. Have used larger pull ups/downs on RS485 quite happily in the past, you do need something there though (unless the TI chip provides them?).
After some more investigation, and re-reading datasheets, I intend to test the following changes:

Increase inductance of common mode filter from 22uH to 100uH. Datasheet recommends minimum of 50uH, 22uH was definitely a mistake.
Increase capacitance of isolation capacitors from 1nF to 4.7nF or 10nF. Datasheet is a little unclear on this, but recommends 2nF in noisy environments, and to double it when using a capacitor at both ends of the link, to 1nF is definitely too small.
Increase resistance of pull-ups and pull-downs from 1k to 4.7k or 10k. This is a total guess, the official implementation doesn't require these at all.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: New BMS for bq76PL455A based batteries

Post by Pete9008 »

Just had a look through the data sheet and it's a little contradictory in places! In particular is states that the total resistance of the COMML lines must be less than 20R but then specifies that a 10R series resistor should be used at each end making this impossible! It also states that this resistance is needed to limit in-rush current so I'm wondering if it should read at least 20R. As you mention it also says to double the cap value if two are used but then on the diagrams showing two it still has 1nF shown.

Changing to the 100u choke is a good move.

The caps will probably make the biggest difference. Looking at the impedance at twice the comms frequency (and assuming default of 250k baud and Manchester encoding) each 1nF cap will have an impedance of around 300R which is going to dominate compared to the choke and series resistor impedance. I would probably go with a 2n2 or 4n7 only increasing further if the voltage levels on the 485 seem marginal. Don't forget to use a high voltage parts for these!

On the pull up/down there is a comment in the data sheet in 8.1.2.1 which mentions 100k. There are no terminating resistors in this application so all the pull ups have to do is hold a large enough voltage across the transceiver input impedance to keep them in the idle state. 100k suggests that the bq76pl has a pretty high impedance on the inputs (makes sense for a low power application) but your 485 driver will be lower so needing a bit more current. A few 10's of k would seem plenty.

Assuming that the bq76pl COMM lines are probably only 485ish the best way to select the components would be to measure the voltage levels on the daisy chain for both bq to bq connections and you bq to 485 connections in both the idle and active states and tune the components on your board to keep them similar (but also ensure that you meet the 200mV minimum level for the 485).
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: New BMS for bq76PL455A based batteries

Post by Pete9008 »

One more thought on the pull up/down. The 1k values make for quite a heavy load to drive through the coupling network, you must be losing 2/3 of the signal. If the drive strength of the bq76 a bit on the low side too it may struggle to reach the 200mV RS485 threshold.
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: New BMS for bq76PL455A based batteries

Post by catphish »

Pete9008 wrote: Thu May 05, 2022 10:47 am Just had a look through the data sheet and it's a little contradictory in places! In particular is states that the total resistance of the COMML lines must be less than 20R but then specifies that a 10R series resistor should be used at each end making this impossible! It also states that this resistance is needed to limit in-rush current so I'm wondering if it should read at least 20R. As you mention it also says to double the cap value if two are used but then on the diagrams showing two it still has 1nF shown.
When I reread the datasheet last night, I found exactly the same set of contradictions. Thank you for confirming that I'm not just misreading it!
Pete9008 wrote: Thu May 05, 2022 10:47 am Changing to the 100u choke is a good move.

The caps will probably make the biggest difference. Looking at the impedance at twice the comms frequency (and assuming default of 250k baud and Manchester encoding) each 1nF cap will have an impedance of around 300R which is going to dominate compared to the choke and series resistor impedance. I would probably go with a 2n2 or 4n7 only increasing further if the voltage levels on the 485 seem marginal. Don't forget to use a high voltage parts for these!
Agreed, 1n is definitely attenuating the signal too much. In testing I have dramatically improved performance by simply bypassing them, but obviously I'd prefer to leave them in for additional safety if I can do so without causing a dramatic loss of performance. I have ordered 4n7 and 10n capacitors to test. Is there a significant disadvantage to going too large with these? I'm using 1000V caps to voltage shouldn't be a problem.
Pete9008 wrote: Thu May 05, 2022 10:47 am On the pull up/down there is a comment in the data sheet in 8.1.2.1 which mentions 100k. There are no terminating resistors in this application so all the pull ups have to do is hold a large enough voltage across the transceiver input impedance to keep them in the idle state. 100k suggests that the bq76pl has a pretty high impedance on the inputs (makes sense for a low power application) but your 485 driver will be lower so needing a bit more current. A few 10's of k would seem plenty.

Assuming that the bq76pl COMM lines are probably only 485ish the best way to select the components would be to measure the voltage levels on the daisy chain for both bq to bq connections and you bq to 485 connections in both the idle and active states and tune the components on your board to keep them similar (but also ensure that you meet the 200mV minimum level for the 485).

One more thought on the pull up/down. The 1k values make for quite a heavy load to drive through the coupling network, you must be losing 2/3 of the signal. If the drive strength of the bq76 a bit on the low side too it may struggle to reach the 200mV RS485 threshold.
I am fairly sure I have made a mistake by loading down the signal with the 1k resistors, but wasn't able to quantify this so thank you for doing some maths here! I have ordered 10k replacements. These may still be needlessly strong to hold the lines in the idle state, but will hopefully be large enough to give a significant improvement.

Thanks again for confirming that the changes I am making are sane. In my initial design, I chose a lot of the values hastily, and since it appeared to work, I didn't give it any more thought until I started testing in real vehicles and realised it wasn't going to be good enough.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: New BMS for bq76PL455A based batteries

Post by Pete9008 »

catphish wrote: Thu May 05, 2022 8:19 pm Is there a significant disadvantage to going too large with these? I'm using 1000V caps to voltage shouldn't be a problem.
Not really. The bigger the cap the more energy is pushed through it and into the TVS diode during pack connects/disconnects (that's why the TVS diodes are needed in the first place) but it's less than a mJ even with the bigger caps so can't see it being an issue. It's possible that you could start over driving the inputs, but again unlikely. It's also a case of diminishing returns as you still have the 1nF at the far end (so I think my earlier comment where I said the caps will make the biggest difference is in error, it's changing the pull up/down that will make the biggest difference). My approach would be to put the 4n7 caps on, measure the signal levels and only if there was insufficient margin try the larger size. That way you end up with the smallest value that gives you the design robustness you need.
catphish wrote: Thu May 05, 2022 8:19 pm I chose a lot of the values hastily, and since it appeared to work, I didn't give it any more thought until I started testing in real vehicles and realised it wasn't going to be good enough.
Sometimes, when you don't have all the information, the best way forward is to just quickly design it, build it, try it and see what works!
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: New BMS for bq76PL455A based batteries

Post by catphish »

I've just reworked a couple of boards with the new parts: 10k, 100uH and 10nF. Everything still works on the bench.

I currently have 2 vehicles I'm testing this in. In both cases, the cables from the BMS are fairly long (1-2m), the original design didn't work unless I bypassed the isolation capacitors, and failed as soon as the motor started spinning.

I will test the modifies boards in both vehicles tomorrow and see if there is a noticeable improvement.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: New BMS for bq76PL455A based batteries

Post by Pete9008 »

Any reason why you haven't built the BMS module into the battery box?
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: New BMS for bq76PL455A based batteries

Post by catphish »

I connected the modified BMS to one of the vehicles today, this one is probably a worst case scenario with the data cable running about 1m alongside an unshielded power line. There is definitely an improvement as it now works with the isolating capacitors in place, but unfortunately it is still unable to operate while the motor is spinning. I'm not sure exactly how the noise is affecting the line, I'll have to get a scope on it when I have a little more time.
Pete9008 wrote: Wed May 11, 2022 3:13 pm Any reason why you haven't built the BMS module into the battery box?
In my own car, I have done this. The BMS is mounted on the wall of the battery box adjacent to the data connections, so the maximum cable run is about 20cm. Unfortunately, my friend who is also using this BMS decided to put it outside the box in 2 vehicles due to space constraints. It's my hope that this shorter cable run will have a substantial impact.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: New BMS for bq76PL455A based batteries

Post by Pete9008 »

Well at it's an improvement at least. TBH 1m in parallel with an unscreened, HV, high current conductor is a pretty big ask. Is he going to reroute it or add screening to see if it improves things?

One other thought, having had a look at your PIO routines it doesn't look like you are doing any glitch/transient rejection. Do you see or would you know if you are getting lots of invalid received messages with the motor running (as opposed not receiving messages)? Most UARTS use multiple sampling points around the centre of the bit period and then majority voting to determine the bit value - would it be worth implementing something similar in your receive routine? I'd also validate the length of the start bit to try to prevent false starts (although some care is needed to minimise deadtime created following a false start, maybe just check it stays low for 2-3 25M clocks). It may also be worth validating both halves of the Manchester encoding to further improve message robustness (I think it's mainly there to prevent DC offsets through the capacitor coupling but it wouldn't surprise me if it is also being used for error detection). Also is there a CRC or checksum on the messages?

Obviously the ideal would be to have noise free comms and not need these extra features but life is never that simple.
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: New BMS for bq76PL455A based batteries

Post by catphish »

Pete9008 wrote: Thu May 12, 2022 4:36 am Well at it's an improvement at least. TBH 1m in parallel with an unscreened, HV, high current conductor is a pretty big ask. Is he going to reroute it or add screening to see if it improves things?
There is no particular plan for that vehicle. It's not the end of the world if the BMS doesn't work while the motor is running, but it's a good testbed to work in improving the implementation, and it would be nice to get low voltage cutoff to work.
Pete9008 wrote: Thu May 12, 2022 4:36 am One other thought, having had a look at your PIO routines it doesn't look like you are doing any glitch/transient rejection. Do you see or would you know if you are getting lots of invalid received messages with the motor running (as opposed not receiving messages)?
You are correct, as soon as I see a transition, I assume it's a valid start bit, then measure the midpoint of every following half-bit. Before adding checksum validation, I was seeing lots of corrupt messages, most of them empty, which suggests that I was seeing both corruption and false starts.
Pete9008 wrote: Thu May 12, 2022 4:36 am Most UARTS use multiple sampling points around the centre of the bit period and then majority voting to determine the bit value - would it be worth implementing something similar in your receive routine? I'd also validate the length of the start bit to try to prevent false starts (although some care is needed to minimise deadtime created following a false start, maybe just check it stays low for 2-3 25M clocks). It may also be worth validating both halves of the Manchester encoding to further improve message robustness (I think it's mainly there to prevent DC offsets through the capacitor coupling but it wouldn't surprise me if it is also being used for error detection).
I agree on all points. I think there are a number of improvements I could definitely make. I will need see how much of this I can fit in the PIO though.
1) When the first transition is detected, take further samples over a short period to verify that it's a true start bit. If not, wait for a new start bit.
2) Once a valid start is confirmed, take multiple samples on each half-bit, invert the samples from the second half, then take a majority vote.
3) If four consecutive half-bits are all detected as "idle" state, abort and wait for a new start bit.
3) If communication fails, ie a request times out or the checksum fails, try re-send the request instead of giving up.
Pete9008 wrote: Thu May 12, 2022 4:36 am Also is there a CRC or checksum on the messages?
Yes. There is a CRC which I have now implemented. However right now if the CRC fails, I throw a tantrum and reset the whole controller.

Edit: one more thing I noticed looking at the code tonight is that I was sampling everything one sample late (10% of a cycle after the peak of the signal eye).
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: New BMS for bq76PL455A based batteries

Post by Pete9008 »

catphish wrote: Thu May 12, 2022 8:03 pmHowever right now if the CRC fails, I throw a tantrum and reset the whole controller.
:lol:
catphish wrote: Thu May 12, 2022 8:03 pm Edit: one more thing I noticed looking at the code tonight is that I was sampling everything one sample late (10% of a cycle after the peak of the signal eye).
What might be worth doing is use the sideset command to toggle a spare output pin at the rx sampling point/s - it makes it very easy to confirm that you are at the optimum point on a scope. I did try to have a look at the sampling point in the code but decided that there was no point as my understanding of the PIO isn't good enough. Can't quite work out the clock speeds in the Rx and Tx routines, Looks like 10 instructions per bit but this doesn't seem to match with the clkdiv setting?

All your changes make perfect sense, particularly point 3 - very good compromise to minimise deadtime on start bit validation. Looking forward to trying this later this year (have just ordered a few picos ready).
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: New BMS for bq76PL455A based batteries

Post by catphish »

Pete9008 wrote: Fri May 13, 2022 5:55 am Can't quite work out the clock speeds in the Rx and Tx routines, Looks like 10 instructions per bit but this doesn't seem to match with the clkdiv setting?
Clock speed is 80 MHz, this is divided by two (clkdiv) to get 40MHz, or 25ns per instruction. One bit (ie high-low, or low-high) is 250ns. Here's some simplified code that I'm going to test shortly. The bitloop is 10 cycles (2 instructions, plus an additional delay of 8).

Code: Select all

beginning:
  wait 0 pin 0          // Wait for data input to go low
  jmp pin beginning     // Loop back to igore the data if we're transmitting
  nop              [8]  // Delay 9 cycles (nop + 8 more)
  set y, 7              // Initialize loop counter
bitloop:
  in pins, 1       [8]  // Read the bit into the ISR, delay 8 cycles
  jmp y-- bitloop       // Loop 8 times

  in null, 24           // Dump 24 bits of zero into the ISR to right align the byte
  push noblock     [3]  // Push to FIFO, delay 3 more cycles to fully skip first half of framing bit
.wrap
This corrects 2 major failings of the current code. 1) Hopefully it correctly aligns the reads to the middle of the first half of each bit. 2) It adds a small delay to the end to avoid the first wait instruction interpreting the stop bit as a start bit when it loops around.

I will also make the other major change (add retries instead of giving up when a read fails). The other things I suggested require doing logic *during* reception of a byte, which is somewhat more tricky to implement within the timing constraints with the limited instructions set of PIO.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: New BMS for bq76PL455A based batteries

Post by Pete9008 »

OK, that makes sense, I'd assumed a Pico clock of 125M and forgotten that the bq76 bus ran that fast.

I'm guessing what is happening is that every PWM switch on the inverter is causing a noise spike that is interpreted as a start bit. The above and the CRC will help but the problem comes if a spike occurs within a byte period before a real message (if it is every PWM event then this is quite likely) as this will mean the real start is missed while processing the erroneous one. If it is possible to validate the start bit then I would do it, even if it is pretty crude (can you just rear 2-3 times and jump out the loop if it is set on any of them?). On the majority voting why not use the spare bits in the FIFO to read each bit 3 times and then do the validation in the C code?

Sorry to preach but I would try to use the sideset instruction to validate the sampling point on a scope. If been bitten numerous times in the past when instruction based timing hasn't worked quite as expected or sampling points have moved as a message progresses so now always physically check whenever possible. I'm assuming that the Pico is always one clock per instruction in the PIO which makes it much more predictable but...

BTW - do you use a debugger for the Pico? If so which one? I've bought a spare Pico as I believe you can use one as a debug interface but was wondering if there is a better way?
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: New BMS for bq76PL455A based batteries

Post by Pete9008 »

Just had a look at the JMP PIN instructions and given that you are already using it to sense the state of the Tx pin in the Rx routine you can't use it again to check the Rx pin, so the above suggestion for start bit validation check isn't going to work (unless you lose the Tx check and reject transmitted messages in software). Shame :-(
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: New BMS for bq76PL455A based batteries

Post by Pete9008 »

One other thought, you could possibly set an IRQ while transmitting and then do a WAIT 0 IRQ instead of the jump in the Rx routine. This would clear the JMP PIN instruction to be used for start bit validation.
Post Reply