It worked finally! I did not upload the sketch correctly to the Arduino Nano!
See here, this helped me:
1 Like
For those who have the current shunt up and running, do you have any problems with the POWER reading on the web interface?
There is an open issue (link below) and I’m trying to find other users with the same problem.
hi,
got my first diybms shunt built finally after waiting for the LM chip for over two months!
well, did the initial powerup test, no sparks or smells, so looks fine.
Now for the programming, been through the thread a couple of times, have an uno and jumpers around, downloaded jtag2updi and using ArduinoIDE uploaded it to the UNO with no errors.
That’s on a win10 machine, now what?
I see that I have to use avrdude which I downloaded (from their site as a complied win exe) and fitted. but I’m struggling after that. i also see that I need to replace avrdude conf file with the one provided by jtag2updi, fine. The command line I see mentioned above by @shampeon :
./avrdude -v -C avrdude.conf -p attiny1614 -c usbtiny -U flash:w:diyBMSCurrentMonitor_ATtiny1614.hex:i
wont work as I don’t have a hex file anywhere 
Do I need to compile the code in PlatformIO and then upload using avrdude?
Basically, I don’t get the process at all!
I’m obvs missing something and the fact that I find PlatformIO an impossible tool to use doesn’t help (nor that I’m not a programmer…)
so any ideas how I progress from here would be welcomed!
OK, I’ll wire +5V/GND from the UNO to the +5V/GND of the shunt and D6 of the UNO to the Reset. Also I’ve disconnected the shunt from other powersupply.
And yes, I’ve downloaded and have on my PlatformIO dir the diyBMS-CurrentShunt-master and all it’s subfolders [which I don’t seem to be using for anything atm!].
cheers
V.
Hex file is downloadable from the releases in the repository.
I didn’t have much luck using avrdude, but was able to load the firmware using a USB serial connector and these instructions above.
thanks, slowly loosing the will to live and program this bleeding chip!
OK, downloaded the hex, fine
went through two different paths using an arduino UNO I have around (on COM8) on win10 PC:
A. trying to follow @stuart instructions in post #63 above.
downloaded and installed jtag2updi configured properly.
wired using a 4k7 and a 10uF (ok, used 20uF, doubt its that much of a difference!)
downloaded and installed MegaTinyCore and configured as explained in the video that stuart linked to.
then tried
avrdude -v -C avrdude.conf -p attiny1614 -c uncompatino -U flash:w:diyBMSCurrentMonitor_ATtiny1614.hex:i
which gave me:
avrdude: Version 6.4
Copyright (c) Brian Dean, http://www.bdmicro.com/
Copyright (c) Joerg Wunsch
System wide configuration file is "avrdude.conf"
Using Port : usb
Using Programmer : uncompatino
avrdude: error: no libftdi or libusb support. Install libftdi1/libusb-1.0 or libftdi/libusb and run configure/make again.
avrdude done. Thank you.
obvs something is fundamentally wrong with my avrdude.
Problem is I don’t understand how the UNO running this whatever jtag2updi gets into the equation and how the avrdude passes stuff into it…
B. for good measure, I also tried to follow @atanisoft instructions, downloaded pymsuprog and run the following command (but again with the UNO wired there…)
pymcuprog write -f ./diyBMSCurrentMonitor_ATtiny1614.hex -d attiny1614 -t uart -u com8 --verify -v debug
which gave me:
pymcuprog.programmer - INFO - Setting up programming session for 'attiny1614'
pymcuprog.deviceinfo.deviceinfo - INFO - Looking for device attiny1614
pymcuprog.serialupdi.physical - INFO - Opening port 'com8' at '115200' baud
pymcuprog.serialupdi.physical - DEBUG - send : [0x0]
pymcuprog.serialupdi.link - DEBUG - STCS to 0x03
pymcuprog.serialupdi.physical - DEBUG - send : [0x55, 0xc3, 0x8]
pymcuprog.serialupdi.link - DEBUG - STCS to 0x02
pymcuprog.serialupdi.physical - DEBUG - send : [0x55, 0xc2, 0x80]
pymcuprog.serialupdi.link - DEBUG - LDCS from 0x00
pymcuprog.serialupdi.physical - DEBUG - send : [0x55, 0x80]
pymcuprog.serialupdi.physical - DEBUG - receive : []
pymcuprog.serialupdi.link - WARNING - Check failed
pymcuprog.serialupdi.physical - INFO - Sending double break
pymcuprog.serialupdi.physical - INFO - Opening port 'com8' at '115200' baud
pymcuprog.serialupdi.link - DEBUG - STCS to 0x03
pymcuprog.serialupdi.physical - DEBUG - send : [0x55, 0xc3, 0x8]
pymcuprog.serialupdi.link - DEBUG - STCS to 0x02
pymcuprog.serialupdi.physical - DEBUG - send : [0x55, 0xc2, 0x80]
pymcuprog.serialupdi.link - DEBUG - LDCS from 0x00
pymcuprog.serialupdi.physical - DEBUG - send : [0x55, 0x80]
pymcuprog.serialupdi.physical - DEBUG - receive : []
pymcuprog.serialupdi.link - WARNING - Check failed
Traceback (most recent call last):
File "d:\program files\python37\lib\runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "d:\program files\python37\lib\runpy.py", line 85, in _run_code
exec(code, run_globals)
File "D:\Program Files\Python37\Scripts\pymcuprog.exe\__main__.py", line 7, in <module>
File "d:\program files\python37\lib\site-packages\pymcuprog\pymcuprog.py", line 285, in main
return pymcuprog_main.pymcuprog(arguments)
File "d:\program files\python37\lib\site-packages\pymcuprog\pymcuprog_main.py", line 80, in pymcuprog
status = _start_session(backend, device_selected, args)
File "d:\program files\python37\lib\site-packages\pymcuprog\pymcuprog_main.py", line 549, in _start_session
backend.start_session(sessionconfig)
File "d:\program files\python37\lib\site-packages\pymcuprog\backend.py", line 366, in start_session
sessionconfig.interface_speed)
File "d:\program files\python37\lib\site-packages\pymcuprog\programmer.py", line 83, in setup_device
options=self.options)
File "d:\program files\python37\lib\site-packages\pymcuprog\nvm.py", line 42, in get_nvm_access_provider
accessprovider = NvmAccessProviderSerial(transport, device_info, baud=frequency, options=options)
File "d:\program files\python37\lib\site-packages\pymcuprog\nvmserialupdi.py", line 51, in __init__
self.avr = UpdiApplication(port, baud, self.dut)
File "d:\program files\python37\lib\site-packages\pymcuprog\serialupdi\application.py", line 81, in __init__
datalink.init_datalink()
File "d:\program files\python37\lib\site-packages\pymcuprog\serialupdi\link.py", line 45, in init_datalink
raise PymcuprogError("UPDI initialisation failed")
pymcuprog.pymcuprog_errors.PymcuprogError: UPDI initialisation failed
pymcuprog.serialupdi.physical - INFO - Closing port 'com8'
guess that is because I didn’t use a usb->serial adapter, getting lost tbh!
any help much appreciated by anyone!
cheers
V.
finally success!
so to recap:
download and setup an arduino IDE project out of the source file on jtag2updi. For good measure update your IDE to latest ver.
configure IDE for UNO and com port, upload code to UNO.
Then open new empty arduino IDE project, install MegaTinyCore boards, select right one.
Leave UNO connected (and doing nothing!) and wire it to Shunt:
UNO: capacitor 10-20uF from Reset to GND
UNO - Shunt wiring:
GND to GND
+5V to +5V
D6 → 4k7 resistor → Reset
following get avrdude (have latest 6.4) and run the following command (correct com port, had the hex file on the avrdude dir to avoid extra paths):
avrdude -v -p attiny1614 -C avrdude.conf -c jtag2updi -b 115200 -P "COM8" -F -U flash:w:diyBMSCurrentMonitor_ATtiny1614.hex:i
NOTE: use the avrdude.conf file that came with the jtag2updi project and NOT the one that was with avrdude! Else it wont work (as shown in my last post log…)!
must have spent more than 6h to program the shunt…
cheers
V.
1 Like
what happens if I only get 0.7V on the UPDI pins?
managed to program the shunt, 5red/6green flash fine when power is given on UPDI pins.
However, when connected to the 25.6V of the 8S bank (+V Sense+V together) and GND to V- on the bank, I only get 0.7V on the UPDI (and no leds flashing). I can see that full voltage goes through F1 and D1 is the right way round.
What could I be missing or is there any other test I could/should do?
Looks like UPDI V+ comes through the RS485 V+ and via the ADM2483. I’ll have another go resoldering it…
EDIT:
resoldered the tiny ones, there were possibly a couple of shorted legs on both LM and INA chips.
Re connected, now with the RS485 connected and shunt powered from the bank, I get a pattern that
usually is 5 red 6fast green, but sometimes it’s only 3red and a greater number of greens followed by a few dim flashing of red and then goes back to normal 5/6. Is that OK?
UPDI V+ - GND pins now are at 2.9V and not 5V (better than 0.7-0.9V I had before resoldering)
FWIW, controller still don’t like it as in the Current Monitor screen wont keep the settings I’m adding (200A, 50mV, 304Ah, 28V full, 1Atail, 98% effic) and comes up with two top blanks and rest 4 zeros 
I’m wondering if the modbus address is right at 90 (I’ve not got any switches/jumpers on) haven’t seen any pointer on what is the default address with both jumpers open.
Further, I also wonder if it’s indeed 19200/8/none/1 the RS485 settings…
if all the above are OK, then I guess I have to look for at the other side at the controller for any issues.
How easy is to check if there’s anything going back and forth the RS485 bus?
I do have a RS485 - > USB cable from the dead aliexpress current monitor
EDIT2:
resoldered for a third time the INA chip (cannot see the pins clearly not even with specs and magnifying glass!) UPDI is now up to 4.95V, so call that fixed!
To be exact, it’s 4.95 whilst the red/green led are off, and drops to 4.85-4.90 when they are flashing.
Still not able to get coms with the controller
V
Guys, i have just connected the current shunt to diybms and current shunt report incorrect power and current also voltage is off by 500mv
Right now my charge controller showing charge current at 13amp, did i incorrectly connect somethings? Please help, thank you
These are my setting, have not really change any options be side the shunt current and battery capacity
it’s only 50mV not 500 off which isn’t that much (just getting values in perspective!)
are you sure you don’t have circa 12A consumption straight off the source and before current goes to the battery via the shunt? a layout of your system would help I guess. Or what’s between the shunt and the bank positive?
No consumption at all, the use the this system to power all the led light i have a round the house, so no consumption at all. Beside the shunt is between charge/load and battery so its should report everything that go in or out right? I dont know what i did wrong 
What are you comparing the voltage to? The shunt should be more accurate than the modules.
0.05V difference seems reasonable.
The state of charge will be 100% if you have just powered up the shunt/current monitor.
This will drop and reset based on the setting you have specified.
All settings are default except shunt current limit from 150 -500, and battery’s capacity. All other setting left as default, shunt report charge current incorrectly. Instead of 12-13A shunt only report .49A-.70A, any idea why?
After 3days of constant troubleshooting and not able to program the shunt. Your post really helped me today. I have been wiring the UNO and shunt wrongly.
Thank you VAS!
3 Likes
[I][main.cpp:2729] lazy_tasks(): Task 2
[D][main.cpp:2250] service_rs485_transmit_q(): Send addr=90, func=3, len=8
[E][main.cpp:2398] rs485_rx(): Short packet 0 bytes
[D][PacketReceiveProcessor.cpp:79] ProcessReply(): Finished all reads
[D][main.cpp:2250] service_rs485_transmit_q(): Send addr=90, func=3, len=8
[E][main.cpp:2398] rs485_rx(): Short packet 0 bytes
[I][main.cpp:2764] lazy_tasks(): Task 3, s=0 e=7
[D][main.cpp:3362] loop(): total_free_byte=81696 total_allocated_byte=218316 largest_free_blk=48128 min_free_byte=72032 alloc_blk=531 free_blk=46 total_blk=577
[D][main.cpp:2250] service_rs485_transmit_q(): Send addr=90, func=3, len=8
[E][main.cpp:2398] rs485_rx(): Short packet 0 bytes
[D][PacketReceiveProcessor.cpp:79] ProcessReply(): Finished all reads
[I][main.cpp:2713] lazy_tasks(): Sleep
[D][main.cpp:2250] service_rs485_transmit_q(): Send addr=90, func=3, len=8
[E][main.cpp:2398] rs485_rx(): Short packet 0 bytes
[D][PacketReceiveProcessor.cpp:79] ProcessReply(): Finished all reads
[I][main.cpp:2718] lazy_tasks(): Task 1
[D][main.cpp:2250] service_rs485_transmit_q(): Send addr=90, func=3, len=8
[D][main.cpp:519] sdcardlog_task(): Wrote to SD log
[D][main.cpp:584] sdcardlog_task(): Wrote current monitor data to SD log
[E][main.cpp:2398] rs485_rx(): Short packet 0 bytes
[D][main.cpp:3362] loop(): total_free_byte=81664 total_allocated_byte=218332 largest_free_blk=48128 min_free_byte=72032 alloc_blk=532 free_blk=46 total_blk=578
[D][main.cpp:2250] service_rs485_transmit_q(): Send addr=90, func=3, len=8
[I][main.cpp:2729] lazy_tasks(): Task 2
[E][main.cpp:2398] rs485_rx(): Short packet 0 bytes
[D][PacketReceiveProcessor.cpp:79] ProcessReply(): Finished all reads
[D][main.cpp:2250] service_rs485_transmit_q(): Send addr=90, func=3, len=8
[E][main.cpp:2398] rs485_rx(): Short packet 0 bytes
[I][main.cpp:2764] lazy_tasks(): Task 3, s=0 e=7
[D][PacketReceiveProcessor.cpp:79] ProcessReply(): Finished all reads
[D][main.cpp:2250] service_rs485_transmit_q(): Send addr=90, func=3, len=8
[E][main.cpp:2398] rs485_rx(): Short packet 0 bytes
[I][main.cpp:2713] lazy_tasks(): Sleep
[D][main.cpp:3362] loop(): total_free_byte=81664 total_allocated_byte=218332 largest_free_blk=48128 min_free_byte=72032 alloc_blk=532 free_blk=46 total_blk=578
[D][main.cpp:2250] service_rs485_transmit_q(): Send addr=90, func=3, len=8
[E][main.cpp:2398] rs485_rx(): Short packet 0 bytes
[D][PacketReceiveProcessor.cpp:79] ProcessReply(): Finished all reads
[I][main.cpp:2718] lazy_tasks(): Task 1
[D][main.cpp:2250] service_rs485_transmit_q(): Send addr=90, func=3, len=8
[E][main.cpp:2398] rs485_rx(): Short packet 0 bytes
any idea what could its be? controller cant com with shunt
Formatted text - BT, Moderator
What shunt are you using? Is it 50mV rated?
Yes, its the 500A 50mV shunt that you suggested on github. When i power up the current shunt board the green led rapid flash 5-6 times than only the red led flash slowly after. Any idea what happened
At first its work but report incorrectly, so i replace the SN65HVD75DR chip think it malfunction. After that the controller no longer show the shunt anymore, and i got the log above through putty
Should i remove the SN65HVD75DR chip and replace with the other that was on the controller
That’s exactly what it should do.
The SN chip controls the communication, so as long as that was reporting voltages to the controller, it was working as expected.