Shunt - Controller: no comms -> SOLVED MAX3485 is NOT compatible with SN65HVD75, DO NOT USE!

[virtuvas]

after a lot of trouble getting a shunt ready and lots of resoldering to get it to actually work I now have the following:

shunt when connected to bank (V+ anv VSense to V+, GND to V- of the bank):

• I get the 5 red / 6 green fast blinking all right and consistently.

Shunt connected to Controller:

• I get 4.95V between the UPDI V+ and GND which drops to 4.92 when the red or green leds flash (that is on a 24V bank)
• I get 4.95V coming from the Controller board alright as well.
• I get 0.2V from A or B to GND, don't know if I should if it's good or bad

I also checked continuity on the Controller between all the 8pins of the 485 chip [says MAX3485 ESA 125] and where they should all go, the terminator, the links to A B terminals and ESP32 pins, all are fine.
I also did the same on the Shunt side between the relevant pins of the ADM2483 BRWZ and all seems fine. Also loosely checked the other side of the chip power/gnd to the ATTiny and the INA228, all is fine.

However, when I wire them together (even checked the 40cm long bus cable leads one by one!) I get nothing on the webinterface. I believe the settings I have are fine, mind I've not wired the address jumpers at all:

I have the usb->RS485 cable that came with the (dead) aliexpress shunt, any ways to test via this either sides to figure out what's wrong?

looking for ideas!

V.

[stuartpittaway]

Using the USB cable you should be able to connect it directly to the shunt.

Then download some sort of Modbus scanning tool for your PC.

[virtuvas]

thanks Stuart, that was easy :-)

aliexpress usb thing identified as com9, setup as you've recommend. Nothing comes nothing goes. Not quite sure what I'm doing there, but seems that I've asked the s/w to read lots of registers, reply is no response to poll. 5V on the V+ GND pins, and 2.2V between either A or B and GND (on the shunt board that's only 0.2V - is that a clue I wonder!)

If I may ask more specific Qs, in theory, shouldn't even with out the INA and LM chips onboard ( I mean that's the ones that I MAY have some problems soldering...) the thing report values at least communication between the shunt pcb and the controller? The ADM2483 BRWZ chip is powered on both sides, ATTiny is obviously working as I get the 5/6flashes, legs on ADM chip are not that bad, I've gone through them a couple of times, must be good, I wonder what could I be missing?

cheers

V.

[stuartpittaway]

Do you have the termination resistors in place? 120ohm each end

[virtuvas]

