PLEASE NOTE: If you had an account with the previous forum, it has been ported to the new Genetry website!
You will need to reset the password to access the new forum. Click Log In → Forgot Password → enter your username or forum email address → click Email Reset Link.
And now there's heavy cloud so it's "not busy" and responding right away! lol I can't win.
I've just printed the bytes available. If the code sees less than 20 bytes it jumps out of the loop. I added code to print the available every time it enters and mostly all 0. So most of the time there is no data on the incoming uart. But when it does come back as non zero it's always 120. So it seems like it sending the six packets all back at once! If I turn the MSB off, then it comes back with 20 bytes every time. Turn the MSB on and it's 120 again!
This kinda points to absolutely lousy coding practices in the MakeSkyBlue MCU. They won't care--after all, us hardware hackers were not supposed to be doing this in the first place 😉.
Which would not surprise me at all. I've seen some Chinese-written source code, and it's unbelievably horrid. I can literally reduce the size of the compiled code by 25-30% (with a significantly less efficient compiler) while simultaneously adding boatloads of features.
I have been reading data from a 40A and 60A controller. The 60A has the usb port. I have had almost no issues with the 40A but the 60A is very inconsistent. My suspicion is noise either from the MSB itself and/or the inverter. I have changed to shielded cable soldered direct to the board on all 3 MSB's. Only 2 units are connected to the esp32 and the issue appears solved.
I only had my new solar shed running for a day before I've gone on leave so no idea how it has been operating. Not back for a few more weeks so will update then. FWIW, I had a similar issue with data logging on my BMS units. I was using long jumper wires and just wrapping in foil made them reliable.
I have changed to shielded cable soldered direct to the board on all 3 MSB's. Only 2 units are connected to the esp32 and the issue appears solved.
Worth noting that the serial lines are all ground-referenced, with no electrical isolation. This alone might play heavily into the issue, as the MSB FET switching will introduce noise into the ground lines. With multiple units in play, said noise can easily exceed the 1/2 VDD digital logic threshold levels--rendering communication rather difficult.
For a robust communication, I would recommend the use of a MAX232 (or SP3232 / equivalent) RS-232 level shifter on both ends of a comm line (i.e. on both the MSB and the ESP32). The level shifters would take 0-3.3v signals from the MSB and buffer them to +/-9v (or +/-12v) for transmisssion--and then drop them back to 0-3.3v signals for the ESP32. The large voltage swing on the cable makes the signals considerably more robust and stable over long thin wires--not to mention improved noise immunity.
In short: logic level serial signals are generally only good for on-board logic...not for the real world.
For a robust communication, I would recommend the use of a MAX232 (or SP3232 / equivalent) RS-232 level shifter on both ends of a comm line (i.e. on both the MSB and the ESP32). The level shifters would take 0-3.3v signals from the MSB and buffer them to +/-9v (or +/-12v) for transmisssion--and then drop them back to 0-3.3v signals for the ESP32. The large voltage swing on the cable makes the signals considerably more robust and stable over long thin wires--not to mention improved noise immunity.
While I agree this would be good practice... For my "short" lines I think it would be too much effort for little payback. now if the lines were going feet instead of inches then it might be worth it. For me, I can live with a 1 in 20 bad crc packet coming back from the MSB. I suspect it might be close to that ratio going back to MSB as well. The effort to make a mini PCB with a max232 on it (Maybe they have small modules already. I didn't look) for the MSB and mount it close to the MSB PCB and then another one for the ESP32 is more work than I want to put it.
But still good practice!
You guys might find this cool. Here is a small graph of the MSB power out with the MSB temp. The blue is MSB power the yellow is the MSB temp and the green is my extra fan that turns on when the temp goes above 45.
I added the extra fan because I was seeing weird behavior on the MSB at full power (possible resets). Once I added the fan, no more resets (if that's what it was) As you can see I really pushing my 60A really close to it's 2800W Max! 😄
While I agree this would be good practice... For my "short" lines I think it would be too much effort for little payback. now if the lines were going feet instead of inches then it might be worth it. For me, I can live with a 1 in 20 bad crc packet coming back from the MSB. I suspect it might be close to that ratio going back to MSB as well. The effort to make a mini PCB with a max232 on it (Maybe they have small modules already. I didn't look) for the MSB and mount it close to the MSB PCB and then another one for the ESP32 is more work than I want to put it.
You're right...for inches, it doesn't make much of a difference. I was writing that in response to @ellcon123, who it sounds has 2-3 MSBs connected to a single ESP32--and presumably a good length of wire in between each one.
Yes, they do make SP3232 micro PCB modules. YMMV as some people complain that they don't work reliably, etc., etc.--but I haven't had any issues with them.
Quick eBay search for SP3232 turned up these little cheap boards: https://www.ebay.com/itm/175211649099
notably different (improved??) from the ones I have.
Yes, I have 50~60cm of cable run. The 40A unit was always stable though.
Was away all of February but the off grid system was running with the 2 MSB 60A connected to the esp32. Unfortunately no data! While fiddling around I managed to turn on solar before battery and fried one MSB! It also killed the esp32. Need to sort out an interlock for that scenario.
For the past 2 days I've had another esp32 monitoring the sole MSB 60A and it's very inconsistent. I don't see any specific issue that may be causing this. Wifi signal strength is low so I'll try an external antenna to improve that. Then I'll shield the esp32 from noise as it's currently sitting loose next to the MSB. Am not doing any checksum as my coding ability isn't extending that far. Thus some of the gaps may be corrupt data being read.
If nothing works then just have to live with what data is coming through. Basic curve is correct as the batteries are full around midday. At 4pm I'm using the clothes drier so solar kicks in again.
Curve looks fine-ish if you have a partly sunny day... It's hard to tell with the graph you posted.
We might need to see more granularity in the graph. Mine jumps around too if the sun darts in and out of clouds.
Yesterday wasn't the best representation of this. but you get the idea..
<fileStore.core_Attachment>/monthly_2023_03/image.png.deb84690a0ffdf8e9fce6eacc1545aa7.png
Checksum is super easy... a couple lines of code..
char cksum = b2 + b3 + b4 + b5 + b6 + b7 + b8 + b9 + b10 + b11 + b12 + b13 + b14 + b15 + b16 + b17 + b18;
if (cksum == b20) {
myMppt.valid = 1;
} else {
ESP_LOGD("custom", "!!!Checksum Mismatch!!! Checksum calc 0x%X : reported 0x%X", cksum, b20);
I started messing with this a little more because I wanted to finally read the parameters I had set since I have
a hard time reading them with the app and I couldn't remember what I had set the bulk and float to.
Well I got that working... I also played with some of the other registers. One I was interested in was the AMPs.'
I swore I could NOT set this/ change this with the app before I added the MCU to read status. But for giggles I tried to
set this with protocol and WOW! It worked. I can, now, throttle the current if I want to!
Maybe you could have set this with the app and I just never got it to work... But I can now set it with my MCU.
😃
set this with protocol and WOW! It worked. I can, now, throttle the current if I want to!
Nice find!
...however, just one thing to keep in mind: if the current setting is "remembered" across power cycles, it very likely is stored in EEPROM/FLASH in the MSB's Nuvoton processor. (Yes, I know, EEPROM is usually rated for "1 million cycles"--but take that number with a large grain of salt. I wore out the memory on the first processor I started on, a Basic Stamp BS2P40...it started giving me verify errors after about 2 years of constant programming work. Definitely not a million writes!)
Which means that if the setting is changed a lot (could be as low as a few thousand times), you may start having issues with the MSB forgetting setup. Occasional changes will be fine--but be forewarned that processors can blow through a couple thousand writes in a fraction of a second!
While fiddling around I managed to turn on solar before battery and fried one MSB! It also killed the esp32. Need to sort out an interlock for that scenario.
Unfortunately, your best bet here will be electrical isolation. It's the most expensive solution, but it will ensure that MSB issues cannot fry your ESP32.
I'd recommend one isolator set per MSB. A quick check on eBay didn't turn up anything that would fit the bill "out of the box" (none of the ones I found had channels going in opposite directions, i.e. RX and TX), but it's not impossible to make with some PC817 optoisolators and resistors.
.however, just one thing to keep in mind: if the current setting is "remembered" across power cycles, it very likely is stored in EEPROM/FLASH in the MSB's Nuvoton processor.
It would be an interesting test to see if it's stored in EEPROM. My guess would be that it is since the bulk and float is.
The next question is... can we find out how many cycles the Nuvoton processor EEPROM is rated for..
Not that I'd ever have the ambition to do so... but I could see really throttling the current down if I'm top balancing my pack and a cell gets too high before the bulk voltage is met. I could see the MCU dynamically setting the current to keep the high cell from over Voltage-ing. I could see lots of writes which could kill the EEPROM if it's only in the 1,000s...
2 hours ago, Busky said:The next question is... can we find out how many cycles the Nuvoton processor EEPROM is rated for..
Like I noted above, just because something has a "typical" rating doesn't mean that it will actually be attained. Perhaps in labratory settings--but real life can often be something completely different (at least it has been in my experience).
From the datasheet: 20k cycles.
//content.invisioncic.com/g308908/monthly_2023_03/image.thumb.png.07ddf242e876a6955c20777955f44a6f.png
It doesn't appear to have EEPROM, just program FLASH. (EEPROM generally is rated 100,000 to 1 million cycles; FLASH can be as low as 1,000 and obviously as high as 20,000 here.)