1. Home
  2. Getting Started
  3. FiPy
  4. LoRaWAN Gateway using CatM1

Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

LoRaWAN Gateway using CatM1

  • D

    Hello, I am trying to use the FiPy to be a LoRaWAN gateway and instead of being connected via WiFi, it is connected by CATM1.

    I am using a hologram SIM and I can establish a connection, everything looks fine and I even get a connection on The Things Network, however I get the following errors:

    [  9095.759] Attaching...
[  9096.140] Attaching...
[  9096.519] Attaching...
[  9098.096] lte connected
[  9098.104] Starting LoRaWAN nano gateway with id: b'CC50E3FFFEA5C304'
[  9098.113] Syncing time with pool.ntp.org ...
[  9099.473] RTC NTP sync complete
[  9100.101] Opening UDP socket to router.au.thethings.network (52.62.83.250) port 1700...
[  9100.123] Setting up the LoRa radio at 916.7999 Mhz using SF10BW125
[  9100.135] LoRaWAN nano gateway online
[  9100.142] You may now press ENTER to enter the REPL
Unhandled exception in thread started by <bound_method>
Traceback (most recent call last):
  File "nanogateway.py", line 458, in _udp_thread
  File "nanogateway.py", line 457, in _udp_thread
AttributeError: 'OSError' object has no attribute 'errno'
[  9175.124] Failed to �ets Jun  8 2016 00:22:57

    After this it will restart every minute or so.

    I have also tried using pybytes and have established a connection but can't see what is going wrong and then it will just reset as well.

    I have added these lines to my nanogateway.py code for the LTE connection:

        def start(self):
        """
        Starts the LoRaWAN nano gateway.
        """
        lte.reset()
        lte.send_at_cmd('AT+CGDCONT=1,"IP","hologram"')
        lte.send_at_cmd('AT!="addscanfreq band=28 dl-earfcn=9410"')
        lte.send_at_cmd('AT!=1')
        lte.send_at_cmd('AT+CEREG=2')
        lte.send_at_cmd('AT+CFUN=1')
        lte.attach()
        while not lte.isattached():
            time.sleep(0.25)
            self._log('Attaching...')
        lte.connect()
        while not lte.isconnected():
            utime.sleep_ms(50)
        self._log('lte connected')
        self._log('Starting LoRaWAN nano gateway with id: {}', self.id)

    and removed the wifi stuff from the config etc.

    I haven't changed anything here, but this is where the error happens:

    
    def _udp_thread(self):
        """
        UDP thread, reads data from the server and handles it.
        """

        while not self.udp_stop:
            try:
                data, src = self.sock.recvfrom(1024)
                _token = data[1:3]
                _type = data[3]
                if _type == PUSH_ACK:
                    self._log("Push ack")
                elif _type == PULL_ACK:
                    self._log("Pull ack")
                elif _type == PULL_RESP:
                    self.dwnb += 1
                    ack_error = TX_ERR_NONE
                    tx_pk = ujson.loads(data[4:])
                    if "tmst" in data:
                        tmst = tx_pk["txpk"]["tmst"]
                        t_us = tmst - utime.ticks_cpu() - 15000
                        if t_us < 0:
                            t_us += 0xFFFFFFFF
                        if t_us < 20000000:
    					    self.uplink_alarm = Timer.Alarm(
                                handler=lambda x: self._send_down_link(
                                    ubinascii.a2b_base64(tx_pk["txpk"]["data"]),
                                    tx_pk["txpk"]["tmst"] - 50, tx_pk["txpk"]["datr"],
                                    int(tx_pk["txpk"]["freq"] * 1000) * 1000
                                ),
                                us=t_us
                            )
                        else:
                            ack_error = TX_ERR_TOO_LATE
                            self._log('Downlink timestamp error!, t_us: {}', t_us)
                    else:
                        self.uplink_alarm = Timer.Alarm(
                            handler=lambda x: self._send_down_link_class_c(
                                ubinascii.a2b_base64(tx_pk["txpk"]["data"]),
                                tx_pk["txpk"]["datr"],
                                int(tx_pk["txpk"]["freq"] * 1000) * 1000
                            ),
                            us=50
                        )
                    self._ack_pull_rsp(_token, ack_error)
                    self._log("Pull rsp")
            except usocket.timeout:
                pass
            except OSError as ex:
                if ex.errno != errno.EAGAIN: #This is line 457
                    self._log('UDP recv OSError Exception: {}', ex)
            except Exception as ex:
                self._log('UDP recv Exception: {}', ex)

            # wait before trying to receive again
            utime.sleep_ms(UDP_THREAD_CYCLE_MS)

        # we are to close the socket
        self.sock.close()
        self.udp_stop = False
        self._log('UDP thread stopped')

    Has anyone had success using a FiPy as a LoRaWAN Gateway with CATM1?

    Also I removed the wifi details from the init line:

        def __init__(self, id, frequency, datarate, server, port, ntp_server='pool.ntp.org', ntp_period=3600):
    0 robert-hh 1 Reply
    Log in to reply
     
  • L

    @Dylan hi, were u able to resolve the reset issue? we r facing the same issue... after connection to the LTE network it send the data; get stacked for a while and then reset.
    we get the following log on runtime:

    [   168.495] attached!
