[Steve Kovarik]

Hello Alex
We would need you to identify the MultiTech device that you have for us to suggest any ideas or solutions.

-Regards

[Steve Kovarik]

Hello Sebastien

Look in “Administration” and “Package Management” to see if there are installed packages as indication Node-Red is successfully installed.
When power is applied to the Conduit and after it boots-up and you are able to log into the device, Node-Red will take an additional 5 to 10 minutes to load.
If you are still unable to log into Node-Red after 10 minutes, it is possible that you configured eth0 as WAN and then to access Node-Red via a WAN interface you need to go to “Administration” then “Access Configuration” and for Node-Red
enable “Via WAN” scroll to the bottom and “Submit” then “Save and Apply”.

-Best Regards

[Steve Kovarik]

Hi

Have you tried clearing the cache on the Browser or try a different Browser.
Depending on what you previously configured in the device, for example if you configured the Ethernet (eth0) interface as a WAN it is possible to lock yourself out of the device if remote access via WAN is not enabled.
As a last resort you can always factory default the Gateway by holding in the ‘Reset’ button for 31 seconds.

[Steve Kovarik]

Hello

Can you specifically try https://192.168.2.1 rather than http://192.168.2.1

[Steve Kovarik]

Hi Cedric

The DeviceHQ server is not pingable by design.
From here I would recommend that you register and open a ticket in our Support Portal at the link below.
The Support Portal will allow you to attach a configuration file and device logs to help troubleshoot.
https://support.multitech.com/support/login.html

[Steve Kovarik]

Hi Cedric

Have you programmed your DeviceHQ ‘Account Key’ into the Conduit AP in “Administration” “Remote Management”?

[Steve Kovarik]

Hello Simon

Currently we only support Packet_Forwarder_to_LoRaServer when the two are interfaced via an Ethernet LAN. The timing is critical and using cellular on the Packet Forwarder is too latent and causes packet loss issues like you are experiencing.

-Best Regards

[Steve Kovarik]

We would also recommend upgrading the firmware on that MTCAP device from 5.0.0 to more recent firmware version 5.3.5

[Steve Kovarik]

Hello

A public IP Address is not required, you would just need to verify the MTCAP has access to the Internet. That can be done by logging into the device and navigating to “Administration” then “Debug Options” and use the ping feature on that page to ping both an IP Address (8.8.8.8) and a hostname (www.google.com).

-Best Regards

[Steve Kovarik]

Hello mgs98

We would recommend to ‘register’ and create a ticket in our Support Portal and request files/instructions to recover the device.
https://support.multitech.com/support/login.html

-Best Regards

[Steve Kovarik]

Hi Matt

I was asking that you perform the specific instructions below.
Are you willing to try that.

Detailed Steps
Obtain the required update files from the downloads page. (You can also find these files in your current build of mLinux in the built/tmp/deploy/images directory.) Refer to the Conduit: mLinux Mode, Other Downloads, and click on Pre-Built Images. Select your hardware (currently MTCAP or MTCDT).
Select the version you want to use.
Then download the jffs2 file desired (base or factory image) and uImage file. For example:
mlinux-factory-image-mtcdt-20150527081222.rootfs.jffs2
uImage–3.12.27-r11.2-mtcdt-20150527052826.bin
On your PC, rename the new firmware files like this:
mlinux-factory-image-mtcdt-20150527081222.rootfs.jffs2 → rootfs.jffs2
uImage–3.12.27-r11.2-mtcdt-20150527052826.bin → uImage.bin
Connect the Conduit to your PC via an ethernet cable and ssh into it.
On the Conduit, first create the destination directory:
mkdir /var/volatile/flash-upgrade
Copy the files to the device. If using Windows, you’ll need a tool like WinSCP or SCP in Cygwin.
Using SCP on your PC:
scp uImage.bin root@192.168.2.1:/var/volatile/flash-upgrade/uImage.bin
scp rootfs.jffs2 root@192.168.2.1:/var/volatile/flash-upgrade/rootfs.jffs2
After transferring the files, on the Conduit run:
For mLinux 3.x:
Run touch /var/volatile/do_flash_upgrade
Run reboot
For mLinux 4 or higher:
Run sudo touch /var/volatile/do_flash_upgrade
Run sudo reboot

-Best Regards

[Steve Kovarik]

Hi Matt

I have had success flashing mLinux firmware using the ‘Auto-Flash during Reboot – detailed steps’ method described at the link below.

http://www.multitech.net/developer/software/mlinux/using-mlinux/flashing-mlinux-firmware-for-conduit/

The mLinux files for this method can be found at the link below.

http://www.multitech.net/mlinux/images/mtcdt/

-Best Regards

[Steve Kovarik]

Hello Luize

Thank you for bringing this to our attention, we are currently looking into it.

-Best Regards

[Steve Kovarik]

Hi Leeky

Aside from configuring the LoRa end-node’s and the LoRa Gateway for maximum power and highest Spreading Factor for maximum range, we find that Gateway placement and antenna height are two substantial factors affecting range.
Placing the antennas as high as possible generally provides maximum achievable range.
Range varies based on many variables.
Range is maximized if ‘line-of-sight’ can be achieved with no obstruction.
Any obstruction induces a ‘fade margin’ that can reduce the RF signal.
Different materials induces a different ‘fade margin’ where earth and water are most challenging.
If you have line-of-sight between the end-node and Gateway with the Gateway antenna elevated to compensate for earth curvature…up to 10 miles range can be achieved.
Aside from line-of-sight deployments it is difficult to speculate what range will be without doing a site survey in that particular environment.
Hope that helps.

-Best Regards

[Steve Kovarik]

Hi Leeky

Here’s some information regarding IP67 installation.
However this doesn’t cover Gateway range.

