What does the serial output show you - I’m betting it is:
Received 2 bytes of payload
as that’s what you have sent - two bytes, and you’ve coded to check for 1. So why the 0? But I agree, it’s not clear what you put in the various boxes - suffice to say, it’s not hex and it translates whatever characters you enter in to binary.
So, to speed things up, that 1 will actually be turned in to 49 which is the decimal for the character 1. You may want to Serial.print the result so you can see what you actually receive.
Yes, I could see, I’m asking if that message comes up in the serial console when you send an uplink (which proves the LMIC stack thinks it has sent) and suggesting that you Serial.println the LMIC.datalen value without the if statement so we can see if you are getting the downlink, even if it is longer than you expect.
Assuming TTN Console (or some gateway log) showed that a downlink should have been transmitted, you need to figure out why your device is not receiving it. You can start by adding the following to the setup, for example after the line for LMIC_setDrTxpow:
// Make LMIC start its RX windows a bit earlier, and listen longer, to
// compensate for an inaccurate clock.
//
// Beware that a specific value may work for a slow data rate, but not
// for faster ones, and remember that RX1 may use different data rates
// than RX2. Like for some tests, RX2 in EU868 (using SF9) worked with
// the standard settings, but RX1 for SF8 needed 2%, while RX1 for SF7
// even needed 5% of the maximum error. For corrections exceeding 0.4%
// (0.4 / 100) this also needs LMIC_ENABLE_arbitrary_clock_error; see
// https://github.com/mcci-catena/arduino-LMIC/blob/master/README.md
LMIC_setClockError(MAX_CLOCK_ERROR * 5 / 100);
Be sure to read the link mentioned in the comment above; the example value of 5% is much higher than the 0.4% mentioned in that documentation. So, you’ll need to set the compile-time flag LMIC_ENABLE_arbitrary_clock_error, or when using the Arduino editor, set the flag in the file Arduino/libraries/MCCI_LoRaWAN_LMIC_library/project_config/lmic_project_config.h
Also note the following comment in LMIC’s source code:
as at this stage, we don’t even know if the device is actually transmitting.
And then please please please confirm that you are seeing the transmitted data in the web console - as that will confirm that all the transmission settings are correct.
I am seeing my transmitted data both on the serial monitor and on the web interface,
when i send downlink i also see it scheduled. but it will not get to the node…
Only in the gateway’s Traffic page, or also in the application/device’s Data page? Only when you see it in the Data page in TTN Console, you know for sure that the device’s configuration matches the secrets that TTN knows, and that TTN has accepted the value of your uplink counter. (The latter check may be disabled, for testing.)
Here, it’s the other way around: are you only seeing it in the application/device’s Data page, or also in the gateway’s Traffic page? (Or even in the gateway’s log files?) Screenshots will help confirm all this.
Morning @cherechi, I think we are really close to solving this.
As Arjan said, just for peace of mind because the downlink will never work if the credentials aren’t correct, can you confirm that you are seeing the uplink on the Device’s Data tab - note, this only shows real time, so you won’t see anything until there is an uplink whilst the page is open.
I use almost exactly the same code base for Arduino 328P + RFM95 setups so I am quite familiar with the issues - it took me a while to get things going but once I did, it works nicely. Whilst you check the console, I’ll get one out so I can dip in to the code myself.
Thanks alot for your concern, I do get the uplinks on the data tab, also i do see the downlinks on the gateway log as shown in the image below as it is sent at 869.525MHz but it never arrives at the node to turn on the LED. But this morning, I tried sending a downlink, my node recieved it and the LED was turned on. now i cannot turn it off anymore as the dowlink will not get to the node again
So we know it can work, we just need to make it work more reliably, so I’d look at Arjan’s comment about the timing tuning:
But also, as I should have mentioned sooner, you should limit downlinks as they render the gateway totally deaf whilst transmitting. So what is the LED for? Can it operate locally?
let me ask this question, If I have a server such as chirpstack installed locally on my gateway with the need to transmit to the things network, will i be able to send more frequent downlinks. this downlink is supposed to be sent for control purposes. such as alarm or control a servo…
If you have your own network & application server then you will only be limited by your local laws / regulations for transmissions as you won’t be using TTN.
However if you have your own server, then you won’t be on TTN so you will need to have a reliable server & internet connection.
Thank you so much for this reply, you have been very helpful. so back to the LED. since i can only send 10 downlinks in 24 hours, i just want to confirm that my downlink can turn on and off the LEDS. this will not be up to 10 dowlinks.
TTN fair use policy is for 10 downlinks per 24 hour period per device.
What you send and what it does is entirely up to you - LEDs, pump, MP3 player, siren and so much more.
But you should consider the consequences that the device happens not to transmit & therefore receive on the schedule you expect or does, but doesn’t get the downlink. So nuclear reactors etc aren’t a good idea.
@cherechi I find this discussion very helpful, one point of interest - AnalogRead by default returns a float and in your example you’re using uint32_t as the return value from AnalogRead - that’s 4 bytes for float compared to 2 for uint32_t
Isn’t there an issue of accuracy meaning being cable to capture the entire range of the ADC?
Also if I may share - I have found that doing the match is much easier with a decoder function rather than do it at firmware level. TTN has awesome decoder capability. My example below does the same thing on a 3.3v board:
function Decoder(bytes, port) {
var decoded = {};
bytes[2];
decoded.battery_voltage =
((bytes[0]*256+bytes[1])*2)*0.0032258064516129;
return decoded;
}
