Interesting & useful - but not answering the question - what other readily available open source gateways are there that have flash rather than an SD card?
On the contrary it very much did.
The RAK boxes are readily available.
There is source that works on them.
They are NOR flash not SD card based; the SD card is for optional runtime data.
The catch is that the manufacturer doesn’t tell people that there’s a source repo that works on them…
We’d already covered Dragino & RAK, so it doesn’t answer the askers question.
What other readily available open source flash based gateways are there other than RAK or Dragino?
I recommend the Ursalink UG85 industrial gateway, it works very well with TTN and other LNS, and it has dual simcards for 4G.
What can you tell us about the embedded computer in this, ie, what is the SoC and what sort of flash media is used?
Is the mobile data modem soldered down, or a sub-module which could be changed out for another? What is the default modem?
Are software sources available? If so, where?
Kerlink offers iFemtoCell that has opkg based system, provides toolchain, and an open firmware (though the firmware itself isn’t open sourced).
This may or may not be an interesting alternative for OP.
It is simple to use, though not turnkey as you are free to use any packet forwarder thus none is preinstalled. Fully compatible with TTN and easy to use (a couple of configuration files to edit in order to register TTN’s server and frequency plan).
Disclaimer: I work for Kerlink.
I realise that I’v sort of hijacked this thread by a segue in to open source gateways, but I realise I’d totally forgotten to mention the two gateways I got from https://m2m-tele.com that are Orange Pi 2 with their own board which work just fine. M2M Tele aren’t showing product at the moment but may be worth keeping an eye on.
What’s used for the filesystem storage on those?
We built a few pi-style gateways where we used the OrangePi PC Plus as it has eMMC. Had to heatsink the processor and had some stability issues which got drastically better when we underclocked (being a gateways is easy).
One the one hand, being able to ssh in and compile code was really nice while iterating on customizations, on another it’s a big complex system with more parts to break. Another issue with budget embedded computers is that the design one likes can go end-of-life and the replacement may not be as suitable; still after an initial learning curve of things that can go wrong and solutions (like wiring up a GPIO to control the USB port power to the LTE modem so we can cycle it) they’ve pretty much just run for 18 months now.
Incidentally, one really nasty way for an embedded Linux to get “stuck” is to decide it should reboot, and then for some reason, not be able to because something in the shutdown hangs, and it just sits there until someone gets at it physically - seen it happen on multiple embedded boards with both ARM and x86 CPU’s. That made figuring out how to use the watchdog timer worthwhile - our management daemon will command a reboot, but when it does so it also stops feeding the watchdog, so one way or the other it actually happens.
1 Like
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
1 Like
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?
1 Like
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.
2 Likes
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…
2 Likes
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.
1 Like
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.
2 Likes