Subscribing to Processor/Logger after Reconnection
Hello there,
So I have tried my best to go through the forums thoroughly to find a solution for my problem but with no definite answer.
So say that I connect to a MMC sensor the first time and then configure it while in that same connection where I create the following during my configuration code:
- Stream of Time Processor for Quat signal (or any other signal for acc,gyro, mag, etc)
- Logger of Time processor for Acc signal
- Logger of Gyro signal
So lets say I establish these 3 objects, where I stream subscribe to a time processor (quat) and log a time processor (Acc) and a raw data signal (Gyro).
So, when I start each sensor or any one (Quat,Acc,Gyro) both stream and logger subscriptions work fine as usual and I can also stop them.
Now the problem comes when I try to disconnect and reconnect to that same sensor without resetting it. So the steps that I conduct is the following:
- First connection to MMC
- Configure sensor with the following processors and/or loggers -> save each ID with
mbl_mw_dataprocessor_get_id()
ormbl_mw_logger_get_id()
- Save state of sensor with serialisation
mbl_mw_metawearboard_serialize()
- Move MMC far enough so that sensor forcefully disconnects -> now code will automatically scan for sensor again
- Bring MMC close enough so it can be detected -> discover sensor with
discoverByAddress()
- Connect to MMC but this time with passing the previously saved state as the 2nd argument into
connectAndSetUp(callback, state)
- Recollect processor/logger object with
mbl_mw_dataprocessor_lookup_id()
ormbl_mw_logger_lookup_id()
-> processor / logger objects are found -> I would think that means that the state was loaded correctly - Now when I subscribe to either processor/logger and start their fundamental signal (wither that is quat,acc, or gyro) I get no outputs.....
So this is the problem I am facing. I am not receiving any data from loggers and processors after a disconnect while I am sure I am receiving data before a disconnect occurs. I have tried to do the same thing but with just stream subscribing to the raw data streams (quat, acc, gyro) and they work correctly where if I start stream quat then disconnect and connect again and then subscribe to quat again, I instantly receive data points (of course without telling it to start the quat). This means that the sensor's configuration which I programmed it before the disconnect is still incontact after the disconnect as I started the quat signal before the disconnect.
I have also tried to create an event which stops the sensor (ex. quat) if it is streaming upon disconnect and then when it reconnects to start it again (in the case of streaming of course not logging) but same results.
The point being is that the processor and logger objects that I receive after a disconnection don't work. This is very problematic because as you can guess, what if I want to keep logging after a disconnection and then reconnect to stop logging and download but cannot because I cannot subscribe to that logger or more precisely don't receive data from it. The code is a bit big so it is hard to post but I have tried to explain the procedure as follows. So, do you have any idea why would the processor/logger objects not work after a forced disconnect which was created in a previous connection session?
Comments
Is there any ideas related to this problem? This is very crucial as disconnection is very frequent and so if I cannot resubscribe to the logs/processors after I reconnect that is a huge problem.
Any help is appreciated. Thank you.
I will have to look into this myself in the next couple of days. I will see if I can reproduce.
Okay thank you.
Are there any updates on this issue?
Hey @abdalrahman9 and @atonino
Apologies, this got overlooked. Im going to put this back into my task list.
Any luck with finding a solution for this?
bump
Can't a solution be found for this. This is a very problematic issue because as if now I require to reset the whole system when at least one device disconnects .... as the API cannot be used to resubscribe to the loggers and download from them ....This is a very big fault in the API