This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

WL1801: RX packets delay and loss trouble

Other Parts Discussed in Thread: WL1801Hi Team,

We are using WL1801 on our board, please see below.
 CPU:
  SH based custom board
 OS:
  Linux Kernel 2.4.31
 WiLink8 Module:
  Murata LBEP5CLWTC-601TEMP
 WiLink8 Driver Version:
  MCP-8.0.0.52_Release (MCP 8.5 SP2)
 WiLink8 Firmware Version:
  Rev 8.9.0.0.76 and Rev 8.9.0.0.79 (included in MCP 8.5 SP3)
We are having a trouble of RX packets delay and loss.
The trouble occurs when our device transmits and receives data with WL1801 continuously.
The time it takes to occur the trouble is variable within a few hours to a few days.
Once the trouble occurs, any wireless communication doesn't work until reconnecting to the AP.

Our verification procedure is as following:

(1) Configure the power management mode
 defaultPowerLevel = 2
 BeaconListenInterval = 1
 DtimListenInterval = 1
 psTimeOut = 150
 powerSaveDozeMode = 1
 ReAuthActivePriority = 1
 BeaconReceiveTime = 50
(2) Start capturing packets with Wireshark

(3) Connect to the AP
Authentication: WPA2-PSK or WPA-PSK
Encryption: AES
Channel: 11 (HT20)

(4) Perform ping from our device to AP

Outputs of ping before the trouble are:
 64 bytes from 192.168.64.1: icmp_seq=4480 ttl=255 time=1.6 ms
 64 bytes from 192.168.64.1: icmp_seq=4481 ttl=255 time=2.1 ms
 64 bytes from 192.168.64.1: icmp_seq=4482 ttl=255 time=3.8 ms
 64 bytes from 192.168.64.1: icmp_seq=4483 ttl=255 time=2.0 ms
Outputs of ping after the trouble are:
 64 bytes from 192.168.64.1: icmp_seq=4485 ttl=255 time=1023.5 ms
 64 bytes from 192.168.64.1: icmp_seq=4486 ttl=255 time=1032.1 ms
 64 bytes from 192.168.64.1: icmp_seq=4487 ttl=255 time=1141.0 ms
 64 bytes from 192.168.64.1: icmp_seq=4488 ttl=255 time=276.4 ms
A part of sniffer log after the trouble is:
 No.     Time                          SrcMAC                DstMAC                Source                Destination           Protocol Length Info
   61286 2020-10-13 11:47:04.933153040 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     190    Echo (ping) request  id=0xdb03, seq=4520/43025, ttl=64 (no response found!)
   61287 2020-10-13 11:47:04.933161647                                                                   TexasIns_ae:89:5e (a8:1b:6a:ae:89:5e) (RA) 802.11   70     Acknowledgement, Flags=........C
   61288 2020-10-13 11:47:04.964827073 00:1b:8b:6e:b6:24     ff:ff:ff:ff:ff:ff     NECPlatf_6e:b6:24     Broadcast             802.11   324    Beacon frame, SN=1961, FN=0, Flags=........C, BI=100, SSID=ap51
   61289 2020-10-13 11:47:05.067198025 00:1b:8b:6e:b6:24     ff:ff:ff:ff:ff:ff     NECPlatf_6e:b6:24     Broadcast             802.11   324    Beacon frame, SN=1962, FN=0, Flags=........C, BI=100, SSID=ap51
   61290 2020-10-13 11:47:05.169764252 00:1b:8b:6e:b6:24     ff:ff:ff:ff:ff:ff     NECPlatf_6e:b6:24     Broadcast             802.11   324    Beacon frame, SN=1963, FN=0, Flags=........C, BI=100, SSID=ap51
   61291 2020-10-13 11:47:05.272073658 00:1b:8b:6e:b6:24     ff:ff:ff:ff:ff:ff     NECPlatf_6e:b6:24     Broadcast             802.11   324    Beacon frame, SN=1964, FN=0, Flags=........C, BI=100, SSID=ap51
   61292 2020-10-13 11:47:05.374179148 00:1b:8b:6e:b6:24     ff:ff:ff:ff:ff:ff     NECPlatf_6e:b6:24     Broadcast             802.11   324    Beacon frame, SN=1965, FN=0, Flags=........C, BI=100, SSID=ap51
   61293 2020-10-13 11:47:05.476838972 00:1b:8b:6e:b6:24     ff:ff:ff:ff:ff:ff     NECPlatf_6e:b6:24     Broadcast             802.11   324    Beacon frame, SN=1966, FN=0, Flags=........C, BI=100, SSID=ap51
   61294 2020-10-13 11:47:05.579234724 00:1b:8b:6e:b6:24     ff:ff:ff:ff:ff:ff     NECPlatf_6e:b6:24     Broadcast             802.11   324    Beacon frame, SN=1967, FN=0, Flags=........C, BI=100, SSID=ap51
   61295 2020-10-13 11:47:05.683244617 00:1b:8b:6e:b6:24     ff:ff:ff:ff:ff:ff     NECPlatf_6e:b6:24     Broadcast             802.11   324    Beacon frame, SN=1968, FN=0, Flags=........C, BI=100, SSID=ap51
   61296 2020-10-13 11:47:05.784061081 00:1b:8b:6e:b6:24     ff:ff:ff:ff:ff:ff     NECPlatf_6e:b6:24     Broadcast             802.11   324    Beacon frame, SN=1969, FN=0, Flags=........C, BI=100, SSID=ap51
   61297 2020-10-13 11:47:05.886188142 00:1b:8b:6e:b6:24     ff:ff:ff:ff:ff:ff     NECPlatf_6e:b6:24     Broadcast             802.11   324    Beacon frame, SN=1970, FN=0, Flags=........C, BI=100, SSID=ap51
At No.61286)
Our device sets the power management bit in the Frame Control Field, goes into sleep mode.
 Frame 61286: 190 bytes on wire (1520 bits), 190 bytes captured (1520 bits) on interface mon0, id 0
 Radiotap Header v0, Length 52
 802.11 radio information
 IEEE 802.11 QoS Data, Flags: .p.P...TC
     Type/Subtype: QoS Data (0x0028)
     Frame Control Field: 0x8851
         .... ..00 = Version: 0
         .... 10.. = Type: Data frame (2)
         1000 .... = Subtype: 8
         Flags: 0x51
             .... ..01 = DS status: Frame from STA to DS via an AP (To DS: 1 From DS: 0) (0x1)
             .... .0.. = More Fragments: This is the last fragment
             .... 0... = Retry: Frame is not being retransmitted
             ...1 .... = PWR MGT: STA will go to sleep
             ..0. .... = More Data: No data buffered
             .1.. .... = Protected flag: Data is protected
             0... .... = Order flag: Not strictly ordered
     .000 0000 0010 1100 = Duration: 44 microseconds
     Receiver address: NECPlatf_6e:b6:24 (00:1b:8b:6e:b6:24)
     Transmitter address: TexasIns_ae:89:5e (a8:1b:6a:ae:89:5e)
     Destination address: NECPlatf_6e:b6:22 (00:1b:8b:6e:b6:22)
     Source address: TexasIns_ae:89:5e (a8:1b:6a:ae:89:5e)
     BSS Id: NECPlatf_6e:b6:24 (00:1b:8b:6e:b6:24)
     STA address: TexasIns_ae:89:5e (a8:1b:6a:ae:89:5e)
     .... .... .... 0000 = Fragment number: 0
     1001 1010 1000 .... = Sequence number: 2472
     Frame check sequence: 0xdbd13c88 [unverified]
     [FCS Status: Unverified]
     Qos Control: 0x0000
     CCMP parameters
 Logical-Link Control
 Internet Protocol Version 4, Src: 192.168.64.130, Dst: 192.168.64.1
 Internet Control Message Protocol
At No.61288-61297)
The AP has buffered the ping packets for our device, sets the bit in the Traffic Indication Map.
But our device stays in sleep mode for a while.
 Frame 61288: 324 bytes on wire (2592 bits), 324 bytes captured (2592 bits) on interface mon0, id 0
 Radiotap Header v0, Length 56
 802.11 radio information
 IEEE 802.11 Beacon frame, Flags: ........C
 IEEE 802.11 Wireless Management
     Fixed parameters (12 bytes)
     Tagged parameters (228 bytes)
         Tag: SSID parameter set: ap51
         Tag: Supported Rates 1(B), 2(B), 5.5(B), 11(B), 6, 9, 12, 18, [Mbit/sec]
         Tag: DS Parameter set: Current Channel: 11
         Tag: Traffic Indication Map (TIM): DTIM 0 of 0 bitmap
             Tag Number: Traffic Indication Map (TIM) (5)
             Tag length: 4
             DTIM count: 0
             DTIM period: 1
             Bitmap control: 0x00
             Partial Virtual Bitmap: 02
             Association ID: 0x01
         Tag: ERP Information
         Tag: Extended Supported Rates 24, 36, 48, 54, [Mbit/sec]
         Tag: Vendor Specific: Microsoft Corp.: WMM/WME: Parameter Element
         Tag: Vendor Specific: Epigram, Inc.: HT Capabilities (802.11n D1.10)
         Tag: HT Capabilities (802.11n D1.10)
         Tag: Vendor Specific: Epigram, Inc.: HT Additional Capabilities (802.11n D1.00)
         Tag: HT Information (802.11n D1.10)
         Tag: Vendor Specific: Atheros Communications, Inc.: Advanced Capability
         Tag: Vendor Specific: Atheros Communications, Inc.: Unknown
         Tag: Vendor Specific: NEC Platforms, Ltd.
         Tag: Vendor Specific: Microsoft Corp.: WPA Information Element
