We will be launching a new product at The Things Conference. Our mission with this project is to set a new standard for the next generation of LoRa products. We tried to do a version before but that did not make it in to market.
Honestly why do you insist in competing against your community of hardware developers and small but creative manufacturers rather than provide the methods and tools to lift everyone’s work on TTN and TTI?
That’s what community means, not having us sit around admiring your latest wdget - that’s what cults do.
The reason we do this is because we want to share open code and innovation on how we think a LoRaWAN device should work. If this competes with the hardware making community we are doing something wrong. We tested our approach with a large amount of device makers and vendors in the ecosystem to make sure we don’t compete but that we enable.
To summarize the stakeholders in our community and how we think we contribute:
LoRaWAN device makers - the open code approach will allow anybody to create a version of the Generic Node. We will launch the most simple version with a few sensors. We already have stealth community members that will create more rugged version for instance.
Embedded developers - we are investing a lot in open source development tools for this product. To make it easier for developers to create applications that can be pushed on the vanilla version of this product. On the roadmap we have a feature that allows the firmware to be pushed over the air. So this means we can have one SKU in the supply chain while a fragmented market is supported.
IoT application builders - this product will make it easier for the end to end application builders maintain their sensor networks.
Makers/DYI - the standard product is also a development board. With a QWIC connector for external sensors. This means you could compare it a bit to a Raspberry Pi for LoRaWAN.
Love to continue the discussion on competition and cooperation. Love to hear where anybody thinks we are unfairly competing.
Is it possible to have LoRaWAN certification in place for this generic device as well? One of the hurdles for small device makers is the combination of Lora alliance membership and certification cost. Certification adds a large cost component to small batches of nodes (25-50 nodes using a specific sensor).
Certification and lowering so called NRE (non-recurring engineering) costs is on of the objectives of this effort. So LoRa certification is part of that. But there is a lot you have to do once you change a reference design that can get your NRE up very fast. e.g.:
Re-tuning on of the antenna - here we are partnering with Fractus Antennas. This gives you more certainty around the antenna optimization process.
Certification in general - we are currently boarding certification partners that will have experience with this reference design. So you will probably reduce on the amount of roundtrips with them.
Hello, great response with clarity in the stakeholders and design intentions. It all sounds quite positive.
Mentioning Raspberry Pi makes me wonder if Linux is involved, or could possibly be involved. The M4 and M0 have considerable history but is not typically associated with Linux.
What is the possibility for an OS, like Linux with ssh and bash command line interface? It could interface with the RF chip that handles detailed LoRaWAN communications.
Good catch.
Technically it can go down to 2.2V (hard cut-off), but to account for some low-quality batteries with higher internal resistance, 2.5V (soft cut-off) is preferred. This value will be SW configurable.
@cslorabox, low power is important but each application drives requirements. I’ve had a Raspberry Pi running on solar power for more than 3 years straight.
If Linux is not involved then comparison to Raspberry Pi is unclear. Rpi has no QWIC connector and comparison to ESP32 or Arduino MKR series seems more appropriate.
A Raspberry Pi hat or combo-board like Arduino Yun seems to make the most sense for this device.
No. In only a tiny, tiny, tiny minority of cases would running Linux on a node be warranted. Your personal experiences may be in unusual contexts, but the overwhelming majority of TTN nodes use truly minuscule amounts of power orders of magnitude below the demands of anything capable of running Linux.
And in the cases where someone does have power to burn, it’s easy to put the MCU-based node in wired communication with a larger system (though you’re probably better off choosing a node with a USB port). Such delegation of the LoRaWAN stack to an MCU is highly preferable anyway, as getting the tight timing right under a multi-tasking OS is tricky - it can be done, or actually, with enough power to run Linux you could just go into receive shortly after transmitting and stay there, switching to RX2 settings halfway through the RX1 if there’s been no pre-amble. The power cost of the radio would be scarcely noticed alongside the cost of the processor.
But the goal here is clearly to make a sensible node for general usage, and such simply cannot accommodate Linux. You’re welcome to design a Linux-based node, but that is not what this project is or should be about at all.
I make things like this as well and I’m thankful for the open sharing. It takes some courage to share many many hours of work. This kind of open system fosters innovation and development for the whole community. I’ve used some of your design/manufacturing concepts so just: Thanks.
