Shield continuously disconnects and reconnects

Bug #696562 reported by Jorge Silva
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Tecla Access
Fix Released
High
Jorge Silva

Bug Description

Tekla shield is paired and connected with my Nexus S (running stock 2.3). Unfortunately, it disconnects and immediately reconnects every 15-20 seconds. It never remains disconnected for over a second. If I lock the phone, it unlocks when the shield does its disconnect/reconnect, although not every time I lock.

Is the goal of the perpetual connection/disconnection to keep the device from locking?

Any suggestions?

description: updated
Revision history for this message
Jorge Silva (jorge-silva) wrote :

This is definitely not an expected behaviour. The Android app is designed to automatically reconnect after a connection times out (e.g., when the Shield is too far apart from the phone), but if this was the case, you should be experiencing a longer delay between each reconnection, leaving the phone unusable with the Shield for about half a minute every time.

My guess is that either the application is silently crashing or the system itself is killing and restarting the process. We will have to do some testing before we can provide an accurate diagnosis.

With regards to the unlocking, Tekla is designed to unlock the phone when a switch event from the shield is received and when a shield connects to the phone (so you can use it right away), so this does make sense.

If you have any more info that you think may be relevant to the solution of this issue, feel free to add it to the bug report above or as an additional comment. We will take a look at this for the following release of the Tekla Android app.

Changed in meadl:
importance: Undecided → Medium
assignee: nobody → Jorge Silva (jorge-silva)
Revision history for this message
Jorge Silva (jorge-silva) wrote :

I marked https://bugs.launchpad.net/meadl/+bug/702683 as a duplicate of this one since I believe it is all related. I managed to put a 2.1 Droid/Milestone in a disconnect/reconnect loop and I now believe this is related to an issue with the buffer of the serial port over bluetooth. Currently, the buffer has a size of 1 byte, which may cause problems if the Shield sends data too fast.

First the symptoms, while in this disconnect/reconnect loop I observed the following:
1. The Tekla Shield is completely unusable
2. The Tekla Shield connects and disconnects immediately so it is very likely that the app is crashing
3. The options dialogue becomes inconsistent and unresponsive (e.g., the notification on the status bar appears, the LED on the Tekla Shield is solid green but the option for connecting with the Shield is not checked).
4. Disconnecting and reconnecting the Shield's power does not solve the problem
5. Restarting the phone does not solve the problem

Are you observing these symptoms too?

Now the work around: after a few tries, I managed to make the app work again by doing the following:
1. Unplug the Shield from power
2. Uncheck the connect to Shield option under Tekla keyboard settings
3. Follow this guide:
http://www.mydigitallife.info/2010/07/02/how-to-switch-or-change-input-method-on-android-smart-phone-device/
to select an input method different from the Tekla keyboard
4. Disable (uncheck) the Tekla keyboard under Settings > Language & keyboard
5. With Bluetooth enabled, go to Settings > Wireless & networks > Bluetooth settings, and unpair the FireFly-XXXX entry under Bluetooth devices by long-pressing on it.
6. Restart the phone
This will effectively "reset" the state of the Bluetooth connection to the Shield, so after restarting, we'll have to set it up again:
7. Connect the Shield to a reliable power source (USB to a desktop computer is recommended) and make sure the bluetooth modem at the top has a blinking red light.
8. Go to Settings > Wireless & networks > Bluetooth settings > Scan for devices to pair with the Shield again
9. When prompted for a passcode use 1234
10. The Shield should now be listed as "Paired but not connected"
11. Go to Settings > Language & keyboard and enable the Tekla keyboard
12. Follow this guide:
http://www.mydigitallife.info/2010/07/02/how-to-switch-or-change-input-method-on-android-smart-phone-device/
to select the Tekla keyboard as the input method
13. Go to Settings > Language & keyboard > Tekla keyboard settings > Connect to shield
14. The Tekla Shield should now connect normally to the app showing the UI navigation keyboard

Please post your results...

Changed in meadl:
status: New → Confirmed
importance: Medium → High
Revision history for this message
Tim Barlott (tbarlott) wrote :

I'm glad you have been able to recreate the conditions I am experiencing.

Unfortunately, after following your instructions exactly (multiple times) I am not able to get out of the disconnecting/reconnecting loop.
I also have a Droid 2 running 2.2 and am getting the exact same behavior. Navigation keyboard pops up, but not switch activity and the disconnect/reconnect loop starts up.

Would you like me to make a video of the process or of the disconnect loop and post the youtube link?

Revision history for this message
Jorge Silva (jorge-silva) wrote :

I am sorry you are having so much trouble. Let's try a more aggressive protocol:

