I’m experimenting with the Raspi-LMIC library (GitHub - pmanzoni/raspi-lmic: This repository is a subset of this one https://github.com/hallard/arduino-lmic/tree/rpi and provides the IBM LMIC (LoraMAC-in-C) library ready to be used with a Raspberry Pi with a Dragino Hat.) with a Adafruit Lora HAT (with a RFM95W - SX1276) connected to a Raspberry pi 4. I have a TTIG 868 indoor gateway. I’m using a 1/4 wave wire antenna.
Using the OTAA code I see join messages arriving at the gateway and see downlink messages in the gateway console. However my device never receives anything. I suspect this is a timing problem so will continue to test. However I remember reading somewhere that you can have problems if the gateway is too close to the device. Mine is in the next room, about 3m distant. Could this be a problem?
Thanks
A quick search / review of the current topics will reveal someone else struggling with a RFM95 on Pi setup so much of that may contribute to your thinking.
Ideally you need a device that’s not running a whole OS to test your gateway is all good. Then you can move on to your very own Mission Impossible.
Right now this is a learning exercise, so looking at the code and tracing the flow is teaching me about the chip. Using a whole OS for now makes this easier. It is not running anything else, has no display, I am just ssh’d in. As an experiment I have set the receiver to continuous mode after sending the join message and I still see nothing received. The gateway messages log shows the send downlink 2s after the uplink so I assume this is occurring in the Rx2 window.
My main question was on gateway placement - I am sure that I read somewhere that if the gateway is too close the signal can overwhelm the receiver.
So much easier to answer questions when you context!
If you want to learn about the RFM95 aka SX1276, LMIC brings so much more ‘stuff’ to the party that you will have to push aside 80% of the code to see what’s going on.
Having learnt (and forgotten a fair amount) of LMIC by reading the source and debugging on the Pro Mini, if I was learning the LoRa chip all over again, I’d do Peer to Peer - most likely with an amalgam of these two code bases:
The Pi-in-the-Sky stuff is for RFM98 as we use 433MHz but as it’s for High Altitude Ballooning which is a bit system critical, it’s a well tested code base. And most importantly, it’s on a Pi! You’ll find Dave Akerman’s chip driver straightforward but a bit different, people ask him why he didn’t use someone else’s and the short answer is that he wrote his first!
However for me the chip is a bit of a black box - push in an array of bytes and they duly arrive 1 second in my database.
[moderator-mode-on]
Technically taking this learning path is somewhat off-topic for TTN/TTS but hopefully will get you started with the underlying radio technology.
I’d be remiss not to ask you to be careful with your experiments to ensure there is no impact on TTS CE or anyone using TTN in your neighbourhood - particularly as you are using downlinks which we try to avoid and there is the fair use policy of 10 a day to consider too.
Which is why, for anyone else reading along, I’ve provided some resources to learn the radio out of harms way of the network.
[moderator-mode-off]
For V3 both the join RX1/RX2 windows and the normal RX1/RX2 windows are 5/6 seconds. For V2 the join windows is 5/6 seconds as well. Seeing a downlink 2 seconds after an uplink is strange if you haven’t joined yet.
That is strange. The log for my gateway always shows pairs of messages like:
The messages are usually 2s apart sometimes as here 1s. Even setting the receiver to continuous mode after the transmit, i do not receive anything.
We wait with bated breath to see your message pairs …
And now we see them - the Rx1 delay is set to 5s, so that’s the message on the console telling the gateway to send the message 5s after the uplink transmission ceased - it’s not the time the transmission occurred.
Which sorts of circles back to the using TTN as a method of learning the radio - you need to know exactly what the NS is going to do to be sure of testing.
I’d read on the Lora regional parameters document that the default RX1 delay for EU is normally 1s so did not realise that the 5s displayed in the log was the actual delay used. Apologies.
I am now getting successful joins from the LMIC code, so tx and rx seem OK. I had to move the TT indoor gateway into the same room as the device to get reception working. Transmission was fine over larger distance, but not reception. Is that just a limitation of the 1/4 wave antenna I am using, might there be some other setting I need to check?
Thanks again
TTIG and node normally do not need to be in the same room.
What is "larger distance’?
“Transmission was fine” what is the transmitter here, node or gateway?
“1/4 wave antenna I’m using” I assume you mean the antenna of the node here.
A 1/4 wave antenna is in fact one half of a dipole. The other half is the ground plane. The hat PCB will probably be designed to serve as the ground plane but can be affected by large metal objects. There could also be something wrong with the hat (PCB} itself.
The best would be to also test the TTIG with a different node and test the node with a different (nearby) gateway.
You can check gateway traffic in the console for RSSI and SNR values of uplink messages received by the gateway.
Depending on source and quality, the antenna might be OK but it also may not be designed for the frequency you are using it for (but was sold like that) and some Chinese antenna’s are just garbage.
Done some more experiments. In fact not related to the antenna at all. Seems to work just after the gateway has been power-cycled, but not later. My previous results with the gateway in the same room were because I had just plugged it in again. Now with the antenna removed completely, the gateway a few metres distant, I get successful reception once I turn the gateway off and on again.
Not recommended - search forum for many posts on this subject. With no load on ant all RF energy is reflected/dumped int the device output stage potentially risking burn out or atl east degradation that may lead to long term failure… most devices will include a warning to say do not operate without ant connected… best reconnected asap - may be range/connection issue is down to prior operation without ant?