How can it be pushed data from LoRa gateway to TTU mote?

Gateways Kerlink Gateways
7

I am also trying to get data from a gateway to mote.

Are you sending data on rfch =0; ? because it looping here if i do that on a mote (not the one i use).
which gateway interface is that?

8

Hi @flits

No I am sending data on channel 10, I think it remains looping since the server requires an ACK according to the manual, so if the mote doesn’t give it back seems to be stack, that’s my conclussion but I am still looking into it.

That interface is the one of Kerlink gateway.

regards!

9

according to this manual
http://ww1.microchip.com/downloads/en/DeviceDoc/40001784E.pdf
mac tx type> <portno> <data>
would be able to response mac_rx <portno> <data>
but here i only get mac_tx_ok.

sending data to the same rfch as my mote seems to fail on the gateway, sending any other channel works.

10

That is fine, that means that your data was sent properly in that port towards the gateway. Now you have to manage to send data from your gateway, when your geteay sends out something your mote will show mac rx port data

11

Just in case you missed it, from The Things Network 2016 Update, emphasis mine:

Fair Access Policy: Practice

  • Golden rule: 30 seconds air-time per device per day
  • For 10 bytes of payload, this translates in (approx.):
    • 20 messages per day at SF12
    • 500 messages per day at SF7
    • more for SF7BW250 and FSK (local-area)
  • If your application requires more bandwidth, think of another solution
  • This allows for >1000 nodes per gateway
  • Downlink bandwidth is even more restricted
    • you can’t send all messages as ‘confirmed uplink’

I don’t know what the actual limit might be.

12

Hi @arjanvanb

What do you mean with that you cannot send all your messages as confirmed uplink? THat is only best effort?

13

Hi @ndarkness,

This is something happening in the gateway. But i have no knowledge about this. Might it be possible to send unconfirmed data to the mote in settings or something?

I also don’t know how to send a confirmation with RN2483. It might be doing so automatically when sending another message (try mac tx uncnf <p> <data>). You can also try to set automatic reply (check out doc of RN2483). But better would be to turn of confirmed downlink.

14

Continuing the discussion from How can it be pushed data from LoRa gateway to TTU mote?:

I have no clue, I managed to sent back a confirmation to the gateway but just once, then on the gateway I saw that the status of the message chaged to success, although I haven’t been able to repeeat it yet… To do that, I used a code snippet like this one, notice that I am using a different port number to send it since I read it in the command reference from RN2483, but I am not sure this is working because as I have mentioned I managed only once.

if (((String)receivedChars).substring(0,5) == “mac_rx”) {
Serial.println("Sever data-> " + (String)receivedChars);
Serial1.write("mac tx uncnf 2 ");//ACK for the server of the data!
return true;
} else
return false;

PS: do you now @scle a better way to check whether mac_rx has arrived?

15

This should be the way to check whether it is received, however it generates a lot of traffic. But there is an other way, with some latency. If you need to have low latency acknowledgement you should enable automatic replay mac set ar on. This does practically the same as your little script.

The gateway will wait forever for acknowledgement of the mote. The LoRaWAN specification (4.3.1.2) has some, though minimal, information regarding how acknowledgement is sent by a mote (end device). If you don’t need the low latency part you should just wait for the next transmission of the mote to confirm the downlink message.

16

HI @scle,

I have done as you mentioned, I enabled the automatic reply, and it seems to be working since I see again the acknowledge in the gateway, so this confirms as well that th gateway works with acknowledge at least from its web interface to send data to motes.

You are right, the LoraWan does not tell much about how the acknowledge should be sent from the mote… On the other hand, concerning more to an implementation way, the TX has to implement as well a mechanisim to check after each transmission if something was sent to him right?

17

I don’t get the question here actually. Could you be a bit more specific?

18

Sorry @scle,

What I meant was that in order to be able to receive data from the Gateway, the implementation of the tansmitter has to take care as well of the receiving part, given that after transmitting whatever, you should listen to anything that may be issued to you, right?

19

Does/will The Things Network also support class B and C devices (‘Bi-directional end-devices with scheduled receive slots’ and ‘Bi-directional end-devices with maximal receive slots’)?

20

Yes that is true. But RN2483 does that for you. It automatically listens to the receive windows after 1 and 2 secs and delivers to you the received messages (if there were any). An acknowledgement from ‘confirmed uplink’ will be sent in one of the two receive windows (with or without data). Furthermore a confirmed downlink package might be attached in which case it will wait for acknowledgement of the mote. Or a unconfirmed package is attached and it will not wait for acknowledgement.

21

I didn’t know that @scle, are you sure about that? I ask because that would be very interesting for improving the speed in my code, since right now I have two delays just after sending something to the mac, if I understand you well, I could remove the delays since they are not actually needed, did you mean that?

delay(1000);//first Rx window to listen
if (LoRaWanReceive()) {
  Serial.print("received mac_rx at 1s!!");
}
delay(2000);//second Rx window to listen
if (LoRaWanReceive()) {
  Serial.print("received mac_rx at 2s!!");
}

Thanks again

22

Hi @ndarkness,

I do believe your delays are unnecessary. The RN2483 will respond after a while with or without your delays. You just have to listen for any message from the module and you might be doing other things in the meanwhile.

23

As far as I can tell, it will be against the TTN Fair Access Policy, to limit the average airtime per node, per day. Some sources for that in Limitations: data rate, packet size, 30 seconds/day Fair Access Policy, nodes per gateway.

24

And as far as regulations are concerned the LoRaWAN gateway is just another device using the ISM band. It too needs to adhere to the maximum duty cycle (typically 1% in Europe for 868 MHz bands). If on a busy gateway all nodes would request confirmed uplink messages the gateway would soon have to be silenced because it will exceed the maximum allowed duty cycle.

1 Like
25

Hi @scle

I can give it a try, but I see an issue in that, if the only moment that my nodoe can receive something is after transmitting, I have to listen to the serial just after transmitting so it does not let my much time to do other things, you might implement some kind of interruption but it will have just occurred after sending so I don’t see an advantage on it right?

26

Hi @ndarkness,

Interruption based programming of the UART interface will be the way to go when resources are scarce. This will enable low power nodes, but requires more knowledge and is tougher to program and debug. You can for instance make the MCU sleep until a message is received on the UART. Handle the message and sleep again. But this has nothing to do with this subject or forum post. Checkout the sleep modes for your MCU for more information.