Multitech Conduit AP

The Multitech Conduit AP: https://www.multitech.com/brands/multiconnect-conduit-ap

Multitech Conduit AP

Since my company primarily focuses on in-building deployments, having a small, discrete-looking gateway that can be installed indoors is much more suitable than the do-it-all carrier-grade roof installations that many other people are using.

I’ve been using Kerlink iFemtocells for a while now; they’re nice, cheap devices with commercial support and are perfectly adequate at covering an office block. However they’re lacking a few nice-to-haves, and the embedded OS is quite outdated and not well documented.

I’m seeing two advantages of the Conduit AP over the iFemtocell:

  • More open firmware built on the Yocto project with accompanying documentation - Kerlink hides all documentation behind a login screen and is not very in-depth
  • Comes with a cellular modem as standard, which is a must when deploying into secure corporate environments like some of my clients…

So far, so good - however, it seems to have been released fairly recently, and nobody’s talking about it. Has anyone had any experience in using it? How much does it cost?
In theory, the firmware and hardware is basically the same as the Conduit, but if anyone’s used them, I’d love to know!

I’m waiting on quotes from Multitech, and if nobody else has the answers, I’ll report back when I have them :wink:

So, I’ve got my hands on a Conduit AP. I receive these units from work, and I thought I would share my notes with the community :smile:

The Multitech Conduit AP comes in these variants:

  • MTCAP-LNA3-915-001A - US model with AT&T/Verizon cellular and AEP software
  • MTCAP-LNA3-915-001L - US model with AT&T/Verizon cellular and mLinux software
  • MTCAP-LEU1-868-001A - EU model with cellular and AEP software
  • MTCAP-LEU1-868-001L - EU model with cellular and mLinux software

There are non-cellular models of the above, without the “LEU1” or “LNA3” in the name. These are roughly €100 cheaper, and do not have the SIM card slot. I have the MTCAP-LEU1-868-001L.
Both the mLinux and AEP models are identical hardware-wise; mLinux is the open developer software, and the AEP model runs Multitech’s proprietary web interface. The AEP model is about €75 more expensive.
I’ve heard rumours of an Asia variant in the works, that will also work in Australia.
Overall I paid around €300 excluding tax, but you must remember that my company buys direct from our regional authorised distributor, so you may pay more.

So, without further ado:

The Conduit AP Specs and Teardown

The Multitech Conduit AP is the smaller brother of the Multitech conduit. While the Conduit is an industrial grade item with swappable radios, the AP is a smaller, less industrial grade unit designed to be discrete.

This product looks like you could put it right in the middle of an office space and nobody would ever question it. I think that’s what MT were going for, and that’s exactly what I need. The outside of the box contains no obvious LoRaWAN markings, and the Multitech logo is certainly there, but it fades into the rest of the unassuming look of the device.
You may be wondering: where are the antennas? All antennas are internal, further adding to the unassuming aesthetic. Seriously, if I didn’t know what this thing was, my eyes would just pass right over it. That’s exactly the look I’m going for, so this is perfect. I don’t want office workers messing with the thing.

Here’s a picture of the unit I received:
IMG-20180329-WA0004
The box appears slightly whiter than the image provided by Multitech, but overall it’s fine. I do get the “90s box PC” vibe from this, and I suspect that this will look more yellow than white 10 years down the line.
Here’s a picture from the back:
IMG-20180329-WA0003
Here we see the IO on this board, and it’s very simple. Here’s what’s there:

  • DC barrel plug which requires 5V 1.4A (5V 2.5A power supply included)
  • Ethernet port (10/100M)
  • Reset hole (press to restart, hold 30 seconds for factory reset)
  • WPS hole (there is no button behind this hole. It’s just a hole. Seriously.)
  • Micro SIM slot for cellular models
  • 4 status lights

Teardown

Opening the case is quite simple, but I would have preferred to have screws instead of clips. To open the case, insert a flathead screwdriver into the 4 holes on the bottom of the case, and apply force inward to release the clip.
IMG-20180329-WA00022
You can see the 4 clip holes around the perimeter of the device.

