poking rs232 of BMS

I've got a battery management unit that is reluctant to demonstrate functionality. The vendor's terminal com software seems non-functional (will not install).

So far the only evidence of life is a control line (one of three) hard on, and rare /XFFE /FFF signalled outputs on the rs232 port. Internal DC-DC fails to power LEM sensor. Balancing terminals seem inactive.

Can anyone recommend a tutorial on poking a serial port for status / data register contents ?

It should be reporting on the voltage of four LiFePO4 batteries, powering a LEM sensor and reporting current. Many other undocumented features for I/O via remote terminal. Has CAN port, which seems to be used only for control power and crude 'run' (input) /'stop charging' (output) LF/DC signals.

I'm in touch with the overseas vendor, but they seem reluctant to comment on their SW functionality or test criteria for the unit. Outgoing photographs and diagrams from here, mostly, so far. The manual and it's diagrams don't make much sense, refering to non-existent hardware or unavailable interface modules.

Someone has gone to a great deal of trouble to chart the identity, labelling and function of I/O terminals, but these are largely ignored in subsequent diagrams or instructions.

Mostly used in SE Asia or the Indian subcontinent. English version is only recently available.

RL

Reply to
legg
Loading thread data ...

What initially comes to mind is to connect a terminal or terminal emulator and try some of the more run of the mill key sequences: return (return n ti mes), ctl-c, ctl-d, esc, F1..Fn, etc. What comes back may not be visible on a terminal unless the terminal can di splay non-printing ASCII characters. A serial line logic analyzer in paral lel may help.

If you are having this much trouble working with this thing, I'd suspect th e quality of the unit as a whole. My gut reaction to your description is t o toss it and get one made by a reputable company or roll your own. The ti me you spend trying to decipher the mysteries of this one could be better s pent doing your own. A simple DAS board with a serial port connected to a P C and program in Basic or Python will do it. Or, if you really want bare bones/low cost and something fast, get a arduin o or if you want to go a small/cheap but functional computer, get raspberry PI 3B+

j
Reply to
three_jeeps

I've got a monitor hooked up, another port dedicated to coms (if it can be established). The monitor can poke, but not react, so sending ACKs in a timely manner would be a problem. Would expect a data and op-mode register to be pumped out, to be translated.

I'm guessing that the BMS is in low power mode, kicking the RS232 occasionally. There will be a connection / com sequence that I haven't discovered yet and that previous hardware install configuration did not anticipate or provide, in order to get the thing running.

The BMS manual wants to control a battery charger disconnect relay. The inverter/charger wants no disconnection (their exact wording includes the term 'NEVER'), just a 'stop charging' closed-contact signal.

The missing sensor power bothers me, though.

The guts are well designed and would be familiar to most developers on this side of the pond, though we wouldn't be allowed to accumulate the same BOM cost. There's really nothing missing there - no short cuts. Should be easily modified if balance insufficient for the cell capacity being employed - the same hardware - populated more extensively, is designed to handle a 10-cell string. This is a

4-cell app.

Their app people are rumouring a SW revision that hasn't been forwarded here or download link-referenced, as yet.

RL

Reply to
legg

Just had J1939 dumped in my lap. Without the vendors com software, I'm afraid this is beyond poking.

RL

Reply to
legg

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.