Having looked under the concentrator, turns out it’s an Orange Pi Zero, so 2Mb of SPI flash with a snapshot build of OpenWRT. Not sure where the overlay for persistence is, as I’m sure you’ve guessed, OpenWRT isn’t in my toolbox.
Good news is they provide full instructions for a rebuild as well as using Armbian on their blog.
Wow, that’s interesting! And really tiny for OpenWRT, too.
I’d actually gone to quite a bit of trouble to get the OrangePi PC plus Booting U-Boot off an added SPI flash (while also having a chip select for the concentrator) with the idea that if it found the image on eMMC bad it could then either boot a fallback SD or USB volume, or maybe copy out a repair image or something… but never got as far as picking a small Linux to try to fit in.
Also ended up having to fix uboot as at some point a box rebooted, and then picked up enough noise on the serial line that U-boot went into command mode and eternally sat there 
(now it has a timeout)
That is indeed good. My gut sense is that Armbian (what we used on ours) would be too big for a NOR flash so probably puts one into SD or USB territory.
But things like having the compiler local, a real editor, etc are great for experiments. The OpenWRT version of our managements scripts inherit heavily from things worked out the first time on the Armbian boxes.
The Zero has an SD Card slot which is for Armbian and upgrade use and other things - I’ve not explored the details as the damn things just work and when I want to kill a gateway with silly ideas, I’ve got the Pi’s to do that on.
I’m using the MikroTip LtAP. Its got LTE, WiFi, ethernet and a mPCI slot for a MikroTik LorRa card.
My cost in New Zealand for the lot (LtAP, LoRa card, External antenna) was just under $600 NZD ($395 USD).
I’m running it off a 50W solar panel, 10A MPPT controller and a 12V71Ah battery
That sounds interesting, but seems like a lot of key details missing on the vendor’s pages.
It says mPCIe, without giving an SPI pinout (there is no standard for SPI on an mCPIe connector, it is a custom extension), which kind of implies a deprecated USB-SPI Bridge (the system block diagram seems to show only USB to the mPCIe slots as well)
But it says it has LBT, which contrastingly points to something current either SPI or MCU-based pico-GW
But then it links to the everyday SPI-only non-pico-GW Semtech repo.
So is it SPI with an undocumented pinout? Or USB? Or what?
FWIW the above mentioned block diagram shows an MT7621 somewhat related to the MT7628 RAK uses.
But it seems it runs “router OS” where “RouterOS is MikroTik’s stand-alone operating system based on linux v3.3.5 kernel” And they somehow claim the right to make you pay for a license…
Why, oh why, can’t hardware companies just make hardware and document the essential facts of it?
RouterOS license is included in the price. RouterOS only supports the MikroTik mPCI cards and the legacy forwarder.
It uses USB over mPCI, don’t know more than that sorry.
Hi @cslorabox, you ask…
Speaking for myself, I deploy automation for paying customers for the data and the difference that can make to their businesses. As a systems integrator, I need to buy sensors, infrastructure and core services that work and are reliable and can be deployed and maintained by technicians. I simply don’t care about the philosophy of “open this” or “closed that”. I don’t care if it uses LoRaWAN, NB-IoT, WiFi, or wet string to move the data. I care about the data and the money.
I suspect that I represent the majority of paying customers and that hardware companies like Kerlink target their products at people like me and simply don’t care about the maker/hacker/learner communities.
May-be and may-be not, but in the LoRaWAN solution space we have choice. There are companies that provide (open) source for those that want more control and companies that provide turnkey solutions.
There are a lot of technologies where one size has to fit all and you either take whatever is on offer or you leave it.
So may-be we should be glad there is something that fits for (almost) all of us out there…
That’s exactly what I do as well, which is why they need solutions where we can fix all of the software.
It’s a fundamental fact that when an organization has or contracts technical capability, then during the lifecycle of an effort, the problems will eventually become entirely concentrated in the closed portions of the system.
Why? Because the problems in the portions that aren’t closed get fixed.
Only those which are unfixable as a result of the decision some vendors make to lock things down end up still there annoying my customers and costing them unnecessary downtime on an ongoing basis.
Indeed, we do
The smarter ones provide both… because there is actually no conflict between having a factory system that works well enough for most out of the box, and not taking silly measures to prevent customers who find issues with it or need to change the capabilities do so.
And given that just about everyone is using an operating system that already requires sources for key parts to be released, and just about everyone’s hardware will run with Semtech’s LoRa code off github, it’s not even any extra work.
They just have to not go out of their way to make it artificially difficult.
Hi @cslorabox, thanks - interesting post.
I suspect that you have something like a “right to repair” view.
I have spent 35+ years (I’m semi-retired now) working on critical systems for offshore Oil & Gas which has a “must not modify” approach policed by organisations like Lloyd’s Register and DNV. The only modifications allowed are those from the supplier done via full Engineering Change Management (ECM). O&G companies, of course, only purchase critical systems from suppliers who will put the appropriate service levels behind their products.
As @kersing rightly says, one of the strengths of LoRaWAN is that we have choices. Suppliers also, of course, are free to choose how they offer products into the marketplace and we are free to choose how we spend our money.
“must not modify” has its place in certain highly regulated settings, but is about assigning responsibility, not about getting things to work.
It is also how you get gear with known quirks which the people in the field build a culture of working around… eg soldiers told they have to power cycle a system every 8 hours, because after that a software bug leads to growing imprecision.
Returning to the realm of a LoRaWAN network, the “interesting” stuff which really governs behavior is in the nodes and the network server. All the gateway really needs to do is pass things back and forth, keep doing that, report to its owners about its ability to keep doing that, let them remotely deploy updates into it, etc. There’s no real business value in a gateway, only liability when it fails to do its simple job.
We get downtime from novel problems, but then we figure out what happened and fix things so it can’t again, or at worst add instrumentation so the next time it happens we’ll collect enough information to understand and fix the problem.
The place we continue to suffer repeating downtime incidents from the same known problems is in the systems we don’t have access to fix.
Any new developments on this topic? I’m also looking for compact LTE gateways.
Dragino warns that they are not for LoRaWan use, e.g: LG308 Indoor LoRaWAN Gateway
Will they work with TTN?
Note: Somehow I cannot seem to post new topics so I’m hijacking this one - not sure why
This thread is really very old.
You can use Dragino LG308, LIG16 or LPS8 for LoRaWAN resp. TTN.
That`s how hardware companies works.Only selling stuff…
Where does Dragino say that you can’t use the LG308 for LoRaWAN?
There are no simple reliable LoRaWAN gateways on LTE - LTE brings in a whole heap of extra backhaul excitement.
But I guess as the topic says ‘simplest’, any of the mainstream vendors are going to be OK - Dragino, RAK etc.
Or you can get a gateway on WiFi and put a MiFi next to it …
Look at MikroTik offerings. Check the announced partnering of TTI with T-Mobile during the virtual TTN conference last January. Videos should be on TTN YouTube channel.
I follow @kersing recommendation.
I am currently testing a Mikrotik LtAP LR8 kit. A very robust construction even with several SIM slots.
The MikroTik LtAP is an amazing bit of Kit and sits idle witnh a load of around 4 watts.
I’m using a 50 watt solar panel, 10Amp MPPT charger and a 71Ah12V battery which gives me (almost) 24x7 power.
A 100w panel gives me year round operation