1. Uncheck the connect to Shield option under Tekla keyboard settings and wait until the bluetooth modem at the top has a blinking red light.
2. Unplug the Shield from power
3. Follow this guide:
http://www.mydigitallife.info/2010/07/02/how-to-switch-or-change-input-method-on-android-smart-phone-device/
to select an input method different from the Tekla keyboard
4. With Bluetooth enabled, go to Settings > Wireless & networks > Bluetooth settings, and unpair the FireFly-XXXX entry under Bluetooth devices by long-pressing on it.
5. Turn off bluetooth
6. Uninstall the Tekla app
7. Turn off the phone
8. Wait a couple of minutes and remove the battery (sometimes the phones don't really turn off completely)
This will effectively "reset" the state of the Bluetooth connection to the Shield, so after restarting, we'll have to set it up again:
9. Wait a couple of minutes and put the battery back in the phone
10. Turn on the phone
11. Turn on bluetooth
12. Connect the Shield to a reliable power source (USB to a desktop computer is recommended) and make sure the bluetooth modem at the top has a blinking red light.
13. Go to Settings > Wireless & networks > Bluetooth settings > Scan for devices to pair with the Shield again
14. When prompted for a passcode use 1234. The Shield should now be listed as "Paired but not connected"
15. Install the Tekla app from the Market
16. Go to Settings > Language & keyboard and enable the Tekla keyboard
17. Follow this guide:
http://www.mydigitallife.info/2010/07/02/how-to-switch-or-change-input-method-on-android-smart-phone-device/
to select the Tekla keyboard as the input method
18. Go to Settings > Language & keyboard > Tekla keyboard settings > Connect to shield. The Tekla Shield should now connect normally to the app showing the UI navigation keyboard

Revision history for this message
Jorge Silva (jorge-silva) wrote :

Forgot to mention that a video of the phone state would be very useful. I am particularly interested in seeing if the phone is at all responsive to switch events when in this state. If you can, please also add shots of what happens on both the phone and the shield (status LEDs) when checking/unchecking the "connect to shield" and the "always show keyboard" option.

Revision history for this message
Alan Lawrence (acl) wrote :

I am having a similar problem with a different IME programmed to receive SEP broadcasts.

Initially, I was using a very noisy switch (touching copper/electrum wires together! Too noisy to be usable, each touch of the wires generated many on/off switch activations). This seemed to put the switch event provider into a state whereby every 3 seconds or so, a disconnect (with on-screen toast) would be followed immediately by a reconnect, with no perceptible delay inbetween.

Having now rigged up better/less noisy switches, the problem is now more how you describe: after using the switches successfully for some number of presses, (a) further switch presses no longer generate/broadcast switch events, and (b) a disconnect occurs approximately every 15-20 seconds, then reconnecting approx 1sec later. (However, even upon the supposed reconnect, no switch events are broadcast.)

Unplugging the shield from power, waiting 30 secs (until notification disappears from Android status bar), then reconnecting the shield to power, seems to fix the problem (switch presses are then picked up, and there is no disconnect/reconnect cycle, until a good number of switch presses have been made). However, what triggers the shield to get into this state, I'm not sure: the first time it took only 10-20 presses, other times it's been more like 100, now I've been failing to trigger it for hours :) so can't report what LEDs are lit up!

Revision history for this message
Alan Lawrence (acl) wrote :

Happened again when trying to demonstrate at the AEGIS UK Plenary :-(, pretty quickly - after only two or three presses. I think my physical switch h/w was sticking, which correlates with the idea that switch noise is what brings it on. Disconnects then reconnects after short gap, every 15s or so, with no switch events being delivered. Lights on the board were the same as when it's working: only one light, from the green PCB, just underneath the top edge of the red "sparkfun.com" thing. (Top edge = when reading sparkfun.com / BlueSMiRF the right way up, which is the opposite way up to the green board it's stuck on).

Revision history for this message
Jorge Silva (jorge-silva) wrote :

That is really unfortunate Alan. For your purposes, you can try using the previous version of the app (0.1.1 alpha), which did not seem to present this problem, while we work on the issue. You can download it from here: https://launchpad.net/meadl/+download

To install the previous version you will need to use the Android SDK, a brief guide is available here: http://www.brighthub.com/mobile/google-android/articles/37151.aspx and you can find additional details elsewhere online.

If you do end up going that route, it would be very useful if you take a few moments to try triggering the issue with that version as well (perhaps by putting the wires together the way you were doing it before) and report back on what you find out. My guess is that if this is an issue with the buffer size, as I suspected originally, the SEP may crash and simply disconnect or time out (since that version did not have an auto-reconnect loop).

Hope this helps... will keep up the updates with progress on the bug, and thanks again for your patience and help in making sure this works the way it should for end-users.

Revision history for this message
Jorge Silva (jorge-silva) wrote :

I was finally able to identify the origin of this bug. The issue is entirely confined within the Shield, which due to switch bouncing (in the order of nano-seconds), enters a loop that prevents it from sending any data. The App on the other hand, does what it should, that is, tries to reconnect when a connection is lost, but even when connected, the Shield continues to be unresponsive causing the App to think the connection has been lost again (after the 15-30s pinging routine times out).

Workaround: Alan is right in comment #6 above (https://bugs.launchpad.net/meadl/+bug/696562/comments/6) unplugging the Shield from power (not just switching it off) and plugging it again will reset it and eliminate the issue temporarily, but it will be triggered randomly again eventually.

Solution: Unfortunately, this will require a minor change in the hardware because the switch filters need an upgrade. However, this will also give us a chance to make other pending enhancements such as making sure the two boards assemble better. I have started the changes in the following branch: https://code.launchpad.net/~jorge-silva/meadl/arduino-shield and will be merging to trunk as soon as the new boards are tested. I anticipate this will take about 2 weeks.

Changed in meadl:
milestone: none → shield-proto-2
Revision history for this message
Jorge Silva (jorge-silva) wrote :
Changed in meadl:
status: Confirmed → Fix Committed
Changed in meadl:
status: Fix Committed → Fix Released
Revision history for this message
Jorge Silva (jorge-silva) wrote :

I am opening this bug again due to recent reports of a similar behaviour. The reason seems to be quite different this time however, since it only occurs in some handsets and not others.

Changed in meadl:
status: Fix Released → In Progress
milestone: shield-proto-2 → 0.5-beta
Revision history for this message
Jorge Silva (jorge-silva) wrote :

A release candidate is available with a fix. Please test it and report your feedback.

Changed in meadl:
status: In Progress → Fix Released
Changed in meadl:
milestone: 0.5-beta → 0.4.5-alpha
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.