[lorawan2016]

Hello Lonny,
Yes you have right the msg_chat logs was for another test related to cdma.
The pointed chat in the script is the gsm but there’s no chat logs similar to the cdma since the shown logs are ended by connection terminated for ppp.

I have noticed as well that the /etc/sbin/pppd requires a provider file in the located in the peers folder so I have created a provider file but it’s empty though the documentation doesn’t mention it’s required which’s indicating something either wrong or missing in the gateway.
Do you know what kind of information should be written in the provider file?

[lorawan2016]

Hello,

I am getting the same problem using Multitech Conduit gateway AEP model and firmware version 1.4.1 .
Minas, Have you resolved the problem?

Any official answer on this?

[lorawan2016]

Hi Ben,

In addition to what Jason is suggesting, you could check that you have internet connection in your Conduit gateway by pinging a site, try in Tera Term login to your Conduit gateway if you are using Windows and then just ping http://www.google.com from the command line and check what’s the response.
Note that MQTT in Node-RED is working properly for me in Conduit firmware version
1.4.1.

Jason, in case of Conduit AEP as packetforwarder when writing custom application with MQTT support using Nodejs or javascript, which interface is available to access the received and sent packets through the gateway?

[lorawan2016]

Thanks for any information on this track 🙂

[lorawan2016]

Hi Kamil,

I don’t know if you already have solved the problem.
What’s the distance between the end-device and the gateway?

[lorawan2016]

Hi Guillermo,

Are you using Microchip module as end-device?
Please share more information about your hardware and firmware version.

Generally, use dr5 and SF7 if the end-device and the gateway near each others.

[lorawan2016]

The answer is on this track http://www.multitech.net/developer/forums/topic/rn2483-cant-join-to-conduit/

[lorawan2016]

Thanks Mike!

Well you are considering the following settings:
1. AEP Conduit version.
2. Network server configuration.
3. Using Node-RED to achieve MQTT messaging.

The question here, is Node-RED reliable enough to be considered for big LoRa network deployment, lets say thousands of end-devices? … can Node-RED be left running the application for two years without interruptions?

While my intention is to have the following settings:
1. AEP Conduit version.
2. Packet-forwarder configuration.
3. Messaging over MQTT protocol.

Hence, according to your answer in the previous message, I have to have a network server in between. Let it be my own network server to be installed instead.

Could you explain to me if the included MQTT library in network server configuration can be used under packet-forwarder configuration? … or I have to install new MQTT library to get the packet-forwarder configuration working to communicate to the application server?

Installing new libraries or software on Conduit gateway, is it recommended without affecting its performance?

[lorawan2016]

Hi Jon,

If RN2483 has adaptive data rate enabled then why we need to set it manually?

Because we set it manually then I suspect it’s not enabled or there’s no support for ADR in firmware version 1.0.1 …. what’s your comment on this?

[lorawan2016]

Yes it’s already SF7 on the gateway, that’s why it works.

[lorawan2016]

Thanks Jon, … it works at dr5.

Hi Yuqian,

Happy to know it works for you, it works for me as well after setting dr5 on the end-device.

Is the SF7 on the gateway or the end-device?

[lorawan2016]

Hello,

Today I did new tests and I got the same problem as Yuqian Li got i.e. denied, not_joined and no_free_ch using RN2483 firmware version 1.0.1 and Multitech Conduit gateway 1.3.2. though there was just one RN2483 to try to connect to Conduit gateway.
After trying the disconnection of the USB cable several times it worked after the 5th try.

[lorawan2016]

Thanks Jon and Peter … finally we see the official response on this track.

I have just tested OTAA with RN2483/firmware version 1.0.1 with Conduit gateway firmware version 1.3.2 and it works from the first run.
I will do more tests to check if it’s reliable in long run or I would get no-free-ch or denied messages as Yuqian is experiencing.

[lorawan2016]

Thanks Mike and Jason,……now I got it.

Jason,…. I thought Conduit gateway already has a packet forwarder and all I have to do is to configure the Conduit gateway as packet-forwarder and then just to write the server address in the gateway-configuration section to create the connection. Apparently, the code in your link tells me it’s not as I have expected.

The broker I want to connect to is MQTT broker so I don’t know if I need to install any MQTT library on Conduit gateway to get this working?

The packet forwarder in your link is C-based code and one has to install C++ tool-chain or similar to get it working?

[lorawan2016]

Mike,

The example in the link is just for two of 8 radio channels, namely radio_ch0 and radio_ch1. The objects below it are 8 spreading factor configurations over the two radio_ch0 and radio_ch1.

[lorawan2016]

Thanks Mike,

Yes I tried previously the Node-RED nodes with MQTT and it worked.
Now my intention is to try the AEP Conduit as packet-forwarder without Node-RED to communicate with an external MQTT broker.