Once the device is opened, you’re greeted by a rather sparse board and two internal antennas raised up on styrofoam. I assume that the non-cellular version will only have 1 antenna.
IMG-20180329-WA0005
I’m not sure why there’s so much empty space. I have two theories: 1) The box needs to be big enough for the antennas, or 2) The device looks more “professional” at this size, even though it could be half the size.

Taking the board out, here’s some things I notice:
IMG-20180329-WA00101

  • The EU cellular model I have has a Telit module displayed front and center.
  • There’s a 3-pin header near the ethernet port. The Conduit came with an onboard USB to serial converter, but this does not - I can only assume that this is the serial connection. I’ve asked Multitech for clarification.
  • There’s two jumper pins, and I have no idea what they’re for - again, I’ve asked MT for clarification.
  • MT claims that the battery is not user-replaceable, but it seems like a pretty simple job - in theory, the battery should last 10 years though.

Flipping the board over:
IMG-20180329-WA00088
Here we see the heart of the machine. We’ve got an Atmel ARM processor. I can’t remember the spec of this model, but the frequency is on their website. In the top right, we see a Semtech SX1301 module. Apologies about the picture quality, but I assure you that’s the chip number!

Conclusion

I know there’s a lot of hobbyists here, and I personally have myself a Pi and a RAK831, but of course for business use, that’s just not acceptable! For the price that Multitech is going with this, this model is just perfect for my business needs, where I do indoor installations and don’t want to worry about range issues.
I’ve been using a Kerlink iFemtocell as well, and I might write up a review on that in the future. While the iFemtocell is a little bit smaller, it’s also more expensive.

I’ve only just started with this model, and the software is almost the same as the MT Conduit. If anyone’s got any software questions, feel free to ask!

Trust me, working in enterprise office spaces and university campuses, trying to set up Zigbee mesh networking is NOT fun. LoRaWAN all the way!

UPDATE: An MT representative told me that they have multiple board revisions, so your internals may look different. He also told me that opening it may void the warranty, so don’t do what I did!

1 Like

Note: the install script for Multitech provided by @kersing didn’t work for me - the networking configuration for the Conduit AP seems to be the issue.

I removed the networking configuration section from the script, and manually modified the networking, and the script ran with no hitches.

For the AP model the network can be set using the MultiTech procedure and the script should skip the network setup. Worked on the AP last time I configured one.
What were the steps you used to configure the AP? And what software version is that AP?

@kersing I amended my previous post - it seemed to be a bit temperamental but it may have just been a one-off. I didn’t know that the script had been tested on an AP.

I ran the script on a brand new AP with a firmware upgrade to mLinux 3.3.13. No other steps were taken - only upgrade, then upload&run script.
After the reboot command in the script, I was unable to connect to it anymore - the static IP configuration was removed, but the DHCP client wasn’t connecting to my network correctly. I did a quick check on my router and it showed that the device was not given an IP address.

I haven’t had time to diagnose the issue, and I need the AP in a working state for now, but when I receive another one, I’ll take the time to figure what exactly went wrong.

Do you know if the AP has a serial port? I can see an internal 3 pin header that looks promising. Any idea of the pinout?

I’ve been using the MTCAP-915-001L for about three months with my own end nodes. It took a little effort to learn to set it up since I had to do it manually, having a linux system interface. The recent versions have a gui interface, or maybe I just got the “wrong” version. I got a lot of help from Multitech to get the wifi communication set up. All this was because I have/had no idea what I was doing but with a little help was able to set up the LoRa forwarder to the SEMTECH server and then push the data to myDevices (CayennaLPP). All of this is explained in the Multitech AP documentation and in hindsight isn’t hard at all.

My experience has been very good with this gateway. It has “failed” only once in three months, a result of a power outage at my home, where I had to restart the LoRa forwarder since I am too dumb to put an auto restart into the configuration file, or whatever. Except for this glitch I have months-long records from my nodes stored both on the SEMTECH server and plot-able via CayenneLPP. The gateway just works and I pay it no attention to it whatsoever. A fine testament to robust operation and reliability.

