Quantcast
Channel: The Things Network - Latest posts
Viewing all 114115 articles
Browse latest View live

CFList by TTN production server v 2.0 for devices using KR 920.9-923.3MHz ISM Band?


CFList by TTN production server v 2.0 for devices using KR 920.9-923.3MHz ISM Band?

$
0
0

@htdvisser, I have one extra question.

Your initial answer regarding this question is 'If you configure your gateway with router.kr.thethings.network the backend will follow the KR920-923 band specification.'

What needs to be done for a private TTN server regarding this CFList for KR920-923 band? What do I need to do on my private TTN router to be recognized as a Korean region?

And, if we have to decide on the content of the CFList for KR920-923 band as a community, is the TTN server v2.0 currently sending an empty content for CFList for a Korean region?

One extra question regarding 'CFList by TTN production server 2.0 for devices using KR 920.9-923.3MHz ISM Band'

One extra question regarding 'CFList by TTN production server 2.0 for devices using KR 920.9-923.3MHz ISM Band'

CFList by TTN production server v 2.0 for devices using KR 920.9-923.3MHz ISM Band?

$
0
0

In your Bridge, you need to set --ttn-inject-region KR_920_923.

Correct

Is there a REST API equivalent to ttnctl

$
0
0

Hello,

Thanks for replay and for the CURL style example but, where to find my OAUTH CLIENT ID AND SECRET ?

Is there a REST API equivalent to ttnctl

$
0
0

We don't have an automated system for this yet. For now they are issued to our integration partners on request. You can send your request explaining your plan to johan@thethingsnetwork.org

Node-Red TTN or MQTT with production v.2 backend

$
0
0

@Innofries,

we solved our issue by connecting to eu.thethings.network on port 1883.
This is the new server address of the TTN mqtt broker on the new backend.
No any issues right now.


Multiple LoRa Nodes

$
0
0

Hi, i'm searching over the internet from many days and i didn't find the answer to my question.

I don't need to send my measures online.

I've multiple nodes in a Star configuration.

I need to send the information from 1 of them to all the other nodes.

It's possible? I don't want to use a gateway.

Node-Red TTN or MQTT with production v.2 backend

$
0
0

I have it working on my RPi.
For v.2 backend you need to upgrade Node-Red to get the new nodes ttn-device and ttn-message.

I didn't work in 1 go but after these 2 commands I saw the new nodes (from htdvisser):
npm install -g --unsafe-perm node-red
npm install -g node-red-contrib-ttn@2.0.0

Note; you need to delete the 'old' (v1) ttn nodes from your node-red flows. It only connected the new nodes for me after I deleted the old ones.

Can I register an ABP device that has fixed DevAddr, NwkSKey and AppSKey?

$
0
0

The Roadmap says Q1 2017.

Switching a MultiTech Gateway between MultiTech's original Lora Network Server and the TTN Server

$
0
0

Hi @hoonppark

Could you share the list of command line commands that you use. I am not very good with the bash command line, so please give a clear list if you can?

Thanks!

Multiple LoRa Nodes

IMST & RPI Gateway first data not received

$
0
0

Hi,

I have a problem, I connected a Sodaq One with my Rasp Gateway and the first 3 o 4 packages did not received in TTN server. I saw in Syslog that appears as CRC fail.

After 5 or 6 packages , the info is correct , you know what could be there?

Many thank's in advance

Eduard

Monmouth, Wales is looking for you!

$
0
0

And our first gateway is now online and ready for testing!

It's only single channel, but if you live in the area, let me know and I'll get you setup with credentials!


Node-Red TTN or MQTT with production v.2 backend

$
0
0

Can you tell me what your node-red version is or the version that is required?

One-way paging or broadcast messages?

$
0
0

I am interested in knowing if LoRaWAN can support some kind of one-way (gateway to device) paging or a some kind of broadcast message that is broadcasted by a predefined list of access points. I am thinking of building an old-school one-way pager. While this should clearly be possible with plain LoRa, i am confused if LoRaWAN will allow such kind of transmitterless device. One person thinks it should be possible, but I am unable to judge if or not he has understood it correctly.

What is the best gateway to learning and entrepreneurship?

$
0
0

The gateway Multitech, the thing gateway or link labs-Loriot (taking into account cost, distance -antenna-, TTN support, support, ease of configuration, number of nodes served, etc.).

Switching a MultiTech Gateway between MultiTech's original Lora Network Server and the TTN Server

$
0
0

@chalaman, you can use the following commands to stop/start MultiTech's LoRa Network Server running on the MultiTech Conduit as well as the poly-packet-forwarder for TTN:

 (1) To start MultiTech's LoRa Network Server on the MultiTech conduit

     $/etc/init.d/lora-network-server start

 (2) To stop MultiTech's LoRa Network Server running on the MultiTech conduit

     $/etc/init.d/lora-network-server stop

 (3) To start the poly-packet-forwarder for TTN

     $/etc/init.d/ttn-pkt-forwarder start

 (4) To stop the poly-packet-forwarder for TTN

     $/etc/init.d/ttn-pkt-forwarder stop

CFList by TTN production server v 2.0 for devices using KR 920.9-923.3MHz ISM Band?

$
0
0

@htdvisser, I've entered my input on https://github.com/TheThingsNetwork/ttn/issues/376 as you suggested above.

Here is one interesting thing.

I started my lora-gateway-bridge running on my laptop as follows:

$ lora-gateway-bridge --ttn-inject-region KR_920_923

And, I tested with a MultiTech's mDot module which is set up to use US Sub-band 2. I was curious if it is going to be able to 'JOIN' or not.

The result was it was able to JOIN the network and able to send data to the TTN Network server.

How can a device using US Sub-band 2 join the network and be able to send data when the lora-gateway-bridge's region is set up as 'KR_920_923'?

Here is my guess on what happened. My guess is TTN server currently sends an empty CFList when a device joins the network for the KR_920_923 region. So, the end device - MultiTech mDot module in my case - received an empty CFList from the network server when joining. Because the CFList was empty, mDot module did not update its CFList and kept using US Sub-band 2.

Is this what really happened?

If my guess is true, when the TTN server later starts sending the CFList with a real channel list (non-empty CFList) for the Korean region, a device using US Sub-band 2 won't be able to JOIN the network.

Viewing all 114115 articles
Browse latest View live




Latest Images