I have the resistor on the shunt side 120 Ohm just rechecked. I assumed the USB side had one, measured it (with cables disconnected, nothing, so added one. Same result :-(

Can I use this usb thing connected to the controller to establish that at least it does work? Or is there a danger of destroying something (the RS485 chip fe) on the controller? could I have a bogus ADM chip? Came from CN (iirc have to check)

V.

[stuartpittaway]

On the Modbus tool, the device address should be 90. Also make sure you have the correct baud rate settings. 19200 etc.

[stuartpittaway]

On the shunt, is the led flashing every 5 seconds?

[virtuvas]

5red then 6green fast and after circa 7secs the 5red start. I guess from green stopping and red starting again it is indeed circa 5sec. Is that what you mean?

[virtuvas]

updated the tool, now does scanning for devices, nope, cannot see it.

[stuartpittaway]

Ok, that flashing light sequence is wrong. From memory I think the attiny cannot find the ina228 chip, or its got a reply from it which was incorrect.

You won't get any Comms until that problem is fixed.

[virtuvas]

hm, so it must be five sec from the first red flash to the next round of red flashes instead of the eight secs I have now? I reread what I typed before and I think it's slightly ambiguous. Took a video to measure with a bit more accuracy. What it does is: 3secs for red/green flashing, 5secs no lights, then 3secs red/green flashing again and loops over. so the blank gap is 5secs but the loop duration is 8. let me know so that I can find someone younger to help resoldering the INA for a fourth time!

cheers

V.

[virtuvas]

https://user-images.githubusercontent.com/17377407/160296514-0478e7d9-37b4-4165-a889-f069d47c601c.mp4

[stuartpittaway]

Take a look at this link/code. It maps what the different light sequence means.

https://github.com/stuartpittaway/diyBMS-CurrentShunt/blob/90cb666cb36d2663e0d77a068723fdb67bc0efd3/Code/diybmsCurrentShunt/src/main.cpp#L71

[virtuvas]

thanks, rather confusing, but went ahead and built a second shunt board :-) now, programmed it fine (came up with the 5red/6green), wired it up and first of all my PC prog identified it as a RS485 modbus device at 90. Wired it to the controller, I get a rock solid 5.01V (on my Uni-T cheap meter) on the UPDI pins and a different flashing pattern:

• dim red flashes every 2sec
• normal green flashes every 5sec.

catch is that still controller is not happy and on basic settings Values valid? is still false, rest all zero. Now, evaluating my hot air gun soldering, the INA on this second board is much cleaner, but the LM is really poor. Will try again the INA chip on the first board see what I can manage...

[stuartpittaway]

Ok, that sounds more promising. The red flash every 2 seconds is the current monitor ATTINY chip taking a reading from the INA228.

The green flash every 5 seconds, is the ATTINY receiving a request from the controller - so some communication must be happening!

Can you see what the controller debug/serial port is outputting ?

Which controller code are you using here? The new one or the one from master?

[virtuvas]

ah, I'm using the NOV2021 code as per all the other changes re influx. btw, system was v.stable managed 7days (haven't managed that before in the three months of testing!)

I (43182) diybms: Task 1
I (44981) diybms-webreq: API call: monitor2
E (45931) diybms: Short packet 0 bytes
I (47336) diybms: Influx task
I (47395) diybms-influxdb: HTTP Client Connected!
I (47580) diybms-influxdb: HTTP Client finished
I (47580) diybms-influxdb: Successful
I (47581) diybms-influxdb: HTTP Client Disconnected!
I (49098) diybms-webreq: API call: monitor2
I (49682) diybms: Task 2
E (50931) diybms: Short packet 0 bytes
I (52587) diybms: Influx task
I (52647) diybms-influxdb: HTTP Client Connected!
I (52821) diybms-influxdb: HTTP Client finished
I (52822) diybms-influxdb: Successful
I (52822) diybms-influxdb: HTTP Client Disconnected!
I (53205) diybms-webreq: API call: monitor2
E (55931) diybms: Short packet 0 bytes
I (56182) diybms: Task 3, s=0 e=7
I (57312) diybms-webreq: API call: monitor2
I (57828) diybms: Influx task
I (57886) diybms-influxdb: HTTP Client Connected!
I (58072) diybms-influxdb: HTTP Client finished
I (58073) diybms-influxdb: Successful
I (58073) diybms-influxdb: HTTP Client Disconnected!
E (60931) diybms: Short packet 0 bytes
I (61422) diybms-webreq: API call: monitor2
I (63079) diybms: Influx task
I (63139) diybms-influxdb: HTTP Client Connected!
I (63330) diybms-influxdb: HTTP Client finished
I (63331) diybms-influxdb: Successful
I (63331) diybms-influxdb: HTTP Client Disconnected!
I (65527) diybms-webreq: API call: monitor2
E (65931) diybms: Short packet 0 bytes
I (68338) diybms: Influx task
I (68394) diybms-influxdb: HTTP Client Connected!
I (68586) diybms-influxdb: HTTP Client finished
I (68587) diybms-influxdb: Successful
I (68587) diybms-influxdb: HTTP Client Disconnected!
I (69182) diybms: Task 1

is it the short packet 0 the problem? don't remember seeing it before

cheers

V.

[stuartpittaway]

Yes, thats the problem. Its not getting a reply.

[stuartpittaway]

I've just fired up my controller and current shunt using the NOV2021 release - all working as expected, so the code looks good.

[virtuvas]

slightly confused (again!) the no reply from the shunt to the controller is due to an error in soldering which chip? got any hints? on today's board, I'd guess LM is to blame (no time to work on it now, willdo at night)

