Remove the shield then program the Mega
I’m using an Arduino Uno with a Dragino lora had (RF96) for the US, it should be 915000000. My Raspberry Pi on the other Dragino hat is pinging TTn.
I am using the LMIC libraries, and a hello world sketch pin mapped:
// Pin mapping
const lmic_pinmap lmic_pins = {
.nss = 10,
.rxtx = LMIC_UNUSED_PIN,
.rst = 9,
.dio = {2, 6, 7},
};
and LMIC config.h
#define CFG_us915 1
// This is the SX1272/SX1273 radio, which is also used on the HopeRF
// RFM92 boards.
//#define CFG_sx1272_radio 1
// This is the SX1276/SX1277/SX1278/SX1279 radio, which is also used on
// the HopeRF RFM95 boards.
#define CFG_sx1276_radio 1
when i connect the node and check the serial output i get this:
Starting
Packet queued
903900000
211338: EV_TXCOMPLETE (includes waiting for RX windows)
Packet queued
903900000
4182735: EV_TXCOMPLETE (includes waiting for RX windows)
am I not on the right frequency?
Using Dragino hat. I have followed along with several tutorials/write-ups and still unable to connect. Showing:
It looks like you are trying to register a gateway by EUI. This probably means you are using the legacy packet forwarder.
Status
not connected
Frequency Plan
United States915MHz
Router
ttn-router-us-west
Is it a must to use basic_pkt_fwd? If so, where to I put these .h, .c files? Do I add them to main.cpp? I am new to this and trying to learn. Any help will be appreciated. Thank you
Thank you. I have used this one and several others. Trying from home now and still will not connect. Any suggestions?
Hi everybody,
I built a single channel gateway with Dragino LoRa Pi hat and RPi 3 and connected it to the TTN. It seems to work fine, in serial console I can see messages like this:
SX1276 detected, starting.
Gateway ID: b8:27:eb:ff:ff:dd:f8:f7
Listening at SF7 on 868.100000 Mhz.
------------------
stat update: {"stat":{"time":"2017-06-17 10:59:28 GMT","lati":50.69827,"long":6.09635,"alti":274,"rxnb":0,"rxok":0,"rxfw":0,"ackr":0.0,"dwnb":0,"txnb":0,"pfrm":"Single Channel Gateway","mail":"hans.schneider@gmx.ch","desc":"built with RPi 3 and LoRa/GPS hat"}}
stat update: {"stat":{"time":"2017-06-17 10:59:58 GMT","lati":50.69827,"long":6.09635,"alti":274,"rxnb":0,"rxok":0,"rxfw":0,"ackr":0.0,"dwnb":0,"txnb":0,"pfrm":"Single Channel Gateway","mail":"hans.schneider@gmx.ch","desc":"built with RPi 3 and LoRa/GPS hat"}}
stat update: {"stat":{"time":"2017-06-17 11:00:28 GMT","lati":50.69827,"long":6.09635,"alti":274,"rxnb":0,"rxok":0,"rxfw":0,"ackr":0.0,"dwnb":0,"txnb":0,"pfrm":"Single Channel Gateway","mail":"hans.schneider@gmx.ch","desc":"built with RPi 3 and LoRa/GPS hat"}}
Packet RSSI: -72, RSSI: -114, SNR: 9, Length: 23
rxpk update: {"rxpk":[{"tmst":3505585321,"chan":0,"rfch":0,"freq":868.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9,"rssi":-72,"size":23,"data":"ABNSAPB+1bNwzMgeAAujBAA1GWNudvI="}]}
After that I commissioned my LoRa KISS from E&A Utrecht by hand and tried to get it connected with the new single channel gateway. Of course I did the needed changes in the sketch like OVERRIDE = true, set my appEUI and appKey. I tried with several SF but unfortunately it doesn’t work at all. I got messages like this:
--- Resetting RN module
Model: RN2483
Version: 1.0.1
Sending: mac set deveui 0004A30B001EC8CC
Sending: mac set adr off
--- Random Seed
-- hwEui read from module: 0004A30B001EC8CC
-- seed: 52364
--- I2C Accelerometer initialized
Sending: mac set rx2 3 869525000
Sending: mac set ch drrange 1 0 6
Sending: mac set ch dcycle 0 799
Sending: mac set ch dcycle 1 799
Sending: mac set ch dcycle 2 799
Sending: mac set ch dcycle 3 799
Sending: mac set ch freq 3 867100000
Sending: mac set ch drrange 3 0 5
Sending: mac set ch status 3 on
Sending: mac set ch dcycle 4 799
Sending: mac set ch freq 4 867300000
Sending: mac set ch drrange 4 0 5
Sending: mac set ch status 4 on
Sending: mac set ch dcycle 5 799
Sending: mac set ch freq 5 867500000
Sending: mac set ch drrange 5 0 5
Sending: mac set ch status 5 on
Sending: mac set ch dcycle 6 799
Sending: mac set ch freq 6 867700000
Sending: mac set ch drrange 6 0 5
Sending: mac set ch status 6 on
Sending: mac set ch dcycle 7 799
Sending: mac set ch freq 7 867900000
Sending: mac set ch drrange 7 0 5
Sending: mac set ch status 7 on
Sending: mac set pwridx 1
Sending: mac set retx 7
Sending: mac set dr 5
Sending: mac join otaa
Join not accepted: denied
Check your coverage, keys and backend status.
Sending: mac join otaa
Join not accepted: denied
Check your coverage, keys and backend status.
Sending: mac join otaa
Join not accepted: denied
Check your coverage, keys and backend status.
Sending: mac join otaa
Join not accepted: denied
Check your coverage, keys and backend status.
Sending: mac join otaa
Response is not OK: no_free_ch
Send join command failed
I even deleted the device in TTN console and created it new with new appEUI and appKey. I also did a gateway reset and started it again but the result is always the same. Gateway and LoRa Kiss are in the same room so it isn’t a coverage problem. The gateway is connected.
What went wrong? Any suggestions?
Hans
‘Packet RSSI: -72, RSSI: -114, SNR: 9’
I think your RSSI is to high. I was not able to see node packets if RSSI wasn’t in the -40 to -50 range. Try setting your SNR to 7 in the gateway.
Can anybody tell me how to set SNR in single_chan-pkt-fwd?
I set the number of join retries to -1 because I want to retry indefinatly (RETRIES = -1).
I get the message that there is no free channel and my KISS LoRa Gadget can not join. What is blocking my single channel? I have only this device and no other is present.
Does the gateway console show up- and downlink packets for your gateway?
No, it doesn’t show up- and downlink packets. What is going wrong and better: How can I fix it?
No up- and downlink packets means your gateway is not receiving data. Make sure the settings of your node match the settings of the gateway, which means the node should transmit using SF7 (dr5) on 868.1 MHz.
As you are using a RN2483 based node which is setup to use 8 channels (looking at the log you posted earlier) there is a 1 in 8 chance the randomly chosen channel will match your limited gateway. (There is a reason full gateways use 8 channels 
)
As the gadget retries the joins with a minimal (too small) delay it will hit the airtime limits within a few retries and you’ll likely need a lot of retries.
I haven’t looked at the code for the gadget (yet) but first thing I would try is to increase the amount of time between join attempts to 1 minute. Next make sure there is at least 3 meters between the gateway and the gadget, power on the gadget and be patient… (open the gateway console and check if any traffic is listed after about 1 hour)
1 Like
Thank you for the suggestion but it seems not to work.
The KISS LoRa is now trying to join for about 12 hours (RETRIES = -1) and I still can’t see any data coming in. SF is 7, both KISS and single channel gateway.
So now it is time to figure out which is the problem, your node or your gateway. Either go with your node to a working gateway or get a working node near your gateway.
1 Like
It’s not as easy as it sounds. The coverage in my region is really bad and I have to drive a long way to find a gateway.
Now I can see data coming in at console of gateway. But if I switch to console of device I can’t see anything. And it looks like the node is always trying to join.
I don’t know the KISS LoRa, but the LMIC European implementation starts trying to join using SF7 on a random channel (one of the three join frequencies). From there on it tries the next channel. After the last channel (channel 2) it increases the SF and starts with the first channel again, until the last channel on SF12 is tried.
If your single channel gateway listens on channel 0 SF7 there is a chance of two in three that no join is atempted on your gateway.
So maybe it is better to configure your gateway to use channel 2 (the last join frequency) and SF7. No matter on what random channel the joining starts, it will hit your gateway’s frequency and SF…
P.S. this only makes sense if the KISS LoRa uses the same join strategy as LMIC…
What data are you seeing in the gateway console?
I can see these lines while watching terminal output of single_chan_pkt_fwd:
and these lines coming in in TTN console:
Does your single channel gateway even support downlinks? (OTAA needs downlinks.) TTN Console does not show your gateway was commanded to send a response; unless the Join Request is also received by other gateways and TTN tells another gateway to send the response, it should really show a Join Accept with a timestamp 5 seconds or 6 seconds after the request:
Not seeing the Join Accept being sent to the gateway could also mean TTN does not accept your request (like due to invalid keys or unknown device).
Also: it’s weird to see each Join Request twice in your screenshot. See Single message shown multiple times for different channels and RSI in rxpk of IC880a gateway log for which the problem was the antenna connector. You might also want to make sure there’s at least a few meters distance between your node and gateway.
1 Like