[   169.890] ] connected!
[   169.902] Syncing time with time.google.com ...
[   170.318] RTC NTP sync complete
[   170.334] Opening UDP socket to XX.XX.XX.XX port 1700...
[   171.365] Watchdog started
[   171.378] Setting up the LoRa radio at 868.1 Mhz using SF7BW125
[   171.397] LoRaWAN nano gateway online
Pycom MicroPython 1.20.1.r3 [v1.11-58398d3] on 2019-12-12; FiPy with ESP32
Pybytes Version: 1.3.0
Type "help()" for more information.
>>> b'\x02\xd4j\x01'
[   171.456] Push ack
[   178.293] Received packet: {"rxpk": [{"data": "QCh1kQEAAAACWlrOb9z6ZwLt0lCqQYGl7PdNqZYjIhhsl023jWO9aEaDIb5UR/0=", "time": "2022-12-16T13:00:43.310577Z", "chan": 0, "tmst": 48778374, "stat": 1, "modu": "LORA", "lsnr": 6.0, "rssi": -26, "rfch": 0, "codr": "4/5", "freq": 868.1, "datr": "SF7BW125", "size": 47}]}
b'\x02\x8dF\x04'
[   198.001] Pull ack
b'\x025\x1a\x01'
[   198.057] Push ack
b'\x027\x83\x03{"txpk":{"imme":false,"rfch":0,"powe":14,"ant":0,"brd":0,"tmst":49778374,"freq":868.1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","ipol":true,"size":36,"data":"YCh1kQGbCgAHA8iFhFAFANKthAGS20VgfuoTknRW6SotrPdh"}}'
[   198.613] Downlink timestamp error!, t_us: 19360015
[   198.633] Pull rsp
[   211.877] UDP recv Exception: tmst
b'\x02\xa3Q\x01'
[   212.035] Push ack
b'\x02\x96I\x03{"txpk":{"imme":false,"rfch":0,"powe":14,"ant":0,"brd":0,"tmst":83213604,"freq":868.1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","ipol":true,"size":36,"data":"YCh1kQGbCgAHA8iFhFAFANKthAGS20VgfuoTknRW6SotrPdh"}}'
[   212.924] Pull rsp
ets Jun  8 2016 00:22:57
rst:0x7 (TG0WDT_SYS_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)

    @robert-hh we already have the changes u proposed in the code we are using for the connection. Could u take a look and let me know if u have any idea about our problem? another thing that is bothering me is why I get the timestamp of Jun 8 2016 00:22:57?

    0
  • D

    I now have a different crash occuring:

    [  3153.373] Pull ack
[  3208.926] Push ack
Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.
Core 1 register dump:
PC      : 0x4010967f  PS      : 0x00060830  A0      : 0x800e07c0  A1      : 0x3ffd9270
A2      : 0x00000001  A3      : 0x00000001  A4      : 0x00000000  A5      : 0x00000001
A6      : 0x00000000  A7      : 0x00060023  A8      : 0x801084ca  A9      : 0x3ffe63e0
A10     : 0x00000001  A11     : 0x00000001  A12     : 0x3f94fa00  A13     : 0x3f94fa00
A14     : 0x3ffe6570  A15     : 0x3ffe64d0  SAR     : 0x00000016  EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000001  LBEG    : 0x4009846c  LEND    : 0x4009849a  LCOUNT  : 0xffffffff

Backtrace: 0x4010967f:0x3ffd9270 0x400e07bd:0x3ffd9290 0x400e082e:0x3ffd92b0 0x400e0d4d:0x3ffd92e0 0x40107505:0x3ffd9300 0x40100e9a:0x3ffd9330 0x400fd269:0x3ffd9360 0x401091ed:0x3ffd9380 0x40100f34:0x3ffd9420 0x400fd269:0x3ffd9450 0x400fd296:0x3ffd9470 0x400e0e1d:0x3ffd9490 0x400e109d:0x3ffd9530 0x400df973:0x3ffd9550

    Also:

    [  5366.448] Failed to pull downlink packets from server: [Errno 118] EHOSTUNREACH
    0
  • D

    Cheers,

    That fixed the connection issue, it's connecting every time now.

    It is still resetting every 5-10 minutes for no particular reason even after using a keyboard reset, this seems like it's related to pybytes since none of my code is running. I have my pybytes json file as follows:

    {"wifi": {"ssid": "", "password": ""}, "wlan_antenna": 0, "dump_ca": false, "lora": {"abp": {"dev_addr": "undefined", "app_skey": "undefined", "nwk_skey": "undefined"}}, "server": "mqtt.pybytes.pycom.io", "ssl": false, "lte": {"apn": "hologram", "cid": 1, "reset": false, "carrier": "Verizon", "band": 28, "type": "IP"}, "device_id": "c4850280-85ab-4a84-b9aa-ded71a7cf2e8", "network_preferences": ["lte", "lora_abp"], "ota_server": {"port": 443, "domain": "18.195.202.40"}, "pybytes_autostart": false, "username": "*****"}

    I thought putting pybytes autostart as false would solve the problem, but it has not.

    Any ideas?

    Note: If I do the keyboard interrupt immediately after a reset it won't do its reset after 5-10mins, I'll have a look through the nanogateway code incase theres another timeout or something, I'll also try and figure out exactly how long it takes before a reset. I'll put a reception strength checker in for each ack so I know it's not reception and maybe a lte.isconnected() to see if it's connected too.

    0 L 1 Reply
  • robert-hh

    @Dylan See this PR and a fixx to the errno trouble: https://github.com/pycom/pycom-libraries/pull/107
    Especially: Change that line:

                    if ex.errno != errno.EAGAIN:

    into

                   if ex.args[0] != errno.EAGAIN:

    P.S.: PyCom has a lot of room for improvement when it comes to keeping the documentation correct and recent as well as responding to PR's from the community.

    1
Log in to reply
 
4 out of 5

Pycom on Twitter