cheers

V.

[stuartpittaway]

I'm guessing this is an RS485 issue.

On controller, check U5/SN65HVD75DR (make sure JP4 is soldered closed).

Check that you have connected pin 1/2/3/4 of the screw terminal to the same terminal on the current monitor 1/2/3/4.

On the current monitor, check pins around the ADM2483xRW chip, and also pins 6,7,8,9 of the ATTINY.

The current monitor already has the 120ohm termination resistor installed, so don't add another one.

If the LM5009A was at fault, you won't get any power to the board, so the LED's won't work.

[virtuvas]

yeah right...

Controller U5 is NOT an SN chip but a MAX3485 :-( I guess back in Dec there was no stock on Mouser and ordered this instead. Reading the specs I'm not quite sure it is good enough. Wonder if you have any experience on that Stuart. sorry,

TCA/PCA trick worked, I'm afraid this doesn't (at least as is!)

the rest of your points regarding the shunt pcb, are tested and OK

V.

[stuartpittaway]

Ok. I've not used that particular chip, is it the same pin out and does it support 5V operation?

[virtuvas]

yes and yes https://www.farnell.com/datasheets/2002060.pdf

I can see that MAX3485 has guaranteed data rate 10Mbps whereas the SN65HVD75 says "up to 20Mbps". Doubt we are running at such speeds!

Slightly confused on the pin 1, 2, 3 functions [p6 of the linked datasheet]:

-pin1 [RO]: Receiver Output. If A > B by 200mV, RO will be high; if A < B by 200mV, RO will be low -pin2 [RE]: Receiver Output Enable. RO is enabled when RE is low; RO is high impedance when RE is high. If RE is high and DE is low, the device will enter a low-power shutdown mode. -pin3 [DE]: Driver Output Enable. The driver outputs are enabled by bringing DE high. They are high impedance when DE is low. If RE is high and DE is low, the device will enter a low-power shutdown mode. If the driver outputs are enabled, the parts function as line drivers. While they are high impedance, they function as line receivers if RE is low

thing is I cannot find anywhere close such a chip (only CN - see two months!) nor can I find any small board to cannibalise.

V.

[virtuvas]

good morning,

resoldered the INA on the first shunt board, now got another led flashing pattern: red flashing brightly (not dim) every two secs then five secs and then two/five again green off all that time every three/four such red loops both are on for 3-4secs and then a bit of panic flashing before resorting to above pattern.

needless to say controller still reports:

diybms: Short packet 0 bytes

https://user-images.githubusercontent.com/17377407/160564365-9d857535-8aec-4629-824a-09ceb595da1e.mp4

next step is resoldering the LM on the second board hoping I'll get the same (hopefully right!) behaviour on both shunts while waiting for a solution on the RS485 chip!

cheers

V.

[stuartpittaway]

On a "normal" power up, the RED LED may flash 5 times - which indicates a factory reset/first time power up.

Then, you should get 5 GREEN flashes.

The slow RED flashes you have on the video seem strange, very slow compared to what I would expect.

Perhaps try using the "Set Fuses" option in platform.io in case the CPU frequency is wrong.

[stuartpittaway]

Looking at the SN65HVD75DR vs MAX3485, I can't see any fundamental differences, so that should work okay.

They both have the same pin out and run at 3.3v.

[virtuvas]

On a "normal" power up, the RED LED may flash 5 times - which indicates a factory reset/first time power up.

It does so if I unplug the lot and with Controller off power (but wired to the shunt) I power up the shunt (connect it to + of battery bank) Then it will do a 5 REDs

Then, you should get 5 GREEN flashes.

well had to video the boot sequence and load it to Adobe Premiere as green flashes much faster and wasn't sure. So exact pattern measured to 1/30th of a sec from the video frames are: cold boot: 2sec for 5RED flashes 1sec for 6GRN fast flashes .8sec RED on (RED flash is always .8sec wont type that below for clarity) 4.8sec OFF RED on 2sec OFF RED on 4.8sec OFF RED on 2sec OFF RED on 4.8sec OFF RED on 2sec OFF RED on 4.8sec OFF RED + GREEN ON for 8secs 1sec OFF 1sec for 3RED flashes 1sec for 6GRN flashes then the loop with 4.8/2 sec of RED flashing goes back on. So loop duration is circa 45secs

https://user-images.githubusercontent.com/17377407/160608873-a28d70b0-6788-4218-93c5-ccd63148dc01.mp4

FWIW, checked again with Controller running and connecting the shunt power afterwards. I get exactly the same sequence only 4 RED flashes instead of 3 after the 8sec both on. BTW, the 3 and 4 red after the 8sec both on, could actually be 4 and 5 as it seems that at the end of both on red does a bit of flashing which could count as one more flash on both...

The slow RED flashes you have on the video seem strange, very slow compared to what I would expect.

Perhaps try using the "Set Fuses" option in platform.io in case the CPU frequency is wrong.

ATTiny on Shunt frequency? Not familiar with that, do you mean to uncomment the 3 fuse lines in builtscript.py?

#    efuse=hex(int(env.GetProjectOption("board_fuses.efuse"), 2)).upper()[2:4]
#    hfuse=hex(int(env.GetProjectOption("board_fuses.hfuse"), 2)).upper()[2:4]
#    lfuse=hex(int(env.GetProjectOption("board_fuses.lfuse"), 2)).upper()[2:4]

BTW, haven't had any luck compiling the shunt code, got lots of errors on main.cpp. Can compile the controller code with no issues though.

I apologise as I feel I'm wasting your time Stuart with all my odd errors!

cheers

V.

[stuartpittaway]

You don't need to compile the code - although you shouldn't see any errors as platformio should drag any dependencies in automatically.

Just use the pre-compiled release version from GITHUB.

On the flashing lights - ignore the initial flashes, the slow red single flash is the one reporting an error.

1x Flash means it cannot communicate with the INA228 chip.

[virtuvas]

thanks once more Stuart,

checked on both boards the LM chip pin by pin (from the top of the chip with a needle) to where it should be linked. All fine checked INAs, both boards crap. Especially confusing the fact that BusVoltage (pin8) has continuity on INA with pin9 and 10. I wonder if I'm missing something. There were problems on the 3-5pins but I unsorted them. Managed to redo the one I believe successfully, wired it up now no reds, but SIX Greens every 8secs (from first flash of six to the next first flash, so really 1sec flashes, 7secs quiet). Got mildly excited, but controller still says:

diybms: Short packet 0 bytes

any clue why I get this sixth flash? BTW, the code you linked earlier is quite clear on red codes, need to search for the greens and it's a bit confusing/difficult to follow

V.

[atanisoft]

need to search for the greens and it's a bit confusing/difficult to follow

Green blinks usually indicates that it is reading from the INA or received a ping over RS485. I'd suggest double check the RS485 IC on both controller and shunt to ensure 100% that all pins are correct.

[virtuvas]

thanks for all the pointers,

have two controllers and two shunts to play. Gone through all the relevant (and not so relevant!) pins checking continuity to where they should end up, INA -> ATTiny -> ADM, LM etc. All terminals are fine and routed properly. After removing/reflowing with hot air both LM and INA chips a few times and checking them over v.carefully (got 20yo son to check pins as well) I now am at a stage where I get on both setups: 1 dim RED flash every 2secs and 1 strong GREEN every 5secs

single RED according to the doc Stuart pointed yesterday is err_INA228Missing. Unless I've destroyed them both, that's impossible as all pins definitely route where they should, good continuity, no shorts (checking always each point to the pins around it for good measure) I'm reflowing at 380-390C, v.low airflow, no need for more than 15-20secs at 30-40mm. Same approach I followed for the TCA/PCA chips with no issues. Mind it's not normal bright flash as previously on various errors (or as it does the 5 flashes when booting) it's a v.dim one, dim as a result of circa 1/4 of the duration of the normal flash (1/30th sec vs 4/30ths for normal flash). I'd hope it implies something else and not INA comms issues as it's difficult to justify it in two pcbs.

also checked the MAX RS chip on both controllers, terminator, wiring, all's fine.

Leaving aside the case I've killed the INAs, I'm thinking that the MAX RS485 may be the culprit. btw, I just noticed this on the boot up sequence:

               _          __
  _|  o       |_)  |\/|  (_  
 (_|  |  \/   |_)  |  |  __)
         /

