Multitech Conduit AP v3 Basic Station

Hi all! Thought I’d share something I’ve been working on, in case it’s useful to anyone else:

For my work I’m currently migrating from V2 to V3 (hosted by TTI), so I’ve been working on getting our gateways of choice (Multitech Conduit AP of course) working on it. The end goal is to entirely automate the gateway provisioning process, but it’s not quite there yet.

I’m not sure how long ago but Multitech released a binary for the new Basic Station forwarder - this is fully supported within a V3 stack, so the aim was this:

  • Work through the incredibly sparse documentation to get the gateway to work on the Europe spectrum in V3
  • Create all associated config files automatically
  • Fully configure the device through one script
  • Automate the provisioning of the device within TTI itself

Find all the scripts and accompanying README here: https://gitlab.com/measuremen/multitech-setup

It’s early days so the script works on a few assumptions:

  • You’re in Europe and using the Europe spectrum
  • You have an Organization within your TTI stack and are creating the gateway in there
  • The device is using MLinux, not the closed-source AEP firmware from Multitech (although I think it will work too)
  • The device is running firmware 5.2 or newer and already has been configured to access the internet

Have fun! No warranty provided :wink:

1 Like

Nice work. However, it looks like you are embedding the channel plan statically inside station.conf. This should not be done according to https://doc.sm.tc/station/gw_v1.5.html:

A configuration need not specify any frequencies or enablement for IFCONF or RFCONF objects. This information is submitted by the LNS based on the channel plan assigned to a gateway. The channel-plan settings are merged with the local configuration before the concentrator board is initialized.

The channel plan configuration is pushed down from the LNS. Only static, gateway specific aspects go into station.conf. Have a look at this example:

1 Like

Ah thanks @bei, greatly appreciated - I carried some incorrect thinking over from the days of the Semtech packet forwarder!
I’ve fixed that up now.