Like at the moment? No. My home is aproximatelly 3.7km away from the nearest gateway so I can not do testing from here. I already tested it a couple of times before very close to the gateway. Now, I’m trying to get more information so I’ll be prepared next time.
I have that. I have the aplication. I have the device EUI consisting of the MAC adress which came in the box with the 32u4. I have the activation method set to ABP. I have the frame counter width set to 16 bits. I have disabled the frame counter checks. I have copy-pasted the credentials into my code. I have it set up.
Hmm, I thought I would see a blue triangle and some data on the console if it’s working.
My idea would be to try and contact someone from the local community, maybe even the gateway owner close to you.
All TTN’ers are nice guys ( ) So maybe a community member could help you test your node.
Just send them a PM… its worth a try
So, for LMIC the wire to pin 6 (or another pin of your choice) is needed to detect a RxTimeout; without it, LMIC will probably hang after an uplink, when it’s trying to determine if there’s any downlink in RX1 or RX2.
I’d guess TinyLoRa does not support downlinks at all?
So, (very) long story short: when using LMIC on the 32u4 I’d say you’ll need the jumper wire as well. (But I’ve not used the Adafruit boards, nor TinyLoRa.)
“Privilege” doesn’t seem to be the correct translation for what you’re trying to say, but when far away from the gateway, indeed use SF12, which is the slowest transmission speed with the best range. Using SF12 the transmission will take a lot longer (so you can send far fewer packets per hour) but chances that a gateway receives the transmission are better. When SF12 works, go down to SF11 and so on.
Also, as long as you’ve not received anything: put the device as high as possible, outside, to improve the chances of a gateway receiving the transmission. And check the length of your antenna wire.
So: do you know how to set the device to use SF12 for your first tests?
Still then: if possible, then LMIC is better, as OTAA is better than ABP, and LMIC supports ADR. But as OTAA needs a downlink for the Join Accept and as you don’t have access to any gateway logs, starting with ABP is better now. And the Adafruit tutorial looks great, so I’d say that starting with TinyLora (which only supports ABP) seems fine too.
That’s correct when using ABP.
Also correct for ABP; blue upward icons denote uplinks. (For OTAA, you’d first see orange and green icons for the Join Request and Join Accept, if all is well, where the green icon is only shown in the gateway’s Traffic page, which you cannot see.)
As an aside: Adafruit’s Decoder for a TTN Payload Format does not support negative values. If you ever get to that point, then see Negative Temperature.
I am sure I am not alone. I live in EU, I successfully use a couple of Feather clones (the BSFrance version). However, I am using LMIC, not TinyLora that apparently does not allow downlinks. LMIC is large but it leaves sufficient room for a temperature sensor library, or GPS, and is used by a lot of people, so it is easier to find help. And jumper is needed.
Just to be sure, so you changed it, right? So it’s:
//#define US902 ///< Used in USA, Canada and South America
#define EU863 ///< Used in Europe
Also, I don’t know how easily the Arduino IDE detects changes in libraries; you may want to do some full compilation.
Not related to your problems:
I’ve no idea. For outdoor gateways you’ll always have line of sight from the sky. (Though the antenna orientation might not be optimal?) Beware that the range might be quite far then, and that you’re using a radio spectrum shared with others. Many others when transmitting from a high location.
Also, with SF12 you cannot send every 5 seconds (or every 6 seconds, given the 1 second delay for the LED): even when doing the experiment for only an hour, a 2 bytes application payload only allows for 25 messages on SF12 on the TTN Fair Access Policy, and only one message every 2 minutes for the maximum duty cycle regulations. LMIC will enforce the latter but not the former. TinyLoRa does not enforce anything. Finally, a hardcoded SF11 or SF12 is not allowed. (But I assume it’s just an experiment, not something you’d be using on a regular basis?)
For the very same reasons: while testing your code from home, if SF12 works, I’d surely go down to try better data rates if possible.
Also, TinyLoRa always transmits at maximum power; I don’t know what that maximum is, and if it’s within EU limits. All said, when using TinyLoRa then one’s own code needs to ensure one plays nice in the shared radio network.
But what if SF10 won’t be enough? Is there a way to change the SF value automatically? The thing has to work because once in the air, I can not reupload the code.
But I assume it’s just an experiment, not something you’d be using on a regular basis?
Well, I’m launching the balloon just once, but that can stay in the air and try to send the data for up to a couple of weeks so it will be sending many packets.
All said, when using TinyLoRa then one’s own code needs to ensure one plays nice in the shared radio network.
I’m fine with it sending data every hour or even once in a day. The tracker is for a contest, winner is the one which lasts longest. I really don’t care about the data, we just need to know if the tracker is still alive.
Thanks to your support, I got it working. Now I have it working using the “MCCl LoRaWAN LMIC” library and with a jumper.
Now I’m rushing to complete the tracker because the contest is in four days.
I’ve got a problem. I’m trying to encode a float into the message. I’m using the “ttn-abp-feather-us915-dht22”. There is a unknown command on the line 195. It’s “LMIC_f2sflt16(input);”. The compiler complains about it. When I googled it, it gave me like 7 results. Everything else about the code is fine. Any ideas?
The -1 in the last line is for sending null-terminated string values. (Which is very much discouraged.) For that, the terminating null-character does not need to be sent. In your case, remove the -1, so:
Also, I have a problem. The code needs to be very energy-effecient. I need to replace “delay(x);” with “Watchdog.enable(x)” so the processor will be dissabled. But when I look at the lmic code, there is no delay there. Just: “const unsigned TX_INTERVAL = 30”. I know that the delay function is located somewhere deep in the library. I couldn’t find it. I just need help locating it so I can replace it with the Watchdog function. That should work, right?
Unlikely you will find a single delay corresponding to TX_INTERVAL. LMIC schedules processes at specific times, and your transmission is only one of them (disclaimer: I have a vague knowledge of its internals).
One way to introduce sleep/delays is to escape from the main execution model. There is some example where delays and sleep are put just after the TX_COMPLETE event, but during sleep also internal time is not updated so some workaround is needed to avoid that transmission is further delayed to satisfy duty cycle limitations (though if you send every hour it might not be problematic).
You may also use an external RTC to switch on/off the board when needed…
I got the Adafruit feathers to work with both LMIC and TinyLora. Let me know if you still need help. This tutorial covers it well, with the only exception that it doesn’t mention that you have to change region (default is US, I am EU).
Thanks to your support we managed to get it working in time. We were second in the picoballoon contest. We published a YouTube video and an Instructable regarding this, and we won the runner up prize with it. Thank you!