CONTROLLER - ver:LocalCompile compiled 2022-03-18T14:10:52.591Z
ESP32 Chip model = 1, Rev 1, Cores=2, Features=50
I (35) diybms-hal: Configure I2C
I (38) diybms-hal: Scanning i2c bus
I (43) diybms-hal: Found i2c device at address 0x20
I (47) diybms-hal: Found i2c device at address 0x38
I (56) diybms-hal: TCA6416A not fitted, assume v4.2 board
I (57) diybms-hal: Found TCA9534A
I (58) diybms-hal: Found TCA6408
I (61) diybms: ** Controller changed state from Unknown to PowerUp **
[    72][E][esp32-hal-gpio.c:95] __pinMode(): Invalid pin selected
E (73) gpio: gpio_set_level(226): GPIO output gpio_num error
[    83][E][esp32-hal-gpio.c:95] __pinMode(): Invalid pin selected
E (84) gpio: gpio_set_level(226): GPIO output gpio_num error
[    94][E][esp32-hal-gpio.c:95] __pinMode(): Invalid pin selected

Press SPACE BAR to enter console WiFi configuration....

....................

No key press detected
I (5452) diybms-hal: CAN driver installed.  Filter=1621098496 Mask=6291455
I (5453) diybms-hal: CAN driver started
I (5455) diybms: LittleFS mounted, total=589824, used=12288
I (5458) diybms: Mounting SD card
I (5470) diybms: SD card available
[  5475][D][settings.cpp:20] ReadConfig(): ReadConfig diybmswifi
[  5478][D][settings.cpp:42] ReadConfig(): checksum verified
I (5475) diybms: Checking for /diybms/wifi.json
I (5500) diybms: Wifi JSON config is identical, ignoring
I (5501) diybms: Fetch config
[  5505][D][settings.cpp:20] ReadConfig(): ReadConfig diybms
[  5512][D][settings.cpp:42] ReadConfig(): checksum verified
I (5513) diybms: ** Controller changed state from PowerUp to Stabilizing **
I (5629) diybms: Hostname: DIYBMS-004CE8AC
I (5629) diybms: TFT screen is INSTALLED
W (13018) diybms-victron: active_errors=0
I (13530) diybms: got ip:192.168.178.101
I (13530) diybms: Request time from time.google.com
I (13556) diybms: You can access DIYBMS interface at http://DIYBMS-004CE8AC.local or http://192.168.178.101
W (14220) diybms-victron: active_errors=0
I (15022) diybms-rules: Set error 4
I (15023) diybms: Active errors=1
I (15023) diybms: Set relay 2=1
I (15024) diybms: Set relay 3=1
I (15025) diybms-tft: Wake up screen
W (15420) diybms-victron: active_errors=0
W (15453) diybms-webfuncs: Incorrect cookie received RVt#4tXvnuB79mmF3S@j
I (15491) diybms-webpost: JSON call
W (15492) diybms-webfuncs: Incorrect cookie received RVt#4tXvnuB79mmF3S@j
W (16620) diybms-victron: active_errors=0
E (17268) diybms: Short packet 0 bytes
W (17500) diybms-webfuncs: Incorrect cookie received RVt#4tXvnuB79mmF3S@j
W (17820) diybms-victron: active_errors=0
I (18025) diybms: ** Controller changed state from Stabilizing to Running **
I (18026) diybms: Set relay 2=0
I (18027) diybms: Set relay 3=0
I (18519) diybms: Task 1
W (19598) diybms-webfuncs: Incorrect cookie received RVt#4tXvnuB79mmF3S@j
W (21622) diybms-webfuncs: Incorrect cookie received RVt#4tXvnuB79mmF3S@j
E (22268) diybms: Short packet 0 bytes
I (23679) diybms-web: default.htm
W (23852) diybms-webfuncs: Incorrect cookie received RVt#4tXvnuB79mmF3S@j
E (23860) httpd_txrx: httpd_resp_send_err: error calling setsockopt : 22
I (24492) diybms-webreq: API call: monitor2
I (25019) diybms: Task 2
E (27272) diybms: Short packet 0 bytes
I (28710) diybms-webreq: API call: monitor2
I (31519) diybms: Task 3, s=0 e=7
E (32269) diybms: Short packet 0 bytes
I (32827) diybms-webreq: API call: monitor2
I (36937) diybms-webreq: API call: monitor2
E (37269) diybms: Short packet 0 bytes
I (41045) diybms-webreq: API call: monitor2
I (42026) diybms: Influx task
I (42234) diybms-influxdb: HTTP Client Connected!
E (42269) diybms: Short packet 0 bytes

