On Tue, 5 Nov 2019 10:36:58 -0800 (PST), three_jeeps
wrote:

On Tuesday, November 5, 2019 at 8:14:42 AM UTC-5, legg wrote:
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
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 times), ctl-c, ctl-d, esc, F1..Fn, etc.
What comes back may not be visible on a terminal unless the terminal can display non-printing ASCII characters. A serial line logic analyzer in parallel may help.

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

j

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