So im new to the whole IoT world and LoRaWAN in general, but i have been doing some reading and wanted to set up a gateway and node. Unfortunately, the only allowed free band is the 433MHz band.
So i was wondering when is support coming? ( i understand it might be difficult to answer)
Are there any alternatives for connecting to TTN? maybe a 433MHz to 915MHz converter or something? alternative site?
Please help and sorry if this is inappropriate to ask here
In which country are you located?
TTN servers have basic support the 433MHz band, meaning that the channels specified as “mandatory” by the LoRaWAN specification are supported. Configuring your gateway with these channels (most 868 hardware supports 433) and pointing it to TTN should work. If it doesn’t, we’ll try and find a solution for that.
Um? I don’t think that’s true for nodes (other than RN2483) and even less for gateways.
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.
1 Like
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 
2 Likes
Thanks and glad to be a part of the community and i will definitely be back here once i start my build
1 Like
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 see now its for a 433 Heltec board… don’t think I have seen working code to use it on TTN
in config.h you cannot set this radiomodule
I just based this sketch here…
https://github.com/matthijskooijman/arduino-lmic/blob/master/examples/ttn-otaa/ttn-otaa.ino
1 Like
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.
1 Like
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.