Question on RX data

[trlafleur]

If I send data to the device from TTN and I ask for a confirmation that the data was received using the LiMC stack, how do I send the ACK back to TTN?? I've looked at the code, and it should do the ACK without any action on my part...

I can see the data being received in the device, but TTN keeps sending it?? ie: it's waiting for an ACK...

At this point, not sure if its a TTN or LiMC issue?? It looks like LiMC is sending something back to TTN each time it receives a block of data.

As you can see from the dump below, TTN keeps sending the data (99 88 77 66 55 44 33 22 11 ) and it seems to never receive an ACK.

Thanks

** LMIC Ver: 2010500

here is the dump from the stack...

 ** LMiC Starting on a M0 Processor **
 ** LMIC Ver: 2010500
 ** TTN Sensor 2, Ver: 3 Soil Moisture 1.1h
 ** /Users/lafleur/Desktop/MySensor-Arduino-development/Arduino_fork/TTN-Sensor2-M0-1.1h/TTN-Sensor2-M0-1.1h.ino 
 ** Jul 12 2018, 08:05:33 
 ** LMIC Debug Level: 2

Vbat: 5.76V 
***  LMiC os_init 
***  LMIC_reset 
***  LMIC_setLinkCheckMode 
***  LMIC_setDrTxpow 
***  Selecting SubBand 1 

***  LMIC_StartJoining 
Event EV_JOINING, time: 6 
Event TXSTART, time: 6 
Event EV_JOINED, time: 11 

NetID:           19
Device EUI:      00 04 A3 0B 00 1A 71 91 
Device Addr:     26 02 25 26 
App Session Key: 34 73 4C 06 F0 35 10 2F 30 48 3E 69 8F 31 90 DE 
Network Key:     98 72 D7 5F 01 B2 28 02 FC 41 7F 02 59 76 02 BE 

***  Sending task1, Time: 11, TX_Channel: 12 
Opmode check: task1, it's ok to send --> Message Queued
Temp MCP: 81.19F 
Vbat: 0.36V 
Event TXSTART, time: 11 

***  Sending task2, Time: 11, TX_Channel: 10 
Opmode check: OP_TXRXPEND, <-- task2, TX was Busy, last msg not yet sent

***  Sending Keep-Alive, Time: 11, TX_Channel: 10 
Opmode check: OP_TXRXPEND, <-- keepAlive, TX was Busy, msg not yet sent

***  Sending task2, Time: 11, TX_Channel: 10 
Opmode check: OP_TXRXPEND, <-- task2, TX was Busy, last msg not yet sent

***  Sending Keep-Alive, Time: 12, TX_Channel: 10 
Opmode check: OP_TXRXPEND, <-- keepAlive, TX was Busy, msg not yet sent

***  Sending task2, Time: 12, TX_Channel: 10 
Opmode check: OP_TXRXPEND, <-- task2, TX was Busy, last msg not yet sent

***  Sending Keep-Alive, Time: 12, TX_Channel: 10 
Opmode check: OP_TXRXPEND, <-- keepAlive, TX was Busy, msg not yet sent
Event TXSTART, time: 15 
Event TX_COMPLETE, time: 16 
***  Received ACK, time: 16 
**  Default Data Received! Len: 9 Port: 01
99 88 77 66 55 44 33 22 11 
Event TXSTART, time: 16 
Event TX_COMPLETE, time: 19 
**  Default Data Received! Len: 9 Port: 01
99 88 77 66 55 44 33 22 11 
Event TXSTART, time: 19 
Event TX_COMPLETE, time: 20 
**  Default Data Received! Len: 9 Port: 01
99 88 77 66 55 44 33 22 11 
Event TXSTART, time: 20 

***  Sending task2, Time: 23, TX_Channel: 8 
Opmode check: task2 it's ok to send --> Message Queued
Temp Si: 80.97F 
Humi Si: 61.88% 
Vbat: 2.77V 

***  Sending Keep-Alive, Time: 24, TX_Channel: 9 
Opmode check: keepAlive task it's ok to send --> Message Queued
Event TXSTART, time: 26 
Event TX_COMPLETE, time: 27 
***  Received ACK, time: 27 
**  Default Data Received! Len: 9 Port: 01
99 88 77 66 55 44 33 22 11 
Event TXSTART, time: 27 
Event TX_COMPLETE, time: 30 
**  Default Data Received! Len: 9 Port: 01
99 88 77 66 55 44 33 22 11 
Event TXSTART, time: 30 
Event TX_COMPLETE, time: 31 
**  Default Data Received! Len: 9 Port: 01
99 88 77 66 55 44 33 22 11 
Event TXSTART, time: 31 

And here from TTN

06:50:16 1 confirmed payload:998877665544332211
06:50:16 1 0 retry payload:[not provided]
06:50:15 1 confirmed payload:998877665544332211
06:50:15 1 0 retry payload:[not provided]
06:50:12 1 confirmed payload:998877665544332211
06:50:12 1 0 retry payload:[not provided]
06:50:11 1 confirmed payload:998877665544332211
06:50:10 1 3 confirmed payload:50613D58024D
06:50:05 1 confirmed payload:998877665544332211
06:50:05 0 0 retry payload:[not provided]
06:50:04 1 confirmed payload:998877665544332211
06:50:04 0 0 retry payload:[not provided]
06:50:01 0 0 retry payload:[not provided]
06:50:01 1 confirmed payload:998877665544332211
06:50:00 1 confirmed payload:998877665544332211
06:50:00 0 2 retryconfirmed payload:51130024
06:49:56 1 confirmed payload:998877665544332211
06:49:56 0 2 confirmed payload:51130024
06:49:51 dev addr:26022526 app eui:70B3DF7EF0001E40 dev eui:0004A3FB001A7191

[terrillmoore]

@trlafleur are you still seeing this? Sorry, because I didn't immediately assign this to myself, it got lost.

[trlafleur]

I believe so, will need to retest

[trlafleur]

Terry: I noticed in the current version 2.3.1 of your LMiC code that you have an example: ttn-otaa-network-time

I take it needs some additional code at the server to function?? any reference to it??

Thanks

~~ _/) ~~~~ _/) ~~~~ _/) ~~~~ _/) ~~

Tom Lafleur

On Mon, Apr 1, 2019 at 2:55 PM Terry Moore [email protected] wrote:

@trlafleur https://github.com/trlafleur are you still seeing this? Sorry, because I didn't immediately assign this to myself, it got lost.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mcci-catena/arduino-lorawan/issues/40#issuecomment-478762214, or mute the thread https://github.com/notifications/unsubscribe-auth/AEXCK9pxdW_dkv9cwg0mGPlTiH5xJj1vks5vcoBJgaJpZM4VF2Ij .

[terrillmoore]

Sorry @trlafleur -- just saw this.

• TTN doesn't yet support network-time.
• LoRaServer.io does, I think.
• It's possible to do something similar at a higher level with TTN (in your network app). If you check the conversation around the network time fix, you should be able to find someone who did this in Switzerland succesfully, with sample code. (You take the tagged "time of arrival", and send it back to the device at the application layer.)