Don’t forget that we are not limited to traditional baud rates, which are often poor in modern mcus, even with fractional baud rate generators.
Can we get the same calculation at a division of the core clock speed, like 10,000 or 20,000bps?
Umm, yeah. However, all those ATtinys operate in the same environment thus their clocks all skew in the same direction thus I don’t think this is a problem in practice.
In theory we could sync things up by periodically sending a 0x00 byte and measure the timing, but I doubt that’d help much.
I was talking about replacements for the optocouplers.
Doesn’t matter, the clock delta is relative so whether both talk 9600 or 21212 baud is immaterial.
However, we have one non-relative component in the equation, which is the optocouplers. They introduce a random signal delay that doesn’t depend on the baud rate, thus it’s more significant at higher speeds.
In my opinion not.
It completely depends on the cell voltage
And the datasheets says 2% accuracy up tp 3.6V, but the cell voltage can be higher, and when 2 neighboring cells have different voltages then the oscillators will run different
According to Stuart is seems like the communication problems occurs when the module discharges (Balances) the cells, which maybe can be explained with the differences in the voltages on the modules and therefore different clocks
And I agree in what you wrote Smurfix. The required accuracy 3.75% do not depend on the baudrate
There is some articles that can be found, describing calibration of the AtTiny oscillators by use of another microcontroller to get more reliable communication.
A small fw on the “Target” puts out the clock out on a pin, and the “Master” measures and calculates the offset, and writes the calibration to the “Target”
Maybe it’s worth considering to see if this makes the communication in the current design more reliable
What also happens in the optocoupler is, that higher frequencies / baudrates makes the opto transistor, in the optocoupler, go more in saturation which effects the Tfall in a bad way, and therefore limits the max speed
I seems like the remedy is to use optocoupler with a opto diode instead of a opto transistor in a setup with serial data, or to just use the transistor as a diode, but it requires access to all 3 pins of the opto transistor
Besides that. The given calculated 3.75% clock accuracy requires a decent signal where it’s possible to sample reliable, but the choosen (Relative slow) optocoupler adds to the problem with specially slow falltime due to saturation in the transistor, which can make the sampling of the incoming signal unreliable / difficult on top of the frequency difference of the oscillators due to different Vdd to the MCU
Also Analog Devices recommend 3.75% accuracy and 2% for harsh setups, and normally there is a oscillator driven UART in one end, which is not the case between the cell modules
Where would you get that wire from, parallel optocouplers on each cell? No thanks.
However, we could simply send a sequence of 0x0F bytes (back-to-back, one stop bit) on the normal serial link. The target can measure the times between 1>0 and 0>1 transitions. Divide that number by five, set your baud rate to it, then send a bunch of 0x0F bytes onwards to the next cell.
No additional wires required.
Totally agree…no more wires between modules 
What I mend was to have the module disconnected from normal operation and the battery. Connect one pin to the ESP32 so the modules can have the oscillator adjusted so the ESP and module have same timing on the UART data
Such calibration could be done with a Vdd in the middle of the working range
The problem, as I see it, with a calibration in a chain of modules is, that the error adds up in the string, and the last module in the string can get a “Reference” data package with jitter / errors in the timing due to the modules between “Reference” from the ESP32 and last module
3 posts were split to a new topic: What needs to be done to get a 4mb .bin as Stuart original build has?
Hi,
I’m designing a 3D printed housing I’d like to share. First prototype is done and already is fine but final tweaking is in progress (Autodesk Fusion360).
It would be much easier to finish it with a 3D model of the PCB with modeled connectors and touchscreen (can be mesh). I’m not familiar with how to generate 3d Models of electronics.
Could anyone share/make such a model and send me please on filip (at) sobstel com.
I can make it myself but I will need some help on how to do it properly without discovering the workflow.
2 Likes
I’ve spent the last three years in my free time designing a solar boat. The boat has 4 26s packs each needing contactors to disconnect them from the ESC. Technically only 4 are necessary but I got some extras for lighting and NAV, I was hoping it would be as simple as adding a rule to a relay board.
Looks like CAN is my only option, I was looking through the code, and possibly victron_canbus.cpp is what I need to change to suite my needs. Any recommendations would be much appreciated!
[Edited: contractors → contactors (Moderator - RW)]
Really great, will you publish your files then?
I’m going to add a pre-charge circuit (on the NH 1P BUC), I didn’t have it, although I’ve been lucky not to suffer any damage to the inverter so far.
They have told me that I can add a led + resistor to the pre-charge circuit and that in this way when the pre-charge is complete the led will turn off. You see the circuit well, I don’t know if the connections are correct, I understand that the Diode means that once the precharge is finished, this led+resistor circuit is left without power until the next precharge process, is that correct?
Hi, i have an issue with CAN communication. I can read can succesfully but i do not know what the values are received from CAN, how can i read them? And I don’t know what the id’s defined, where i can learn which id defines with sensor and which value describes the value that is understandable value.
Yes, I will. I’m doing final test prints, stay tuned.
1 Like
@Chapulino What’s a BUC?
Your LED will never light up because the wire of the diode with the — (on top) needs to be more negative than the other end for any current to flow. That cannot happen, and it’s the wrong direction for the LED in any case.
If you want a light that turns off when the precharge is finished, forget about the 1N4007 diode and connect the other end of your LED + 2k resistor to the Victron’s + side, not the battery’s -. in other words, in parallel to your 50Ohm resistor.
BUC =
Thank you very much for the help, I have made a prototype with a capacitor instead of the victron and the schematic that I detail and now it works
1 Like
I noticed my esp32 pinout is different than the schematic. It’s the ESP32-WROOM32 but has 30 pins. Is it possible to work? If it’s not possible for a direct swap can I just use wires to connect each pin to the correct location?
The correct one is the 32U or 32D right?
EDIT: I got it connected using some wires but I don’t have GPIO0 on the dev board. I’m assume because of this it gives me an error in the serial monitor.
rst:0x10 (RTCWDT_RTC_RESET),boot:0x3b (SPI_FAST_FLASH_BOOT)
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
EDIT: it’s working! just had a few wires crossed! What does not having GPI0 do?
Ok, so the controller seems like its working, apologies for my previous post, I also picked up a
ESP32-WROOM-32UE which looks to have the correct pinout. This is just so I don’t have a bunch of wires running to my older ESP32.
I am having issues flashing the ATTiny 841 I’ve tried a few different things but I can’t seem to get it working. I did get them from Aliexpress a few years ago so it’s possible they don’t work.
If not, anyone has any ideas on what might be wrong?
EDIT: Immediately after ordering new ATTiny Chips, I realized my issues and got it working (GPIO0 which is needed for flashing was connected to the wrong pin).
Hey All, can anyone recommend a good cheapish active blanacer ?
and @stuart have you ever considred building this into your current modules, making them “adjacent pressure difference equalization ?”
GPIO0 is used for the BOOT button - required for programming the chip.
Launched a new YouTube video yesterday highlighting some important changes around CANBUS charging and emulation of PylonTech battery.
3 Likes