are the following lines worrying?

[    72][E][esp32-hal-gpio.c:95] __pinMode(): Invalid pin selected
E (73) gpio: gpio_set_level(226): GPIO output gpio_num error
[    83][E][esp32-hal-gpio.c:95] __pinMode(): Invalid pin selected
E (84) gpio: gpio_set_level(226): GPIO output gpio_num error
[    94][E][esp32-hal-gpio.c:95] __pinMode(): Invalid pin selected

cheers

V.

[atanisoft]

are the following lines worrying?

[    72][E][esp32-hal-gpio.c:95] __pinMode(): Invalid pin selected
E (73) gpio: gpio_set_level(226): GPIO output gpio_num error
[    83][E][esp32-hal-gpio.c:95] __pinMode(): Invalid pin selected
E (84) gpio: gpio_set_level(226): GPIO output gpio_num error
[    94][E][esp32-hal-gpio.c:95] __pinMode(): Invalid pin selected

Those lines can safely be ignored. I believe they are coming from the TFT library trying to reinit SPI.

I now am at a stage where I get on both setups: 1 dim RED flash every 2secs and 1 strong GREEN every 5secs

I believe this is normal. The red blink is when it is talking to the INA chip and the green is when it receives an RS485 packet.

single RED according to the doc Stuart pointed yesterday is err_INA228Missing.

It would only emit the single red blink in that case as the method which handles the blink doesn't exit, it will remain in the blinking pattern until reset.

I'm thinking that the MAX RS485 may be the culprit.

Very possible, which exact MAX chip did you get?

[virtuvas]

thanks Mike, good to know that the shunts are most likely OK! I was getting disappointed for not being able to solder two ICs on a board :-)

I have MAX3485 on the Controller board: https://www.farnell.com/datasheets/2002060.pdf

from an earlier post to Stuart:

I can see that MAX3485 has guaranteed data rate 10Mbps whereas the SN65HVD75 says "up to 20Mbps". Doubt we are running at such speeds!

Slightly confused on the pin 1, 2, 3 functions [p6 of the linked datasheet]:

-pin1 [RO]: Receiver Output. If A > B by 200mV, RO will be high; if A < B by 200mV, RO will be low -pin2 [RE]: Receiver Output Enable. RO is enabled when RE is low; RO is high impedance when RE is high. If RE is high and DE is low, the device will enter a low-power shutdown mode. -pin3 [DE]: Driver Output Enable. The driver outputs are enabled by bringing DE high. They are high impedance when DE is low. If RE is high and DE is low, the device will enter a low-power shutdown mode. If the driver outputs are enabled, the parts function as line drivers. While they are high impedance, they function as line receivers if RE is low

couldn't really find a similar explanation of the operation of these pins on the SN65, what's more worrying is that I'll have to order from CN, so circa 2months and I was hoping to move the battery bank to the boat soon (like this week!) :-(

cheers

V.

[stuartpittaway]

