Hey guys,
The following function belongs to the BLE112 class library. On the line that starts with “local header…” a bit mask is used in the position of the first two bits of the header.
Is there any guidance you can provide to understand this part? The bitmasks.
I’m asking because I want that my adaptation for the BGM113 of “send_command” gets always 0x20 as first bit (as it stands for commands and command responses). In the BLE family, the first bit is always 0x00 for these.
I could just hardcode the 0x20 on it and there wouldn’t be issues about it, but the second bit can’t be hardcoded since it varies for each instruction.
function send_command(name, msg_class, msg_id, payload, callback = null) {
server.log(“huh?”)
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(BLE_TIMEOUT, 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", (len >> 8) & 0x07, len & 0xFF, msg_class, msg_id);
server.log(header)
server.log(payload)
uart_write(header, payload);
}
Any help would be deeply appreciated!
You’re getting your bits and bytes muddled. header is a four-byte string that looks to like payload length upper byte, payload length lower byte, message class ID, message ID.
(len >> 8) & 0x07 moves bits 8 through 15 of the length value into bits 0 through 7 then clears (ie. ignores) bits 3 through 7. len & 0xFF ignores all but bits 0 through 7 of the length value. I’m assuming that’s how a length in the range 0-2047 is encoded the way the BLE112 expects.
That suggests you shouldn’t replace one of these with 0x20 because that will mess up the payload size data the BGM will receive. The API 1.0.2 reference manual even names these two bytes as hilen and lolen in the various command tables, but then it also implies the first byte of the header is 0x20.
So I would try changing (len >> 8) & 0x07 to 0x20 and see what happens.
Curiously, the function BLE112 class’ uart_write() function contains some rogue 0x20s, but I can’t see how they’d ever be written out.
Hey!
I did change that first byte to a hardcoded value and disabled this line on the “hexdump” function:
if (ch >= 32 && ch <= 126 && ascii) dbg += format("[%c] ", ch);
It was printing the outcome as 20 00 01 00, now it isn’t. Although I’m still unable to properly send the response 
Curiously, the function BLE112 class’ uart_write() function contains some rogue 0x20 s, but I can’t see how they’d ever be written out.
Indeed, but I don’t see how could they affect. I guess I’ve not stumbled upon that scenario yet. I tried printing flag messages to the server to see if that routine you mention gets activated but it doesn’t (at least not while I’m trying to send “system_hello” command).
You mean this one, right?
if (_packet_m) {
if (payload == null) {
packet_size = format("%c", header.len(), 0x20);
} else {
packet_size = format("%c", header.len() + payload.len(), 0x20);
}
}
I’ve not come across the moment where _packet_m is not null so it can initiate that cycle.