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

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.

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

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.

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 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 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 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 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.