I'm sure the rs485 chip is ok.

So you have got to a good point. A small red flash every 2 seconds is normal and means it's reading the ina228 chip.

The green flash every 5 seconds means it's receiving a request from the controller which is good.

What you now need to do is to follow the path back from the current monitoring board into the controller. It could be a fault on the controller side.

[virtuvas]

good point Stuart, struggling to find what I may be missing though as RS485 looks fairly independent path/pad ways...

the RS485 chip on the controller is just 8pins, gone through both controller boards pin by pin to the ESP32 IO21,IO22,IO25, all fine. Checked GND and 3V3, fine, measured voltage when board is up and running, 3.29V checked A and B and the 120 Ohm resistor, fine going all the way to the terminals. so looks like resistors/terminals/power/comms to ESP32 are OK.

The fact that the shunt board "receives" something (green led) every 5sec is I guess good. Tried undoing and swapping A B (just in case!) green stopped flashing every 5secs, so that looks right as well. fwiw, tried again all 2X2 combos exact same behaviour.

I cannot see any other thing to check on the controller unless something odd happens within my two different ESP32 chips. Have posted a pic of them in an earlier thread as you thought they may not be compatible, but I think you concluded they are fine:

doubt I've missed proper soldering of one of the pins on both chips (sockets continuity is checked!)

having replaced both TCA chips with their PCA counterparts, hasn't created any issues elsewhere. Wonder if they may have some effect on the RS485 protocol instructions or whatnot, but tbh I think it's far fetched.

Also wonder if I could drop baud rate for testing? I've not got any switch/jumpers on the two set of BAUD/ADDRESS pads on the shunt board. I have 19200/8/none/1 (default values) on the web interface. Any point in testing anything there?

Else I guess I'll have to look at the s/w side of things (if I can...)

cheers

V.

[stuartpittaway]

Double check the pin out of the ESP32 you have just to make sure. The pin out should conform to espdevkit-c footprint.

No point in changing the baud rate.

Do you have access to an oscilloscope?

[virtuvas]

well IO21, IO22 & IO25 are in the same places, haven't checked all the rest. will do at some point tonight.

I have a cheap oscilloscope (20quid from CN) https://www.youtube.com/watch?v=7IonDhAPvY0&ab_channel=RuiSantos could possibly do simple tests given the right instructions (keep in mind I'm not a computer scientist/electronics engineer!)

V.

[virtuvas]

