I’m not using 6/7/8/11. However according to the PICO, 9 and 10 are available (on DevKit I’m making the assumption to use IO16/17 instead which are not available on the PICO)
I’m sticking to the recommended ports for SPI.
I was only looking to use 36 & 39 for an IRQ trigger (for touch and MCP chip). I can’t see any filtering caps on the reference design “esp32-devkitc-v4_reference_design”.
It might be easier just to pick one ESP32 design for ease - DEVKITC V4 wins for me on cost and availability.
Yes, it is understandable.
I was talking about something different. Not a replacement for a main shunt, but only for additional current measurement (like PV fields) an alternative for INA226/229, which could be an I2C AI extension + ACS758 current sensors.
Yes, it is still I2C, but it is the same as for INA226/229. And yes, it should be placed somewhere near the main board.
Maybe just make an I2C connection available for further extensions for enthusiasts if there are free pins left.
Understood, but in this case why not use the controller to talk to the charger and get the current and voltage measurements directly from it? Most (decent) charge controllers have some sort of communication interface.
Totally understandable. I haven’t seen a DevKit-C v4 board though, a lot of places are shifting to offer PICO-D4, WROVER and ESP32S2 based modules. Each have their own odd quirks which makes it interesting to work with. In my designs I opted for DevKit-C v3 (newest at the time) and TTGO-T1 as they share the same footprint on one side (TTGO-T1 is one pin shorter) and the second header is 2.54mm narrower on the TTGO-T1 so they fit in the same footprint. The TTGO-T1 also includes an SD slot on the bottom side and a 3D antenna like you see on the PICO-D4 typically.
The pins I shared are the defaults and recommended per datasheets for the ESP32.
Good catch! I did not see that 9 and 10 are available on the PICO, it is interesting that they shifted the functionality from those pins to 16,17. I’d recommend avoiding 16 and 17 if you can so that users can swap in a WROVER board with PSRAM.
It’s in the WROOM-32 datasheet in section 6, a 270pF cap from 36->37, 38->39. This is common on all Espressif produced boards and 37,38 are typically not exposed on third-party boards since these caps are inside the metal sheidling of the module. I know of only one or two third-party boards that expose these pins and the general consensus is avoid them, though having the two extra ADC1 pins would really be nice!
A bit overkill to use an ADC pin for that but it should work. Just be VERY careful with your ISR code, this is one area that causes a ton of issues for people moving to the ESP32 from other platforms (mainly AVR). The ISR handler should simply set a flag that you check in loop() or notify a task that runs in the background to do processing. In all cases, it must complete work within ~300usec otherwise it will trip the ISR WDT. I’d also suggest switch PIO to use the “esp32s2” branch of arduino-esp32 instead of the default v1.0.4 build that they are packaging now since this is planned as one of the next releases and it will help in the ISR code a bit.
Thanks for the feedback, I’ve no other use for any of the ESP ADC pins, and struggling with the amount of free pins. I’ll be using 34/35/36/39 as inputs.
I’ve modified the design to use MCP23017 (i2c) instead of the SPI variant. This has allowed me to move the IVR reset pin onto the MCP chip and free up 2 I/O for i2c usage.
It also means i2c is available on the board for interfacing with other components.
One word of caution with the MCP23017, if you are powering the chip with 5v and planning to use 5v on the IO pins you will also need the I2C side to be 5v which may cause damage to the ESP32. You can use a couple FETs to split the I2C bus into a 3v3 and 5v segment to protect the ESP32 or you can switch to a different IO expander. I switched from MCP23017 to TCA6416 since it offers split voltage (I2C at 3v3 and IO at 5v as example).
I’d suggest at least two spare I2C headers on the PCB for users to expand it. Depending on the above I2C bus voltage you may consider one being 3v3 and the other as 5v.
Of course, but that does not tell you about the people that did not pick DIYBMS. The soldering, programming, and mounting, is an enormous cost that someone with my use case won’t bother with.
My setup used to have an Electrodacus SMBS0, which did everything out of the box. I did not like it because it has an LCD and the wifi is in AP mode. There is really no excuse for me going down the DIYBMS path, except I wanted to design a circuit board. This has been a perfect way to get into it because I could copy your design, add a few simple things to it. It is mind blowing how much stuff you factor into these things and there’s no way I could have made something useful if I wasn’t able to copy 99%.
Well, yes, except the alternative is exactly the same, but with 16 boards all flopping around, and 16 fussy wires connecting them.
I agree that one starts to think about removing the redundancy, but I think that is a mistake. The separate design is desired by some, and the simplicity of software and instructions is huge if the individual and combined boards are identical in that respect. In other words, the modular design is the beauty of this system, and I think you should keep it.
I think it is important to understand that the balancing is a very low priority in my use case. I managed to fry 7 of 8 modules because I have not properly secured them. I just picked up the pack via the wires hoping the boards wouldn’t find a way to short. They did. I am totally befuddled as to how I managed to kill 7. I had 2 spares, so now I have 3 modules and I think one of them is on the highest cell. They aren’t doing any balancing. The balancing only makes my battery larger, which just does not matter. In the summer, I have plenty of solar. In the winter, the back up is to turn on the generator. This means that the 10, 20, 40% gain in capacity by having balanced cells just won’t be noticed unless I actually measure the capacity.
The module board now will cut back on the power when it gets too hot, right? Well, that’s fine with me. I don’t know what the Batrium can drain. The Electrodacus does not seem to do much at all. It never got warm.
I think I will make an 8x board. My plan is to copy/paste the pcb from the jlcpcb design, placing them side by side. Then I just connect the RX/TX. I’m tempted to use 2x ethernet connectors for the module’s power.
Sure, but how do you define success? More users? Less support? More variety of use cases? I think it is important to understand that right now, you probably have a self selected set of users that can take care of themselves. If you make an all in one board that is much more simple to deploy, you’ll get a lot more users, but they will be less able to figure the stuff out. That creates demand for simpler documentation.
Keep in mind that the Linux/Redhat model could work here. Someone, maybe me, for example, could buy, assemble, program, a 12-24v setup and resell to others and of course provide the technical support.
Yes, I agree. I think that the folders can be arranged to make the options more obvious. Having 2 branches, one for jlcpcb and one called “master” is inviting confusion. The branches are in a pull down, which is not obvious unless you’re familiar with git.
I suggest folders:
Modules
---- 1x hand soldering (1 per cell)
---- 1x jlcpcb (1 per cell)
---- 4x jlcpcb (12v)
— 8x jlcpcb (24v)
Controllers
etc
AllInOnes
etc…
That makes sense from some sort of marketing standpoint, but the board I made for myself can trivially have 8 relays of decent size, and 2 shunt measurements. So from a cost to make standpoint, there is no benefit to fewer relays or shunts. Again, it makes no difference if a user does not use them.
No, please, the cost of additional boards is high. The daughter thing is better than having to deal with wires, but still, the INAs are too dead useful for too many users. Again, the cost is $1.3 for each chip! This is squat compared to the headaches and confusion of an additional board.
I have not paid attention to the new board you are designing, so I apologize for being unable to help with the trade-offs. From skimming over this forum, I get the sense that you are putting in several other communication things to coordinate with other stuff. If I were you, that would be the area where more than one controller board would be available. My opinion is that if there was just one controller, it would be just like the current one, but have 8x relays (4x TLC222A) and 2x INA226. The optional controller would have more communication options. Again, I apologize for not really understanding the trade-offs.
I agree that daughter boards may be more expensive but there are benefits to exposing the I2C bus so allow secondary boards (like an INA breakout board) to be added. Similarly exposing the CAN/RS485/Display components as simply a pin header would be doable as there are breakout boards for most of these pieces available today, and most of these require extra components to be usable.
I’m saying put the INA on the controller board. If there’s just one controller board, then it should have 2x INA226, and 4x TLC222A for 8 relays. I’m saying do not relegate the INAs to a daughter.
It makes no difference that the INAs and relays are not wanted by some. Those extra unused chips will not bother anyone.
Regarding Stuart’s new controller, the LCD is the thing that I would NOT put on the controller. I have no problem with some header that one can connect a ribbon cable to an external LCD, but for those that don’t want an LCD, that LCD would be hard to ignore. The INA chips are easy to ignore.
Sorry, I don’t understand your numbers. With the 560ohmR, aren’t I getting 5.89mA? 3.3v right?
Also, the total watts if all 6 relays are on will be 116mW and the PCF8574 says it can drain 400mW, so I seem OK there too.
I am not suggesting a nS that is any different than n modules, just that they are on one board and thus are already daisy chained.
I don’t see why this would be any extra support. I am not suggesting you @stuart should make these variants.
The key to minimizing support question is obvious documentation. I am NOT saying “more documentation”. For example, the folder names and arrangement on git is poor. The existing 2 different module variants should not be separate branches, they should be separate folders. They should be under the folder named “Modules”, named “hand assembled” and “jlcpcb assembled”. The current name “circuit” is confusing. With that improvement, a folder named “8x Modules (single board jlcpcb)” would be pretty obvious in my opinion.
From my point of view exposed I2C connectors is a perfect solution. You need INAs, someone else need other functionality. There is a bus available - connect to it whatever you like - flexibility is always good. You have personally written that when it is about a couple of dollars price, then it is not a question for you, then why a daughter board suddenly is such an issue - a couple of dollars for a PCB boar + the same price for INAs?
I agree they are confusing, however as there is not documentation and videos on the subject I’m not radically going to change that. Perhaps on the next major release/update.
As I mentioned, its just a header, not mandatory.
What are people needing 8 relays for? What is driven through these?
The INA chips are fine, but again there are multiple variants of those depending on voltage measurement needed - do we install 48V or 36V etc. a daughter card would be useful in this scenario.
Likewise, should a change in measuring tech be needed in the future, the daughter card can be swapped out/upgraded without replacing the whole controller module/pcb.
You’ve still not mentioned how you are keeping the high voltage isolated from the 3.3v circuits.
Once you move into the “resell to others” it becomes a commercial decision, and currently that is prohibited by the terms of the licence applied to DIYBMS. Even if it’s not for profit.
Because the additional board is a lot more cost than the few bucks for the 2x INA. If you make the board by hand, that’s a ton of work. If you order it assembled from jlcpcb, it’s a minimum of $40ish, and if you do the “right thing” and resell them, that’s yet more work (find 4x buyers, find 4x boxes, get a stamp, etc).
Again, if the goal is more “sales”, the costs: soldering, wiring, mounting, programming, and extra boards from jlcpcb must come down. This is why I asked Stuart what is goals are. Maybe he does not judge his success by whether there are a lot of users, but if he does then there is no excuse to make a version without 2x INA and 4x TLP222A. Seriously, just imagine the support questions when someone finds out that they ordered the stuff and it does not do the most obvious functionality, providing state of charge?! The INA chips will measure state of charge on any system voltage when they are low side shunts.
If the goal is a lot of sales. Make a version that has 8x modules and 1x controller with relays and INAs all on one board, and allow someone to build and resell these. This will work for 12v and 24v systems. Every RV that puts solar and lithium will be a custom upgrade and thus this solution is ideal.
If you want to supply a 48v, then beg jlcpcb to stock the ina229, and make a 16x single board version.
for applications with multiple charge controllers switching off most of them during top balancing to reduce the charging current during balancing
In my application I would personally use 4 or 5 relays, depending on how much would be available, and it would always be nice to have at least 1 spare channel, just in case.
I completely support a daughter card, it is much more flexible solution. Modular system is usually better for further extensions, especially in DIY and hobby projects.