Cool, are you also using an RF95 with the mini?
whats your sketch code look like?
Probably unrelated to the Join problems, but your DevEUI DDDDDDDD... does not seem to be a proper EUI. From the specifications, emphasis mine:
6.2.1 End-device identifier (DevEUI)
The DevEUI is a global end-device ID in IEEE EUI64 address space that uniquely identifies the end-device.
If your device does not provide a proper EUI then better let TTN Console generate one for you.
That said, the screenshot of your gateway shows that TTN sent a Join Accept to the gateway, so somehow either the gateway was not transmitting that, or the node did not receive it. Make sure there are at least a few meters between node and gateway. And for LMiC, search this forum for MAX_CLOCK_ERROR.
(Also, I guess you know you should not send text.)
@jezd
I used the sketch generator at https://lcd-web.nl/ttngenerator/ . Hope he will add more sensors in the future.
@arjanvanb
Thank for pointing me to look back again about DevEUI. Now, I find the way to let TTN generate it for me. First, I thought there wasn’t auto gen. I also found the problem why my script did not join in the first attempt. The gateway freq is AS1 while my node is AS2. My friend modified LMIC and changed name to AS923_Upper that I thought it is AS2. In fact, it is AS1 freq. When I set to the right freq, it can join in a few seconds.
Changing a text message to a Hex string will take me some time because I am not a real programmer. I might ask someone around here to help me.
2 Likes
The examples in the sketch generator already send sensor data in a proper way. Like when selecting “Moisture, Temp and Light” then you’ll see:
void build_data() {
dataTX[0] = (light << 4) | (tempK / 256);
dataTX[1] = tempK;
dataTX[2] = moisture / 256;
dataTX[3] = moisture;
}
This sends a total of 4 bytes (32 bits) for 3 sensors:
- 4 bits for light in a scale from 0 to 15 (hexadecimal
0x0-0xF) - 12 bits for temperature in Kelvin with one decimal, in a scale from 0.0 to 409.5 (
0x000-0xFFF) - 16 bits for moisture in a scale from 0 to 65535 (
0x0000-0xFFFF)
If you’d send that as human-readable text, you’d need many more bytes (like 14 characters, so 14 bytes, when sending separated with semi-colons as 15;409.5;65535, or 0x31353B3430392E353B3635353335 when displayed as hexadecimal ).
It even explains how to decode:
/* **************************************************************
* build data to transmit in dataTX
*
* Suggested payload function for this data
*
* var light = (bytes[0] & 0xF0) >> 4;
* var temp = (((bytes[0] & 0x0F) <<8 | bytes[1]) - 2731) / 10;
* var moisture = bytes[2] << 8 | bytes[3];
*
* return { payload: light + ";" + temp + ";" + moisture };
*
* *************************************************************/
…which you could use to decode and then return the values any way you want:
function Decoder(bytes, port) {
// Test with 0A470000 for 0, -10, 0, or FB78FFFF for 15, 20.5, 65535
var light = (bytes[0] & 0xF0) >> 4;
var temp = (((bytes[0] & 0x0F) << 8 | bytes[1]) - 2731) / 10;
var moisture = bytes[2] << 8 | bytes[3];
return {
light: light,
celcius: temp,
// Unary plus-operator to cast string result of toFixed to a number:
fahrenheit: +(32 + 1.8 * temp).toFixed(1),
moisture: moisture
}
}
1 Like
Thank. It makes my life a lot easier. First glance on those lines in my sketch, I don’t know what they are for.
Recently I facing this problem too and realized it’s all AS1 freq, could you tell me more about your modified LMIC for AS2 freq support?
The gateway must listen on the right frequency exact as your node sends. Check on your gateway first, I use Raspberry PI with RAK831. I choose one of global_conf.json from https://github.com/TheThingsNetwork/gateway-conf and replace the original file in my RPI .
For my node, I changed freq in this file lorabase.h (LMIC library.)
Thanks @Somsak, now GW and nodes completely in synced.
but there is a thing still bugging me out, how to deal with 500Khz_UPFBASE/UPFSTEP and DNFBASE/DNFSTEP for AS2 in lorabase.h file?
// Default frequency plan for US 915MHz
enum { US915_125kHz_UPFBASE = 902300000,
US915_125kHz_UPFSTEP = 200000,
US915_500kHz_UPFBASE = 903000000,
US915_500kHz_UPFSTEP = 1600000,
US915_500kHz_DNFBASE = 923300000,
US915_500kHz_DNFSTEP = 600000 };It’s the other way around.
A gateway will be listening continuously, and on multiple frequencies and spreading factors. A node, however, must listen at the exact same time as the gateway transmits, and using the exact same frequency and spreading factor. (RX1, and RX2 if nothing was received in RX1, both using a specific frequency and spreading factor as defined in the given frequency plan.)
Thank @arjanvanb for making it clear.
@danielpardede In fact, I did not modify lorabase.h by myself.
There is an example on https://github.com/orenonline. Look at “arduino-lmic-as923
Added AS923 code into LMIC”. It might answer what you try to ask.
Somsak
Hi i am also using Arduino Pro Mini +Lmic(otaa) by node is working and serial monitors show
message queued
EV_JOINING
and noting else, may there is no Gateway nearby also my console device status is “not seen”
and data uplink bytes.
What is this problem?? please help
like you wrote … ’ maybe there is no Gateway nearby
so i must have my own gateway???
if you want to be 100% sure to connect to The Things Network… yes.
even if there is a GW nearby (and there is one… see map in your console) it’s not sure that it receives your nodes signal.
and the owner can switch it on/off whenever he wants.
i understand, is there any way to test my device working correctly?
without to be sure that a (TTN !) gateway is within range, is listening and forward your data So you can see in your console’s application tab, that your node is actually transmitting and trying to join the network (yellow thunder) … no that will be difficult.
beside the question of a gateway in range, there could be all kinds of other little 'problems.
be it mechanical … like the antenna.
or electrical… like wrong connections.
or wrong keys in your software setup and application