flir / rawboson Goto Github PK

Does this tool assume that the Boson 320/640 is connected to the computer using the USB C adapter?

I cannot get the set commands to work. Always returns
Error : Boson Status (Buffer Overflow)

Example: bosonSetFFCWarnTimeInSecx10()
./rawBoson c00050074 00 15

This command expects UINT_16 or two bytes (here 00 15)

bosonSetTimeForQuickFFCsInSecs()
./rawBoson c0005007a 00 00 00 40

This command expects UINT_32 or 4 bytes (here 00 00 00 40)

All give: Error : Boson Status (Buffer Overflow)

What am I missing? Thanks

On behalf of : jveitchmichaelis

Similarly the code in the SDK does some work to escape the start and end frame markers if they appear in the packet, but the rawboson library doesn't. Is this simply a rare occurrence, and the raw library is getting away without it, or is it necessary to communicate with the camera?

I'm guessing it's just to add some robustness, because without a payload length in the frame header, you can have situations where the escape marker has to be escaped ad infinitum.

Just noticed that setup_serial returns -1 if it does not encounter any errors. However it returns -1 if it does encounter errors.

at the same time, the code that calls setup_serial checks for 0 as an error, and any other value as successful:

I see that the other functions in serial.c return 0 on failure, and 1 on success. Perhaps this is how setup_serial was originally meant to work?

Hello,

I am not sure what is the command to control the high/low gain of the Flir Boson, can you guide me through this?

I have looked through the https://www.flir.com/globalassets/imported-assets/document/boson_sdk_documentation_9hz-v11412-and-later.pdf
but it does not contain information about the lower level serial protocol. Where could I get this documentation?

If you run rawBoson requesting a changing value from the camera, such as frame count:

while true ; do ../rawBoson/rawBoson c0020002; done

you will encounter frame counts where CRC errors are reported in interesting patterns:

0x00 0x03 0x25 0x96 
0x00 0x03 0x25 0x97 
0x00 0x03 0x25 0x97 
0x00 0x03 0x25 0x98 
0x00 0x03 0x25 0x99 
>>> Error : Boson Bad CRC Received 
>>> Error : Boson Bad CRC Received 
0x00 0x03 0x25 0x9B 
0x00 0x03 0x25 0x9C 
0x00 0x03 0x25 0x9D 
>>> Error : Boson Bad CRC Received 
>>> Error : Boson Bad CRC Received 
0x00 0x03 0x25 0x9F 
0x00 0x03 0x25 0xA0 
0x00 0x03 0x25 0xA1 
0x00 0x03 0x25 0xA1 

Is this an error in rawBoson, or the camera firmware?
Adding the v flag to the rawBoson command produces more information.

When making many requests in very quick success to the Boson 320 over USB it is common to have errors reported by rawBoson of the form:

>>> Error while receiving bytes (No START Detected) 

For a while, I thought this meant that a character other than the start character (0x8E) had been received but after setting breakpoints and modifying the code a bit I realized that the Boson 320 is actually not responding at all.

Here is the current code:

// Repeat until START BYTE is received or timeout (10sec) happens!!
endwait = GetTickCount () + SERIAL_TIMEOUT;
while ( (GetTickCount() < endwait) )  {
  if ( car_waiting(serial) ) {
        car = read_serial_car(serial)&0xFF;
        if ( car == 0x8E ) {
            boson_stuffed_package[i++]=0x8E;
            break;
        }
  }
}
if ( i==0 ) {
    boson_stuffed_package_len=i;
    return -1; // ERROR NO DATA or START FRAME received
}

So when the "return -1" is reached we know:

• the start code (0x8E) hasn't been received
• other characters could have been received, but we don't know
• the loop could have timed out.

Here is a rewrite that made it clear to me what the Boson 320 is doing:

int64_t now;
now = GetTickCount();
endwait = now + SERIAL_TIMEOUT;
while ( now < endwait) )  {
    if ( car_waiting(serial) ) {
        car = read_serial_car(serial)&0xFF;
        if ( car == 0x8E ) {
            boson_stuffed_package[i++]=0x8E;
            break;
        }
    }
    now = GetTickCount();
}

if ( i==0 ) {
    boson_stuffed_package_len=i;
    if (now >= endwait)
        return -3; //  // ERROR TIMEOUT
    else
        return -1; // ERROR START FRAME not received
}

When I run that code, the return -3 is always the branch taken. It's never the case that the start code is missing or that a different character is returned.

This leads me to believe that a shorter timeout might be advised.

Hi

I used Boson GUI 1.5.0 to try out some settings. All good until I tried enabling the "Averager" functionality (I clicked Save and Reboot). When the Boson restarted, it completely freezes after the Splash screen is displayed. I think this is due to that the OTS firmware expects a 60Hz datastream, and Averager changes the framerate to half at 30Hz.
I can't use Boson GUI since the device completely freezes, so there isn't enough time to manually click in the GUI to restore to factory defaults/change undo the settings.

That's why i'm trying to use rawBoson to programmatically change settings, but it still doesn't work.

Here's one set of commands i've tried, disable averager & freeze, then save:

rawBoson -p/dev/ttyACM0 -b921600 c0000B x0 x0 x0 x0 v b # Disable Averager
rawBoson -p/dev/ttyACM0 -b921600 cE0001 x0 x0 x0 x0 v b # Disable Freeze
rawBoson -p/dev/ttyACM0 -b921600 c50018 v b # Write settings

Another set of commands, try to restore to factory defaults, write and then reboot:

rawBoson -p/dev/ttyACM0 -b921600 c5001B v b # Restore to factory defaults
rawBoson -p/dev/ttyACM0 -b921600 c50018 v b # Write settings
rawBoson -p/dev/ttyACM0 -b921600 c50010 v a # Reboot Boson

I do get response from the device briefly, for a split second after the splash screen is displayed. So it looks like the Boson module receives the commands, but fails to properly apply the settings before it freezes.

Wondering if you have any ideas on how to resolve the issue? Wouldn't want to throw rather expensive equipment in the bin.

Product: FLIR Breach (PTQ136).
OTS SW VERSION: 2567
BOSON SW VERSION: 2.0.14857

Receive_Serial_package() returns -2 on a timeout rather than the -3 expected by the code in main()