@Batigolle
I can confirm that Pi 3 with Dragino Hat works with the modified boksem code as I described with up and download.
Thanks HaSch
I will try this code with your changes
Has anyone done any dragino + mqtt direct application? the dragino firing the packages to the server on a normal pc via mqtt?
Hi all
I did the test with Raspberry PI3 and Dragino Hat v1.4 and
I confirm that with the changes suggested by @HaSch ,
it works
by also receiving the Downstream Messages !
I made a further modification to the global_conf.json file
For the test I used a sensor with the code .ino taken from the examples folder of tftelkamp / single_chan_pkt_fwd.git,
subsequently modified, to transmit, only on channel 868100000
The default installation on the raspberry, / bokse001 / dual_chan_pkt_fwd
receive the messages only on channel 868300000, so I modified the global_conf.json file
by inverting the values of the two freq and freq_2 fields
from
{ “freq”: 868100000,
“freq_2”: 868300000,
…
to
{ “freq”: 868300000,
“freq_2”: 868100000,
…
Finally,
in the sensor code, to receive the DownStream message,
I added the following line of code, inside the setup () function, before do_send (& sendjob);
// Let LMIC offset for +/- 1% clock error
LMIC_setClockError (MAX_CLOCK_ERROR * 10/100);Hello. Using my LG01P gateway, I am not able to transmit the incoming data (via LoRa) to the server. Someone with similar problem? Each time you transmit different, always forward the same value to the server
Hi all
to implement, a gateway with Raspberry PI3 + Dragino Hat v1.4, which allows to use the Downstream messages, I opened a new Topic where I gathered all the information
LINK TOPIC
Hello Everyone, I’m from India and ordering A Dragino Gateway with 868 Mhz option.
But my node SX1272 sends payload from 865 to 867 Mhz Frequency.
Does Dragino scan the spectrum from 865 to 868 Mhz ?
We have already tested successfully our node device with Kerlink and MultiConnect Conduit with 868 Mhz as they are able to scan and receive from 865 to 868 Mhz range.
And will I be able to receive the data with Dragino 868 Mhz ?
hallo, plz help me, i use lora mini dev + Lora GPS/Hat at same freq (868mhz), and i use sensor node dht 11 humidity, i just can recieve data from lora mini with serial to my laptop, i don’t know how to connect lora mini to lora hat, lora hat is actived and connected to TTN, i use single channel pkt fwd, please help me give me a sketch or anything how to connect lora mini + lora hat and get the sensor data…
Hey, I managed to solve this issue by resetting the frame counters on the device settings in the TTN console (Overview tab). After the counter reset, the node status changes and the TTN begins logging the payload data once again.
Hi Everyone, i have build a Single Chan Gateway with the Dragino Lora GPS Hat and the Packet Forwarder by Telkamp (https://github.com/tftelkamp/single_chan_pkt_fwd) and connected it to TTN. (I know this forwarder is deprecated) Im receiving packets from some Node, but on the TTN Console it doesnt show any transfered Data in the “Traffic” Section, it is empty.
I already checked the UDP connection, which seems to be fine. TTN is definetly getting the status msgs with the gps data. (Shows the location of the Gateway on the map, at least on the TTN mainpage https://www.thethingsnetwork.org)
The “Received Messages” counter on the console only shows 2, even though I received much more packets with the gateway.
Does anyone know why there is nothing listed on the “Traffic” section on the TTN console?
And does anybody know how to fix it?
Thank you guys very much.
How are you sure you are actually receiving more packets with the gateway than the 2 Received Messages that your counter shows? If you are referring to the output that you see in the terminal after starting the Single_Chan_Pkt_Fwd routine on your RaspberryPi that isn’t always packets being received. I don’t have access to my Pi at the moment but you will see periodic updates in terminal that are just the Packet Forwarder routine running through it’s loop but unless you’ve actually received something it won’t show up as traffic on the Console.
Yes, I’m pretty shure about that. 
Ok, so you’re using the dual_chan_pkt_fwd now and not using the single channel packet forwarder you alluded to in your other post. It could be the problem here if things weren’t set up right but you are still right that you have apparently received packets. Are you using the Dual Channel setup that Batigolle has used?
The next assumption is that the reason you’re not seeing it in TTN is that the packet is not meant for TTN. I pick up random packets here in Montreal that I know do not show up in my Gateways count, as I can pretty much guarantee that that count number I see are all messages from my sensors. At least on my test gateway as it’s not that high of a number.
Thanks a lot for your concerns. Right now Im using the Dual Channel Packet Forwarder that Batigolle introduced in the forum, but its based on the Single Channel Packet Forwarder by Telkamp.
I thought that unknown Packets from different Networks than TTN are also received and processed by the servers and then dumped.
I’m wondering why the TTN Console shows 2 received msgs but doesn’t show any information in the Traffic section.
Next week the hardware for my node and a real LoRaWAN Gateway Module should arrive, then I can continue testing the TTN.
Ok good luck, I had the same issues at first with my LG-01 that I had bought initially but was able to make it work well enough. Haven’t had this issue with the LoRa Hat that I had tested though. Hopefully with your node and real Gateway you’ll have an easier time.
Hello, I’ve created a loRaWAN Gateway using a Raspberry Pi 3 and a LoRa Sheild, it works fine. Then I tried to send data to this gateway using a node made of: Arduino, Lora Shield and sensors (DHT22 and tsl2561). First, I send a basic “Hello World” message using this code (https://github.com/matthijskooijman/arduino-lmic/blob/master/examples/ttn-abp/ttn-abp.ino). It worked fine. But, When I tried to send DHT22 data (temperature and humidity) I couldn’t. The last thing I tried is to use this code (https://github.com/goodcheney/TTN_Mydevice/blob/master/DHT11_Mydevice), I’ve made some changes (the DHT22 declaration and the reading). But I’ve always that payload: 01670000026800 which is not the data I’ve wanted. What is wrong with my code? Is there any other way to send data properly to the gateway? Please, I need your help. Thanks.
1 Like
Hi @airichi
did you change the decode code, to read the hexadecimal string and convert it back to numbers, on the application where the node is registered?
defauly the decode code in payload formats, reads a hexadecimal string and converts it to text
That hex value is in your code you linked to on line 18, if you remove or comment out that line what do you see from your node? Remember to make sure that the rest of your mydata lines are appropriately setup properly if you do that.
I’d also suggest maybe looking at this code, to see how he uses a DHT sensor with the LMIC library. Even though it’s not the same device the code might be helpful to you.
Hello @Batigolle thank you for your reply!
I know that the default code is in Hexadecimal,initlora I convert it manually to ascii to check if the correct message has been send.
Thank you @glbaum, this is my code:
#define DHTPIN A0
#define DHTTYPE DHT22
DHT dht(DHTPIN, DHTTYPE);
float temperature,humidity;
float tem,hum;
unsigned int count = 1; //For times count
String datastring1="";
String datastring2="";
String datastring3="";
static uint8_t mydata[7] = {0x01,0x67,0x00,0x00,0x02,0x68,0x00};
/* LoRaWAN NwkSKey, network session key
This is the default Semtech key, which is used by the prototype TTN
network initially.
ttn*/
static const PROGMEM u1_t NWKSKEY[16] = { 0xDA, 0x8E, 0x60, 0xD4, 0x9A, 0x40, 0x7C, 0x68, 0x46, 0x57, 0x0D, 0xFD, 0x63, 0xE2, 0x8E, 0x48 };
/* LoRaWAN AppSKey, application session key
This is the default Semtech key, which is used by the prototype TTN
network initially.
ttn*/
static const u1_t PROGMEM APPSKEY[16] = { 0x31, 0x24, 0x5B, 0xD6, 0x28, 0xAE, 0xF9, 0x9F, 0x90, 0x54, 0x53, 0xF5, 0x8A, 0xD2, 0xBD, 0xA9 };
/*
LoRaWAN end-device address (DevAddr)
See http://thethingsnetwork.org/wiki/AddressSpace
ttn*/
static const u4_t DEVADDR = 0x26011300 ;
/* These callbacks are only used in over-the-air activation, so they are
left empty here (we cannot leave them out completely unless
DISABLE_JOIN is set in config.h, otherwise the linker will complain).*/
void os_getArtEui (u1_t* buf) { }
void os_getDevEui (u1_t* buf) { }
void os_getDevKey (u1_t* buf) { }
static osjob_t initjob,sendjob,blinkjob;
/* Schedule TX every this many seconds (might become longer due to duty
cycle limitations).*/
const unsigned TX_INTERVAL = 10;
// Pin mapping
const lmic_pinmap lmic_pins = {
.nss = 10,
.rxtx = LMIC_UNUSED_PIN,
.rst = 9,
.dio = {2, 6, 7},
};
void do_send(osjob_t* j){
// Check if there is not a current TX/RX job running
if (LMIC.opmode & OP_TXRXPEND) {
Serial.println("OP_TXRXPEND, not sending");
} else {
dhtTem();
// Prepare upstream data transmission at the next possible time.
// LMIC_setTxData2(1,datasend,sizeof(datasend)-1,0);
LMIC_setTxData2(1, (byte *)mydata, sizeof(mydata), 0);
Serial.println("Packet queued");
Serial.print("LMIC.freq:");
Serial.println(LMIC.freq);
Serial.println("Receive data:");
}
// Next TX is scheduled after TX_COMPLETE event.
}
void onEvent (ev_t ev) {
Serial.print(os_getTime());
Serial.print(": ");
Serial.println(ev);
switch(ev) {
case EV_SCAN_TIMEOUT:
Serial.println("EV_SCAN_TIMEOUT");
break;
case EV_BEACON_FOUND:
Serial.println("EV_BEACON_FOUND");
break;
case EV_BEACON_MISSED:
Serial.println("EV_BEACON_MISSED");
break;
case EV_BEACON_TRACKED:
Serial.println("EV_BEACON_TRACKED");
break;
case EV_JOINING:
Serial.println("EV_JOINING");
break;
case EV_JOINED:
Serial.println("EV_JOINED");
break;
case EV_RFU1:
Serial.println("EV_RFU1");
break;
case EV_JOIN_FAILED:
Serial.println("EV_JOIN_FAILED");
break;
case EV_REJOIN_FAILED:
Serial.println("EV_REJOIN_FAILED");
break;
case EV_TXCOMPLETE:
Serial.println("EV_TXCOMPLETE (includes waiting for RX windows)");
if(LMIC.dataLen) {
// data received in rx slot after tx
Serial.print("Data Received: ");
Serial.write(LMIC.frame+LMIC.dataBeg, LMIC.dataLen);
Serial.println();
}
// Schedule next transmission
os_setTimedCallback(&sendjob, os_getTime()+sec2osticks(TX_INTERVAL), do_send);
break;
case EV_LOST_TSYNC:
Serial.println("EV_LOST_TSYNC");
break;
case EV_RESET:
Serial.println("EV_RESET");
break;
case EV_RXCOMPLETE:
// data received in ping slot
Serial.println("EV_RXCOMPLETE");
break;
case EV_LINK_DEAD:
Serial.println("EV_LINK_DEAD");
break;
case EV_LINK_ALIVE:
Serial.println("EV_LINK_ALIVE");
break;
default:
Serial.println("Unknown event");
break;
}
}
void setup() {
// initialize digital pin as an output.
Serial.begin(9600);
while(!Serial);
Serial.println("Connect to TTN and Send data to mydevice(Use DHT11 Sensor):");
#ifdef VCC_ENABLE
// For Pinoccio Scout boards
pinMode(VCC_ENABLE, OUTPUT);
digitalWrite(VCC_ENABLE, HIGH);
delay(1000);
#endif
// LMIC init
os_init();
// Reset the MAC state. Session and pending data transfers will be discarded.
LMIC_reset();
/*LMIC_setClockError(MAX_CLOCK_ERROR * 1/100);
Set static session parameters. Instead of dynamically establishing a session
by joining the network, precomputed session parameters are be provided.*/
#ifdef PROGMEM
/* On AVR, these values are stored in flash and only copied to RAM
once. Copy them to a temporary buffer here, LMIC_setSession will
copy them into a buffer of its own again.*/
uint8_t appskey[sizeof(APPSKEY)];
uint8_t nwkskey[sizeof(NWKSKEY)];
memcpy_P(appskey, APPSKEY, sizeof(APPSKEY));
memcpy_P(nwkskey, NWKSKEY, sizeof(NWKSKEY));
LMIC_setSession (0x1, DEVADDR, nwkskey, appskey);
#else
// If not running an AVR with PROGMEM, just use the arrays directly
LMIC_setSession (0x1, DEVADDR, NWKSKEY, APPSKEY);
#endif
// Disable link check validation
LMIC_setLinkCheckMode(0);
// TTN uses SF9 for its RX2 window.
LMIC.dn2Dr = DR_SF9;
// Set data rate and transmit power (note: txpow seems to be ignored by the library)
LMIC_setDrTxpow(DR_SF7,14);
// Start job
do_send(&sendjob);
}
void dhtTem()
{
// Lecture du taux d'humidité
float h = dht.readHumidity();
// Lecture de la température en Celcius
float t = dht.readTemperature();
Serial.print("########### ");
Serial.print("NO.");
Serial.print(count);
Serial.println(" ###########");
Serial.println("The temperautre and humidity :");
Serial.print("[");
Serial.print(t);
Serial.print("℃");
Serial.print(",");
Serial.print(h);
Serial.print("%");
Serial.print("]");
Serial.println("");
count++;
////memcpy (mydata,&t,4);
int16_t t1=(t*10);
mydata[2] = t1>>8;
mydata[3]=t1;
mydata[6] = h * 2;
}
void loop() {
os_runloop_once();
}
Do I have to initialize mydata at the same time I read data from my sensor?
Thank you for the code, I’ll try to use the same methods.
This is the payload in that packet that you are seeing and what I was referring to in my earlier post. So from the looks of it you are not replacing that value with the appropriately acquired values from the DHT sensors farther down in your code. It was also why my suggestion to you was to omit or comment out that line of your code to see if you see a different payload being sent. Assuming the rest of your code is correct and I apologize, I haven’t looked over it all very carefully, you should see a different payload being sent.
One last thing, from the code I shared this is something that I think you should look at:
char packet[30] = "";
// Get temperature event and print its value.
sensors_event_t event;
dht.temperature().getEvent(&event);
if (!isnan(event.temperature)) {
char floatStr[10];
dtostrf(event.temperature, 3, 2, floatStr);
strcat(packet, "Temp: ");
strcat(packet, floatStr);
strcat(packet, "*C\n");
} else {
Serial.println("Error reading temperature!");
}
// Get humidity event and print its value.
dht.humidity().getEvent(&event);
if (!isnan(event.relative_humidity)) {
char floatStr[10];
dtostrf(event.relative_humidity, 3, 2, floatStr);
strcat(packet, "Humidity: ");
strcat(packet, floatStr);
strcat(packet, "%");
} else {
Serial.println("Error reading humidity!");
}
if (!strlen(packet)) {
// Don't send empty packet
return;
}
In your code besides that default value on line 18, you are then using mydata three separate times with varying lengths mydata[2], mydata[3], and mydata[6] unless I missed it somewhere else, if you do see a different payload by removing line 18, it will most likely be the value stored in mydata[6] and not all of the data that you want.