I have added the serialize code right after the connectAndSetup succeeds (inside its callback) and now I pass it as a second parameter as you said.
Still, makes no difference when the process is killed (like when a sigkill is issued or when the raspberry is shut down by pulling the power cord).
However, I added some log lines to metawear.js code, inside the connectAndSetup to see if NobleDevice.prototype.connectAndSetUp is working and to check where does it stop. Looks like the MetaWear.mbl_mw_metawearboard_initialize call never finishes.
This is the output when I execute the code right after killing the process:
MetaWear initializing
Discovered e2:3e:dd:94:99:5f
loading state e2:3e:dd:94:99:5f
Loaded sensor state <Buffer@0x2e91560 01 07 03 01 01 35 19 01 00 00 00 02 00 01 02 03 00 03 01 02 00 04 01 00 04 00 03 01 02 05 00 02 07 03 03 03 03 01 01 01 06 00 00 00 07 00 00 00 08 00 ... >
Connecting e2:3e:dd:94:99:5f ---> this connectAndSetup fails
Disconnected 19 disconnected ----> I capture the disconnect event and issue a new connect() call
trying to reconnect
Connecting e2:3e:dd:94:99:5f ----> Trying again to connect
NobleDevice connected undefined ---> now it works
Deserializing
Initializing
NobleDevice connected undefined ---> wow! two calls of connectAndSetup succeed
Deserializing
Initializing
Sending reset e2:3e:dd:94:99:5f
Disconnecting connected
qDisconnected 19 disconnected
I added some annotations in the code, and you can see that after I try to reconnect, NobleDevice.connectAndSetUp is called twice, and they both end up in the initialize code.
The weird thing appears when I let the process, which is stuck, finish correctly (by pressing 'q'). Then, the next time I launch it works well.
This is the same no matter I use the serialize/deserialize code, which I add in the following block for reference:
function save_state(device) {
console.log("saving state", device.address);
var state_size = ref.alloc(ref.types.uint32);
var buffer = MetaWear.mbl_mw_metawearboard_serialize(device.board, state_size);
var state_buffer = ref.reinterpret(buffer, state_size.deref(), 0);
fs.writeFile(device.address.replace(/:/g,"") + ".txt", state_buffer, function (err) {
if (err) console.log(err);
console.log("State saved");
});
}
function load_state(address, callback) {
console.log("loading state", address);
fs.readFile(address.replace(/:/g,"") + ".txt", function (err, data) {
if (err) console.log(err);
console.log("Loaded sensor state", data);
callback(data);
});
}
function connect (device) {
console.log("Connecting", device.address);
sensor_fusion_setup = false;
device.connectAndSetUp(function (error) {
if (quitting)
MetaWear.mbl_mw_debug_disconnect(device.board);
console.log("Connected", device.address);
save_state(device);
// ........... rest of code
}
// Discover a custom address and setup disconnect handler to reconnect
MetaWear.discoverByAddress(address.toLowerCase(), function (device) {
console.log("Discovered", device.address);
current_device = device;
load_state(device.address, function (data) {
sensor_state = data;
connect(current_device);
});
// ........... rest of code
}
Monitor the BT adapter to see what is going on at the Bluetooth level during connectAndSetup.
It sounds like the connection is still being flooded with sensor fusion data upon reconnect so you probably will want to program the board to stop streaming upon disconnect.
@Eric said:
Monitor the BT adapter to see what is going on at the Bluetooth level during connectAndSetup.
You mean with hcidump?
It sounds like the connection is still being flooded with sensor fusion data upon reconnect so you probably will want to program the board to stop streaming upon disconnect.
How can I "program the board to stop streaming upon disconnect"?
@Eric said:
Monitor the BT adapter to see what is going on at the Bluetooth level during connectAndSetup.
You mean with hcidump?
Yes, log the console output of "hcidump".
It sounds like the connection is still being flooded with sensor fusion data upon reconnect so you probably will want to program the board to stop streaming upon disconnect.
How can I "program the board to stop streaming upon disconnect"?
Ok, I made it to work in some other way. The problem was that the eventListenerse must be removed if the connection resets while board is not initialized.
As of the events, I managed to make the led blink red on disconnect. But looks like the event is now by default, that is, everytime the board disconnects, the red led blinks. I thought recording the event is a "one time event". How can I remove the event handler and reprogram it again? As now I am doing it every time I connect to the board.
/**
* Handles a disconnection Event for the MetaWear board that is passed by recording
* the MetaWear commands that shall be executed on the board when Event is fired.
* @param board calling object
*/
function disconnectionHandler(board){
// Callback to execute when commands have been recorded.
let commandsRecorded = () => {
console.log('MetaWear commands have been recorded.');
};
// Retrieve event pointer representing a disconnect event
let dc_event = MetaWear.mbl_mw_settings_get_disconnect_event(board);
// Start recording MetaWear (!) commands that shall be executed when the disconnect event is fired.
MetaWear.mbl_mw_event_record_commands(dc_event);
// Switch accelerometer to standby.
MetaWear.mbl_mw_acc_stop(board);
// Issue a soft reset.
MetaWear.mbl_mw_debug_reset(board);
// End the command recording and execute the callback.
MetaWear.mbl_mw_event_end_record(dc_event, MetaWear.FnVoid_EventP_Int.toPointer(commandsRecorded));
}
In addition I register an Event Listener for the disconnection that writes a message to my csv-file where I am writing my data to and that ends the data
// (2) Init stream
let dataStream = ServiceCsvFiles.createStream(directory, fileName);
// ...
// (4) Get acceleration signal
let accSignal = ServiceMeMoHardware.getAccDataSignal(MeMoConnected.board);
// ...
// (6) Remove event listener from last iteration
MeMoConnected.removeAllListeners('disconnect');
// (7) Add new event listener for unexpected disconnect
MeMoConnected.addListener('disconnect', () => {
let disconnectMessage = 'Unexpected disconnect!';
// Write one last line (error message) to csv file
ServiceCsvFiles.writeMessageToCsv(dataStream, disconnectMessage);
// End stream
dataStream.end();
// And resolve Promise
resolve(false);
});
Comments
I have added the serialize code right after the connectAndSetup succeeds (inside its callback) and now I pass it as a second parameter as you said.
Still, makes no difference when the process is killed (like when a sigkill is issued or when the raspberry is shut down by pulling the power cord).
However, I added some log lines to metawear.js code, inside the connectAndSetup to see if NobleDevice.prototype.connectAndSetUp is working and to check where does it stop. Looks like the MetaWear.mbl_mw_metawearboard_initialize call never finishes.
This is the output when I execute the code right after killing the process:
I added some annotations in the code, and you can see that after I try to reconnect, NobleDevice.connectAndSetUp is called twice, and they both end up in the initialize code.
The weird thing appears when I let the process, which is stuck, finish correctly (by pressing 'q'). Then, the next time I launch it works well.
This is the same no matter I use the serialize/deserialize code, which I add in the following block for reference:
I have omitted the parts that were posted before.
Monitor the BT adapter to see what is going on at the Bluetooth level during
connectAndSetup.It sounds like the connection is still being flooded with sensor fusion data upon reconnect so you probably will want to program the board to stop streaming upon disconnect.
You mean with hcidump?
How can I "program the board to stop streaming upon disconnect"?
Yes, log the console output of "hcidump".
https://mbientlab.com/cppdocs/0/settings.html#handling-disconnects
Ok, I made it to work in some other way. The problem was that the eventListenerse must be removed if the connection resets while board is not initialized.
As of the events, I managed to make the led blink red on disconnect. But looks like the event is now by default, that is, everytime the board disconnects, the red led blinks. I thought recording the event is a "one time event". How can I remove the event handler and reprogram it again? As now I am doing it every time I connect to the board.
Reset the board to remove the disconnect event.
I solved it the following way:
In addition I register an Event Listener for the disconnection that writes a message to my csv-file where I am writing my data to and that ends the data