Announcement

Collapse
No announcement yet.

Moto E4 Phones Disconnecting

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Moto E4 Phones Disconnecting

    We have 3 pair of Verizon moto E4

  • #2
    Hi FTC11180

    Could you elaborate on how they are disconnecting? Is it the wifi that is disconnecting or is the USB connection to your REV Robotics Expansion Hub?

    Tom

    Comment


    • #3
      Tom Eng thank you for responding. It is the wifi that is disconnecting. We have 3 pair of moto e4's, and we have been programming with them since September. However, it was not until a competition that we discovered the problem. Once we have pressed init in autonomous, within a minute or so the wifi seems to disconnect. The phones make a chime, and autonomous is no longer initialized. Upon returning to school we tried the other two pair of moto e4's and found they disconnect in the same manner. We loaded the same code onto moto g4s and they can sit in an initialized state without disconnecting. Not all of the phones were up to date from motorola so we performed the system updates. The moto e4s still disconnect while initialized in autonomous. We downloaded a fresh driver station app, and robot controller app and essentially used just the pushbot drive by time sample code and they still disconnected (our original code was using dogecv, so our testing seems to have eliminated that). Through networking, it seems we have found at least one other team out there who is having the same experience. I hope this helps uncover the problem. Thank you.

      Comment


      • #4
        Here is the code working

        Comment


        • #5
          Sorry, here it is
           

          Comment


          • #6
            I can confirm that we are seeing this also with our Moto E4 phones. For some opModes (see below), if Init is pushed and the phones and robot are sitting and waiting (as usually happens before autonomous starts), after 30-60 seconds the phone will disconnect and the DS goes back to "Select Op Mode" with nothing selected.


            Some data points:

            We ran a moderately complex opMode, with Vuforia initialized. It DOES disconnect in this case.

            We ran a simple linear opMode with nothing but runTime telemetry messages being sent to the DS. It does NOT appear to disconnect in this case (we waited for over 3 minutes and it was still OK waiting for the Play button to be pressed).

            We ran the ConceptVuforiaNavRoverRuckus sample opMode with the only change being adding our vuforia key. It DOES disconnect in this case. Tech team, can you reproduce this problem by running this opMode on a pair of synced MotoE4 phones?

            So perhaps the issue is Vuforia related? FTC11180, did you have Vuforia active?

            Tech team, please help ASAP as this makes the Moto E4 phones unusable in competition (at least with Vuforia and/or Vuforia-frame-based CV)!!

            A few lines of the AS Logcat when this happens are below
            Code:
            10-31 08:49:20.779 1466-1936/? E/IzatSvc_Wiper: W/Num of elements returned by LOWI 1
            10-31 08:49:20.784 1466-1760/? D/HS20: Clearing ANQP cache: all: false
            10-31 08:49:20.787 1954-2033/? I/QCNEJ: |CORE| CNE received action: android.net.wifi.STATE_CHANGE
            10-31 08:49:20.788 1954-2033/? I/QCNEJ: |CORE| Updating network info: [type: WIFI[], state: DISCONNECTED/DISCONNECTED, reason: (unspecified), extra: <unknown ssid>, failover: false, available: true, roaming: false, metered: false]
            10-31 08:49:20.788 1954-2033/? D/QCNEJ: |CORE| Wifi Info Reset
            10-31 08:49:20.788 1954-2033/? I/QCNEJ: |CORE| WifiInfo was reset, abandoning update
                |PB_MSG| sendWifiStatus - subType: 101 networkState: 4 wifiState: 3 rssi=0 freqBand = _2GHz ssid= bssid=00:00:00:00:00:00 ipV4Addr= ifNameV4= ipAddrV6= ifNameV6= timeStamp:2018-10-31 08:49:20.788 net handle=0 isAndroidValidated = false DNS addrs= 0.0.0.0, 0.0.0.0, 0.0.0.0, 0.0.0.0, 
            10-31 08:49:20.790 1954-2033/? I/QCNEJ: |PB_MSG| ****encoding**** --> notifyRatConnectStatus ratType=1 status=4 ipV4Addr= ipV6Addr=
            10-31 08:49:21.822 10896-11063/com.qualcomm.ftcrobotcontroller V/Robocol: issuing peerDisconnected(): lastRecvPacket=2.029 s
            10-31 08:49:21.823 10896-11063/com.qualcomm.ftcrobotcontroller V/RobotCore: Network: unknown, disconnected
            10-31 08:49:21.826 10896-11063/com.qualcomm.ftcrobotcontroller I/RobotCore: ******************** STOP - OPMODE /storage/emulated/0/FIRST/matchlogs/Match-0-Concept:_Vuforia_Rover_Nav.txt ********************
            10-31 08:49:21.826 10896-11054/com.qualcomm.ftcrobotcontroller W/AudioTrack: AUDIO_OUTPUT_FLAG_FAST denied by client; transfer 4, track 44100 Hz, output 48000 Hz
            10-31 08:49:21.827 10896-11063/com.qualcomm.ftcrobotcontroller I/RobotCore: Lost connection while running op mode: Concept: Vuforia Rover Nav
            10-31 08:49:21.828 10896-11908/com.qualcomm.ftcrobotcontroller I/RobotCore: saving match logcat to /storage/emulated/0/FIRST/matchlogs/Match-0-Concept:_Vuforia_Rover_Nav.txt
                logging command line: exec logcat -d -T '10-31 8:48:47.000' -f /storage/emulated/0/FIRST/matchlogs/Match-0-Concept:_Vuforia_Rover_Nav.txt -n4 -v threadtime UsbRequestJNI:S UsbRequest:S art:W ThreadPool:W System:W ExtendedExtractor:W OMXClient:W MediaPlayer:W dalvikvm:W  *:V
            Code:
            
            


            CHEER4FTC website and facebook online FTC resources.
            Providing support for FTC Teams in the Charlottesville, VA area and beyond.

            Comment


            • #7
              We are not using vuforia, only dogeCV. However, when we downloaded a fresh app, and only used a very simple linear autonomous (the dogecv modules were not imported, it was a fresh app) that just moved the robot forward, the phones still disconnect when sitting in the "init" state.

              Comment


              • #8
                An interesting data point.

                I paired an E4 DS with an E4 RC and ran the ConceptVuforiaNavRoverRuckus opMode waiting after init for play. It disconnected.

                I paired a ZTE DS with a ZTE RC running the same thing. It did NOT disconnect.

                I paired a ZTE DS with an E4 RC running the same thing. It did NOT disconnect.

                I paired an E4 DS with a ZTE RC running the same thing. It DID disconnect.


                From these experiments, it looks like it may be an issue running the DS software on the E4 phone???
                CHEER4FTC website and facebook online FTC resources.
                Providing support for FTC Teams in the Charlottesville, VA area and beyond.

                Comment


                • #9
                  Cheer4FTC we just tried a similar setup, using the E4 as the RC and a G4 as the DS. We have left it initialized for quite a long time and no disconnect. It does seems that the issue is occuring when the E4 is the DS. Im just surprised more teams aren't reporting an issue.

                  Comment


                  • #10
                    I'm guessing only a few teams have competed so far (where this issue shows up) and a small percentage are using E4s, so the overlap is not a lot of teams at this time.
                    CHEER4FTC website and facebook online FTC resources.
                    Providing support for FTC Teams in the Charlottesville, VA area and beyond.

                    Comment


                    • #11
                      We're having problems with our E4 phones, but haven't been able to track it down yet. We've been following the thread, but didn't have any answers to offer.

                      The problems we're having seem random and we haven't identified any patterns yet.

                      The phones are new, so we've been trying to get the settings right. Our first thought was that the problem might have been coming from all of the preinstalled Apps. It seemed like there were random messages asking for updates, or that some app didn't have access to the internet. We've been disabling apps and blocking notifications, which has helped a bit.

                      At the moment, our main challenge is tele-op. It will work for a short period of time (10-15 minutes), and then the robot starts behaving strangely. One time the right side of the drive system stays on at full power even when no one is touching the controller. (Watching the robot do donuts is cute, but not effective.)

                      Sometimes a complete power cycle will work, other times not. Last night, driver practice ended without the team being able to restart the robot.

                      The log files hinted at some possible things to check, but we're a long way from solving the issue.

                      We've ran autonomous, but only for program testing. Our robot hasn't spent time waiting for start, so no data to add to that discussion yet.

                      Comment


                      • #12
                        Are you running a LinearOpMode for your Autonomous? If not, ignore the rest of this post as it only is relevant if you're running a LinearOpMode.

                        If you are doing LinearOpMode then when you have the disconnects, are you calling waitForStart(); or are you doing a while (!isStarted() && !isStopRequested()) { telemetry-stuff; }?

                        If you are using waitForStart(), what about trying the while !isStarted() and sending telemetry back to the driver station.

                        One of the comments in this thread mentioned using the E4's as the DS and RC didn't have the problem when the OpMode was passing back telemetry while waiting, so I'm wondering if there's possibly some timeout on the E4 that might be in the DS when it's not getting anything back from the robotController (there's supposed to be a keepalive, but who knows), and if you can actively make the DS do something while waiting, it might not disconnect.

                        I hope this helps.

                        -- Gordon.

                        Comment


                        • #13
                          Good thinking, gorpong ! If I run a basic linear opMode with the following code replacing waitForStart(), it seems to sit in init just fine.
                          Code:
                            
                           while (!opModeIsActive()&&!isStopRequested()) {     telemetry.addData("Status", "Waiting in Init");     telemetry.update(); }
                          but if I comment out the 2 telemetry lines, it disconnects after 30-60 seconds. So this does seem to point towards some timeout issue in the Moto E4 driver station if it doesn't get any messages for a while.

                          FTC11180 , try replacing your waitForStart() with the above code and see if that possible workaround addresses your issues until the real bug can be found and fixed.
                          CHEER4FTC website and facebook online FTC resources.
                          Providing support for FTC Teams in the Charlottesville, VA area and beyond.

                          Comment


                          • #14
                            Thanks all for the detailed info. We'll check this out. I wonder if this is some type of power save issue (just thinking out loud - I do not have any evidence that it is).

                            Comment


                            • #15
                              [QUOTE=Cheer4FTC;n67270]Good thinking, gorpong ! If I run a basic linear opMode with the following code replacing waitForStart(), it seems to sit in init just fine.
                              Code:
                              while (!opModeIsActive()&&!isStopRequested()) { telemetry.addData("Status", "Waiting in Init"); telemetry.update(); }
                              but if I comment out the 2 telemetry lines, it disconnects after 30-60 seconds. So this does seem to point towards some timeout issue in the Moto E4 driver station if it doesn't get any messages for a while.

                              Any chance of getting a Driver Station log with the fail in it.
                              Seems like the smoking gun would be in there...

                              Comment

                              Working...
                              X