When i am sending data from lora dragino node .I am not recieving it on ttn server.I am using india frequencies.
This is in breach of the Fair Use Policy by sending so frequnently & probably illegal as well. Please read the Learn section linked top of this page.
Suspending thread pending confirmation of FUP
Ok i will make changes in according to fair use policy .But why i am not getting data on my application .
Please do not post an image if the text can be copied & pasted - console screen shots are OK, but serial logs not so much.
What firmware/stack/code are you using on the Dragino - link to source plus version?
What connection method - ABP or OTAA are you using?
What antenna are you using?
What gateway - make & model - are you using?
Is the gateway hearing the Join Request in the gateway logs?
If so, what RSSI & SNR is reported?
How far apart are the gateway & the device?
If you are using OTAA:
Doe the Join Request appear in the gateway console?
Does the Join Request appear in the device console?
Is there a Join Accept generated?
Does the gateway console show the Join Accept being sent?
Does the gateway logs show the Join Accept being transmitted?
I am using ttn abp code that is present as example in MCCI LoRawan LMIC library with some small changes .connection method is abp .I am using Enthutech lora shield with Semtech SX1276 chip.some times gateway hears the request and i am gettin SF12 ,BW125k,SNR -15.5,RSSI -94 . Gateway is just one meter away from device,
As it’s not Dragino, can you supply a link.
Can you also answer each of the questions in full please for us to be sure, in the mean while here is a informed guess:
Either you don’t have an antenna or it’s not correctly fitted or the radio has been damaged.
Forum search on device not heard will find lots of comments about how LoRa is Long Range - 1m is literally shouting at the gateway so hard it’s probably overloaded. You need 5m and a solid wall separation - if the antenna was good - which it may be because the gateway may be mis-reporting due to the overload.
As you are using ABP your previous screen shot of uplink every few seconds is of concern - things don’t start working by hammering away at the airwaves - please ensure you are using a push to test button - push, evaluate, adjust, repeat.
As you’ve made some ‘small changes’ to the LMIC code, not sure where you got it or what version you are using, can you tell us what those changes are just in case they impact the device.
Please consider that questions are to help you get a resolution, missing out answers makes the process longer and prone to volunteers getting bored.
Here is the link for lora shield–Arduino Shield for LoRa® / LoRaWAN® | Enthu Technology Enthu Technology .I am using the same antenna that comes with kit and its correctly fitted .In the code i added frequencies for india and removed two parts one is
case EV_TXSTART:
Serial.println(F(“EV_TXSTART”));
break;
case EV_TXCANCELED:
Serial.println(F(“EV_TXCANCELED”));
break;
case EV_RXSTART:
/* do not print anything – it wrecks timing */
break;
case EV_JOIN_TXCOMPLETE:
Serial.println(F(“EV_JOIN_TXCOMPLETE: no JoinAccept”));
break;
and the second one is // TTN uses SF9 for its RX2 window.
LMIC.dn2Dr = DR_SF9;
// Set data rate and transmit power for uplink
LMIC_setDrTxpow(DR_SF7,14);
The signal quality suggests otherwise.
Your formatting of code should be with the </> tool. It’s not clear why you’d remove some of the event messages. The SF9 and SF7 settings are OK.
There are many questions un-answered about how far the uplink gets, without which no further progress can be made.
@glv13 Actually in the presence of a very ‘loud’ signal that over loads the system then the antenna might well be correct and well fitted. LoRa almost expects, and is designed for, detecting a low level signal from a significant distance and/or after deep absorber penetration and as such it can effectively ‘ignore’ the major overloading signal and instead detect the minor ‘crossover’/bleed signal and say hey that is more like what is expected and report that! The bleed signal is most likely perceived to be on an adjacent channel also and naturally the overall system then responds on that…but as the node is expecting responce of the same channel as it had shouted loud on it never gets to hear it (unless the close proximity and effectively loud shout back from the GW bleeds the other way at the node, though this is less likely to be picked up - the GW is designed to handle multiple signals on multiple channels and with varying SF’s).
Only real solution and way to eliminate this risk is decent seperation, 5, pref 10+m gap ideally with some absorber in between (wall, thick/double glazed window, etc.) Such that a normal ‘in channel’ signal is in the Goldilocks range (Forum search) for working with LoRa development to avoid ‘debuggung’ RF issues at same time as debugging h/w and/or firmware issues…