如何协调响应与 Beaglebone black 上 RS485 通信的请求？

Question

I have a Beaglebone black running on linux Debian with a cape Comms2 with RS485 connectivity (the linux serial port device is at /dev/ttyS1).

I have no issue at making thinks communicate with a BMS (battery management system) device except that its protocol looks so weird that I can't safely sync between my requests and its responses.

Let me dive into the protocol which I reversed engineered: the frame for asking voltage, current and SoC (State of charge) is 0x90 and the frame is as follows:

<Buffer a5 40 90 08 00 00 00 00 00 00 00 00 cs>

With cs being the checksum (cumulative sum of all bytes, keeping the LSB).

The 13-byte response is as follows:

<Buffer 69 40 86 00 84 00 00 75 30 03 e2 4c 00>

To decode the frame, skipping the 3-first bytes, we do:

• bytes 3, 16-bit BE: voltage, apply scale 0.1V: 0x0084 = 132 * 0.1 = 13.2 V
• bytes 5, 16-bit BE: skip
• bytes 7, 16-bit BE: current, apply offset 30000, then scale 0.1A 0x7530 = 30000 - 30000 = 0A
• bytes 8, 16-bit BE: SoC, apply scale 0.1%: 0x03e2 = 994 * 0.1 = 99.4%

My code log gives the following values, which are as expected.

Pepsr v2.2.236 4:08:15 PM [pepsr-olenlab2] -- ✅- RS 485: voltageCurrentSoc: { voltage: 13.200000000000001, current: 0, soc: 99.4 }

So far so good.

But now, as I need much more data from the BMS, I must request more frame on a periodic way. I implemented a Q/A system in a setInterval() as follows:

class Rs485 {

    // … blah blah …

    start() {
        
        // == Analyze the received frames
        serialport.on('data',  data => {
                
            // Append data
            this.readingBytes = this.readingBytes.concat(Array.from(data))
            //this.log('data received: ', data, 'as array', Array.from(data), 'length is', this.readingBytes.length)
        
            // Data is OK?
            if (this.readingBytes.length == 13) {
                this.parseMessage(new Buffer.from(this.readingBytes))
                this.readingBytes = []
            }
        })
        
        // == Prepare the next frame to be requested
        this.askFor = 0
        this.askForCount = Object.keys(Rs485.FRAME_TYPE).length
        
        
        const request = () => {
            const key = Object.keys(Rs485.FRAME_TYPE)[this.askFor]
            const type = Rs485.FRAME_TYPE[key]
            //this.log('Now asking for ', this.askFor, 'th type, aka', key, ', value:', type)
            this.request(type)
        }
        
        // == On open…
        this.serialport.on('open', () => {
            this.success('Successfully open')
        
            request()
        })
        
        // == Periodically ask for the next frame type (1Hz)
        setInterval(() => {
            if (!this.serialport.isOpen) {
                this.log("Port Open Status: " + this.serialport.isOpen)
                return
            }
            request()
        },1e3)
    }

}

parseMessage() simply does what we did above based on the frame type.

As you can see, I store the current requested frame type in a variable and I assume the next packet to be received to be the response of the request.

One thing I guess I must make clear is that I didn't found a hook in the response header that I can link to the request.

So my question is how I can improve the communication model so that I can better reconcile response with request?

Answer 1

If you only ever send requests of the same type (eg the battery voltage, current and SoC query) then there's no practical need to associate requests with responses. You can get away with just firing a new request every second without even looking at responses. If a few frames go missing or get corrupted during transmission, no harm done - as long as the subsequent responses arrive, you'll have fresh data.

When you want to detect communication failure in this solution, start a timer on receiving a response (timer value depends on your system - maybe 10-60 seconds?) and declare a communication failure if you haven't received any new responses before the timeout expires.

If you send requests of different types then - yes, you need to remember which type of request got sent most recently and wait for the correct response. In this solution you need to start a timer with each request, then wait until the current request frame either receives the corresponding reply frame or times out. Don't send a new request before this happens. Process a single request-response transaction to its successful or unsuccessful end before starting a new one. This way any transmission failures on the communication line get caught by the timeout and requests and responses shouldn't fall out of sync. Again, the timeout values depend on your system.