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.
I also have a v118 40A msb without usb so will have to look at that in the coming weeks.
Older boards may have an optoisolator connection for an internal WiFi module--which are the same comm pins. I do have 2 of those "WiFi modules", so could provide pinouts of that IF your units match what I have photos of.
My previous posts were for a 60A v118 that I purchased this year and it uses the Bettsun mcu. This morning I swapped it with my other 60A v118 which I purchased 2021, maybe 2020. It has the usb but no actual connector soldered on! This uses the Nuvoton mcu.
No response when trying the gnd, tx & rx on the top left of the board. As per previous msb. I then traced the usb pins to an unpopulated header as per the photo. Connected these and it responds!!! Left pin is gnd, middle pin is connected to esp32 rx and right pin is connected to tx.
Hopefully the 40A msb will work but I now have my 3 ant bms's and 2 msb's in Home Assistant.
My previous posts were for a 60A v118 that I purchased this year and it uses the Bettsun mcu. This morning I swapped it with my other 60A v118 which I purchased 2021, maybe 2020. It has the usb but no actual connector soldered on! This uses the Nuvoton mcu.
I betcha they're both Nuvoton MCUs, and they started "white-labeling" to "Bettsun" to obscure the real MCU. Like China loves to grind the part number off the top of critical/strategic chips to make it much more difficult to identify them...
Success with 40A v118, built 2018. Lower pin is gnd, middle pin to rx & upper pin to tx.
Backside of the board is a giveaway.
FWIW, I now have my 3 MSB's connected to 1 esp32 (only has 3 uarts) within Home Assistant. It just loops and reads 1 MSB per cycle so update is ~ every 10s.
I've noticed an oddity with my logging. I recently wanted to add a separate fan to blow on the controller when it gets really hot. So I was going to muck with my code to publish the MSB temp so I can turn on a fan. Well in playing with this I noticed it's take a very long time for the MSB to respond with the status. About 20 seconds. Now this only happens when it's going full mppt! If I turn the MSB off, then it seems to respond right away. Now I haven't put a scope back on to see if I'm missing anything back from the controller. But it's pretty consistent in the range it takes to respond.
Has anyone seen this?
So my poling goes something like this:
My esphome update interval is set to 300ms for transmit.. Every 10 of those I send the 0x55 command to request. So I am requesting data about every 3 sec.
My read poling is every 100ms. Where I check for uart data.
I'm getting nothing until after I send the 0x55 command about 6 times. I'm timing the response time from the last response and it's 17-20 seconds.
I really hate the way I wrote this code and I'd love to re-do it... but that's low on my list.
Has anyone seen this?
Jim
As the sun started going down... I was getting faster responses.. I really think it's internal noise on the uarts when the internal mosfets are firing!! I think it's not getting the requests with correct checksums and just the brute force of sending so many 0x55 packets, one gets to the uart clean enough that it sees it as a valid request.
And when the Mosfets aren't going so crazy when the sun is less, the packets are more likely to go through.
As the sun started going down... I was getting faster responses.. I really think it's internal noise on the uarts when the internal mosfets are firing!! I think it's not getting the requests with correct checksums and just the brute force of sending so many 0x55 packets, one gets to the uart clean enough that it sees it as a valid request.
Very likely what's going on.
How long are the wires between the MSB and your logger?
Also, do you have any DC ground potentials going on here?
Very likely what's going on.
The wires are no more than 6 in. And there is only one ground coming from the MSB to the esp32. I might have to do some creative shielding if it gets really bad. I don't know if it's on the module itself or in the connections to the controller.
For all I know it's getting these bad packets even with the Wi-Fi controller when it's firing away! It's strange. It's somewhat consistent in the amount of retries it takes. But the amount of tries it takes is less when less power is going through the controller.
Sid, It's very strange..
When the MPPT is "busy" it take about 6 sends of the 0x55 packet. It doesn't seem to matter how often I sent the 0x55 packet. If I send it every 3 sec.. It take about 6 packets. If I sent every 1.5 sec it take about 6 packets.
If I send every 600ms it takes about 6 packets. So I'm wondering if maybe the MSB uart has to come close to over flowing the uart and send an interrupt to the micro to finally process it. where as when it's not busy, it has time to check the uart process immediately??
I also thought maybe the ESP32 isn't sending right away and it's waiting for a full buffer before it sends. But that doesn't make sense why the MSB responds right away when it's non busy?
So maybe it's not really bad CRC to the MSB micro?
Everything is mounted so I don't really want to tear it down to put a scope on the lines. but now this is bugging me! 🙂
So I'm wondering if maybe the MSB uart has to come close to over flowing the uart and send an interrupt to the micro to finally process it. where as when it's not busy, it has time to check the uart process immediately??
From a microprocessor hardware perspective, this would not be the case. Generally speaking, MCUs have a 2-level buffer...in other words, if more than 2 characters are received without being read, it starts losing characters. Anything more than this is completely software-created.
I also do not see why the MSB MCU should be any more "busy" when more power is being handled. All of the PWM outputting should (!) be handled with the PWM modules...so all the MCU has to do is tell the PWM modules what output duty cycle is desired.
I'm not sure if you're sending any "state control" commands--because if so, it's possible that the MSB MCU is getting "out of sync" of the serial stream. Remember where earlier on I shared a "state control" command, which had a non-standard blank space in it? If this is blank space is omitted, it's highly probable that that's messing things up.
If you are using "state control commands" on a regular basis in your code, I'd suggest removing those--and see if it makes any difference.
Obviously, as there is no "official spec" for these things, we're kinda hacking pioneers 😉
Everything is mounted so I don't really want to tear it down to put a scope on the lines. but now this is bugging me! 🙂
Understood...though I can't help but wonder if interference is the issue.
From a microprocessor hardware perspective, this would not be the case. Generally speaking, MCUs have a 2-level buffer...in other words, if more than 2 characters are received without being read, it starts losing characters. Anything more than this is completely software-created.
Yeah I don't think this is the case either. I sent some other 0x33, 0cCC to "fill" the buffer and that did nothing.
QuoteIf you are using "state control commands" on a regular basis in your code, I'd suggest removing those--and see if it makes any difference.
No the only thing I'm sending is the 0x55 packet.
QuoteUnderstood...though I can't help but wonder if interference is the issue.
I thought so to at first but it's just too regular that at the 6th packet it responds. Occasionally it take 5 packets and occasionally it takes 7
Now it's bugging me. I should be doing my day job right now! 😄
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!
So something weird is going on. I have a 40A version that I may setup and test what's going on!!!
But for now I'll just live with the weird behavior! 🤷♂️