Adding a new edge node is trivial and requires no change or attention whatsoever to the gateway per se, just a registering of the device on the SEMTECH site and myDevices.

I have helped two different colleagues set up similar Multitech gateways now and I am particularly interested and pleased with the version with the embedded cellular modem (mine has only an ethernet or wifi connection, but no cellular modem). This is ideal for deployment at customer sites, where most customers do not look kindly upon requests to access their corporate wifi networks.

I am very pleased with the Multitech AP gateway. I am still waiting for my TTN gateway to stay up for more than 24 hours before stalling/re-booting. Eventually whatever is wrong with it might be fixed but for now I unhesitatingly recommend the Multitech AP, at about the same cost as the TTN gateway, as an excellent way to manage LoRaWAN edge node traffic. I expect to buy and deploy dozens of them.

Is there a reason you haven’t connected your gateway to TTN? My MultiTech conduit has been sending data to TTN since October 2015 allowing other TTN users to take advantage of the coverage as well.
I’ve tested the software it works for the AP model as well…

That’s the difference between the AEP and mLinux model. (-001A vs -001L)

  • The mLinux version is a pure command line Linux device, designed for “developers”. If you’re comfortable on a Linux command line, this one is for you, as it’s much more flexible.
  • The AEP version comes with a nice web interface to make setting up private networks easy, and is a proprietary software from Multitech - as such it is considerably more expensive.

From what I see, both models are exactly the same hardware-wise. Has anyone tried flashing the AEP firmware on an mLinux model? Don’t expect any support from Multitech if you do that though, since you didn’t pay for it :wink:

Yes, I had to, to test my installer and packet forwarder :wink: However as these replace/bypass the AEP features by forwarding the data to TTN it doesn’t make much sense if you want to run a TTN gateway. So for TTN use, I would suggest keep the additional $$ in your pocket and go for the mLinux model.

AEP is packed with features, and while I haven’t used it much myself, it looks like it would be great if you need a standalone setup… I just find it strange that they didn’t build in packet forwarder configuration.

Maybe they just want to lock you into using their software stack? It feels like a financially (not technically) motivated decision to me, because it doesn’t seem that difficult to add.

While I personally am fine with Linux command line, my colleagues aren’t, and having a web interface which allowed for configuration to the TTN network (even if it was just the reference Semtech software, not yours @kersing) I might actually consider the extra cost.

As I said before, I’ve got a cellular version and I plan to exclusively buy cellular models, albeit the EU version. I work with some large enterprises, where corporate network/internet access is a definite “hell no”.

While I haven’t actually tried the functionality out yet, I’m planning on popping in a SIM card and testing it out after Easter - I’ll post my findings on setup and reliability at the end of the week.

@kersing I originally did register the Multitech AP as a gateway on TTN but could never get it to show up. I know now that I needed to set the TTN forward IP address in the gateway config file to get this to work. I must say, setting up the TTN gateway was super easy and it worked first time out for me with zero fuss. Setting up the Multitech gateway took a bit more work. Not because I don’t know how to navigate in a Linux environment (I do) but because the “instructions” for doing so only became clear to me after I had finally succeeded in doing it!

In fact, since I have two gateways, my plan was to use the TTN gateway as the public one and the Multitech as the “private” one. I even bought an antenna for roof mounting for the TTN gateway, but this part of the plan is on hold until the TTN gateway can stay on for more than a day.

@Eelviny The GUI interface makes it really quite easy to set up the Multitech gateway for packet forwarding (it comes with a forwarder) and might be worth the extra cost for newbies or those who don’t know simple Linux commands. Having the embedded cellular means one can literally plug in the gateway anywhere and get data streaming to the back office app. My colleague was pleasantly surprised when he started getting environmental data from one of the nodes he is using for testing on his smartphone when he plugged the Multitech gateway in at a restaurant.

Unknown yet is which gateway/interface will be best for provisioning/maintaining gateways for customer deployment. In large office buildings or hospitals, we expect to need one gateway per floor. It would be great if one on the roof were enough for full coverage but we haven’t got to this point yet. But if one has to provision several or even many gateways per customer site, then provisioning and maintenance become issues. I suppose we will find out…

