poking rs232 port BMS

[legg]

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

 

[Winfield Hill]

legg wrote...

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

Maybe rely on user forum threads in Asia / India,
using Google translation, is that a viable option?


--
Thanks,
- Win

 

[TTman]

On 05/11/2019 13:36, 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

X FFE/FFF smells of baud rate error... Is that a possibility ???

--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

 

TTman <kraken.sankey@gmail.com> wrote in news:qps1nb$8rt$1@dont-
email.me:

On 05/11/2019 13:36, 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

X FFE/FFF smells of baud rate error... Is that a possibility ???

For stuff like this, folks should remain in the single baud mode of
less than 9600. Work out all the bugs before you try higher rates.
Higher handshake rates should be left out.

That might fix the entire problem. How much data are these ports
trying to pass in a given datagram event? IOW is a high data rate
even needed at all?

 

[legg]

On Tue, 5 Nov 2019 14:41:46 +0000, TTman <kraken.sankey@gmail.com>
wrote:

On 05/11/2019 13:36, 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 ?

snip

RL

X FFE/FFF smells of baud rate error... Is that a possibility ???

I'm interpreting it as the BMS kicking the RS232 tx line, looking
for life at 'my' end - signs of a possibly working terminal in
the BMS. They accumulate at a rate of ~once every half hour or so.

It's the simplest of 3wire connections - rx, tx and gnd, with no other
pins offered on the port.

RL

 

On Tue, 5 Nov 2019 14:41:46 +0000, TTman <kraken.sankey@gmail.com>
wrote:

On 05/11/2019 13:36, 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

X FFE/FFF smells of baud rate error... Is that a possibility ???

Random 0xFF characters are often a sign of false start bit ("0"), but
the voltage returns quickly back to idle "1" state. A false start bit
has to be about 0.5 to 1.4 bit times to produce 0xFF and 1.4 to 2.3
bit times to produce 0xFE.At 9600 bit/s that would correspond to 60
to 230 us long positive going noise pulse.

 

[legg]

On Tue, 5 Nov 2019 16:20:45 +0000 (UTC),
DecadentLinuxUserNumeroUno@decadence.org wrote:

TTman <kraken.sankey@gmail.com> wrote in news:qps1nb$8rt$1@dont-
email.me:

On 05/11/2019 13:36, 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.
snip

RL

X FFE/FFF smells of baud rate error... Is that a possibility ???



For stuff like this, folks should remain in the single baud mode of
less than 9600. Work out all the bugs before you try higher rates.
Higher handshake rates should be left out.

That might fix the entire problem. How much data are these ports
trying to pass in a given datagram event? IOW is a high data rate
even needed at all?

All manual references fall back on 9600. It's not noise. /xffe or
/xfff could just be the monitor having difficulty with half-hour
spacing between the characters. It read /xffc, once.

Simple 3 wires are all that's available.

RL

 

[legg]

On 5 Nov 2019 06:41:38 -0800, Winfield Hill <winfieldhill@yahoo.com>
wrote:

legg wrote...

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

Maybe rely on user forum threads in Asia / India,
using Google translation, is that a viable option?

The tech support is supposedly forwarding a new version
of the software (mewyeah.exe), but seems to forget to
attach it, or provide a link to it, in his correspondence.

His e-mails/texts hit around 3.30 in the morning here.
I've suggested that 8pm NA / 9AM SEA might be more productive.

Luckily, there's more than one workbench here, and more than
one datalogger harness. Three serial ports being hogged for
this.

Just my luck if it turns out BMS can only communicate on lower
port numbers.

RL

 

[Jasen Betts]

On 2019-11-05, legg <legg@nospam.magma.ca> wrote:

On 5 Nov 2019 06:41:38 -0800, Winfield Hill <winfieldhill@yahoo.com
wrote:

legg wrote...

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

Maybe rely on user forum threads in Asia / India,
using Google translation, is that a viable option?

The tech support is supposedly forwarding a new version
of the software (mewyeah.exe), but seems to forget to
attach it, or provide a link to it, in his correspondence.

His e-mails/texts hit around 3.30 in the morning here.
I've suggested that 8pm NA / 9AM SEA might be more productive.

Luckily, there's more than one workbench here, and more than
one datalogger harness. Three serial ports being hogged for
this.

Just my luck if it turns out BMS can only communicate on lower
port numbers.

I've seen software that could only communicate on ISA-bus serial ports

--
When I tried casting out nines I made a hash of it.

 

[Jasen Betts]

On 2019-11-05, legg <legg@nospam.magma.ca> wrote:

On Tue, 5 Nov 2019 16:20:45 +0000 (UTC),
DecadentLinuxUserNumeroUno@decadence.org wrote:

TTman <kraken.sankey@gmail.com> wrote in news:qps1nb$8rt$1@dont-
email.me:

On 05/11/2019 13:36, 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.
snip

RL

X FFE/FFF smells of baud rate error... Is that a possibility ???



For stuff like this, folks should remain in the single baud mode of
less than 9600. Work out all the bugs before you try higher rates.
Higher handshake rates should be left out.

That might fix the entire problem. How much data are these ports
trying to pass in a given datagram event? IOW is a high data rate
even needed at all?

All manual references fall back on 9600. It's not noise. /xffe or
/xfff could just be the monitor having difficulty with half-hour
spacing between the characters. It read /xffc, once.

Simple 3 wires are all that's available.

RL

What sort of serial poert are you using that handles 12 bit symbols?


--
When I tried casting out nines I made a hash of it.

 

[Jasen Betts]

On 2019-11-05, legg <legg@nospam.magma.ca> 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.

FF is a single narrow pulse on the data line FE is a slightly wider
pulse, are you sure you have the baud rate set correctly?
uising a too low rate can cause this.

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

poke at it with leds and resistors, or theres software that can do
that too. I use statserial.

--
When I tried casting out nines I made a hash of it.

 

[boB]

On Wed, 6 Nov 2019 05:51:45 -0000 (UTC), Jasen Betts
<jasen@xnet.co.nz> wrote:

On 2019-11-05, legg <legg@nospam.magma.ca> 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.


FF is a single narrow pulse on the data line FE is a slightly wider
pulse, are you sure you have the baud rate set correctly?
uising a too low rate can cause this.

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

poke at it with leds and resistors, or theres software that can do
that too. I use statserial.

Maybe it's modbus where you have to hit it with an address, a command,
data and a CRC to get it to respond correctly ?

OR some other proprietory system but still may need prodding to
respond ?

Modbus and CANbus is common for BMS's as far as I know but other
systems exist too of course

 

[mpm]

On Tuesday, November 5, 2019 at 8:32:39 AM UTC-5, legg wrote:

One option:
Get a RIGOL oscilliscope with the free "advanced trigger" options installed.
There's one on sale right now for around $300. (at TEquipment.net)

You can decode the bus, (inverting if need be).

We do a lot of RS-232, 485 and Modbus stuff here, and lately my Rigol DS2072A has been a life-safer for weird comm problems.

Good luck.
BTW: I just posted a similar Chinese problem regarding a new laser etcher we got, so I feel your pain. You would think for all the tariff dollars flowing out of bank account we would at least get a User Manual in English!?

As for Chinese software, I've always wondered which works best: The actual software, or all the spam-hack virus bloatware it loads.

 

[legg]

On Tue, 05 Nov 2019 08:36:39 -0500, legg <legg@nospam.magma.ca> 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 ?

snip

Just had J1939 dumped in my lap. I'm afraid that without
mfr's com SW, it is beyond a bit of poking.

RL