-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Listener Error While Receiving Data from Two Xbees at Once Via Bluetooth #8
Comments
Hi @JesseG689, We have not been able to reproduce the problem you mention. The listeners are independent each other, since they are registered in different Could you please paste the code referring to the broadcast receiver? Make sure you register the correct listener with the Best regards. |
Hi @rubenmoral, Thank you for your reply. That's good to know that my code is fine so far. The Listeners are each set to the correct device. The bug occurs immediately when one of the XBee devices is turned off, way before the broadcast receiver even processes the ACTION_ACL_DISCONNECTED event - so I don't think the broadcast receiver could be causing this issue. The ACTION_ACL_DISCONNECTED signal is fired about 20 seconds after powering off one of the XBee devices. My broadcast receiver is initialized within onCreate():
And my broadcast receiver code is as follows:
In order to determine exactly which device was disconnected, I have two timers running on separate threads which check the data every 3 seconds to make sure the Listeners are still receiving data. They check to see if a volatile Boolean variable (receivedSensorxReading) is set to true at least once every 3 seconds while connected.
Every time the Listeners receive and process new data, they set the receivedSensor1Reading and receivedSensor2Reading flags to true Let me know if any of this doesn't make sense and I can explain it better. Thanks for taking the time to look into my issue. |
Just a quick update, I can also get this bug to happen while one Xbee is already connected and the other Xbee is in process of connecting. I'll explain the process...
I'm almost positive that the two Xbee device Listeners are linked together somehow. If anything goes wrong with one, then it shuts down the Listeners for both. Here's the debug error log that I receive during this example process:
|
@JesseG689 unfortunately, we still cannot reproduce your issue. It makes no sense that the listeners are linked because they belong to different objects, and there is not any static class that handles them. May I ask you to send us by email the app source code to take a deeper look and try to reproduce the issue? You can send it to apps.feedback@digi.com. Thanks. |
Hi, I'm fairly new to Kotlin and Android so this might end up being a silly mistake.
I'm trying to design an app which will connect to two XBee3 modules at once via Bluetooth and continuously receive User Data Relay messages from them. I also use Kotlin coroutines to help with threading and preventing the app from being blocked.
I define both device variables and two IUserDataRelayReceiveListeners like this:
I then created two functions which connect to each XBee in the background (I'm just showing the connect function for xBeeDevice1):
Everything works great, and both Listener functions receive and process the data concurrently. I also have a Broadcast Receiver which will detect when they disconnect, and it will run the disconnect() function on the proper XBee device.
I believe I have discovered a bug when I turn off one of the XBees while they are both actively connected. Sometimes (not all the time) the Listener for the other XBee will stop receiving data and not work, so then I'll have to reconnect to get it working again.
So, for example, if I shut power off of xBeeDevice1 then xBeeUserDataListener2 will sometimes stop receiving data, even though xBeeDevice2 is still active.
Do you have any idea how this might be happening? Are the two separate UserDataRelayListeners somehow linked together?
The text was updated successfully, but these errors were encountered: