Generic Node Stealth Community

End Devices (Nodes) Generic Node
#1

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.

GNSE_v1.1_pinout

Specification

  • STM32WL55CCU6 dual-core Arm Cortex®-M4/M0+ @48 MHz
  • 256 Kbytes of Flash & 64 Kbytes of SRAM
  • SX126x sub-GHz radio
  • Power output up to +22.00 dBm
  • LoRa, (G)FSK, (G)MSK, BPSK modulations
  • 868 MHz & 915 MHz dual-band operation
  • 2xAA battery powered node with wide input voltage range: 2.2V - 5.5V
  • ATECC608A-TNGLORA pre-provisioned LoRaWAN secure element
  • LIS2DH12 - ULP 3-axis accelerometer
  • SHTC3 humidity and temperature sensor
  • MX25R1635 16Mb SPI NOR Flash for FUOTA and data-logging
  • A user button, an RGB LED, a buzzer and a user-friendly expansion and programming options.

generic_node_se_stacked

Please sign up here if you like to be part of the initial stealth community: Generic Node Subscription (copy 01)

For information about Generic Node see: Generic Node

10 Likes
#2

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.

1 Like
#3

Good point.

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.

6 Likes
#4

Hi @wienkegiezeman,

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).

1 Like
#5

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.
6 Likes
#6

Hi

Nice to see a Qwiic connector. How does one program the board?

Alain

#7

SWD signals are shown on the headers. Something else might also be supported, but SWD is key for full leveraging the chip capabilities.

#8

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.

#9

No, and such make no sense on a node, which would be designed for low battery power

#10

In the pinout diagram the PCB silkscreen left of the battery connector says 2.5 - 5.5V

Which one is correct?

1 Like
#12

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.

4 Likes
#13

@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.

#14

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.

#15

The links to the hardware does not seem to work…

https://thethingsindustries.github.io/hardware ( found on Home | Generic Node )

#16

The GenericNode Documentation repository can be found here:
https://github.com/TheThingsIndustries/generic-node-docs

Please create a new issue in the repository to get issues with the documentation addressed.

Also see the following topic: Generic Node

#17

Does TTI have an idea when this may be available and an idea of pricing?

#18

I expect they have. Let’s hope they will share it soon.
But this topic is for recruting stealth community members, not for public announcements.

For questions about Generic Node please use the Generic Node topic.

#19

Why do this say it has an SX126x sub-GHz radio when the STmicro MCU already has one on it? Also I don’t see an SX126x anywhere in the schematic.

#20

I think you answered your own question on both points :slight_smile:

1 Like