[lorawan2016]

Hi Lawrence,

Is the node.send(downlinkPackets); for Node-RED only or it’s possible to use it in any javascript code?

for the uplink messages in javascript or node.js, do you know what interface to use to access the uplink payload?

[lorawan2016]

Hi Yuqian,

I have heard from one of sales engineers last week that class A and class C is released in one firmware and the version for that firmware is 1.0.4 but I don’t know how to get it.

The idea is not to upgrade the firmware on Microchip module but as I wrote in my previous messages is to downgrade the firmware on the gateway to earlier versions and check if it works. This way we can narrow down the issue and it would be easier to track it.

The strange thing is that there’s no official comment on this problem and why?

[lorawan2016]

There’s version 1.0.4 now and that’s why I consider version 1.0.1 is an old version.

[lorawan2016]

Hi Yuqian,

Since the 1.0.1 is old firmware version, just for testing, try to downgrade the firmware on your gateway to either

Firmware version 1.0.33 (Released 09/25/2015)
OR
Firmware version 1.1.2 (Released 02/02/2016)

You can do this easily by registering your gateway in MultiTech DeviceHQ https://www.devicehq.com

Before doing the downgrade it’s important to save your configuration and then let DeviceHQ do the job for you after scheduling the downgrade to be done on next restart of the gateway. It will take a couple of hours or less depending on your internet connection.

Then test it with RN2483 firmware version 1.0.1 to check if it works better.

Later on, you may upgrade your gateway easily to any firmware version as all of them are available on DeviceHQ.
Another alternative is to do the firmware downgrade/upgrade for your gateway manually if you have the firmware file available on your system.

[lorawan2016]

Hello,

Thanks again Mike.
Though this is not exactly answering my questions, I appreciate the time you spent answering my question. Simply, I can’t find the 8 radio channel configurations in any of the given links and in the TTN link there’s mLinux not AEP configuration.

In Conduit AEP configuration as packet forwarder, is the MQTT client/broker needs to be configured and enabled so that the packets forward to the server in two directions?…. I am asking this because I have AWS MQTT to subscribe/publish from/to the gateway.

Do you have any idea?

[lorawan2016]

I am quite sure that last year I connected RN2483 with MultiTech gateway and it worked without any problem but I’m unsure from which firmware version this problem has been introduced.

Another approach is to investigate this problem if you have another LoRaWAN module from ARM mBed i.e. SX1272 or similar one from Murata and try to connect it to the same Multitech gateway and check if it works. If it works then it’s compatibility problem and Microchip or MultiTech has to find a solution for it.

I don’t know why there’s no official response on this track yet !!

[lorawan2016]

Hi Yuqian,

I am trying to investigate this problem but I need some information from you.
Do you know which Microchip firmware version in your RN2483 module? … you can use Tera term and the version will be printed on the screen upon starting the module.

Have you investigated if it works with earlier firmware versions of the Multi-tech gateway?

[lorawan2016]

Hello wojtek t,

If there’s a timeout occurs on the end-device then this could be a bug in the Microchip OR MultiTech firmware to work reliably with each other, LoRaWAN stack problems?

It might be worth raising the same question track at Microchip forum.
This problem was discussed in different forums now but no official answer works!!!

[lorawan2016]

Hi Yuqian,

Check if this is the correct path to edit the file.

/var/config/lora/lora-network-server.conf

or find its location in your gateway, there should be similar one.

[lorawan2016]

Another approach is to configure 8 radio channels in the Multitech gateway rather than the default activated ones ch0 and ch1.

[lorawan2016]

Hi Yuqian,

Yes I have seen this behavior previously and I think this is related to radio channels configurations since the LoRaWAN module RN2483 is trying to send in a pre-configured frequency in the activated channel normally ch0 and ch1 as the default settings of the MultiTech conduit gateway require but it fails when there is no enough time during the pre-configured duty cycle for each radio channel especially when there’s interference “causing the return status no_free_channel” as I remember it between LoRaWAN end-device and the gateway.

In my point of view, I recommend to re-configure the radio channels according to your region available legal frequency bands and set on each channel not just the frequency band but also, the duty cycle, data rate and set the channel to on. Don’t forget to save your configuration after setting the new configuration. Try to adjust the frequency until you find the suitable band to communicate to the gateway. The bandwidth in each channel is 125 KHz.

In Europe the activated frequencies in RN2483 are 868.1, 868.3 and 868.5.

Kindly share your findings if you would try this approach and this is would be helpful for others as well.

[lorawan2016]

Thanks Mike,

I already know your links but none of them clarify the approach or any example for AEP packet-forwarder to configure the 8 radio-channels with legal frequencies in EU, duty cycle, data rate, etc..

What’s to avoid and what’s recommended in such configurations? … best practices.

[Author]

Posts