Why is that a bad thing? The 433-866MHz range is ideal for the low power, long range and low throughput technology LoRaWAN is.
It also depends on where you live. I have no knowledge of any countries that limit you to 433MHz.
Why is that a bad thing? The 433-866MHz range is ideal for the low power, long range and low throughput technology LoRaWAN is.
It also depends on where you live. I have no knowledge of any countries that limit you to 433MHz.
ā Georgetown is Guyanaās capital, on South Americaās North Atlantic coast.
Iām from Guyana, a country in South America, so it will be the 1st one set up in the country! TBH Iām hoping to make a LoRaWAN system as my final year project as a cheap solution for smart/IoT interconnectivity
Well largely because I was worried about TTN support, thatās why I said it was bad lol
Cool! Welcome to The Things Network community! Letās build this thing together!
It will be a bit more challenging than in some other countries though. Youāll have to do some research into what hardware you need, find out where to buy it, and you will probably run into strange issues as we havenāt had many people test our 433MHz support. But if youāre up for the challenge, youāll help a lot of people in other countries too
Thanks and glad to be a part of the community and i will definitely be back here once i start my build
Hello, me and my thesis mates are also planning to connect our gateway via TTN. However, we got a Heltec ESP32 board which has a 433 MHz band. I already registered my device but when I run our Arduino code itās stuck in
Packet queued
3240: EV_JOINING
Do you have any documentation in using 433MHz as TTN nodes?
Maybe also tell us which country youāre in.
@htdvisser are you saying that for example here in the Netherlands, you expect gateways to also receive signals at 433 Mhz? (or that they can be set to receive 433 Mhz?)
Here is the complete code, Iām from the Philippines, btw.
/*******************************************************************************
* Copyright (c) 2015 Thomas Telkamp and Matthijs Kooijman
*
* Permission is hereby granted, free of charge, to anyone
* obtaining a copy of this document and accompanying files,
* to do whatever they want with them without any restriction,
* including, but not limited to, copying, modification and redistribution.
* NO WARRANTY OF ANY KIND IS PROVIDED.
*
* This example sends a valid LoRaWAN packet with payload "Hello,
* world!", using frequency and encryption settings matching those of
* the The Things Network.
*
* This uses OTAA (Over-the-air activation), where where a DevEUI and
* application key is configured, which are used in an over-the-air
* activation procedure where a DevAddr and session keys are
* assigned/generated for use with all further communication.
*
* Note: LoRaWAN per sub-band duty-cycle limitation is enforced (1% in
* g1, 0.1% in g2), but not the TTN fair usage policy (which is probably
* violated by this sketch when left running for longer)!
* To use this sketch, first register your application and device with
* the things network, to set or generate an AppEUI, DevEUI and AppKey.
* Multiple devices can use the same AppEUI, but each device has its own
* DevEUI and AppKey.
*
* Do not forget to define the radio type correctly in config.h.
*
*******************************************************************************/
#include <lmic.h>
#include <hal/hal.h>
#include <SPI.h>
// This EUI must be in little-endian format, so least-significant-byte
// first. When copying an EUI from ttnctl output, this means to reverse
// the bytes. For TTN issued EUIs the last bytes should be 0xD5, 0xB3,
// 0x70.
static const u1_t PROGMEM APPEUI[8]={ 0x19, 0x9D, 0x00, 0xD0, 0x7E, 0xD5, 0xB3, 0x70 };
void os_getArtEui (u1_t* buf) { memcpy_P(buf, APPEUI, 8);}
// This should also be in little endian format, see above.
static const u1_t PROGMEM DEVEUI[8]={ 0x2B, 0x9F, 0x07, 0x73, 0xEF, 0xEB, 0xB0, 0x00 };
void os_getDevEui (u1_t* buf) { memcpy_P(buf, DEVEUI, 8);}
// This key should be in big endian format (or, since it is not really a
// number but a block of memory, endianness does not really apply). In
// practice, a key taken from ttnctl can be copied as-is.
// The key shown here is the semtech default key.
static const u1_t PROGMEM APPKEY[16] = { 0xAE, 0xC8, 0xFF, 0xF2, 0xBD, 0x69, 0x94, 0xA5, 0xB8, 0x50, 0xD0, 0x6F, 0xF1, 0x17, 0x00, 0x9D } ;
void os_getDevKey (u1_t* buf) { memcpy_P(buf, APPKEY, 16);}
static uint8_t mydata[] = "Hello, world!";
static osjob_t sendjob;
// Schedule TX every this many seconds (might become longer due to duty
// cycle limitations).
const unsigned TX_INTERVAL = 60;
// Pin mapping
const lmic_pinmap lmic_pins = {
.nss = 18,
.rxtx = LMIC_UNUSED_PIN,
.rst = 14,
.dio = {26, 33, 32},
};
void onEvent (ev_t ev) {
Serial.print(os_getTime());
Serial.print(": ");
switch(ev) {
case EV_SCAN_TIMEOUT:
Serial.println(F("EV_SCAN_TIMEOUT"));
break;
case EV_BEACON_FOUND:
Serial.println(F("EV_BEACON_FOUND"));
break;
case EV_BEACON_MISSED:
Serial.println(F("EV_BEACON_MISSED"));
break;
case EV_BEACON_TRACKED:
Serial.println(F("EV_BEACON_TRACKED"));
break;
case EV_JOINING:
Serial.println(F("EV_JOINING"));
break;
case EV_JOINED:
Serial.println(F("EV_JOINED"));
// Disable link check validation (automatically enabled
// during join, but not supported by TTN at this time).
LMIC_setLinkCheckMode(0);
break;
case EV_RFU1:
Serial.println(F("EV_RFU1"));
break;
case EV_JOIN_FAILED:
Serial.println(F("EV_JOIN_FAILED"));
break;
case EV_REJOIN_FAILED:
Serial.println(F("EV_REJOIN_FAILED"));
break;
break;
case EV_TXCOMPLETE:
Serial.println(F("EV_TXCOMPLETE (includes waiting for RX windows)"));
if (LMIC.txrxFlags & TXRX_ACK)
Serial.println(F("Received ack"));
if (LMIC.dataLen) {
Serial.println(F("Received "));
Serial.println(LMIC.dataLen);
Serial.println(F(" bytes of payload"));
}
// Schedule next transmission
os_setTimedCallback(&sendjob, os_getTime()+sec2osticks(TX_INTERVAL), do_send);
break;
case EV_LOST_TSYNC:
Serial.println(F("EV_LOST_TSYNC"));
break;
case EV_RESET:
Serial.println(F("EV_RESET"));
break;
case EV_RXCOMPLETE:
// data received in ping slot
Serial.println(F("EV_RXCOMPLETE"));
break;
case EV_LINK_DEAD:
Serial.println(F("EV_LINK_DEAD"));
break;
case EV_LINK_ALIVE:
Serial.println(F("EV_LINK_ALIVE"));
break;
default:
Serial.println(F("Unknown event"));
break;
}
}
void do_send(osjob_t* j){
// Check if there is not a current TX/RX job running
if (LMIC.opmode & OP_TXRXPEND) {
Serial.println(F("OP_TXRXPEND, not sending"));
} else {
// Prepare upstream data transmission at the next possible time.
LMIC_setTxData2(1, mydata, sizeof(mydata)-1, 0);
Serial.println(F("Packet queued"));
}
// Next TX is scheduled after TX_COMPLETE event.
}
void setup() {
Serial.begin(9600);
Serial.println(F("Starting"));
#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();
// Start job (sending automatically starts OTAA too)
do_send(&sendjob);
}
void loop() {
os_runloop_once();
}
I donāt see ā LMIC_setupChannels in LMIC init ?
I just based this sketch hereā¦
https://github.com/matthijskooijman/arduino-lmic/blob/master/examples/ttn-otaa/ttn-otaa.ino
Hi, I am new to this forum. I purchased a bunch of 433Mhz LoRa devices and I am struggling to understand why the frequency might be a problem.
I would have thought that TTN shouldnāt care about what frequency my gateway is operating on since TTN will only receive TCP packets. Why does 433Mhz support have to be implemented on TTNās side? Any pointers?
I am in Uruguay BTW. I researched a bit and it seems that I can use either 915Mhz (ISM) or 433Mhz (as used by ham radio).
Thanks!
The gateways in LoRaWAN are fairly dumb, itās up to the network to decide which frequencies to use for example on downlinks and also enforce the duty cycle for the specific frequency plan you use - among other definitions.
Sir, any update on this? We are planning to do the same thing.
Hi guys , we are from israel , we are working on ESP32 .
as the serial monitors tells , the ESP32 works with 433 MHz frequency , TTN doesnāt have support with that frequency ! any ideas of what should we do ? THANKS
It seems youāre out of luck:
Weāre not planning to support EU433 officially. With V3, this will be much easier to do for private networks. In EU, on the public network, we stick to 863-870 MHz.
For Israel, https://www.thethingsnetwork.org/docs/lorawan/frequencies-by-country.html#i shows no plan yet:
Country Frequency Plan Regulatory document ā¦ ā¦ ā¦ Israel EN 302 208
The latest LoRaWAN 1.1 Regional Parameters is the first to mention Israel:
Country name Band / channels Channel Plan ā¦ ā¦ ā¦ Israel 433.05 - 434.79 MHz EU433 915 - 917 MHz Other
However, for that, @htdvisser already wrote in October 2018:
TTNās official recommendation is to wait until the LoRa Alliance publishes a regional parameters specification that is suitable for Israelās 915-917 band. Until then you could experiment with the 433MHz band (but you will need different hardware for that).
I do know that the LoRa Alliance has been working on a āmiddle eastā regional specification, but I canāt share any details about that yet.
Iām very sorry that I canāt be of more help, this is out of TTNās control, so weāll just have to be patient.
If, alternatively, you want to see if TTN wants to support EU443 after all, then see https://www.thethingsnetwork.org/forum/t/proposal-for-eu-433-frequency-plan/13090.
I donāt see any support for Lorawan 433Mhz anymore. why is that?
Search the forum with regards to 433MHz support by TTN.
There is no 433 support and there has not been support for 433. There will not be support either in the future as things stand now.
Search this forum for details.