https://webfiles.multitech.com/mmm/IP67_install.pdf

-Best Regards

[Steve Kovarik]

Hi Leeky

I can provide this.

[Steve Kovarik]

Hello Maia

Try the “radio-cmd” command utility to issue ‘AT Commands’ to the radio.
$ radio-cmd at#shdn

https://www.multitech.net/developer/software/mlinux/using-mlinux/utilities/radio-cmd-usage/

-Best Regards

[Steve Kovarik]

Hi Carsten

The only situation I experience where the ‘reset’ switch does not perform a factory default is if some ‘custom application’ has been loaded that is controlling the Gateway.
I would recommend to ‘register’ and open a support ticket for direction on other recovery options.
https://support.multitech.com/support/login.html

-Best Regards

[Steve Kovarik]

Hi Fred

Thank you for the follow-up information.
The IP Address assigned to the modem [10.12.245.242] is a private IP, firewalled by the cellular carrier.
You won’t be able to access the device remotely unless you work with your cellular carrier (SIM Provider) to get “Mobile Terminated Data Service”.

The only other option with the SIM service you currently have would be to use DeviceHQ.
DeviceHQ is a Cloud based management platform you can use that is included with the purchase price of the device.
https://www.multitech.com/brands/devicehq

-Best Regards

[Steve Kovarik]

Hi Fred

Likely because your SIM card is not provisioned for “Mobile Terminated” data service.
What is the IP Address assigned to the modem from the cellular carrier?
This is displayed on the ‘Home’ screen when a cellular connection is active.

If you enable “ICMP via WAN” under “Administration” then “Access Configuration” [submit then save and apply]
you should be able to successfully Ping the cellular IP assigned to the modem from the Internet.

-Best Regards

[Steve Kovarik]

Hi Fred

First off…you would’ve needed to have the 4G SIM card provisioned for “Mobile Terminated” data service, this usually takes the form of a Public, Static IP Address assigned by the cellular carrier to the SIM.
Secondly, there is a configuration option in the Gateway [https via WAN] under ‘Administration’ then ‘Access Configuration’ that needs to be enabled to allow remote web administration to the device.

-Best Regards

[Steve Kovarik]

Hi EG

The two firmware files are identical, The MTCAP+ signifies that that particular firmware file was uploaded and selected to be used with MTCAP and MTCAP2.
Either firmware file will work for MultiTech model MTCAP-LNA3-9165-001A.
Sorry for the confusion.

[Steve Kovarik]

Hello Amirhossein

If you log into the Conduit web administration and select “Administration” then “Firmware Upgrade”, is there a checkbox on the page for “Signed Firmware Validation”?

[Steve Kovarik]

Hello Amirhossein

5.0.0 is dated. There have been many fixes and improvements since.
We would recommend that you upgrade the Conduit firmware to (signed) version 5.2.5
Then if the problem persists, open a support case so we can troubleshoot what is happening.
http://www.multitech.net/developer/downloads/
https://www.multitech.com/support/support

-Best Regards

[Steve Kovarik]

Hello

The MTQN-MNG1-B02 is a cellular modem with Serial UART or USB interface. This is not the SOM model that allows it to host a program.

Model MTQN-MNG1-B01 is the SOM (system on module) build with the additional Cortex cpu that allows you to drag-and-drop a (mbed) program onto the enumerated drive.
Depending on what you are trying to do, you may have the incorrect model modem, but this may help explain the behavior you are experiencing.

-Best Regards

[Steve Kovarik]

Hi Jacky

The ‘Packet Forwarder’ may not start if the Conduit does not have access to the Internet.
First step is to verify the Conduit has Internet access and can resolve a host name.
To do that…log into the Conduit web administration and select “Administration” then “Debug Options” and scroll down to the Ping utility.
Try and Ping both an IP address 8.8.8.8 and a Hostname http://www.google.com.
If successful, I would suggest to open a Support Portal ticket to further troubleshoot https://support.multitech.com/support/login.html

If the Ping test is unsuccessful, you’ll need to work on getting successful internet access for the Conduit Gateway.

-Best Regards

[Steve Kovarik]

Hello Jacky

To configure the Conduit ‘Frequency Sub-band’ log into the Conduit web UI and select the “LoRaWAN”, “Network Settings” tab.
With the ‘LoRa Mode’ set to “Network Server” the ‘Frequency Sub-band’ setting is on this page under ‘LoRaWAN Network Server Configuration’.
The Frequency Sub-band setting is valid if using US915 channel plan.
For example if you are using EU868 (for Europe) there is no ‘frequency Sub-band’ setting and that part can be ignored.

-Best Regards

[Steve Kovarik]

Hi Philippe
Use a paperclip to hold in the ‘rest’ micro-switch button located on the front panel of the device for 15 seconds to reset to factory defaults.
This should set it back to the default of 192.168.2.1

-Best Regards

[Steve Kovarik]

Hi Tomas

You could use a paperclip straightened out and try to factory default the device by using the paperclip to hold the “Reset” button in for 31 seconds.
The MTCAP device should factory default back to it’s default IP of 192.168.2.1 where you can access it through the GUI.

-Best Regards

[Steve Kovarik]

Hi EG

Part of the Verizon certification process has the Verizon network download the APN to the modem/SIM which is why if the modem detects a Verizon SIM, the APN field is omitted from UI.
There are different ways to manually program the APN into the device as a one-time task.
You can go to “Administration” then “Debug Options” and select “Show” for “Radio Terminal” to issue AT Commands to the device to set the APN.
Another method is to disable cellular and ssh into the device to gain access to the cellular radio to set the APN.
If you have any issues just open a ticket in the portal at the link below.
https://support.multitech.com/support/login.html

-Best Regards

[Author]

Posts