I have transmitted data from my lora node SX-1276 to THE THINGS NETWORK (ttn). Now I want this data to appear on my mobile as a message(sms) or I need to have an app in my mobile which shows the data which has been stored in the TTN. What should I do to get this data as a message in my mobile. It would be very helpful if you could tell me all the possibilities to do so.Please reply
↧
TTN to SMS - howto?
↧
The BARGAIN basement part 5
↧
↧
LoRaWAN Academy - Week 10 & final grade
Hello,
i am doing the LoRaWAN Academy course from The Things Conference and would love some info about the final grade and the week 10 assignment. I did post my project in the academy board some weeks ago but the points are not raising and still stuck at 80% (hovering with the mouse tells me there are points for week 1 till 9 but not week 10). How get i points for week 10 and will the QA points be included in the final exam too? They are all at zero atm (length of the bars). Stupid me wants to get a high score 
Thank you very much for the help!
Cheers
Caspar
↧
TTN to SMS - howto?
Develop an application that exploits SMS delivery services, and integrate it with TTN.
↧
The LIBRARY basement part 8
↧
↧
The LIBRARY basement part 8
↧
'data storage integration' and raw string
tnx for your answer.
Now I know this is useless information for me because I have the data already decoded.
↧
The LIBRARY basement part 8
↧
How to send negative temperature value efficiently
Strings are not appreciated in LoRaWAN 
and the sign at the end is just a bit.
Integer or decimal? range? you can always add a number and then subtract it.
↧
↧
The LIBRARY basement part 8
↧
Accurate Humidity Sensors, CE, IP65 (Europe)?
Hi there,
Can anyone recommend (tested/does have experience with) accurate humidity sensors with CE, IP65 enclosure, available in Europe?
Thanks for any pointers!
↧
TTN gateway (kickstarter backed) defect
The ethernet connection of my TTN gateway has stopped, both LEDs off. It is the kickstarter model.
How to get it repaired?
↧
One of my ttn UNO cannot join anymore
Fixed by upgrading the RN2483 firmware to 1.0.5.
I think I bumped on every single possible problems… If you want, I can write a beginner article here or somewhere else, that combines :
- gateway hardware fix (push the board firmly in the slot)
- gateway firmware update
- the things uno rn2483 firmware update on linux (it is possible)
After that, a beginner can follow the Johan Stokking youtube tutorials !
↧
↧
Configuring The Things Uno TX Power
Hi,
I am currently carrying out a project involving the development and testing of a GPS tracking device using LoRaWAN. In order to carry out range tests I would like to be able to adjust the tx power of the transceiver. Having reviewed all the ttn libraries main functions which are viewable from ttn’s website, there doesnt seem to be any which allow you to set tx power. After reviewing the LoRaWAN Specifications manual and Microchip’s RN2483 manual it would seem as though the chips tx power is adjustable, however I can’t seem to find out how it can be done. Can anybody advise?
Cal.
↧
STM nucleo F411RE (Lora Module Does not work!)
Hello!!
I am using a STM Nucleo F411RE board + a I-NUCLEO-LRWAN1 shield and the serial monitor on the arduino IDE says that “Lora Module is not ready”. Please help.
I used the library at https://github.com/stm32duino/I-NUCLEO-LRWAN1
My setup
The serial monitor
Thank you very much
↧
ADR problems - node of the same type have different ADR behaviour
I try something more with another node, 1060bd.
Yesterday this node opeartes with a SF7, then I shielded it for all the night and this morning I remove the shield and I found it with a SF12.
Then TTN start to send downlink msg every time the node send an uplink (every hour).
This is the mosquitto downlink log from yesterday till now:
Feb 17 09:18:27 senlab-t/devices/1060bd/events/down/sent {“payload”:“YOEvASaAFwACYNKhHPXwO+Zs3isTHM1fx1Ffv0A=”,“message”:{“app_id”:“senlab-t”,“dev_id”:“1060bd”,“port”:2,“payload_raw”:“AQcBAQcIBuMCBwgDXwkADw==”},“gateway_id”:“eui-1dee0eb900028599”,“config”:{“modulation”:“LORA”,“data_rate”:“SF7BW125”,“airtime”:66816000,“counter”:23,“frequency”:867700000,“power”:14}}
Feb 18 06:49:52 senlab-t/devices/1060bd/events/down/sent {“payload”:“YOEvASaFGAADVf8AAzz/Bqw=”,“message”:{“app_id”:“senlab-t”,“dev_id”:“1060bd”,“port”:0},“gateway_id”:“eui-1dee03a372f1126a”,“config”:{“modulation”:“LORA”,“data_rate”:“SF9BW125”,“airtime”:164864000,“counter”:24,“frequency”:869525000,“power”:27}}
Feb 18 07:49:39 senlab-t/devices/1060bd/events/down/sent {“payload”:“YOEvASaKGQAFA9KthANV/wADLIV4/Q==”,“message”:{“app_id”:“senlab-t”,“dev_id”:“1060bd”,“port”:0},“gateway_id”:“eui-1dee03a372f1126a”,“config”:{“modulation”:“LORA”,“data_rate”:“SF12BW125”,“airtime”:1482752000,“counter”:25,“frequency”:869525000,“power”:27}}
Feb 18 08:49:42 senlab-t/devices/1060bd/events/down/sent {“payload”:“YOEvASaKGgAFA9KthANV/wADYCLDlQ==”,“message”:{“app_id”:“senlab-t”,“dev_id”:“1060bd”,“port”:0},“gateway_id”:“eui-1dee1a0a6e94d4bf”,“config”:{“modulation”:“LORA”,“data_rate”:“SF12BW125”,“airtime”:1482752000,“counter”:26,“frequency”:869525000,“power”:27}}
Feb 18 09:49:50 senlab-t/devices/1060bd/events/down/sent {“payload”:“YOEvASaKGwAFA9KthANV/wADJbGK9Q==”,“message”:{“app_id”:“senlab-t”,“dev_id”:“1060bd”,“port”:0},“gateway_id”:“eui-1dee1a0a6e94d4bf”,“config”:{“modulation”:“LORA”,“data_rate”:“SF12BW125”,“airtime”:1482752000,“counter”:27,“frequency”:869525000,“power”:27}}
Feb 18 10:49:41 senlab-t/devices/1060bd/events/down/sent {“payload”:“YOEvASaKHAAFA9KthANV/wADHOnA3Q==”,“message”:{“app_id”:“senlab-t”,“dev_id”:“1060bd”,“port”:0},“gateway_id”:“eui-1dee1a0a6e94d4bf”,“config”:{“modulation”:“LORA”,“data_rate”:“SF12BW125”,“airtime”:1482752000,“counter”:28,“frequency”:869525000,“power”:27}}
Feb 18 11:50:04 senlab-t/devices/1060bd/events/down/sent {“payload”:“YOEvASaKHQAFA9KthANV/wADtk6xvQ==”,“message”:{“app_id”:“senlab-t”,“dev_id”:“1060bd”,“port”:0},“gateway_id”:“eui-1dee1a0a6e94d4bf”,“config”:{“modulation”:“LORA”,“data_rate”:“SF12BW125”,“airtime”:1482752000,“counter”:29,“frequency”:869525000,“power”:27}}
Feb 18 12:49:36 senlab-t/devices/1060bd/events/down/sent {“payload”:“YOEvASaKHgAFA9KthANV/wADcpP3+A==”,“message”:{“app_id”:“senlab-t”,“dev_id”:“1060bd”,“port”:0},“gateway_id”:“eui-1dee1a0a6e94d4bf”,“config”:{“modulation”:“LORA”,“data_rate”:“SF12BW125”,“airtime”:1482752000,“counter”:30,“frequency”:869525000,“power”:27}}
Feb 18 13:49:56 senlab-t/devices/1060bd/events/down/sent {“payload”:“YOEvASaNHwACFwEFA9KthANV/wADQ9uFew==”,“message”:{“app_id”:“senlab-t”,“dev_id”:“1060bd”,“port”:0},“gateway_id”:“eui-1dee1a0a6e94d4bf”,“config”:{“modulation”:“LORA”,“data_rate”:“SF12BW125”,“airtime”:1482752000,“counter”:31,“frequency”:869525000,“power”:27}}
I’ve also catched the last one downlink (13:49:56) with the TTN console, that shows the ADR commands:
I don’t know if the link-adr commands are correct, from the mosquitto log there is a “config” payload that I don’t know if refers to the current condition or represent a configuration command.
In case the adr command are really trying to lower the SF, it could be that the problem is the gateway or the node.
Gianluigi
↧
One of my ttn UNO cannot join anymore
Hi, new LAB stories are always welcome tnx.
↧
↧
The LIBRARY basement part 8
We are at Mobile World Congress #MWC2019 in #Barcelona – from 25 – 28 Feb.
Book a meeting with us - https://calendly.com/thethingsindustries/ttn-mwc and learn about our end-to-end secure LoRaWAN network server with 99.9% uptime, generic node and the newly announced indoor and outdoor gateway.
↧
ADR problems - node of the same type have different ADR behaviour
Given the frequency 869.525, the downlinks are all in RX2, except for the very first one, which is in RX1 (and is the Join Accept). Of those RX2 downlinks, only the first is sent at the TTN-specific SF9 (as expected), all others use the LoRaWAN default SF12 (as a workaround).
Now, an example has proved that, when using RX2, TTN surely is smart enough to repeat ADR on SF12 if nothing changed when the node ignored the ADR downlink in the documented SF9. The same can been seen in the code. But I feel TTN should not keep using SF12 for ADR in RX2 then; assuming your node is using the TTN specific settings that it got in the EU868 OTAA Join Accept, it will never receive the RX2 downlinks when TTN uses SF12…
On the other hand, maybe the bug is that it should not repeat forever, but only once. And maybe it uses SF9 again when the node sets ADRAckReq at some later time again. And the other nodes do accept the RX2 SF9 downlink?
That’s the gateway’s configuration for the downlink. Like frequency, data rate and power that is to be used for the transmission. It’s not some configuration payload that is sent to the node.
The data sent to the node is taken from, e.g., "payload": "YOEvASaFGAADVf8AAzz/Bqw=" for the SF9 downlink, which indeed is a MAC command in FOpts = 0355FF0003, which according to the 1.0.2 specification and the EU868 regional parameters decodes to:
- 0x03 = LinkADRReq MAC command
- 0x55 = DataRate_TXPower: data rate 5 (SF7/125KHz); TX power 5 = 6 dBm
- 0xFF00 (LSB) = 0b00000000 11111111 (MSB) = ChMask = channels 1 thru 8
- 0x03 = 0b00000011, so ChMaskCntl = 0b000, so indeed the bits in ChMask above directly refer to individual channels. This also sets NbTrans = 3, telling the node that each unconfirmed uplink should be transmitted 3 times? (I don’t understand that, but I assume it’s unrelated to your problems, as I assume it’s the same for the other nodes…)
And the first SF12 downlink, which your node will not have received, gives FOpts = 0503D2AD84 0355FF0003, which indeed also repeats the TTN specific RX2 settings:
- 0x05 = RXParamSetupAns MAC command
- 0x03 = DLsettings: RX1DRoffset = 0 (RX1 downlink uses the same data rate as the preceding uplink) and RX2DataRate = 3 (SF9/125kHz for RX2)
- 0xD2AD84 (LSB) = 0x84ADD2 (MSB) = RX2 frequency 869.5250 MHz
…followed by the LinkADRReq MAC command 0x0355FF0003 as described above.
So, all above aside: why didn’t that specific node receive or process the SF9 downlink? (As other nodes do process it, so certainly receive it, I doubt the gateway is to blame.)
↧
ADR problems - node of the same type have different ADR behaviour
Ah, the code seems to show that this number is increased when packet loss has been detected. Surely shielding all night has made TTN detect that. In time, this number will decrease again…
↧