Gateway comparison: Dragino LPS8 and Mikrotik LR8

Appreciate your overall impressions…I run both as well along with many others. For me the LPS8 was quicker/easier to set up and deploy than the LR8 but then I don’t use either specifically for node development…lots of others to chose from. If I was to give one to a user to fire and forget it would be the LPS8 as less risk of bricking it though as you say RouterOS and the LR8 have more features for a pro networking person to configure and play with, and I like the Mikrotiks power options…the LPS8 came with its own external PSU so no real issue with fact it’s external…helps placement flexibility.

The only factual thing I would challenge is that Semtech have evolved the concentrator baseband and RF front end offerings such that there are now 4 conc chips… the original SX1301, then reduced temp range, slightly reduced spec SX1308, the newer architecture but essentially same spec SX1302, offering lower power and most recently the SX1303 with some enhanced features and lower power… in most real world deployments the actual core 8 channel TTN related performance as RF system is broadly the same… minor implementation changes by different manufactures can negate small device improvements. Note I haven’t tested all chip variants myself yet as still awaiting some gw/con card manufacturers to ship me final units for eval.

Thanks for your write-up.

Having used both devices almost from their release dates I would like to add that there have been a number of firmware updates for the LPS8 steadily making it a more capable device (addition of BasicStation, added remote management) where the LR8 just received bug fixes.
Also the open source and accessible OS of the LPS8 allowed me to add my own remote management provisions which were very useful for the switch to V3. For the LR8 the best option seems to be to create a VPN connection to allow secure remote management.

In my experience non MikroTik users have a harder time setting up the LR8 (I’ve had to help a couple of them to get things running) where basic setup for the LPS8 seems to be less of challenge.

Once installed both work equally well.

Can you please uncheck the ‘error’ for forward settings in the LR8? Packets with CRC errors should not be forwarded to TTN. (Which MikroTik should know by now but seems not to want to fix the default setting).

The real advantage of an open source gateway based would be that you can throw away the vendor silliness and just make your own remote-administration-optimized build using the plain Semtech packet forwarder and daemons to manage whatever Internet backhaul solution you pick.

Typically you wouldn’t be doing much runtime configuration, because you’d have most of your needs baked into your deployment image.

Though if you don’t chose to throw it away, LUCI based configuration stuff tends to be scripting that’s in source form on the box anyway.

I am a newcomer here, but the Mikrotik LR8 comes with RouterOS and offers very interesting features. For example you can easily isolate the LR8 in a VLAN for privacy or establish a VPN. Kind regards, Kellogs

The LR8 is very nice if you are already familiar with RouterOS and don’t mind being locked in by the vendor. For most LoRaWAN gateways RouterOS is overkill and an easier remote management solution would be more welcome.

Nevertheless, it the LR8 is a very affordable option which allows easy outdoor deployment. Just make sure to consider how to manage the gateway before deploying at remote locations.

Dragino LPS8 is based on OpenWRT so it is a nice solution. But it seems to be an indoor solution when Mikrotik LR8 can be used indoor and outdoor. i am using both OpenWRT and Mikrotik on my routers. Mikrotik is not really locking you down. They claim to own their OS, in fact RouterOS is pure Linux kernel. But I agree OpenWRT can be updated on the long run.

Outdoor within certain limits. The unit is IP54 and needs to be mounted the right way to prevent moisture ingress.

However there is no way to get to the Linux prompt or to load custom software. Building your own distribution will be hard because hardware information is missing.
Hmm, as they are using Linux at least the kernel sources should be available upon request or they are breaching the kernel license.

Yes, Mikrotik is using a Linux kernel, I can confirm and this is public information.

1 Like

And that’s where opensource ends… ROS is mostly rewritten from scratch, and so are most services. That’s the reason why e.g. OpenVPN udp mode has been unsupported for years in ROS… original code was terrible so Mikrotik refused to support/rewrite it.

I worked with openWRT and derivatives extensively before jumping into ROS in the mid 2000s, also made my own custom *WRT firmwares for WISPs…

I don’t understand such “vendor locking” in the LR8? as any Mikrotik device will receive upgrades for the life of the device unless hardware prevents so.

On the contrary, in my eye, I prefer ROS, specially, over a non standard openWRT, night and day.

In my opinion, from a bussiness/commercial standpoint, Knot, LR8 (or any outdoors routerboard with miniPCIe support to plug the Lora card) has an edge… commercial support for example, or the ability to assemble a device with any required features hardware wise, while keeping management homogeneous.

UI/management wise there’s simply no comparison. I would get the shivers if I had to manage networks made of hundreds of openWRT devices.

For most LoRaWAN gateways RouterOS is overkill and an easier remote management solution would be more welcome.

What do you mean with easier remote management?? I find it quite the opposite? ROS has the best and most flexible remote management amongst any network vendors, I use it daily, RoMON (remote config in layer 2, you can access devices with no IPs/L3) is simply unmatched, not even cisco or alike offers it.

Also, there’s the Dude for free, to build network monitoring dashboards…

Yes ROS won’t allow you to install not touch the system… for me that’s an advantage actually. And how any router device should be.

Yet there’s still the possibility of running KVM (x86), MetaROUTER (ppc) or containers (ROS v7, arm for now) so not locked “out”, flexibility is there.

It boils down to whether you want a development environment, where LPS8 has easier entry curve, or want a pro device with pro features in networking, management and provisioning, with resiliency and stability: RouterBoard/ROS; in that case you’ll need to either learn (steeper curve), use this or Mikrotik forum, or locate a Mikrotik consultant.

Many make the mistake of going with whatever is “easier” for the developer, or “at the beggining”. Problems come after, when such infrastructure needs to be maintained, secured, revamped or quick upgrades are required due to a new exploit or alike… if physical visits are required, or cumbersome firmware upgrades are required, then all the “ease” at the beggining is moot and gone…

I am glad your experiences are positive, Keep in mind not everyone has the same requirements and expectations.

I’ve been using MikroTik hardware for well over 10 years and while their offering has many strong points it is lacking in others.

And the vendor decides what the life of the device is, not the user. What is the published MikroTik life cycle for LR8? Does it match the expected deployment time for the users?

Which also translates to ‘while having many settings not relevant for LoRaWAN gateways’. The LR8 tries to be a router and a gateway where I would prefer it focuses on being a superb gateway.

With OpenWRT out of the box I agree. However for OpenWRT I can replace/enhance the firmware with remote management that focuses on LoRaWAN management where with the MikroTik management I still have router management with LoRaWAN bolted onto it.

What would you advice for management of remotely deployed (as in not part of a network I manage or own) LR8s that are behind a firewall/NAT solution only allowing outbound connections?

[quote=“fcojmontilla, post:12, topic:54092”]
Many make the mistake of going with whatever is “easier” for the developer, or “at the beggining”. [/quote]

Many might but I have multiple gateways deployed at remote locations for over 5 years and trust me, I know about challenges of (remote) management. And up till now I haven’t found a solution that beats balena.io and a configuration server for the LoRaWAN parameters (which doesn’t work for either LPS8 nor LR8)

1 Like

Sorry, maybe I shall have stated since the beggining not a “regular user” I am a Mikrotik Official Consultant & Certified Trainer.

These are my views though, I don’t represent Mikrotik.

Couldn’t agree more though, not everyone have the same requirements and expectations, and I may lean too much to the consulting experience side.

Sorry, don’t understand your point. Mikrotik focus on disruptive market, never had a problem of programmed obsolescence if that’s your concern? Have 15+ old equipment that still works…

If you refer to market shortage, or the time it takes since a product “launch” until it reaches the market, yes it has happened, and also there’s plenty of broken stock nowadays.

And yes sometimes is hard to source just launched and “hot” products, but don’t think this is Mikrotik specific?

Totally opposite views here I must admit… LoRa is just another interface of a router… and we are talking about gateways… in my eyes this is actually a big plus, as allows to e.g. deploy LoRA easily on already deployed WISP towers… where almost none would allow a home router (let a lone a Pi) to be deployed…

Also wAP LR8 is just one LoRA product amongst dozen or so in Mikrotik LoRA range, nothing prevents you from fitting a LR-2/8/9 card on any suitable routerboard…

As you said, not everyone has the same requirements and expectations… I am sure that beats the “logical” provisioning part of LoRaWAN, TTN? which certainly is terrible, but I was referring to an unconfigured device, with no IPs… which yes, (layer 2 remote access) is possible with Mikrotik.

Didn’t know Balena were into LoRA… thanks for the link!

I think we both have our views (logically) leaning towards our fields of expertise; mine on the physical and networking part (L2-L3) and yours to the upper layers…

Nothing prevents you from using RouterOS API, or internal scripting, flashfig, etc to customize your provisioning…

Regarding custom firmwares, been there… burden and responsibility for maintenance being good or not, I bet depends on the business, I prefer to leave that to a specialized company and focus on other areas…

A tunnel concentrator that you can control… For outgoing tunnels SSTP giving the less fuss and tampering by telcos (Mikrotik’s rewrote their own SSTP implementation). WG interesting too…

1 Like

I suspect neither of those although the second is good to know.

It’s “how long can I buy these for” sort of question - rather than writing up extensive documentation for a deployment and then finding the product is discontinued two years in to a four year project.

As for the bells & whistles, I still have an LR8 on the shelf after @Jeff-UK, one of the our gateway masters, the other being @Kersing) reported having a bun fight with the UI. Gateways should have an appliance mode so you can enter the gateway server address and get on with the next job. Apple became the biggest company in the world by selling a computer with one mouse button …

1 Like

Go on Nick, dust it off, get it registered and online and go deploy somewhere/expand the network…you know you want to really! (If I can muddle through and succeed I’m sure you certainly can too…probably you would find it easier, failing that will swap you for a TTIG/LPS8 when I finally get North again as would like to try and fettle one again…).

1 Like

Nick, hang onto yours as they’re rare as hens teeth. None of my suppliers have stock or know when they’ll receive new stock.

1 Like

I didn’t think IS-IS had been implemented in RouterOS.

I wonder what level packet forwarder software would be - definitely Network layer - but as the software talks directly to the hardware, I guess Data Link layer as well.

Completely share that… but that may happen with either brand?

Routerboards are fully programmable, same “programming” is interchangeable (hardware interfaces allowing) between any of them.

So if you e.g. write custom scripts used internally, or assemble custom provisioning, as long as there’s a LoRA interface in the routerboard, it doesn’t matter which exact “board” you use, you’re not tied to specific model of hardware.

If we focus on wAP physical “form factor” of course I cannot know, but looking at the amount of products based on it I don’t think is gonna be phased out any time soon, maybe new hardware added, but hardware form factor will possibly remain.

Again, I agree, Mikrotik curve is rather steep at the beggining, and UI feels awkward, I thought exactly the same. But once I got trained, I understood why network engineers love WinBox and why Mikrotik designed it this way, it’s great for network admins.

Mikrotik Philosophy though is to “give the cane” providing ROS, and assorted tools (dude, netinstall, flashfig, etc) and let proffessionals to build their whole system, rather than provide a “canned” one.

With the dude + tunnel concentrator where gateways connect, you can build a dashboard to have everything easily and centrally managed… But yes you need to build it.

Anything I can be of help with the LR8 just let me know… will do my best to “streamline” and pave the way to make it less steep at the beggining.

That’s a really carp argument - if other brands said they were going to jump off a cliff, would Mikrotik?

So the brand that publishes such information wins - and the brands that choose to leave us in the dark get a lower score.

We just want a LoRaWAN gateway (well, actually I also want a closed WiFi network as I don’t just do LoRaWAN) - so the Mikrotek UI tends to rule itself out.

Perhaps there could be some serious sales for them & you if you build us a canned version that we can deploy - and when we need a bell or a whistle, we commission you to sort it out for us.

Would be interested in the answer to this if anyone knows or cares to comment.

And that is the probem in the context of this discussion on this forum - >>95% of forumites and TTN users are not network engineers (though may be familiar with smply plugging in and setting up their ISP supplied DSL router/Wi-Fi AP) and certainly not network admins - they just want an easy to deploy easy to use simple gui or precooked git install of a LoRaWAN GW…not all the bells & whistles. Most of the users are hobbyists,/hackers, teachers, students, concerned community users (will my river or culvert flood?, is my air polluted, where is grandma? or has she turned the kettle on this morning?, where is my bicycle!), farmers, bee-keepers & apiarists, viticulturists, arduino hackers, and even :scream: sales, marketing & biz dev types! …few network admins :wink:

@fcojmontilla Thanks for effectively voluteering yourself as now the go to person on the Forum for Mikrotik related issues :wink: :rofl:

1 Like

Indeed, the majority of IoT developers aren’t network engineers - the device is being created by the hardware engineer & the firmware developer and the backend is being developed by a web or desktop developer. They just want data to flow, not mess with BGP, DHCP, UDP or any other elements of the alphabet soup.

In some respects, having to involve someone at a network engineer level to get a gateway installed is an actual barrier to roll out. If I give a gateway to someone in corporate IT, say it uses DHCP and just needs to be able to communicate OUT via UDP, all good. If I give them a manual to install it, it disappears for months.

2 Likes