search

mcci-catena / arduino-lmic

LoraWAN-MAC-in-C library, adapted to run under the Arduino environment
https://forum.mcci.io/c/device-software/arduino-lmic/
MIT License
650 stars 212 forks source link

Gateway Modem 4G #464

Closed geppoleppo closed 5 years ago

geppoleppo commented 5 years ago

Hello, I need your help. I have a gateway with 4g modem. I get to broadcast uplink correctly but I can't send downlink messages. If I connect the gateway with the Ethernet cable it works perfectly. Other nodes (not developed with the LMIC library) are able to receive downlink messages with the Gateway connected to the 4G modem. Has anyone had experience in downlink transmission with 4G gateways? Thanks

terrillmoore commented 5 years ago

@geppoleppo Sorry you're having problems. Can you please let us know:

  1. the node hardware (CPU, etc.)
  2. the LMIC software version
  3. the region
  4. are you using LMIC_setClockError(), if so what value?
  5. how big is your downlink message?
  6. what spreading factor are you using?

Thanks, --Terry

geppoleppo commented 5 years ago

1) MCU Atmega 1284P - hope rfm95w 2) Lmic version 3.0.99 3) Europe 4) yes: LMIC_setClockError(MAX_CLOCK_ERROR * 10 / 100); (i have try with 200/100....) 5) 9 bytes 6) SF=11

terrillmoore commented 5 years ago

Can you try reducing the clock error to MAX_CLOCK_ERROR * 1 / 100, and see if that improves things? (Counter-intuitive, I know.)

Also please turn off debugging output inside the LMIC (in case you're using it).

And make sure you return without doing any prints or extra work on an EV_RXSTART.

Thanks!

cstratton commented 5 years ago

This is an odd issue, because while having the node receive at the correct time is challenging, the timing at which a gateway transmits is based on its own internal free running clock - the server sees when the uplink packet ended according to that clock, and commands the gateway to transmit the downlink relative to the same clock.

There is potentially an issue with mobile data backhaul, in that the whole round trip from node through gateway to server and back through gateway to node must be completed in the RX1 delay, which is standardly 1 second. Although I wasn't having problems meeting that with LTE data modems, for a custom network I've changed the RX1 to two seconds just to be sure.

One possibility to investigate would be if those other nodes are actually receiving their downlinks in RX1, or if they are receiving them in RX2. If you own the gateway, an important debugging step would be to look at the gateway's raw traffic page. For both the working and non-working node, make sure that you can see that the downlinks are actually listed, and look to see if the difference of counts from the triggering uplink is one million microseconds, or something longer. However, a gateway summary view may show packet which were commanded, but reached the gateway only after the time they needed to be transmitted and so were dropped there. The latest version of the Semtech packet forwarder code logs errors for late packets (they are actually reported as being "early" because they could not be sent until the clock rolls over in a bit less than an hour). I'm not sure if older versions that are widely running log that.

Also worth noting that TTN Europe uses nonstandard settings for RX2, but will fall back to standard ones in a sticky way. It's unclear if you are using TTN or something else, but either way if your backhaul might be slow enough that only RX2 downlinks get to the gateway in time, but your node and server may be disagreeing on the air settings applicable to RX2 causing your LMiC node to fail, while other nodes that have the same RX2 definition as the server succeed.

geppoleppo commented 5 years ago

Information update: -Gateway model used: Dragino LG308 and RAK911 with rpi (4g router) -set error to MAX_CLOCK_ERROR * 1 / 100 -Debug Level: 0

report_1 report_2

cstratton commented 5 years ago

It would be very useful if someone tried to see if the downlink was working with a Gateway connected witha 4G modem.

This is generally workable, yes, I've been doing so for months on end. The issue would be if mobile network delays cause the transmit request to not get back to the gateway in time for receive window.

It's rather hard to tell from your logs what exactly is going on in your case, the logs are rather odd, both in terms of timing and in terms of why SF7 uplinks seem to be triggering SF8 downlinks. Having a downlink datarate offset is a possibility in LoRaWAN (in fact I'm using such in a custom system) but it adds to the complexity of your situation, since it is unclear what is normal and workable vs. what might be indicative of the problem.

terrillmoore commented 5 years ago

@geppoleppo in discussions with other people in Europe we've found that regulatory bandwidth limitations on the downlink channel may have some affect here.

I would make sure that you have downlink working at all -- since you're using ABP, we don't have the built-in test from JOIN. The quick test is: make an OTAA node, if your network will support it.

Please update to 3.0.99.5 (if you're not already using it).

Test in this configuration.

Then remove your clock-error setting -- that is no longer needed on my test platforms (and indeed I'm thinking about making that call a no-op, because it does more harm than good with the new code) -- you'd need to use a new API that says "yeah, this is value I want for the new LMIC". The reason the clock error was needed at all was that the timing in the LMIC didn't match Semtech code. Now it does, and I find things work better without it.

Remember that the gateway is limited to 1% duty cycle on normal channels, and you hit this quite quickly on JOIN loops. The duty cycle is 10% on the channel that's normally used for RX2, but since RX2 is normally SF12, you hit that pretty quickly too. And it's up to the network what to do.

geppoleppo commented 5 years ago

Thanks Terry for the support. Maybe I found the error. I believe it is in the Gateway firmware. In fact I installed the previous version and now it seems to work. For completeness of information: gateway model: Dragino LG08 Firmware not working: LG02_LG08 - build-v5.2.1569218466-20190923-1402 Working firmware: LG02_LG08 - build-v5.1.1545026772-20181217-1407 Thanks again

terrillmoore commented 5 years ago

Interesting. Thanks for the update. I'll close this now, and you can reopen if needed.