Electronics-Related.com
Forums

poking rs232 port BMS

Started by legg November 5, 2019
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
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
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
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.
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
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?
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
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
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.
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.