Hello everyone
I’m Marc 33 from Germany
I set up a gateway with a raspberry and a dragino HAT. And use a TTGO Lora board with Oled to do a few tests. It works so far. But I can’t find any example code for using the Oled to display the RSSI and some Infos like State of Connection. Does anyone of you have a few example codes that I can use for testing. Greetings Marc
Link to my Board: https://www.makershop.de/plattformen/arduino/esp32-lora-board/
That’s not a gateway, but a non-compliant device which leads to misoperation of the network in a way that negatively impacts other users, not just yourself. Please disconnect it immediately.
But I can’t find any example code for using the Oled to display the RSSI and some Infos like State of Connection.
Once you’ve stopped interfering with the shared network by running a non-compliant device that pretends to be (but is not!) a gateway, look for the previous thread here on using such a display.
You’ll then need to consider where the display is, and what information is knowable to it.
A node generally doesn’t have any RSSI to show, because downlink events are rare.
Nor does LoRaWAN have any real concept of a “connection” - you could show details such as OTAA session state, or ADR state relatively to ramping up or down data rate, but these are fairly distinct.
A typical actual gateway sees traffic at too high a rate for a display of individual packet RSSI to be very meaningful, what is useful there instead is things like the state of the backhaul connection to the network server, and statistics about total packets received or sent, their pacing, etc.
I wanted to test something with Lora first and then I get a gateway that is released with 8 channels. The board I use is a TTGO with onboard I2C Oled. it is currently only about a few example codes so that I can test a little more. on the subject of RSSI and db: there are lots of examples with which you can see how well the signal was sent via this downlink function ?! I would definitely like to support the Lora network and will swap the gateway for a good approved gateway as soon as possible. greetings Marc
You need to unplug the non-compliant thing now, not when you have a replacement as it interferes with other’s use of the shared network
RSSI of uplinks is only known at the network side, you cannot squander expensive downlink bandwidth sending that back to the node. Thus with extremely rare exception (the very infrequent situations when a downlink is appropriately sent) you can only know the RSSI on the network/internet side, not on the node side.
I now buyed the iMST iC880a Board
estimated arrival is in 2 Days …
then i will fire it up and will make my tests with it
i hope you are happy with this gateway 
regards from germany
How exactly does a single channel gateway “interfere” with the network?
As long as it adheres to sending downlinks on the appropriate channel I do not see the harm.
This has been documented and explained many times here previously.
The short version is that it leads the network to configure other nodes on the assumption that it is available. But in reality, it’s only available on one channel and data rate, not the huge variety that an actual gateway is required to support. So after being configured to a short range mode taking into account the gateways presence, the gateway isn’t actually “there” for that mode (but only for one originally used), and also not for the next channel used (which is required to not be the same as the previous) and so the node can no longer reach the network. It will be hours to even days before it times out of using those setting and reverts to ones that work and can be picked up by other actual gateways a little further away; while if it is had stayed in long range mode it would have remained able to reach those actual gateways the whole time.
Pretending to be a gateway when not actually being one is a “bait and switch” issue and practically if not intent, a denial of service attack on other users.
Ah now I understand, the ADR get’s too optimistic. Thank you for explaining again.
It’s not ADR, it’s the lack of full 8 channels & the ability to listen for signals on different spreading factors.
If you have a Single Channel Packet Forwarder and a device, not unreasonably, transmits, per specification, on a channel the SCPF is not listening on, the uplink is lost. Additionally, most SCFP don’t implement Channel Activity Detect at all and if they do, can’t hear all of the SF’s. So a SCPF is pretty much stuck on one channel and one, maybe up to three or four SF’s out of a possible combination of 48.
The illustration above was of a device that gets picked up by a SCPF, thinks it has a connection to the network and then takes forever before it comes to the conclusion that it’s not because it has been using the an SF appropriate to the range of the SCPF but all the channels. If it had joined a full gateway further away, it would have started out with a more appropriate SF.
now my new Gateway is online and it is supported i hope now all it`s fine 
the old single channel gateway is now offline but my new rpi with ic880a Gateway is up an running
regards from Germany
Hi Mark
Apologies in advance to TTN for off topic.
Regarding the TTGO kit, there’s plenty of Arduino examples about how to use the OLED. I bought a couple of those boards without displays and the displays separately, and was able to fit them and set them up as a Tx and Rx and display RSSI levels as I drove around my neighbourhood with the transmitter on top of mast at home. Search for TTGO to find the libraries.
Tony
Apologies if I’m misunderstanding your use-cases, but would it not be better/easier to use the TTNMapper project?
I think this is the most well maintained/up-to-date version: https://github.com/kizniche/ttgo-tbeam-ttn-tracker
If you use TTN, then you can’t really use downlinks on more than a “few times a day” basis, so there’s no RSSI to display at the node.
If you use TTN in conjunction with something like a mobile data feed back to your phone, then that can see the uplink RSSI - but not the node itself.
If instead of using TTN or LoRaWAN you implement a point-to-point type of ping pong test - and stay within regulatory usage limits - then you may be receiving at the moving node and actually have an RSSI to display, either from the far end or having it echo back yours.