ElectronicCats / Beelan-LoRaWAN

A LoRaWAN library for compatible arduino board
https://www.beelan.mx
MIT License
189 stars 77 forks source link

Confirmed downlink? #46

Closed bkaraceylan closed 2 years ago

bkaraceylan commented 3 years ago

Hello,

Using chirpstack, I am unable to get acknowledgement for confirmed downlink requests for Class-C devices. Is this not supported or am I doing something wrong?

Thanks,

Edit: It seems confirmed downlinks are not working for Class-A devices also.

iotpanama commented 3 years ago

Los enlaces descendientes no funcionan... Como se puede corregir esto

plachta-zabatt commented 3 years ago

I will have to test later but they are working for Class-A devices I believe. I at least am fairly certain that they show up in device_ack table if you implement postgresql integration w/ chirpstack.

sabas1080 commented 3 years ago

Hi everyone, we have tested the solution to this problem, help us to test

iotpanama commented 3 years ago

Hi everyone, we have tested the solution to this problem, help us to test

How can we do the tests?

novvere commented 3 years ago

I'm also implementing a solution for confirmed downlinks I have tested it with Class A and will begin testing Class C in the next days. My main question is when to send the ACK from the node to the gateway as the LoRaWAN specification says the node can send it immediately in an empty downlink or deferred to the next schedules uplink. As my tests with TTN shows the server is continuously re sending the downlink until the node sends and ACK I think I will set a flag so the first uplink after a confirmed downlink will implicitly include de ACK bit set.

novvere commented 3 years ago

One additional question. How does ttn stack v3 manage confirmed downlinks? in v2 Class A devices the downlink is sent every time until and ACK from the node is received. As Class C device remains listening most of the time, when is the downlink resent? Is it also sent only after an uplink?

iotpanama commented 3 years ago

Hi Miguel

Indeed, the behavior would be that the gateway automatically sends an ACK automatically in the time window opened by the device. This is configured in the sending function, when you expressly request a confirmation from the gateway. This is very useful in class A devices as it allows a just moment for the sensor to go into deep sleep.


Ing. Jorge Quevedo

Movil +50763280221

Movil +50762028069

Web: http://www.iotpanama.com/ www.iotpanama.com

Panama city - Panama

Por favor, tenga en cuenta su responsabilidad ambiental.

Antes de imprimir este mensaje de correo electrónico, pregúntese si realmente necesita una copia en papel.

El contenido de este mensaje es confidencial.

Este mensaje no tiene carácter vinculante.

Este mensaje va dirigido, de manera exclusiva, a su destinatario y contiene información confidencial sujeta al secreto profesional cuya divulgación no está permitida por la ley. En caso de haber recibido este mensaje por error le rogamos, que de forma inmediata, nos lo comunique mediante correo electrónico remitido a nuestra atención y proceda a su eliminación así como a la de cualquier documento adjunto al mismo.

De: Miguel Romaní notifications@github.com Enviado el: miércoles, 28 de octubre de 2020 3:50 a. m. Para: BeelanMX/Beelan-LoRaWAN Beelan-LoRaWAN@noreply.github.com CC: Jorge Quevedo jquevedo@iotpanama.com; Comment comment@noreply.github.com Asunto: Re: [BeelanMX/Beelan-LoRaWAN] Confirmed downlink? (#46)

I'm also implementing a solution for confirmed downlinks I have tested it with Class A and will begin testing Class C in the next days. My main question is when to send the ACK from the node to the gateway as the LoRaWAN specification says the node can send it immediately in an empty downlink or deferred to the next schedules uplink. As my tests with TTN shows the server is continuously re sending the downlink until the node sends and ACK I think I will set a flag so the first uplink after a confirmed downlink will implicitly include de ACK bit set.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/BeelanMX/Beelan-LoRaWAN/issues/46#issuecomment-717788778 , or unsubscribe https://github.com/notifications/unsubscribe-auth/APROQ2KMBC3NVDVPRHKX2W3SM7LMLANCNFSM4Q67HTTA . https://github.com/notifications/beacon/APROQ2JPHOALPYP6JWUNILLSM7LMLA5CNFSM4Q67HTTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFLEJM2Q.gif

wero1414 commented 3 years ago

@mr3188 @iotpanama @bkaraceylan i started the PR #58 fixing the timming problems for the downlinks, by far i got the Class C working well, and i think Class A but i need to do more testing, the PR is now just for US but feel free to start adding your regions, so we all can test! thanks!

stale[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

daeynasvistas commented 3 years ago

.. is this working? never was able to confirm ack using chirpstack i can see the ack in the log gateway, but readAck() never seams to catch the value.

sabas1080 commented 3 years ago

@daeynasvistas the changes in #58 the pullrest are in the latest release

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.