I use TTN I guess … 
I use HTTP integration from TTN, is there anything wrong if I want to share my access?
Thanks
Okay, the HTTP Integration is not running on your gateway, and is not limited to just a single gateway. Instead, it’s assigned to an application, which will receive data from all TTN gateways that happen to receive your device’s transmissions.
You’re all set then. Any TTN-registered device that is close to your gateway will have its transmissions forwarded to their application.
1 Like
yes you right, I use the TTN http integration (not on my gateway). But if someone external is say passing by my gateway (so not registered), can he take advantage of my gateway to transmit his data back to his end server/database?
1 Like
Yes 100%. I have roamed between hundreds of Gateways in the UK with my GPS nodes for mapping.
OK cheers! So say I have my current sensor already successfully transmitting on my gateway, I travel by other gateways (set as public by other makers) and I shall receive my data also? (I guess I have to make sure to allow public network mode on my sensor)
1 Like
There is no such thing. When you’re using TTN’s community network then your gateway is “public” by definition.
Note that contact details and location might be hidden by an owner, but even then the gateway will just forward all LoRa packets it receives to the network it’s connected to, in this case TTN. TTN will ignore messages sent by devices from other networks, but all devices properly registered with TTN will see their data end up in their application, when received by a gateway that is registered with TTN.
1 Like
OK thanks! I will try this out thanks so much. Indeed what is odd to me is the fact that the device must send a JOIN command prior sending data. With weak coverage, I guess the sensor must detect when it is not any more JOINED to a gateway (especially when moving like a tracker on a car) and send another JOIN command prior sending new data.
No. A join just registers a device with the network, not with a specific gateway. Once joined, it just transmits, regardless if it’s still close to the gateway(s) that were involved in registering with the network, and regardless if those gateway(s) are still operational. It might not even notice that transmissions are not received; it just transmits and hopes that one or more gateways will forward its data to TTN.
Using things like ADR or confirmed uplinks might make it detect that too many transmissions have not been received. But even when that happens, it does not need to join again. Instead, the LoRaWAN stack on the device would then (eventually) lower its SF or increase its transmission power.
See https://www.thethingsnetwork.org/docs/lorawan/ and https://www.thethingsnetwork.org/forum/t/how-often-should-a-node-do-an-otaa-join-and-is-otaa-better-than-abp/11192
2 Likes
Thanks a lot Arjan
I assume that here on TTN you registered your gateway and can open your gateway page here on TTN?
Your gateway is a pass-through towards TTN servers and transparently transmit the data to and from he TTN servers.
Any access from these 3rd party nodes either have a TTN account set up to retrieve/redirect the data on their TTN account towards a cloud where they can sell services and provide apps to get that data without users to have to login TTN.
Only the node communicates to your gateway, but node users should not directly use your gateway IP address. They should use the TTN servers instead.
When you have set up the gateway on your TTN console page, you can also set up applications.
Those applications can then get devices connected to it.
When you register new devices in your new application you will get be able to register ABP or OTAA.
Both ABP and OTAA setup contains special unique keys that every node must be programed for so the TTN servers can redirect your specific node to the specific application.
With ABP you only get data sent from the TTN gateway to your application if the increment counter increase. If you do a firmware update, or when you powered off the node that transmit counter gets set to 0 but the TTN gateway will not redirect the data until it reached the last known counter value.
OTAA has the possibility to register your node automatically after the power went down and you start up the node again. You still need a special key so the TTN servers can match your node to your application. These keys are found when you register your node.
When you set up your gateway, you can also create some code on a server or PC that has a callback registered to TTN servers gets notified that there is new gateway messages, or application messages. So nothing gets stored on TTN, you are responsible to catch that data and store it.
OR you can set up in your application “integrations” that either stores data on this TTN server for 7 days, or redirects it to your cloud severs automatically. In that case you only have to get your data from your e.g. AWS database.
1 Like
Just a quick clarification on following to write:
Is This is a gateway not TTN network server issue. Thus this will true to any 3rd party gateway not just TTN gateway. My understanding was intelligence us build in Lora end node stack and network server. Gateway is just a plain pass-through switch.
Thx
This is not a gateway issue, it is not a TTN issue either. It is a LoRaWAN security feature to prevent replay attacks. Anyone considering it to be an issue should invest a bit more time to study the LoRaWAN specifications.
Understood - thx for clarification, you write up was confusing. I have read the spec and understand.
Hi All, thanks for sharing and your time replying. I have played more last week end, now I can register my 2 end devices, played a bit with everything. Indeed the issues were a bad provisioning and most important a couple of bugs that I had to clean up (DEVEUI cannot be updated real time on STM32 LORA Stack v1.3.1 apparently) so that I can finally succeed in registering my 2 devices (which I assume can get connected now through any LORA public gateway). My question was certainly odd for most of you guys and I assume it is a MUST that anyone can beneficiate from the comunities’gateways (otherwise what is the point to develop such a nbIOT network…). I was asking that because I could not be successful at all so far… To recall my story, I started about a year ago to develop a connnected device, and I went into a dual stack LORA and another one (I guess it is not difficult to guess the other one 
). At that stage I could easily get things done for the 2nd network as everything went smoothly after a preliminary registration: all setup with some HTTP post sent directly to a mariaDB running an raspberry pi & all under control without the need of subscribing any other external database services. But when I came into Lora, I ordered a Dragino gateway that I could not turn running OK with my devices (I could not see even a single Join attempt). I decided then to order a 2nd dragino as I assumed the 1st one to be somehow malfunctioning, but same happened. After so many nights and days spent on that, I finally gave up and I left it there. As a HW/FW developper I could not spend more time on that as many other things were in the pipe, & we know a week full time is easily spent on that kind of setup indeed. Although I believe I have the knowledge to get into details and sort out code both on embedded MCUs and PCs, i gave up…
Recently I purchased a RAK gateway, got it setup quickly, installed the missing desktop/VNC/etc on the raspbian OS… and it was all working good within a few hours (well I could see my LORA join command nicely received and I was very very happy!). I understand things can get wrong by so many means, a simple bug/a bad provisioning/the single channel frequency of the dragino setup out of band and then we are in a dead end…From ecosystem point of view, I reported a year ago few bugs to ST, and I can see the new STACK is more mature now. But my point is that these tiny little bugs here and there may render the solution quite difficult to setup especially for a non developper guys. I really like the LORA open architecture which is really a plus! I wish tools to get mature (we are there or nearly there no worries!). My message is more for the newcomers, I just want to say never give up and things are getting easier with tools that are nicely supported online by you guys! So thanks so much everybody, I wish LORA to get the success that it deserves!!! (I may say ‘she deserves’ as LORA sounds girly 
) Cheers! Flo
1 Like
Is this also the same in The Things Stack. I mean, if I have a private network but I register my gatewawy on TTN, are the messages forwarded to the “public TTN”? (I mean public as outside my network).
Im interested on doing so.
Thank you so much.
Registering a gateway with The Things Stack is not equivalent to registering it on the TTN community network.
Private instances of The Things Stack do not forward data to the community network (and do not receive data from the community network either)
To forward traffic to the public network (and possibly receive data from it) you need to use the packet broker which requires a valid netid which requires a Lora alliance membership which costs at least $3000 a year unless you are an institution.
1 Like
Thank you for the answer @kersing. I havent been able to find this information on the official website. Could you tell me where it is?