Installing the MP forwarder would be a better solution. :wink:

I would be surprised if that turns out to be necessary. At our monthly meetup location the gateway is at the top of an 8 story building, the meetups in the basement and we’ve got no trouble getting data to the gateway.

For deploying larger numbers of MultiTech gateways I would look into the ansible & custom image used by the TTN New-York. They developed their solution to solve these issues. @terrillmoore should be able to point you in the right direction.

Good to know, it would be great if we could get along with just one gateway per location/building.

I expect we will be deploying large numbers of gateways but at different sites. If we roll out the solutions at a reasonable pace then provisioning is much less of an issue.

On using the Multitech gateway with TTN, I found the documentation somewhat less than complete. Especially for these newer, less expensive Multitech AP gateways, it would be useful if a knowledgeable person would create a tutorial for connecting them to the TTN as a packet forwarder.

The tutorial we found seems to have been written for a Multitech Conduit and was mostly about how to connect the Conduit to the local wifi, etc.

With the right instructions it should only take most people 10 minutes to connect the Multitech AP to TTN and start forwarding LoRaWAN packets. There are a lot of pitfalls and false turns possible and the Multitech documentation is just wrong in a lot of places.

For example, apparently there are three key words associated with cellular service providers, one of which has to be entered into the configuration file otherwise the cellular modem will not work. This is undocumented and took several hours to tease out via discussions with Multitech personnel on their help line. This kind of thing can be very frustrating for new users and could be a nice opportunity for TTN to capture more “business” by making it easy/easier, just like it is with the TTN gateway.

It seems you have the knowledge so feel free to document it so others do not need to stumble along the same path.

TTN is a community. You are part of the network :wink:

The tutorial was written based on the hardware that was available at the time.

As I mentioned above, feel free to contribute. I spend many hours (well over 300) of my spare time on development and debugging of the MP packet forwarder and the install script, it would be nice if someone from the community (or may-be one of the people making money by using the software in a business setting) would invest/contribute a bit as well.

1 Like

I wasn’t suggesting you write it, necessarily.

Perhaps when I know more about what I am doing with the gateways, I will write a tutorial. I have to do this for my clients anyway eventually…

I just provisioned 21 MultiTech Conduit 246s, and 24 MultiTech Conduit APs, using our Ansible package. Worked very well. See GitHub - IthacaThings/ttn-multitech-cm: Ansible setup for configuration management of Multi-Tech Conduits for The Things Network Org and (currently) GitHub - terrillmoore/conduit-mfg: Manufacturing instructions for deploying Conduits with Ansible (moving soon to IthacaThings) for more info. Feel free to get in touch - contact info at https://ttni.tech.

The setup includes a “jumphost” which receives incoming SSH calls from the gateways, allowing clients to reach the gateways via a reverse SSH tunnel. Currently managing 50+ gateways; it’s still somewhat rough, but it’s working well. Installs the Kersing router, and can handle the older 210s, the 246s and the APs.

1 Like

Thanks for the info, will be in touch…

I know. However it seems no-one else feels the need to do so…

So, I’ve been using this unit for about 2 weeks now, and I’ve got to say, the results are… unimpressive. I have 4 sensors that broadcast every 5 minutes, and sometimes more often than that. They never broadcast less often. Take a look at this graph:
widget_5aaa5c16f159691290bc2421%20(1)
This is the number of packets per hour, separated by sensor. Every sensor is broadcasting at SF8, with a payload of 18 bytes. As you can see, I’m dropping anywhere from 1-4 packets per hour!

My first thought is that maybe something is wrong with the sensors, but when I then compared the result against my Kerlink iFemtocell, placed directly next to the MTCAP…
widget_5aaa5c16f159691290bc2421%20(2)
These are the results I’m expecting. I know I’m never to going to get 100%, but I think the MTCAP’s packet loss is simply unacceptable.

Every sensor is within 1m of the gateway for this test. Is anyone else experiencing issues like me, or did I just get a defective unit?