OK, got my oscilloscope running, tuned it (loosely so that it shows giggly lines when the green led flashes on the shunt: cables from osc goes to either A or B and GND of Controller board atm. 1-2V, DC, 10-20ms are the current settings that produce something hopefully meaningful for you. A and GND:

B and GND:

I guess the idea is to try and find if there's something going from the shunt back to the controller, right? I also guess that what the osc is picking is the signal going from the controller to the shunt (as it coincides with the green led flashing) waiting for instructions!

[stuartpittaway]

Rather than looking at the RS485 data (which is difficult to decode), probe the TX/RX pins on the ESP32 and the ATTINY chips to ensure that data is being sent/received.

When the green LED flashes on the current shunt, you should see a TRANSMIT occur from the ATTINY back to the ESP32

[virtuvas]

thanks,

Shunt ATTiny TX and GND: similar graph on RX and GND, guess you don't want that. So looks like it's transmitting something which is a split sec after the green led flash on the shunt.

On the ESP32, I'm afraid I need some help, which pin is TX and which one is RX??? are we talking about VSPI_MOSI & MISO? If so, picked them up from J8 pin 1 and 4? J8 pin1 to GND:

similar output on MOSI and GND (just inverted)

FWIW, these are every 15secs and NOT related to the green led flashing on the shunt. makes sense?

V.

[virtuvas]

trying to find more info on these boards I have, I came across this: https://testzdoc.zerynth.com/reference/boards/nodemcu_esp32/docs/img/nodemcu_esp32_pin.jpg which mentions that ADC from pin D25 can only be read with Wifi OFF, guess not to worry?

generally wonder to what extent I may be facing issues due to my NodeMCU ESP32S vs the ESP32-DEVKITC

[atanisoft]

that ADC from pin D25 can only be read with Wifi OFF, guess not to worry?

That is likely not applicable as the BMS doesn't read any analog values from any pin last I checked. A short explanation on the ADC + WiFi issue is that the WiFi phy uses ADC2 (used by pin numbers below 30) which can conflict with user code trying to use ADC2 concurrently. When WiFi is enabled ADC1 (pins 33-39) are the only reliable ones. This limitation was fixed in other variants of the ESP32 chip (ESP32-S2/S3/C3/C6/H2/etc)

[virtuvas]

thanks Mike, was wondering if I should try and get a definitely tested and approved ESP32 chip - especially as I could get that within a week which is definitely not the case for the SN65HVD75DR chip which is nowhere to be found in the EU...

is that anygood? https://grobotronics.com/esp32-development-board-esp32-devkitc-32d.html

[stuartpittaway]

@virtuvas you need to look at ESP32 pins IO21 (RS485 RX) and IO22 (RS485 TX) you can also check IO25, which should go high/low during a transmission.

Assuming a valid signal is getting to the current monitor, IO21 is a likely candidate for a problem.

[virtuvas]

well, unfortunately (or fortunately!) all three pins respond to green led flashing, the following is IO21 the receiving end...

https://user-images.githubusercontent.com/17377407/161062142-5636af13-b767-4234-b02a-289acd50593d.mp4

behaviour of the others is similar. Edit to note that IO22 signal duration is 1/5 or less to the IO21 and it's up/down a few times, whereas IO25 is a plain square wave the size of IO22.

So, if I got that right, ESP32 sends a request (of some sort) to the Controler based RS485, this goes via the A/B/GND bus wire to the shunt and to the ADM2483. This sends message to ATTiny, it does it's thing, posts back to ADM2483 and then the opposite route to the ESP32. If so, looks like there is data going back and forth (unless what I see is the data package which has no real data in it (simplistically speaking)

the lot implies that the RS485 does it's job (although it's not the SN65HVD75) right? in which case could it be an incompatibility of the ESP32S board?

EDIT: shouldn't the shunt take it's time to ask/collect/calculate and THEN reply? seems a bit too fast to me... Further, timingwise it seems that IO25 and IO22 look like happening at the same time. IO21 doesn't (at least durationwise) seem to match with IO25, unless IO25 is only happening in TX mode.

V.

[virtuvas]

dropping to 10ms from 5 and poking again a bit it is clear that:

IO22 (TX) duration is short (starts 3V3 and drops to 0) IO25 duration is identical to IO22 (starts 0 goes up to 3V3) IO21 (RX) duration has got first the short bit of the other two, then a delay (around twice the duration) followed by a much longer receiving piece (again starts 0 goes to 3V3)

IO22:

IO25:

IO21:

makes sense, and makes one wonder what happens with the signal received by IO21...

V.

[stuartpittaway]

So the annoying thing, it all looks like it's working!

Perhaps try the original controller code/firmware from master branch.

[virtuvas]

good idea, however, tried that and failed miserably! I mean, I uploaded the old code with no issues, powered off and then on, no matter what, I get to the waiting for modules on the screen and trying to refresh and then change settings to 8S and 5k speed, it comes up with a:

Failed to save settings

ideas?

[stuartpittaway]

It's probably an issue with cookies on the browser.

Try it again in incognito mode

[virtuvas]

you're right re cookies. however, no change, does exactly the same :-( having a look at the code, maybe add any debug/print lines on the terminal on what it's picking, but didn't have much luck on the new code tbh. I'll try on the old. Is there an easy way to print in some sort of raw format what it's receiving?

V.

[virtuvas]

well, tried, nothing arrives according to the log. Would it make sense to order another ESP32 like this:

https://grobotronics.com/esp32-development-board-esp32-devkitc-32d.html

I'll find a use for it if not, but I can have it on Sat if I'm lucky, worth it or no?

V.