Event not being handled by send_command() code (BLE112 to BGM113)

Device Code
1

Hi,

I have the following function:

function send_command(name, msg_class, msg_id, payload, callback = null) {
    
    log("LOG", format("call %s", name));
    
    // Queue the callback, build the packet and send it off
    local command = {name=name, msg_class=msg_class, msg_id=msg_id, callback=callback};
    local timer = imp.wakeup(20, function() {
        // The timeout has expired. Send an event.
        command.result <- "timeout";
        fire_response(command);
    }.bindenv(this));
    
    command.timer <- timer;
    _response_callbacks.push(command)
    
    local len = payload == null ? 0 : payload.len();
    local header = format("%c%c%c%c", 0x20, len, msg_class, msg_id);
    server.log("this is my error?!?!?!");
    server.log(header)
    uart_write(header, payload);
    
}

Which is a slight variation of the send_command() function found on the BLE112 class library (being adapted for BGM113, which is what I’m using).

For the BLE112, the main difference is at this line:

local header = format(“%c%c%c%c”, (len >> 8) & 0x07, len & 0xFF, cid, cmd);

Where cid and cmd are msg_class and msg_id.

I’ve been processing most of my commands properly, see for example what happens for “system_addresss_get” command:

image
Notice that on the line that says “this is my error?!?!?!”, the header is being printed before calling uart_write(). A correct execution of this, ends with a response of the type:
LOG: resp system_address_get: OK

Now, applying the same methodology to “get_scan_response”, the callback is unhandled and I don’t truly know why, meaning the execution is not entirely correct, see the screenshot please:

image

In comparison with the previous command, when I print the header, I get 3 empty boxes. Like if the header can’t be read. I tried typing server.log(typeof header) and it says string, like it should be. But there’s something here that’s causing this event to be unhandled properly. What’s weird about it is that the message sent and the message recieved are exactly what we should expect (if we refer to this SDK).

I’m lost here, if anybody can help, I’d appreciate it.

2

I don’t understand your issue here. What do you mean by “when I print the header, I get 3 empty boxes”? Is your issue just that your debug logs don’t look like you think they should?

May be relevant that 0x20 is a space, so will print as a blank character.

The logging you attach is not from the code you have put above.

3

Yes, its weird that I use server.log(header) for one command response (system_address_get), and I cannot get the binary representation for another command response like gap_set_scan_parameters.

And I’m not exactly sure if its a coincidence that when this happens, my logs get

“LOG: resp gap_set_scan_parameters: ok (unhandled)”.

Judging from the RECV and SEND logs, I’m getting the correct interaction with the device (for both events), but I’m not sure if this might complicate the execution of more complex tasks.

4

Server.log will only show binary if it’s below 0x20, I believe. If numbers are above that, then it’ll treat them as printable. My guess is you’re seeing space (0x20) then three bytes >0x7f.

If you want to log binary packets you should really log them properly, eg:

local s="";
foreach(b in buffer) { s+=format("%02x ", b); }
server.log(s);

Looking in the library, it will print “unhandled” if you don’t have a handler registered for this message, so I guess that’s what’s happening here.

1 Like
5

About this, I just attached the send_command() function where I think the issue is located, the server.log(“this is my error?!?!?!”) and the following line server.log(header) are indeed printed there.

I just left everything else about the response to discard the possibility I wasn’t mapping the events/commands from this one as they should.

And I’m not sure this will carry consequences, because I’m trying to replicate the function discover_mode from this example application:

6

I suggest you print the packet hex (using my code above) then you can see whether you’re registering the right handler…

7

Yes, but I’m not sure where exactly, these are the functions I have to fire a command and to recieve the response for such command (gap_set_scan_parameters)

function gap_set_scan_parameters(scan_interval, scan_window, active, callback = null) {
        local payload = format("%c%c%c%c%c", scan_interval, 0x00, scan_window, 0x00, active);
        return send_command("gap_set_scan_parameters", 0x03, 0x06, payload, callback);
    }

and this is how I handle the response:

if (event.msg_type==0x20 && event.length==0x02 && event.msg_class==0x03 && event.msg_id==0x06) {
        event.result <- payload[0] + (payload[1] << 8);
        event.name <- "gap_set_scan_parameters";
        
    }

In the second screenshot of the original post the command/response are correct. But despite this, the event appears unhandled.

I will try to write the buffer to the log as you are telling me and see whats up

8

So are you passing a callback into get_set_scan_parameters()?

The symptoms are that you aren’t, and hence it’s defaulting to null - then, your response handler is identifying the packet right but there’s no function to call so all you see is the event.name (“gap_set_scan_parameters”) and “unhandled”.

Hard to say more without seeing your whole device code, but seems like that’s what is happening.

1 Like
9

Yes, I’m not passing the callback into it, like I said, I’m trying to implement this application (BLE Locator for BLE112 in the function discover_mode()):

The get_set_scan_parameters only takes the first 3 input parameters and the callback is left as default (null).

For the command to take effect I necessarily have to pass the callback? In the case of the BLE112 didn’t seem the case (at least for this application).

Sorry for the noob questions Hugo, is just that is the first time I’m dealing with these applications. I appreciate your answers.

10

Hugo,

Your responses allowed to arrive to a solution. I was worrying about the outcome in the log and the way it is coded, if no callback is passed, it will totally look like this. I didn’t knew that, thanks for clarifying.

:smiley: