Transmit in Progress Error when sending packets.

Home › Forums › mDot/xDot › Transmit in Progress Error when sending packets.

Tagged: ,

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • April 20, 2017 at 6:59 pm #18463
    Ajay K
    Participant

    I have been receiving “Transmit in Progress” error while trying to uplink a packet to the gateway. This is happening on a particular mdot amongst the 50 mdot’s communicating with the conduit.

    Just to give you little background, even though the mdot that is returning the “transmit in progress” error constantly, it had connected successfully to the private lora network at one point and transmitted couple of packets successfully, before getting into the state it is in currently.

    Before transmitting any packet I always check the return values of the following two functions mentioned below and also the mdot sleeps for a minute between transmissions.

    getNextTxMs()
getIsTransmitting()

    So with these checks in place and also with a 1 minute sleep interval between transmissions why would the Send method return a “transmit in progress” error.

    Also FYI, we are operating the US915 frequency band

    Thanks,
    Ajay

    April 21, 2017 at 10:33 am #18478
    Ajay K
    Participant

    Any thoughts regarding this issue, as I am not sure how to explain the occurrence of this error when all the checks have been made?

    Also does the “send” method return a specific error code for this scenario?

    Thanks,
    Ajay.

    May 10, 2017 at 4:34 am #18978
    Chad Goyette
    Participant

    I am also interested in this error which i have recently been receiving, though on an xDot instead. I am running Private lora network with a custom app, US915mHz and most up to date libxdot-mbed5 with the appropriate mbed-os.

    May 10, 2017 at 1:39 pm #18988
    Mike Fiore
    Blocked

    Ajay and Chad,

    Can either of you supply a simple application that reproduces the issue? This would be very helpful for us to get to the bottom of this issue.

    Also, the explicit version number (e.g. 2.0.14 – can be found in commit messages) of the mDot/xDot library would be helpful as well.

    Cheers,
    Mike

    May 10, 2017 at 4:48 pm #18992
    Ajay K
    Participant

    Hi Mike,

    Thanks for getting back to this thread. We have already opened a ticket already for the same issue and have provided the necessary logs. Its not that it can’t be reproduced easily, but in my case when the mdot is run over a period of time, it starts to generate the “Transmit In Progress” error.

    The case# for the ticket opened is 5079839.

    Also the mdot lib version the custom firmware was built against is 2.0.17 and mbed os 5.4.2.

    Thanks,
    Ajay

    May 11, 2017 at 6:34 am #19001
    Chad Goyette
    Participant

    Mike,
    I am running libxDot-mbed5 2.0.17-1 with mbed-os 5.4.2. This issue isnt something that pops up right away and seems to present its self over time. i have only experienced this with one device so far but i do expect a couple of my field installed devices may be experiencing the same issue. unfortunately i am not able to provide the application at this time.

    June 9, 2017 at 10:02 am #19477
    Chad Goyette
    Participant

    Mike,
    Any update on this? I have another couple devices that i have found stuck with this problem (happens over period of time). Is there a way that you can suggest a way to detect and recover from this?

    June 12, 2017 at 1:36 pm #19508
    Chad Goyette
    Participant

    Mike,
    Below i was able to capture some logging when this error occurred. does this provide any insight to what is going on and what i can do differently?

    Data Change Detected…
    Sending data… Ack Status = 8
    [DEBUG] Send with tx timeout 40000
    [INFO] Preparing frame
    [DEBUG] ADR ACK CNT: 2 LIMIT: 64 DELAY: 32
    [TRACE] NA: 00000011
    [TRACE] NSK: 570a78ae3eaf97fb99185b0e252d983d
    [TRACE] DSK: e0e7fd41a9476b4e7981aca63d0e0690
    [TRACE] Adding MIC to frame
    [TRACE] Sending 17 bytes
    [TRACE] Number of available channels: 1
    [DEBUG] Using channel 64 : 903000000
    [INFO] Configure radio for TX
    [DEBUG] Session pwr: 26 ant: 3 max: 26
    [DEBUG] Radio Power index: 20 output: 19 total: 22
    [DEBUG] TX PWR: 20 DR: 4 SF: 8 BW: 2 CR: 1 PL: 8 CRC: 1 IQ: 0
    [INFO] Configure radio for TX
    [DEBUG] Session pwr: 26 ant: 3 max: 26
    [DEBUG] Radio Power index: 20 output: 19 total: 22
    [DEBUG] TX PWR: 20 DR: 4 SF: 8 BW: 2 CR: 1 PL: 8 CRC: 1 IQ: 0
    [DEBUG] mDotEvent – TxDone
    [TRACE] Event: OK
    [TRACE] Flags Tx: 1 Rx: 0 RxData: 0 RxSlot: 0 LinkCheck: 0 JoinAccept: 0
    [TRACE] Info: Status: 0 ACK: 0 Retries: 0 TxDR: 4 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0
    [TRACE] RX1 on freq: 923300000
    [TRACE] RX DR: 13 SF: 7 BW: 2 CR: 1 PL: 8 STO: 16 CRC: 1 IQ: 1
    [TRACE] Stats: Up: 13 Down: 8 DupTx: 0 CRC Errors: 0
    [INFO] Rx Window 1
    [TRACE] Event: RX_TIMEOUT
    [TRACE] Flags Tx: 0 Rx: 0 RxData: 0 RxSlot: 1 LinkCheck: 0 JoinAccept: 0
    [TRACE] Info: Status: 3 ACK: 0 Retries: 0 TxDR: 4 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0
    [TRACE] RX2 on freq: 923300000
    [TRACE] RX DR: 8 SF: 12 BW: 2 CR: 1 PL: 8 STO: 12 CRC: 1 IQ: 1
    [TRACE] Stats: Up: 13 Down: 8 DupTx: 0 CRC Errors: 0
    [INFO] Rx Window 2
    [TRACE] Event: RX_TIMEOUT
    [TRACE] Flags Tx: 0 Rx: 0 RxData: 0 RxSlot: 2 LinkCheck: 0 JoinAccept: 0
    [TRACE] Info: Status: 3 ACK: 0 Retries: 0 TxDR: 4 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0
    [DEBUG] ACK timeout repMax: 1 ackMax: 8
    [INFO] ACK resend attempt: 2 / 8
    [TRACE] Number of available channels: 1
    [DEBUG] Using channel 64 : 903000000
    [INFO] Configure radio for TX
    [DEBUG] Session pwr: 26 ant: 3 max: 26
    [DEBUG] Radio Power index: 20 output: 19 total: 22
    [DEBUG] TX PWR: 20 DR: 4 SF: 8 BW: 2 CR: 1 PL: 8 CRC: 1 IQ: 0
    [INFO] Configure radio for TX
    [DEBUG] Session pwr: 26 ant: 3 max: 26
    [DEBUG] Radio Power index: 20 output: 19 total: 22
    [DEBUG] TX PWR: 20 DR: 4 SF: 8 BW: 2 CR: 1 PL: 8 CRC: 1 IQ: 0
    [DEBUG] mDotEvent – TxDone
    [TRACE] Event: OK
    [TRACE] Flags Tx: 1 Rx: 0 RxData: 0 RxSlot: 0 LinkCheck: 0 JoinAccept: 0
    [TRACE] Info: Status: 0 ACK: 0 Retries: 0 TxDR: 4 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0
    [TRACE] RX1 on freq: 923300000
    [TRACE] RX DR: 13 SF: 7 BW: 2 CR: 1 PL: 8 STO: 16 CRC: 1 IQ: 1
    [TRACE] Stats: Up: 14 Down: 8 DupTx: 0 CRC Errors: 0
    [INFO] Rx Window 1
    [TRACE] Event: RX_TIMEOUT
    [TRACE] Flags Tx: 0 Rx: 0 RxData: 0 RxSlot: 1 LinkCheck: 0 JoinAccept: 0
    [TRACE] Info: Status: 3 ACK: 0 Retries: 0 TxDR: 4 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0
    [TRACE] RX2 on freq: 923300000
    [TRACE] RX DR: 8 SF: 12 BW: 2 CR: 1 PL: 8 STO: 12 CRC: 1 IQ: 1
    [TRACE] Stats: Up: 14 Down: 8 DupTx: 0 CRC Errors: 0
    [INFO] Rx Window 2
    [TRACE] Event: RX_TIMEOUT
    [TRACE] Flags Tx: 0 Rx: 0 RxData: 0 RxSlot: 2 LinkCheck: 0 JoinAccept: 0
    [TRACE] Info: Status: 3 ACK: 0 Retries: 0 TxDR: 4 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0
    [DEBUG] ACK timeout repMax: 1 ackMax: 8
    [INFO] ACK resend attempt: 3 / 8
    [TRACE] ADR Lowering datarate
    [TRACE] Number of available channels: 8
    [DEBUG] Using channel 7 : 903700000
    [INFO] Configure radio for TX
    [DEBUG] Session pwr: 26 ant: 3 max: 21
    [DEBUG] Radio Power index: 20 output: 19 total: 22
    [DEBUG] TX PWR: 20 DR: 3 SF: 7 BW: 0 CR: 1 PL: 8 CRC: 1 IQ: 0
    [INFO] Configure radio for TX
    [DEBUG] Session pwr: 26 ant: 3 max: 21
    [DEBUG] Radio Power index: 20 output: 19 total: 22
    [DEBUG] TX PWR: 20 DR: 3 SF: 7 BW: 0 CR: 1 PL: 8 CRC: 1 IQ: 0
    [DEBUG] mDotEvent – TxDone
    [TRACE] Event: OK
    [TRACE] Flags Tx: 1 Rx: 0 RxData: 0 RxSlot: 0 LinkCheck: 0 JoinAccept: 0
    [TRACE] Info: Status: 0 ACK: 0 Retries: 0 TxDR: 3 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0
    [TRACE] RX1 on freq: 923300000
    [TRACE] RX DR: 13 SF: 7 BW: 2 CR: 1 PL: 8 STO: 16 CRC: 1 IQ: 1
    [TRACE] Stats: Up: 15 Down: 8 DupTx: 0 CRC Errors: 0
    [INFO] Rx Window 1
    [TRACE] Event: RX_TIMEOUT
    [TRACE] Flags Tx: 0 Rx: 0 RxData: 0 RxSlot: 1 LinkCheck: 0 JoinAccept: 0
    [TRACE] Info: Status: 3 ACK: 0 Retries: 0 TxDR: 3 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0
    [TRACE] RX2 on freq: 923300000
    [TRACE] RX DR: 8 SF: 12 BW: 2 CR: 1 PL: 8 STO: 12 CRC: 1 IQ: 1
    [TRACE] Stats: Up: 15 Down: 8 DupTx: 0 CRC Errors: 0
    [INFO] Rx Window 2
    [TRACE] Event: RX_TIMEOUT
    [TRACE] Flags Tx: 0 Rx: 0 RxData: 0 RxSlot: 2 LinkCheck: 0 JoinAccept: 0
    [TRACE] Info: Status: 3 ACK: 0 Retries: 0 TxDR: 3 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0
    [WARNING] SEND TIMED OUT after 40000 ms
    [WARNING] Mac: ResetState
    [WARNING] Link: ResetState
    [ERROR] ACK not received
    Operation Timed Out – ACK not received
    Setting ack to ‘0’…
    ambient temp = 74.525002
    volt-check = 1.000000
    [TRACE] configuring RTC Alarm A to wakeup 15 seconds from now
    [INFO] entering sleep (stop) mode 00000037รกcsampleCount = 1
    hbCount = 7
    Linkcheck Fail count = 1
    Setting ack to ‘8’…
    [DEBUG] ACK timeout repMax: 1 ackMax: 8
    [INFO] ACK resend attempt: 4 / 8
    [TRACE] Number of available channels: 8
    [DEBUG] Using channel 5 : 903300000
    [INFO] Configure radio for TX
    [DEBUG] Session pwr: 26 ant: 3 max: 21
    [DEBUG] Radio Power index: 20 output: 19 total: 22
    [DEBUG] TX PWR: 20 DR: 3 SF: 7 BW: 0 CR: 1 PL: 8 CRC: 1 IQ: 0
    [INFO] Configure radio for TX
    [DEBUG] Session pwr: 26 ant: 3 max: 21
    [DEBUG] Radio Power index: 20 output: 19 total: 22
    [DEBUG] TX PWR: 20 DR: 3 SF: 7 BW: 0 CR: 1 PL: 8 CRC: 1 IQ: 0
    Data Change Detected…
    Sending data… Ack Status = 8
    [DEBUG] mDotEvent – TxDone
    [TRACE] Event: OK
    [TRACE] Flags Tx: 1 Rx: 0 RxData: 0 RxSlot: 0 LinkCheck: 0 JoinAccept: 0
    [TRACE] Info: Status: 0 ACK: 0 Retries: 0 TxDR: 3 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0
    [ERROR] Transmit in progress
    Transmit Error – Transmit in progress
    Setting ack to ‘0’…
    ambient temp = 74.525002
    volt-check = 1.000000
    [TRACE] configuring RTC Alarm A to wakeup 15 seconds from now
    [INFO] entering sleep (stop) mode 00000037รกcsampleCount = 0
    hbCount = 8
    Linkcheck Fail count = 1
    Measuring Coupons…..
    Coupon 1 Test = 0.000000
    Coupon 2 Test = 0.000000
    Coupon 3 Test = 0.000000
    Coupon 4 Test = 0.999512
    Data Change Detected…
    Sending data… Ack Status = 0
    [ERROR] Transmit in progress

    June 14, 2017 at 4:44 pm #19543
    Mark Ruys
    Participant

    You use stop mode (sleep), then you get these “Mac: ResetState” errors. Run the code from http://www.multitech.net/developer/forums/topic/timer-unreliable-after-a-dot-sleep/ just after the dot->sleep(.., .., false). Always.

    I can’t see from your log, but you need at least 3 seconds between join attempts, and probably also between uplink messages.

    July 10, 2017 at 6:04 am #19885
    Chad Goyette
    Participant

    Thanks Mark.
    I don’t believe this is a sleep issue since its not consistent (can sometimes take a week of running to happen) and i have many other devices that use sleep and don’t experience this issue. Is there an official answer to what may be happening? Also until i can get to the bottom of what is going on is there a recommendation on a method to detect this error so that i can force the xdot to reset? I tried the getIsTransmitting() and that doesn’t seem to change state when this event takes place.

    July 12, 2017 at 8:16 am #19912
    Jason Reiss
    Keymaster

    I would have expected 8 attempts to complete in ~35 seconds.
    After 3 attempts ~15 seconds the device believes 40s have elapsed.
    That leads me to believe this is a clock issue.

    It appears that the ACK timer is still active and fires after the sleep.

    [INFO] ACK resend attempt: 3 / 8
    …
    [WARNING] SEND TIMED OUT after 40000 ms
    …
    [TRACE] configuring RTC Alarm A to wakeup 15 seconds from now
    …
    [INFO] ACK resend attempt: 4 / 8

    If getIsTransmitting() returns false and send fails, then I would reset.

    Log from my mDot with timestamps showing ~35 seconds to complete 8 retries
    [2017-07-12 08:02:47] [DEBUG] Send with tx timeout 40000
    [2017-07-12 08:03:19] [INFO] ACK resend attempt: 8 / 8
    [2017-07-12 08:03:21] [DEBUG] mDotEvent – MissedAck : retries 7

    July 12, 2017 at 10:08 am #19914
    Mike Fiore
    Blocked

    There was an issue with the mbed system “tick” getting corrupted after xDot wakes from sleep mode. This is resolved in the latest Dot Library 3.0.0 release candidate and will be in the production 3.0.0 release.

    July 12, 2017 at 12:00 pm #19917
    Ajay K
    Participant

    Hi Mike,

    I have asked this question before as I started this particular issue thread. I was wondering if this is an issue with MDot as well as we use the MDot and we have seen this reproduce in the field although very sporadically. Do you suppose we have an MBED ticker issue here as well?

    Thanks,
    Ajay

  • Author
    Posts
Viewing 13 posts - 1 through 13 (of 13 total)
  • You must be logged in to reply to this topic.