HE910 CMUX Dropping

13 thoughts on “HE910 CMUX Dropping

  1. This is a different issue than my previous post. 

     

    I noticed that for some reason I cannot keep a CMUX session between the HE910 and my MCU open for more than one day; typically it will fail within 16 hours.  The HE910 will lock up and will not respond to commands over CMUX or regular non CMUX commands.  I was hoping that sending a CMUX disconnect command would return the module to normal AT mode, but it had no effect.

     

    The only way I can get the HE910 to operate properly is by powering cycling the module.  I am operating the module in a low signal area (maybe if the HE910 loses signal it has an internal reset?)  I’m not sure if that could be related to the problem.

     

    If I do not enter CMUX mode, the device will not lock up and communication between my MCU and the HE910 will work well.  I have recorded all the data going over the CMUX’ed UART connection with a probe and I’m not seeing any framing or data errors.  

    I am sending test packets every 10 seconds to verify the connection is still operational, but I’m not sure if that matters either.

      

    Is there anything I need to do to ensure CMUX doesn’t stop working?

     

    Thanks! 

     

    1. Hi Jeff,

       

      are you sure the HE910 is still ON (PRWMON = HIGH) when CMUX communication stops?

      Do you confirm you are using UART, not USB? 

      Does it happen when the module is in idle, TCP/IP connection, PPP…. ?

       

      HE910 fw. version and CMUX driver version?

      1. Andrea,

        I’m using the latest FW version 12.0.0.4, but this issue was also present in 12.0.0.3.

        PWRMON and Reset are still pulled high by the HE910.  The communication is between a microcontroller and the HE910s UART.  If I don’t start CMUX,  regular AT mode  communication will work fine and has been tested for days, so I don’t believe I have a power related issue.

         

        When in CMUX mode, here is how I’m using the ports:

        Control Channel: Send Test command and v24 packets (for Virtual Port 1, 2, and 3) every 10 seconds

        Virtual Port 1: Check registration status (AT+CREG?) and signal strength (AT+CSQ) every 15-20 seconds, check SMS every 180 seconds.

        Virtual Port 2: Send and Receive UDP packets between a server over GPRS or 3G every 15 minutes.

        Virtual Port 3: Check GPS location every 5 seconds.

         

        By using an external full-duplex monitor on the CMUX connection, I’m not seeing a single framing error.  In less than 24 hours, the HE910 will just stop responding to all CMUX frames and won’t return to regular AT mode.

          1. Andrea,

            Sorry for the long delay. I have been trying to find a work-around for this but I haven’t found one.  I did two traces using the TTC trace tool, however so that you have all the info you need I did them from power on until the CMUX stops, so they are quite large (250MB and 70MB respectively).  I can also provide more if needed.

             

            You can download the traces off my dropbox at:

            https://www.dropbox.com/sh/jcbprfpbjgbw6hn/up1hvARK1D 

             

            From what I can tell, it appears that when the CMUX stops responding, that the whole HE910 may have crashed as the trace stops working as well and just repeats the bytes F9 00 1F 00 00 00 AE AE about every second.  You’ll be able to see that in the trace binaries that at the end of each file all you’ll see is those bytes repeated.

             

             

          2. hi Jeff,

             

            can you confirm the log was captured using the auxiliary UART port? because there are a lot of missing parts because of slow baudrate. Do you have the possibility to connect the USB or is not available in your HW ?

             

            We are trying to reproduce the issue here but we need to know what is the AT sequence exchanged on channel2 to set up the UDP connection every 15min.

             

            Thanks

          3. Andrea,

            Is there a way to specify the port speed for the TRACE port?  Perhaps through an AT command?  If so, I will be able to capture the trace at a higher speed.  It appears to capture invalid information when I set the port speed to something higher on the TTC tool, I’m assuming there is a command I need to run on the device as well.

              

            Thanks! 

          4. Hi Jeff,

            the faster way is using the USB.

            But meanwhile can you try to sniff the serial port communication and send me the log of Tx and Rx ( in hex of course .. )

             

          5. Luca,

            For whatever reason, I can’t seem to get any of my HE910s to connect over USB. However, here is a log (converted to hex) of the serial communication.  Everything will work fine for hours, then the communication will stop.  Right now I am determining that the CMUX communication has "crashed" after 30 seconds with no response from the HE910.  (See the last 4 lines of the log.)

            However, I’m fairly sure that this problem may be bigger (unrelated to CMUX) as the trace port also "crashes" and stop trasmitting data at the same time. 

             

            I can upload more logs or change the timeout from 30 seconds to however long or make any other input or communication changes you want and re-run it.

             

            The lines are prefaced with a timestamp in the format:

            HHMMSS.SSS  

              

            Here is the link to the log: https://www.dropbox.com/s/cnjfmyxw33amkj5/1.hex.log 

             

            Thanks! 

             

             

          6. Hi Jeff,

             

            I’m  really sorry , it’s long time I don’t come to you.

            The CMUX sequence you shared with me doesn’t show anythyng strange, apart the fact CMUX stop responding, also to ht etest frame.

            I see you always follow the Test Command with a V24 sequence (RTS 1 DTR 1 ) broadcatted to every virtual channel. Is there a reason for that?

            Anyway , in order to understand what happens I really need a trace, better if over USB.

  2. Andrea, 

    Yes, the trace was captured using the auxiliary port.  I do not have USB access to the HE910, but I will check to see if I can modify one of my boards to accomodate it.

     

    I’m not sure if this has anything to do with it, but I have noticed that this problem seems to happen more often in a weak signal area.

     

    I am not running AT commands on channel 2 every 15 minutes, I am just sending data through an open UDP connection every 15 minutes once the udp connection is set up. Here are the channel 2 AT commands I am running to set it up.  I omitted my ip address below:  

    ————– After Reset ——————

     

    AT+CGATT=0

    OK

     

    ATE0

    OK

     

    AT+CR=1

    OK

     

    AT+CRC=1

    OK

     

    AT+CLIP=1

    OK

     

    AT#USERID=""

    OK

     

    AT#PASSW=""

    OK

     

    ——————After Carrier Registration—————–

     

     

    AT+CGDCONT=1,IP,"c1.korem2m.com",0.0.0.0

    OK

     

    AT+CGQREQ=1,0,0,1,0,0

    OK

     

    AT+CGQMIN=1,0,0,0,0,0

    OK

     

    AT#SKTTO=995

    OK

     

    AT#DSTO=20

    OK

     

    AT#PKTSZ=400

    OK

     

    AT#SCFG=1,1,300,995,200,30

    OK

     

    AT#SGACT?

    #SGACT: 1,0

    OK

     

    AT+CGATT=1

    OK

     

    AT+CGREG?

    +CGREG: 0,1

    OK

     

    AT#SGACT?

    #SGACT: 1,0

    OK

     

    AT#SGACT=1,1

    #SGACT: 10.110.204.203

    OK

     

    AT#SKTD=1,5203,"XXX.XXX.XXX.XXX",255,5204

    CONNECT