Two concurrent packet forwarder in the same gateway

Home Forums Conduit: mLinux Model Two concurrent packet forwarder in the same gateway

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #32070
    sebastian barillaro
    Participant

    Hello,

    I have a LoRa Gateway MTCDTIP-L4E1-275L-868. I understand this gateway has two LoRa boards v2.1 inside.
    For a research experiment, I would like to run two packet forwarder (pkt_forwarder) concurrently, with different configurations each.
    I tried to duplicate the binary into pkt_forwarder-0 and pkt_forwarder-1, and then executing them using -c flag to indicate its respective configuration file.
    ./pkt_forwarder-0 -c global_config.json.radio0
    ./pkt_forwarder-1 -c global_config.json.radio1

    However, I receive error messages like
    (pkt_fowarder-0)
    Configuring radio…
    ERROR: sx1301ar_start failed ; Calibration of AD9361 PLL charge pump failed

    (pkt_forwarder-1)
    Configuring radio…
    ERROR: sx1301ar_start failed ; AD9361 BB PLL failed to lock

    It seems there are a race condition for configuring the LoRa boards.
    It seems to me that I am not configuring correctly. What would be the right way to assign a LoRa chip to each one of the pkt_forwarder running?

    With best regards

    Sebastian

    #32071
    Jason Reiss
    Keymaster

    I do not think this is possible with the v2.1 hardware. The Sx1301 array is accessed through an FGPA, all SPI calls are multiplexed through a single SPI interface.

    The packet forwarder global_conf.json file configures both Sx1301 chips.

    A gateway with two MTAC-LORA-1.5 cards can run with a packet forwarder process for each card.

    What is the premise of the experiment that would require two packet forwarders?

    Perhaps a process that receives the UDP data from one packet forwarder could mimic the connects to a network server that two packet forwarders would make?

    #32074
    sebastian barillaro
    Participant

    Dear Jason,

    Thank you very much for your prompt response.

    We are working with Satellite back-hauling for a LoRaWAN network. The idea behind this experiment is to study the impact of satellite back-hauling in a LoRaWAN network. For such, we want to have two packet forwarder running at the same time. This means, one packet forwarder connected to the Network Server through a satellite link. While the second one connected to the Network server using a regular Ethernet link, as reference.

    I have been able to run two copies of chirpstack-gateway-bridge, each one with different configurations. Both receive UDP, but one forward through the LAN, while the second one forward to a Satellite Terminal.

    The second experiment that we want to run is to have the gateway working for two different network servers. Something that we know it is not considered on the design of a LoRaWAN network, but it could be potentially doable if two packet forwarder can operate interdependently. Again, for researching purposes.

    I am aware that I am pushing for a non-standard use of the device beyond on what it has been designed for. Even though, I would really appreciate any help you could give me to achieve this goal.

    With best regards

    Sebastian

    #32075
    Jason Reiss
    Keymaster

    The SPI resource can only be controlled by one process, so this will limit you to one packet forwarder.

    I suggest creating a program, like the chirpstack-gateway-bridge, that listens locally for UDP messages and sends them over each backhaul in separate sockets.
    There are no utilities already available to achieve this non-standard use, it will need to be a custom application.

    The UDP protocol is similar to the following protocol for the v1.5, the JSON message will differ but since you are only passing messages through you should only be interested in the socket connections.
    https://github.com/Lora-net/packet_forwarder/blob/master/PROTOCOL.TXT

    Let us know if you have more questions.

Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.