Whichever code is running your gateway - presumably https://github.com/Lora-net/picoGW_packet_forwarder ?
↧
ERROR: Packet REJECTED, unsupported RF power for TX - 24
↧
Sending text messages to a large number of nodes
This isn’t a good fit for TTN, even in areas where the availability of wider bandwidth downlink channels means an individual message itself could fit.
If it is achievable at all depends on things like the power source available to the nodes. It’s very hard to make a battery powered device receive an infrequent broadcast at an unexpected time - you essentially have to have periodic traffic going one way or the other to keep things in coordination so that you only run the power hungry receiver at infrequent, agreed upon times. So now you’re no longer only doing one thing a week.
Anyway, that’s not really on topic here as this is the TTN forum.
↧
↧
Reach of Node?
Hi, I meant the node with the name "hsnrgps2
↧
Reach of Node?
Ärjan,
thanx for the info. Indead it’s “hochschule_niederrhein” with some experiment I think.
Can JP not move this data to “experiment”?
@jpmeijers I am new in this forum and juist started using the TTN Mapper.
I was happy to see that one of my gateways had a reacht of 50 km and more, but it may be wrong…
Best
Marc
↧
HeyWhatsThat experience
I would like to share my experience with you. I have received data on ttnmapper from 120km away. Since it is an indoor gateway, and is located in a small depression, this is very far. So I looked at https://www.heywhatsthat.com (line of sight calculator). Exactly from where I received data it shows a line of sight, so the data seems to fit together very well.
According to heywhatsthat.com this is the largest possible line of sight.
↧
↧
Axioma QALCOSONIC E3 with OTAA
Here’s my noob’s decoder for Qalcosonic W1 with loraServer :
↧
ERROR: Packet REJECTED, unsupported RF power for TX - 24
Sorry stupid question, above there is some code (writing from mobile).
Reference = ideal code for the situation to copy the idea / function.
↧
Update to 3.9
Hi, we have an enterprise stack server hosted at AWS built with the cloud formation template. We only built it a couple of weeks ago and it’s version 3.8. How do we update this to 3.9 ?
↧
ERROR: Packet REJECTED, unsupported RF power for TX - 24
For changing the power table in the json, I believe you already have that in the thread.
For changing the algorithm in the code to settle for the closest match, I’d assume someone has done it in some version, they’re all pretty comparable when you start diffing the relevant portions of the actual code.
But that may be a legitimate question - is there a version of the packet forwarder which settles for a close rather than exact match?
↧
↧
My first setup
Hello all,
I am looking for creating a bike tracker based on Lora.
In a first time I want to make a proof of concept and then I will develop a board if it works well.
I am not sure of where I must start.
What I understood is I need of:
- A gateway (Just two gateway in my city…): RAK7246 looks good but maybe I can have better for the price. If possible I want to cover a long range (can I cover 5km in town with this product?)
- A GPS tracker: RAK7200 will make the job in a first time
- A software application: Is there an Android app to display the position on a map? Or I will use IFTTT to start.
Thanks for your lights. I want to be sure that if I buy that I will be able to make something at home.
↧
Missing Pub/Sub providor - AWS IoT
I am following this document to create an AWS IoT connection from an application we have created.
I have got to the stage where we need to create a new Pub/Sub Integration but when i click on Add the document suggests i should have three providers, NATS / MQTT and AWS IoT.
We seem to be missing the AWS IoT option.
I’m not sure if this is due to us running version 3.8.4. I have asked in another thread how we do about updating to 3.9.
Are we missing the option due to a version difference or does it need to be added elsewhere ?
↧
ERROR: Packet REJECTED, unsupported RF power for TX - 24
There are a number of versions (that I know) that take the next lowest power and they are
- Jac Kersing’s multi-packet forwarder (SX1301 chip)
- my published patched version https://github.com/JoToSystems/LoraPacketForwarder (SX1301 chip)
- the Semtech reference code for the “new” SX1302 chip
↧
Things Outdoor Gateway - TTOG part 1
My Gateway has suddenly stopped working – well, actually a few months ago, but I’m just getting to it now. It seems properly configured …
and the log seems normal:
INFO: tx_start_delay=1497 (1497.000000) - (1497, bw_delay=0.000000,INFO: Beacon dequeued (count_us=1239450094)
JSON up: {"stat":{"time":"2020-09-11 19:18:17 GMT","lati":35.69403,"long":-78.77931,"alti":143,"rxnb":0,"rxok":0,"rxfw":0,"ackr":0.0,"dwnb":0,"txnb":0}}
##### END #####
# GPS coordinates: latitude 35.69403, longitude -78.77931, altitude 143 m
# Valid time reference (age: 1 sec)
### [GPS] ###
# SX1301 time (PPS): 1232450059
### [JIT] ###
# BEACON rejected: 0
# BEACON sent so far: 8
# BEACON queued: 11
# TX errors: 0
# RF packets sent to concentrator: 0 (0 bytes)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# PULL_DATA sent: 3 (0.00% acknowledged)
### [DOWNSTREAM] ###
# PUSH_DATA acknowledged: 0.00%
# PUSH_DATA datagrams sent: 1 (155 bytes)
# RF packets forwarded: 0 (0 bytes)
# CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets received by concentrator: 0
### [UPSTREAM] ###
##### 2020-09-11 19:18:17 GMT #####
WARNING: [gps] GPS out of sync, keeping previous time reference
JSON up: {"stat":{"time":"2020-09-11 19:17:47 GMT","lati":35.69397,"long":-78.77934,"alti":142,"rxnb":1,"rxok":0,"rxfw":0,"ackr":0.0,"dwnb":0,"txnb":0}}
##### END #####↧
↧
Sending text messages to a large number of nodes
Too bad 
, but thank you for these answers. This makes some topics more clear.
↧
ERROR: Packet REJECTED, unsupported RF power for TX - 24
Let’s try and explain the problem. I published this previously in the TTN Slack channel but that may have disappeared by now
The gateway code is compiled from two pieces of code,
- the Packet Forwarder code which faces the internet and server
- The SX1301 Hardware Abstraction Layer (HAL)
The two pass messages via a Queue.
The packet forwarder has a test (refer line 2014-2026 of the picoGW code https://github.com/Lora-net/picoGW_packet_forwarder/blob/master/lora_pkt_fwd/src/lora_pkt_fwd.c) where it checks for a match of the requested power from the server and the powers listed in the tx_lut table
The HAL performs the same test but in this case it selects the next lowest power from the tx_lut table
The first thing that struck me, there is duplicated and redundant checking being conducted.
So the simple solution is to remove the test in the Packet Forwarder and allow the HAL to perform the check and select the most appropriate power.
I am not familiar with the picoGW so I cannot guarantee this is the solution but this will at least give an insight into the root cause.
↧
ERROR: Packet REJECTED, unsupported RF power for TX - 24
The patch I published also addressed another issue.
If you look at line 971 of the code you will see a “ToDo” where there is no checking of the configuration parameters.
There is no check for the entries in the tx-lut table are in increasing order of power. This is necessary for the selection process in the HAL code to work. As long as the tx_lut table has not been modified it should work fine.
↧
Maybe a problem with my RHF0M301
Does the gateway have a gps receiver? If so, is there a gps antenna connected?
If there is no gps or no antenna there is nothing to worry about. That is a normal message. If there is a gps with antenna you need to make sure it can receive satellite signals.
↧
↧
My first setup
Bike Tracker to track something you have lost - or to record its movement whilst you ride it?
First is feasible, the second will be constrained by how often you are legally allowed to transmit & the TTN fair use policy. You need to think about how much detail you want on this as the most you can send is once every 2.5 minutes on a short range setting.
Apart from the Pycom Gateway, you will struggle to find a lower cost gateway than the RAK7246 - but if you want to reach out over a distance, you will need a decent antenna high up.
The RAK7200 will indeed provide a tracking function. It’s internal antenna is ‘OK’.
Data is piped through the gateway to a backend server that has a number of ways of connecting on to your application - at which point the possibilities explode. There are hundreds of apps for mapping, how you get it to display a location depending on your data you’ll need to check out. I’m not sure IFTTT is a good fit, but something like Node-Red may be better. The fun of this is trying things out, and at least the software at an entry level doesn’t come with any significant cost apart from the most valuable of all, your time.
↧
Feather M0 EV_JOIN_TXCOMPLETE: no JoinAccept problem
If you want to be sure that this is not a problem caused by your code, you can try the latest release of the paxcounter software. I am testing in central Berlin, too, and get immediately join with a TTGO T-Beam 1.0 and paxcounter (based on MCCI LMIC 3.2.0)
↧
Feather M0 EV_JOIN_TXCOMPLETE: no JoinAccept problem
What use has PaxCounter on Feather M0 LoRa?
It is not ESP32 and has neither WiFi nor Bluetooth.
↧