Lora/TTN RN2483
Moderators: grovkillen, Stuntteam, TD-er
Lora/TTN RN2483
Hi,
I have some devices connected over Lora, but have the same problem for all of them...
For example have in device two sensors, DS18B20 and INA219, time for send is 60s.
Problem is, ESP send 10x info from INA and 1x from DS18B20, i dont know what is wrong.
Ideal for me is send info from both in one message.
Any idea ?
I have some devices connected over Lora, but have the same problem for all of them...
For example have in device two sensors, DS18B20 and INA219, time for send is 60s.
Problem is, ESP send 10x info from INA and 1x from DS18B20, i dont know what is wrong.
Ideal for me is send info from both in one message.
Any idea ?
Re: Lora/TTN RN2483
Can you go into the TTN console and see if you have checked in the device config if you need to have an acknowledgement?
Also double check the RX2 frequency. (Network Layer -> Advanced MAC settings)
(869.525 should be the preferred RX2 frequency)
Desired RX2 data rate index: 3
Also double check the RX2 frequency. (Network Layer -> Advanced MAC settings)
(869.525 should be the preferred RX2 frequency)
Desired RX2 data rate index: 3
Re: Lora/TTN RN2483
All see ok... ?
Re: Lora/TTN RN2483
Maybe better to disable ADR for now as it tends to send downlink messages which may alter settings in the LoRaWAN radio.
What SF are you using?
If SF7 is "good enough" then ADR is useless anyway as you can't get any lower.
What SF are you using?
If SF7 is "good enough" then ADR is useless anyway as you can't get any lower.
Re: Lora/TTN RN2483
Yes, SF is 7, strong signal...
Maybee any exact setup for IDX or time send in device list ?
This issue dont have exactly "key" every hour, day is random exact random hi
I have now two sensors and both make the same problem...
Maybee any exact setup for IDX or time send in device list ?
This issue dont have exactly "key" every hour, day is random exact random hi
I have now two sensors and both make the same problem...
Re: Lora/TTN RN2483
Can you check in the TTN console to see if the network tries to send some downlinks to the node?
Maybe you need to have access to the gateway to see this traffic? (as in you need to be the owner or colaborator of the gateway)
Maybe you need to have access to the gateway to see this traffic? (as in you need to be the owner or colaborator of the gateway)
Re: Lora/TTN RN2483
I am Owner, easy to me...
As you see, some down are...
Device
GW
As you see, some down are...
Device
GW
Re: Lora/TTN RN2483
It looks like the gateway is sending downling messages to change your RX1 settings.
Was this node joined via OTAA or ABP?
Was this node joined via OTAA or ABP?
Re: Lora/TTN RN2483
Is connected by OTAA, any idea what change ?
Re: Lora/TTN RN2483
Can you check the timing stats page to see what the duty cycle is of the LoRa controller?
I tend to use that timing stats for the lora too, to get some estimate on the air time.
Maybe you're hitting the 1% and then the controller queue may do some things which at first may seem confusing?
I tend to use that timing stats for the lora too, to get some estimate on the air time.
Maybe you're hitting the 1% and then the controller queue may do some things which at first may seem confusing?
Re: Lora/TTN RN2483
Sry, but I dont know, what you exactly mean...?
Re: Lora/TTN RN2483
You're only allowed to send for 1% of the time.
Meaning the nr of messages you can send heavily depend on the used spread factor.
The RN2483 does have 8 channels and the firmware does take into account the 1% air time rule per channel.
This allows you to send upto 8 messages in a burst.
The timing stats page does have an entry showing the air time so you get an idea about the air time in the "duty" column.
I do compute the expected air time per message for this.
Roughly speaking, the "air time" doubles per SF step you go up. Thus from SF7 to SF8 will double the air time for the same message.
You can also see the air time in the TTN console.
Rough estimate is like 50 - 70 msec per message in SF7 mode.
Thus using SF7, you could send roughly 15 messages per 100 sec. (9 per minute)
Meaning the nr of messages you can send heavily depend on the used spread factor.
The RN2483 does have 8 channels and the firmware does take into account the 1% air time rule per channel.
This allows you to send upto 8 messages in a burst.
The timing stats page does have an entry showing the air time so you get an idea about the air time in the "duty" column.
I do compute the expected air time per message for this.
Roughly speaking, the "air time" doubles per SF step you go up. Thus from SF7 to SF8 will double the air time for the same message.
You can also see the air time in the TTN console.
Rough estimate is like 50 - 70 msec per message in SF7 mode.
Thus using SF7, you could send roughly 15 messages per 100 sec. (9 per minute)
Re: Lora/TTN RN2483
There is no change when SF is changed. When I change "Max Queue Depth" there will be a change Dallas and Ina sensor, but still not have all info in one msg.
Re: Lora/TTN RN2483
OK, I think I misinterpreted your question then.
What do you mean by "in one message" ?
How often do you try to send to this controller? (thus interval settings per task sending via this controller)
What controller settings do you use?
Re: Lora/TTN RN2483
I mean send Dallas + Ina together in one msg - Is it even possible ??
I send data from devices to controles one by 30s.
Settings for controles is default.
Can you post please recommended settings for lora controler ? Maybee also recommended timig and IDX for devices ?
Maybe I don't even need to send/receive both sensors in one message, but I need to send data from sensors to sequentially - tmp/current/tmp/current. At the moment, 10x temperature and 1x current will pass and vice versa.
Tnx
Re: Lora/TTN RN2483
When combining task values, you may want to use rules to 'copy' those values into a "dummy" task. (TaskValueSet)
This "dummy" task should then be coupled to the LoRaWAN/TTN controller.
When all values are copied, you can trigger to send the values to the controller by calling a "taskrun" on this "dummy" task.
The IDX value and taskindex are also present in the decoded TTN message, so you can extract those to help decode the data.
If you are running samples in "batches" you can also set the Sample Set Initiator
This can be set to the first task in a row you expect to have a new value present.
Let's assume you act on some trigger (e.g. GPS distance travelled or current measurement threshold exceeded)
This then triggers and event like this:
In this example, task3 (the dummy task) will always send as the first one of a batch to the controller.
Thus if you set the Sample Set Initiator to task3, a single byte counter will be incremented until the next time this task sends data to this controller.
This way you can still see to which "batch" of samples a received sample belongs.
It also may be useful to detect if you receive duplicates of the same message, or that you may be missing lots of samples inbetween.
This is a great feature for debugging TTN traffic and also to stitch together samples when only receiving a fraction of the messages.
This "dummy" task should then be coupled to the LoRaWAN/TTN controller.
When all values are copied, you can trigger to send the values to the controller by calling a "taskrun" on this "dummy" task.
The IDX value and taskindex are also present in the decoded TTN message, so you can extract those to help decode the data.
If you are running samples in "batches" you can also set the Sample Set Initiator
This can be set to the first task in a row you expect to have a new value present.
Let's assume you act on some trigger (e.g. GPS distance travelled or current measurement threshold exceeded)
This then triggers and event like this:
Code: Select all
on myEvent do
taskrun,1 // run task 1 called "dallas"
taskrun,2 // run task 2 called "ina"
taskvalueset,3,1,[dallas#T1] // Set in dummy task at taskindex3 the value1
taskvalueset,3,2,[ina#V] // Set in dummy task at taskindex3 the value2
taskvalueset,3,3,[ina#A] // Set in dummy task at taskindex3 the value3
taskvalueset,3,4,%uptime% // Set in dummy task at taskindex3 the value4
taskrun,3 // Run the Dummy task, to flush the data to the controller
taskrun,4 // Run some other task, to let this one flush its data too to the controller
endon
Thus if you set the Sample Set Initiator to task3, a single byte counter will be incremented until the next time this task sends data to this controller.
This way you can still see to which "batch" of samples a received sample belongs.
It also may be useful to detect if you receive duplicates of the same message, or that you may be missing lots of samples inbetween.
This is a great feature for debugging TTN traffic and also to stitch together samples when only receiving a fraction of the messages.
Who is online
Users browsing this forum: No registered users and 20 guests