Losing my fricken mind - BXOR

ericmedley

Someone please check my math...
I'm working on comms with a BlU100 (I'd rather ram a flaming sharp stick in my eye)

They use a really janky hex protocol with a checsum.

here's the string in their example:
"0x02, 0x88, 0x01, 0x0F, 0x1B, 0x83, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x84, 0x03"

what I'm supposed to do to make a checksum is XOR the charactors in the "body" of the message which is the following part of the previous message:
" 0x88, 0x01, 0x0F, 0x1B, 0x83, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00"

The first char ($02) is the message header, the last char ($03) is the termination. The penultimate char (($84) is supposed to be the check sum. I have done the XOR in code and on a calculator and come up with $1F. The answer according to the documentation is supposed to be $84. My method (according to the documentation) of XOR-ing is:

result =$88 BXOR $01
result= result BXOR $01
result= result BXOR $0F
result=result BXOR $1B
etc...

any hints as to what I'm doing wrong? Or is the documentation wrong? anyone have experience with the BLU100?

GregG

It looks like they only xor from the $83 through that $01 and a bunch of zeros, could the $88,$01,$0F,$1B be considered part of a "header" and not part of the body?

ericmedley

I could post the section of the protocol that deals with this but it's actually several pages and I don't want to bore you with that. I can confirm it with some old code that the London folks wrote about 10 years ago that the segment being checksummed is correcct. Oddly enough when I try their code I get the same result. I'm thinking that it might be a typo in the manual. But, what scares me is another example given shows up incorrect as well.

If I only had the actual unit here I could test against reality. I can tell you this is the worst thought out protocol I've ever seen. The best part is the message IDs are 5 values
0x02 STX
 0x03 ETX
 0x06 ACK
 0x15 NAK
 0x1B Escape

However, if these values occur withing the body of the message (which they often do) then they have a set of replacement values you have to sub in AFTER you do the checksum. ANNNNNND if the checksum happens to work out to be one of these reserved values, IT needs to be subbed in. c'mon folks, it's the fricken 21st century. wake up and smell the 16+ bit word length. It's okay to use plain text stuff. All the cool kids are nowadays...

feddx

Eric, you are right. the protocol is BS and it will make you want to light a baby on fire. But you need to checksum BEFORE the ESCAPE OUT feature. The way the sucktastic protocol works is as follows:

Create the command,
Create the checksum via XOR,
Do the extra special "Escape Out" for certain values (add $80 to the byte and preface it with $1B),
Append with STX and ETX

This is a little subroutine I wrote, I hope it helps:

Define_Function integer fnBSSCommand(Char Initial_Cmd[20])
{
    local_var Char Raw_Cmd[20]
    local_var Char After_Build[30]
    local_var Char Final_Command[40]
    local_var integer CS_Count
    local_var integer PB_Length
    local_var integer RC_Count
    local_var integer RC_Length    
    local_var integer Check_Sum
    
    After_Build = ""
    
    //Calculate Checksum
    PB_Length = length_string (Initial_Cmd)
    Check_Sum = Initial_Cmd[1]
    for (CS_Count = 2;CS_Count<=PB_Length;CS_Count++)
    {
        Check_Sum = Check_Sum ^ Initial_Cmd[CS_Count]
    }
    
    Raw_Cmd = "Initial_Cmd,Check_Sum"
    
    //Escape out the specific bytes that need to be changed
    RC_Length = length_String (Raw_Cmd)
    For (RC_Count=1;RC_Count<=RC_Length;RC_Count++)
    {
        if (Raw_Cmd[RC_Count] = $02 || Raw_Cmd[RC_Count] = $03 || Raw_Cmd[RC_Count] = $06 || Raw_Cmd[RC_Count] = $15 || Raw_Cmd[RC_Count] = $1B)
        {
            After_Build = "After_Build,$1B,(Raw_Cmd[RC_Count]+$80)"
        }
        Else
        {
            After_Build = "After_Build,Raw_Cmd[RC_Count]"
        }
    }
    
    Final_Command = "STX,After_Build,ETX"
    
    SEND_STRING DSP1,"Final_Command"
}

Also remember if you're using live feedback from the device, you NEED to REVERSE all those "ESCAPED OUT" bytes the BLU sends you back. It's like the process above only reversed:

Define_Function Char[17] fnBSSRetun(Char Reply_Cmd[]) //Need to pull the escapes out
{
    local_var char raw_return[30]
    local_var char real_return[20]
    local_var integer Replycount
    local_var integer replylength
    raw_return = "Reply_Cmd"
    replylength = (length_string(raw_return)-1)
    real_return = "raw_return[1]"
    For (Replycount=2;Replycount<=replylength;Replycount++)
    {
        if (raw_return[Replycount] = $1B)
        {
            real_return = "real_return,(raw_return[Replycount+1]-$80)"
            Replycount++
        }
        Else
        {
            real_return = "real_return,raw_return[Replycount]"
        }
    }
    Return (real_return)
}

I hope this helps madman.

ericmedley

feddx wrote: »

Eric, you are right. the protocol is BS and it will make you want to light a baby on fire. But you need to checksum BEFORE the ESCAPE OUT feature. The way the sucktastic protocol works is as follows:
etc...
.

Andrew,
What a guy! Thanks! it's amazing how close our code is. I even named some of my stack_vars the same... I seem to remember a guy like you helping out with another DSP a while back...