We would like to resolve the trouble.
Do you have relevant known issues, etc.

Best regards,
Kenichi.
  • Hi,

    You may try disabling 802.11 PS and ELP and re-test

    https://processors.wiki.ti.com/index.php/WL18xx_Driver_Debug#Disable.2FEnable_ELP

    Thanks

    Saurabh

  • Hi Saurabh,

    Thank you for your response.

    We are trying your suggestion.

    One moment, please.

    Regards,

    Kenichi
  • Hi Saurabh,

    We have tried your suggestion.

    But the trouble has occurred, please see below.

    The setting of set_power_mode is:
    # wlan_cu
    > / w p 1
    > / q
    
    We are using wlan_cu command instead of iw command because of using MCP8.5 SP2 on Linux Kernel 2.4.31 and Wireless Extensions.

    The setting of set_default_powerlevel is already Awake (is not ELP).
    defaultPowerLevel = 2
    
    A part of ping log is:
    [2020-11-13 00:24:54.734] 64 bytes from 192.168.64.1: icmp_seq=32691 ttl=255 time=1.9 ms
    [2020-11-13 00:24:55.734] 64 bytes from 192.168.64.1: icmp_seq=32692 ttl=255 time=2.1 ms
    [2020-11-13 00:24:56.735] 64 bytes from 192.168.64.1: icmp_seq=32693 ttl=255 time=2.0 ms
    [2020-11-13 00:24:57.736] 64 bytes from 192.168.64.1: icmp_seq=32694 ttl=255 time=1.8 ms
    [2020-11-13 00:24:58.737] 64 bytes from 192.168.64.1: icmp_seq=32695 ttl=255 time=1.5 ms
    [2020-11-13 00:25:14.059] 64 bytes from 192.168.64.1: icmp_seq=32710 ttl=255 time=305.4 ms
    [2020-11-13 00:25:15.697] 64 bytes from 192.168.64.1: icmp_seq=32711 ttl=255 time=941.2 ms
    [2020-11-13 00:25:17.078] 64 bytes from 192.168.64.1: icmp_seq=32713 ttl=255 time=321.8 ms
    [2020-11-13 00:25:27.019] 64 bytes from 192.168.64.1: icmp_seq=32723 ttl=255 time=250.7 ms
    [2020-11-13 00:25:35.940] 64 bytes from 192.168.64.1: icmp_seq=32732 ttl=255 time=162.0 ms
    
    A part of sniffer log is:
    No.     Time                          SrcMAC                DstMAC                Source                Destination           Protocol Length Info
     225626 2020-11-13 00:24:53.867364154 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     190    Echo (ping) request  id=0x5303, seq=32691/45951, ttl=64 (reply in 225628)
     225628 2020-11-13 00:24:53.867592579 00:1b:8b:6e:b6:22     a8:1b:6a:ae:89:5e     192.168.64.1          192.168.64.130        ICMP     190    Echo (ping) reply    id=0x5303, seq=32691/45951, ttl=255 (request in 225626)
     225646 2020-11-13 00:24:54.868457164 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     190    Echo (ping) request  id=0x5303, seq=32692/46207, ttl=64 (reply in 225648)
     225648 2020-11-13 00:24:54.869105882 00:1b:8b:6e:b6:22     a8:1b:6a:ae:89:5e     192.168.64.1          192.168.64.130        ICMP     190    Echo (ping) reply    id=0x5303, seq=32692/46207, ttl=255 (request in 225646)
     225665 2020-11-13 00:24:55.869979542 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     190    Echo (ping) request  id=0x5303, seq=32693/46463, ttl=64 (reply in 225667)
     225667 2020-11-13 00:24:55.870009197 00:1b:8b:6e:b6:22     a8:1b:6a:ae:89:5e     192.168.64.1          192.168.64.130        ICMP     190    Echo (ping) reply    id=0x5303, seq=32693/46463, ttl=255 (request in 225665)
     225683 2020-11-13 00:24:56.870961650 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     190    Echo (ping) request  id=0x5303, seq=32694/46719, ttl=64 (reply in 225685)
     225685 2020-11-13 00:24:56.870988434 00:1b:8b:6e:b6:22     a8:1b:6a:ae:89:5e     192.168.64.1          192.168.64.130        ICMP     190    Echo (ping) reply    id=0x5303, seq=32694/46719, ttl=255 (request in 225683)
     225704 2020-11-13 00:24:57.871742046 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     190    Echo (ping) request  id=0x5303, seq=32695/46975, ttl=64 (reply in 225706)
     225706 2020-11-13 00:24:57.871772785 00:1b:8b:6e:b6:22     a8:1b:6a:ae:89:5e     192.168.64.1          192.168.64.130        ICMP     190    Echo (ping) reply    id=0x5303, seq=32695/46975, ttl=255 (request in 225704)
     225747 2020-11-13 00:24:59.662573142 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     190    Echo (ping) request  id=0x5303, seq=32696/47231, ttl=64 (no response found!)
     225843 2020-11-13 00:25:04.782613859 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     190    Echo (ping) request  id=0x5303, seq=32701/48511, ttl=64 (no response found!)
     225859 2020-11-13 00:25:05.482303852 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     190    Echo (ping) request  id=0x5303, seq=32702/48767, ttl=64 (no response found!)
     225952 2020-11-13 00:25:10.618820210 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     190    Echo (ping) request  id=0x5303, seq=32707/50047, ttl=64 (no response found!)
     225971 2020-11-13 00:25:11.712516002 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     190    Echo (ping) request  id=0x5303, seq=32708/50303, ttl=64 (no response found!)
     225974 2020-11-13 00:25:11.898852504 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     198    Echo (ping) request  id=0x5303, seq=32708/50303, ttl=64 (no response found!)
     225975 2020-11-13 00:25:11.898858106 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     198    Echo (ping) request  id=0x5303, seq=32709/50559, ttl=64 (no response found!)
     226004 2020-11-13 00:25:13.132448982 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     190    Echo (ping) request  id=0x5303, seq=32710/50815, ttl=64 (reply in 226007)
     226007 2020-11-13 00:25:13.193077224 00:1b:8b:6e:b6:22     a8:1b:6a:ae:89:5e     192.168.64.1          192.168.64.130        ICMP     190    Echo (ping) reply    id=0x5303, seq=32710/50815, ttl=255 (request in 226004)
     226044 2020-11-13 00:25:14.829554322 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     190    Echo (ping) request  id=0x5303, seq=32711/51071, ttl=64 (reply in 226046)
     226046 2020-11-13 00:25:14.829581326 00:1b:8b:6e:b6:22     a8:1b:6a:ae:89:5e     192.168.64.1          192.168.64.130        ICMP     190    Echo (ping) reply    id=0x5303, seq=32711/51071, ttl=255 (request in 226044)
     226051 2020-11-13 00:25:15.142490157 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     190    Echo (ping) request  id=0x5303, seq=32712/51327, ttl=64 (no response found!)
     226069 2020-11-13 00:25:16.142195903 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     190    Echo (ping) request  id=0x5303, seq=32713/51583, ttl=64 (reply in 226071)
     226071 2020-11-13 00:25:16.212829597 00:1b:8b:6e:b6:22     a8:1b:6a:ae:89:5e     192.168.64.1          192.168.64.130        ICMP     190    Echo (ping) reply    id=0x5303, seq=32713/51583, ttl=255 (request in 226069)
     226108 2020-11-13 00:25:17.938891464 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     198    Echo (ping) request  id=0x5303, seq=32714/51839, ttl=64 (no response found!)
     226109 2020-11-13 00:25:17.938909127 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     198    Echo (ping) request  id=0x5303, seq=32715/52095, ttl=64 (no response found!)
     226151 2020-11-13 00:25:19.962386110 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     190    Echo (ping) request  id=0x5303, seq=32717/52607, ttl=64 (no response found!)
     226270 2020-11-13 00:25:26.091661225 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     198    Echo (ping) request  id=0x5303, seq=32723/54143, ttl=64 (reply in 226274)
     226274 2020-11-13 00:25:26.152958682 00:1b:8b:6e:b6:22     a8:1b:6a:ae:89:5e     192.168.64.1          192.168.64.130        ICMP     190    Echo (ping) reply    id=0x5303, seq=32723/54143, ttl=255 (request in 226270)
     226296 2020-11-13 00:25:27.412120825 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     190    Echo (ping) request  id=0x5303, seq=32724/54399, ttl=64 (no response found!)
     226356 2020-11-13 00:25:30.872213495 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     190    Echo (ping) request  id=0x5303, seq=32727/55167, ttl=64 (no response found!)
     226385 2020-11-13 00:25:31.783235892 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     190    Echo (ping) request  id=0x5303, seq=32728/55423, ttl=64 (no response found!)
     226432 2020-11-13 00:25:34.408550978 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     190    Echo (ping) request  id=0x5303, seq=32731/56191, ttl=64 (no response found!)
     226443 2020-11-13 00:25:35.001334145 a8:1b:6a:ae:89:5e     00:1b:8b:6e:b6:22     192.168.64.130        192.168.64.1          ICMP     190    Echo (ping) request  id=0x5303, seq=32732/56447, ttl=64 (reply in 226445)
     226445 2020-11-13 00:25:35.074637779 00:1b:8b:6e:b6:22     a8:1b:6a:ae:89:5e     192.168.64.1          192.168.64.130        ICMP     190    Echo (ping) reply    id=0x5303, seq=32732/56447, ttl=255 (request in 226443)
    
    Our device consistently clears the power management bit in the OoS Data Packets, doesn't go into sleep mode.

    However ping packets delay and loss occurs.

    In addition, aggregated ICMP Echo Requests often appears after the trouble.

    For example is No.226108 and No.226109.
    Frame 226108: 198 bytes on wire (1584 bits), 198 bytes captured (1584 bits) on interface mon0, id 0
    Radiotap Header v0, Length 60
    802.11 radio information
        PHY type: 802.11n (HT) (7)
        MCS index: 7
        Bandwidth: 20 MHz (0)
        Short GI: False
        FEC: BEC (0)
        Number of STBC streams: 0
        Data rate: 65.0 Mb/s
        Channel: 11
        Frequency: 2462MHz
        Signal strength (dBm): -50dBm
        .... .... .... .... .... .... .... ...0 = Last part of an A-MPDU: False
        .... .... .... .... .... .... .... ..0. = A-MPDU delimiter CRC error: False
        A-MPDU aggregate ID: 7928219
        [Duration: 56µs]
    IEEE 802.11 QoS Data, Flags: .p.....TC
    Logical-Link Control
    Internet Protocol Version 4, Src: 192.168.64.130, Dst: 192.168.64.1
    Internet Control Message Protocol
    
    Frame 226109: 198 bytes on wire (1584 bits), 198 bytes captured (1584 bits) on interface mon0, id 0
    Radiotap Header v0, Length 60
    802.11 radio information
        PHY type: 802.11n (HT) (7)
        MCS index: 7
        Bandwidth: 20 MHz (0)
        Short GI: False
        FEC: BEC (0)
        Number of STBC streams: 0
        Data rate: 65.0 Mb/s
        Channel: 11
        Frequency: 2462MHz
        Signal strength (dBm): -50dBm
        .... .... .... .... .... .... .... ...0 = Last part of an A-MPDU: False
        .... .... .... .... .... .... .... ..0. = A-MPDU delimiter CRC error: False
        A-MPDU aggregate ID: 7928219
        [Duration: 56µs]
    IEEE 802.11 QoS Data, Flags: .p.....TC
    Logical-Link Control
    Internet Protocol Version 4, Src: 192.168.64.130, Dst: 192.168.64.1
    Internet Control Message Protocol
    
    It seems that transmitting packets doesn't work either.

    Regards,

    Kenichi
  • Hi Kenichi,

    As a troubleshooting step, can you pls test with latest firmware version :https://git.ti.com/cgit/wilink8-wlan/wl18xx_fw/log/

    This version is mostly tested with NLCP driver,  but it would be a good test to see if you see any change in behavior with this version.

    Regards

    Saurabh

  • Hi Saurabh,

    I tested with latest firmware version: 8.9.0.0.86.

    But the trouble was not improved.

    Regards,

    Kenichi
  • Hi,

    Can you pls test with short doze setting - powerSaveDozeMode = 0

    Regards

    Saurabh

  • Hi Saurabh,

    I tested with short doze setting.

    It worked for about one week, but the trouble, the same as before, occurred.

    Regards,

    Kenichi
  • Sasaki-san,

    We are a little short handed right now, and may not be able to respond back to you until next week.  Hopefully this is acceptable, please let me know if it is extremely urgent.

    Regards,

    Travis