May I ask, can you share or confirm that you repurposed M1 according this guide? GitHub - seeed-lora/WM1302-doc I still killed 7h during weekend tried to get online GW.
there was theory that TTN is not reachable, but it is
nmap eu1.cloud.thethings.network
Starting Nmap 7.93 ( https://nmap.org ) at 2024-02-18 21:29 EET
Nmap scan report for eu1.cloud.thethings.network (63.34.215.128)
Host is up (0.053s latency).
Other addresses for eu1.cloud.thethings.network (not scanned): 52.212.223.226
rDNS record for 63.34.215.128: ec2-63-34-215-128.eu-west-1.compute.amazonaws.com
Not shown: 997 filtered tcp ports (no-response)
PORT STATE SERVICE
80/tcp open http
443/tcp open https
8888/tcp open sun-answerbook
Nmap done: 1 IP address (1 host up) scanned in 5.00 seconds
somehwre read that no need to open any ports, as all " magic" happens auto in bground.
Thanks!
from rpi terminal →
##### 2024-02-18 19:20:57 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 0
# CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 1 (125 bytes)
# PUSH_DATA acknowledged: 100.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (100.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
### SX1302 Status ###
# SX1302 counter (INST): 90726994
# SX1302 counter (PPS): 0
# BEACON queued: 0
# BEACON sent so far: 0
# BEACON rejected: 0
### [JIT] ###
src/jitqueue.c:440:jit_print_queue(): INFO: [jit] queue is empty
#--------
src/jitqueue.c:440:jit_print_queue(): INFO: [jit] queue is empty
### [GPS] ###
# Invalid time reference (age: 1708284057 sec)
# no valid GPS coordinates available yet
### Concentrator temperature: 27 C ###
##### END #####
JSON up: {"stat":{"time":"2024-02-18 19:20:57 GMT","rxnb":0,"rxok":0,"rxfw":0,"ackr":100.0,"dwnb":0,"txnb":0,"temp":26.9}}
INFO: [up] PUSH_ACK received in 51 ms
INFO: [down] PULL_ACK received in 52 ms
INFO: [down] PULL_ACK received in 54 ms
Looking at your post from ~2 days ago (console view) this one? :-
eui=00016c001ff1e21c
Note when registering in TTN Console GW ID cannot be re-used if gateway deleted, the GW EUI can/should be re-used (Devices often use the term “gateway id” or similar in their documentation/gui set up rather than “gateway eui” or wherever which can lead to confusion. In the Console GW ID is user (lower case) text to be used for convenient though at time of registration it will often suggest an option of the form “eui-aabbccddee…” e.g in this case “eui-00016c001ff1e21c”
Successfully got my Sensecap M1 to work with TTN, following the instructions above. But: you have to use an older raspy os based on debian 10 buster, not debian 11 bookworm. The reset script will not work, since directly writing to the gpio devices has been disabled. You’d have to use pinctrl instead, however I did not manage to adapt the reset script accordingly.
some time ago I took a closer look at how to get the SenseCAP M1 working with The Things Network. While doing so, I realized that by using the ChirpStack packet multiplexer, it’s possible to serve multiple LoRaWAN networks in parallel, so you don’t have to decide on just one network.
I have put together a guide on GitHub that shows how to run Helium and The Things Network simultaneously on a SenseCAP M1. Feel free to take a look and let me know what you think
You are not the first to figure this out and the technical potential…….the problem is it doesn’t solve the practical implementation and legal aspects of doing so!
Each Network LNS will be ignorant of what the other network is doing specifically wrt downlinks (Acks, ADR commands, joint accepts, and so on) and there are then two issues - the downlinks may clash potentially voiding efforts and more particularly as a Tx device the gw has its own duty cycle limits to consider in many parts of the world and especially in busy areas the summed commands of two or more networks may cause the gw to breach the legal limits in that jurisdiction .
If you wish to try on your own private networks that’s at your risk, however, please do not attempt this on TTN as you may cause issues for other users….especially the owners of community gw’s.
Hi Jeff,
thanks for your feedback . It seems there may be a misunderstanding regarding how the packet multiplexer operates.
From a technical perspective it does not change the RF behavior of the Gateway, which remains fully compliant with regulatory duty-cycle limits. The multiplexer only duplicates the UDP packets, which are already being sent to the backend and does not generate additional RF traffic. In addition downlink traffic is minimal and negligible even in a big city.
In my setup, I have tested it with multiple clients on both networks and it has not caused any issues.
If there are concrete technical references or real world evidence supporting your concerns, I would be very interested to look into them. The scenarios you describe seem for me largely theoretical. Even on the physical layer, UDP packets can be lost due to WiFi or RF interference, Ethernet and hardware issues
The gateway does not keep track of regulatory duty-cycles, the LNS does. So with two LNSes in control of your gateway you risk not being compliant. As well as having to transmit two downlinks at the same time. Specifically with Helium where the gateway also transmits to provide proof of coverage.
Another potential issue is the frequency plan used by the different networks. If not 100% the same you will be missing uplinks for one of the networks because your gateway can only listen on a limited number of frequencies.
BTW, connecting a gateway to multiple networks has been possible for 10 years and has been discussed numerous times on the forum. The official TTN point of view is that a gateway may only connect to a single LoRaWAN network server.
My point entirely - it does nothing to assist in the management of the gateway (as re-enforced by Jac), the ensuring correct handling of none overlapping messages, the minimisation and practical distribution across viable GW’s of downlinks (if the LNS ‘knows’ a given GW may be in breach of D.C. it can elect to use another close (signal condition wise) proximity GW as alternate path) and network management signals to mitigate/minimise conflicting messages - basically GW queue management; because the 2 (or more) networks have no idea what the other is doing. This is an acute problem where gws and the LNS work together to implement any kind of JIT queue. Basically all the points previously highlighted by both Jac and me.
No misunderstanding about the mux operation - as highlighted this has been a ‘thing’ for a long time and is well understood (potentially not just for UDP - legacy SMTC style PF - traffic for any other TCP/IP or related network traffic between GW & LNS). It’s a lack of understanding of what the practical and potential legal consequences are of attempting to insert one into a LoRaWAN system architecture. Where there may be a role, depending on application, is where the alternate LNS connection is treated entirely as uplink only - possibly for back up data capture, but without ANY form of associated downlink(s) - so e.g. no ability for an end node to ‘join’ the alternate network. Device/Network and associated credentials & keys, channel plans etc., would need to be shared between the networks via an alternate backchannel. No ADR control etc. OTAA hard, ABP may be slightly easier….!
Just because you havent seen the problem in your tests does not mean problems dont/wont happen or that you havent caused problems for other community users (how would you know?!) and given the scale & scope of TTN around the world (not to say some of the other networks you mention) hence the position outlined - not on TTN.
I would like to step out of this discussion at this point. In my own setup, I have not observed any of the issues described and I consider a regulatory duty-cycle violation to be highly unlikely in practice. My goal was simply to contribute something positive and share my experience, with the goal of helping The Things Network gain more coverage and gateways, especially as it currently feels less active compared to other networks.
I came into this with good intentions and wanted to have a technical discussion. I am not claiming to have invented anything new. From my perspective, however, I still do not see practical downsides in my setup, nor have I seen any negative effects during longtime testing.
It’s unfortunate that this discussion feels more confrontational than technical. That was never my goal. For anyone interested, the guide can also simply be used to understand or configure a packet forwarder correctly for TTN-only use.
Given the different viewpoints, I will leave it at that and step back from the topic. I would only like to add that many users in this forum experiment, tinker, and share custom configurations. It would be good to keep discussions technical and respectful. Being labeled as acting irresponsibly or illegally for sharing a setup in good faith, when nothing wrong was done does not feel fair.
There wasn’t anything confrontational in the responses of two people who were in at the start of TTN, one doing LoRa before LoRaWAN was invented. You got the very best technical feedback you could possibly imagine. If you don’t like the technical info provided, ask yourself if that’s not an emotional reaction to being told your idea isn’t such a good one, rather than moving forward, reviewing the information, do more research and form a counter argument based on more technical info.
The forum may be quiet, but TTN is processing packets at the rate of 1,300 messages per second, which after rejecting packets that aren’t for the network and deduplication, results in 270 msg/s being passed on.
We get TTN for free so its good to minimise the server workload, something your solution could potential increase but not something you can see. And if everyone took up the idea, it can get really messy really quickly.
It’s hard to characterise the issue of breaching radio limits - it’s the gateway that could be doing it but it’s the responsibility of its owner to ensure it doesn’t. No one accused you of being a serious criminal, think more setting yourself up for going 5km/h over the speed limit.
Given two world class subject matter experts have told you what they think, if your gateway does attract some interest from the local authorities, Google will highlight any defence you make rather moot.
.
. It seems there may be a misunderstanding regarding how the packet multiplexer operates.