Hello, can I ask when it will be operational on the community network?
2 Likes
I want to test the v3 stack with a node running LoRaWAN 1.0.2.
Is there a TTN v3 test server somewhere in the public internet, which i could use for the test?
you tell me… I have the same probs 
Hmm, i’m sure someone out there already did a docker install in some cloud. Please, let us share…
1 Like
It is a great contribution of TTN to open source the V3 stack. But you guys have put in a lot of hard work. When you make the source code open source, then many people will establish their own private server in the gateways and will no longer want to use the services of TTI or TTN despite having good internet connection. Will this not cut the revenues of TTI as you are giving all your hard work to community for free?
We need to build a few things for that, most importantly peering (so that all gateways are available in V2 and V3 at the same time) and a V2 compatibility layer around the V3 Identity Server so that V2 services keep working. Then, we start deploying V3 PCN clusters to which you can migrate your applications.
Currently, our first priorities are getting a 3.0.0 tagged release out, fix development tooling and finish the Console.
I think V3 PCN clusters become available in preview in May.
No, you need to set that up yourself for the time being. We’re gonna do that, but we’re only going to do that right, i.e. with peering and the same user accounts, for a smooth experience.
Thanks for raising this.
We believe that there is no commercial value in a proprietary LoRaWAN stack. It is a solved problem. There are other open source LoRaWAN initiatives too. Note that all successful development tools (web servers, databases, frameworks, compilers, IDEs, etc) are open source. Offering a proprietary LoRaWAN server stack is either creating vendor lock-in for no apparent reason, or hiding a mess of a codebase.
When building an open, crowd sourced and decentralized network, we want to do that in a transparent way, i.e. doing it open source. Our stacks have been open source from day 0.
As for the community setting up their own networks; I rather have them use The Things Network Stack V3 for that than another stack. This is because V3 is built for the future, scalable, and it will support peering with the public community network, so that still it becomes part of the global network. Also, should these private networks one day be migrated to the public community network or to a commercial private network, then no APIs are changed and devices can be migrated seamlessly.
As for our commercial initiative setting up own open source networks; for the context, The Things Industries provides services and proprietary functionality for enterprise use. TTI offers SLA, commercial support, some advanced monitoring and alerting features, a scalable Kubernetes self hosted or private cloud hosted deployment, multi-tenancy, advanced integrations with commercial cloud platforms, an on-premises Join Server with HSM support, etc, then that is where value is added. And here again, if businesses start using the open source distribution but want commercial services later, we can do that seamlessly. Finally, our larger customers are happy that our stack is open source, because it is a more sustainable model (anyone can become a maintainer by forking) and it allows for easy quality assurance and auditing.
13 Likes
Hi,
We have already implemented Class A and Class C on STM32L072RZ Nucleo board and have verified its functionality on TTN.
We have successfully connected on TTN server with both Class A and C but not sure how to verify Class A or C on the server end (TTN).
Is there any way we can confirm whether data is from Class A or Class C.
Please guide.
Hi,
I am using the build-in MQTT broker for class A up-link and down-link message test. The LoRaWan stack version is V3.0.0-RC2.
I can successfully get the up-link message from the node device. But for the down-link message, I think it doesn’t work.
From the host PC, I open two terminals. One receives message with mosquitto_sub, and the other send out the message with mosquitto_pub. I use the following command to send out the message:
mosquitto_pub -u app1 -P NNSXS.UCV7QADOLDV5YAEPRVE6HBX3AFK22CVBWYAMKBQ.KNM665HUYJK7D3ZLRXORDXUGRIYQGOSQ6WHZQSF24RQAGSDSUOKA -h localhost -t "v3/app1/devices/dev1/down/push" -m '{"downlinks": [{"f_port": 15,"frm_payload": "QkJCQg==", "confirm": true}]}'
I think that I should receive this message in terminal one because I subscribe the topic “#”. Also I should get the ack message also. But I can get nothing output. While the uplink message works well.
Does anyone know what’s the wrong with it?
Again, the question: Has someone here a TTN v3 server running and open for public?
- is there a hosting provider willing to rent some TTN V3 pre installed servers for a short period ?
- what is the minimum / preferred hardware (cpu/mem/ect) to setup a V3 server ?
1 Like
Why not asking https://www.scaleway.com ? They offer hostings in Amsterdam and Paris. Regional food, tastes better!
We would like to build a local community network, which is probably funded by the state.
The network is to be built on the basis of the V3 stack, but operated on its own hardware. The network should be open to anyone and enable peering with the TTN.
Will this be possible and will there be licensing costs or costs for peering?
What other conditions are necessary to implement such a project?
For this we have some questions:
• How does peering work in the V3?
• Is peering already installed?
• Will the peering be charged?Hi,
Is there, or will there be, a docker image of ‘thethingsnetwork/lorawan-stack’ for arm?
I have followed getting started with V3 docs, using Raspberry PI but
docker-compose --verbose run --rm stack is-db init
fails with
standard_init_linux.go:207: exec user process caused “exec format error”
Verbose logging reveals cockroach and redis start fine and it is the lorawan-stack stack image that is not arm64.
eg:
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- (‘thethingsnetwork/lorawan-stack’)
urllib3.connectionpool._make_request: http://localhost:None “GET /v1.30/images/thethingsnetwork/lorawan-stack/json HTTP/1.1” 200 None
compose.cli.verbose_proxy.proxy_callable: docker inspect_image -> {u’Architecture’: u’amd64’,
Any advice would be appreciated.
Thanks
At the moment we don’t have a Docker image for Arm. It’s mostly because our build pipeline doesn’t support manifests at the moment.
We do, however, release binaries for various Arm platforms, see the assets under, for example, https://github.com/TheThingsNetwork/lorawan-stack/releases/tag/v3.0.2
You can easily turn this into a background process with systemd, see here: https://www.raspberrypi.org/documentation/linux/usage/systemd.md
LoRaWAN Deployment Models
As we get close to the production release of the V3 stack, it is important to understand the different deployment options and pros and cons of each one. This flexibility to choose between different models is one of the key features of the V3 stack.
is class c usable yet?