I designed a node myself from the schematics to the embedded software. During development I changed from a LoRa module to a LoRaWAN module (the difference is the on board protocol stack and quite some trouble saved). The Microchip RN2483 has a comprehensible datasheet / manual and I managed to join the TTN and send data within 2 days of work, including programming of the UART driver on my controller.
https://www.microchip.com/wwwproducts/en/RN2483
that’s great… show it to us then 
Hey have a look at this.
Also with the micro chip.
But I plan to redesign it because I don’t like the Mikrocontroller.
If somebody has a perfect low power Design please share it.
It uses a ATmega328, which is capable of very low power operation, so what the problem with it ?
If you tell us the problem, its easier for others to suggest something ‘better’
Not in the modern sense. Most of what an ATmega gets you is the least “porty” Arduino port, or the ability to run from a wider range of supply voltages. But in this case you need the SX127x which doesn’t have the ATmega’s higher voltage capability, and they design isn’t trying to use a lithium cell anyway. Most importantly, because it has an RN2903 there are actually two MCUs, which is one more than needed.
That’s not to say it can’t work or that it may not solve some problems the asker would otherwise have to solve on their own.
I didn’t found any good I2c library. That is the problem. Can the RN2903 used stand alone?
Also to get values from an I2c device?
At the moment the plan is an esp32. But also from point of power consumption and operation range is not optimal.
I found nothing perfect that smal can uses one cell 1.5V Bettery and has modern architecture.
At the moment I am testing the heltec module. But the SX127x has the problem of not an integrated LaroWanstack. If their existing an one single chip it where great.
Being more descriptive helps, so in what way is the I2C library for the Atmega not good ?
OK I thought it is an Software I2C.
Isn’t it? What library u use for i2c?
Stand alone usage for a custom purpose and an an integrated LoRaWAN stack are very nearly incompatible opposites.
In theory this could be met by something which implemented LoRaWAN in pre-installed firmware and supported a scripting language.
In more realistic practice, it would mean an open source LoRaWAN implementation that works and is readily extended with custom code for the applications purpose. You’d be creating a custom build of the LoRaWAN implementation every time your changed the application code, but you wouldn’t really be customizing it, just linking it with your customizations.
Or two MCUs - one for your code, and one for the LoRaWAN stack, which is circling back to where this started.
There are lots of viable ideas, and near countless ways in which a tiny implementation mistake can break any of them.
You can run a software I2C if you insist, but most people just use the standard wire.h which is one of the core libraries that come with the Arduino IDE and runs on the hardware I2C port.
OK thanks. When this seems to be a good solution. I will see what I will do.
Hello guys, sorry for post here, but as new user I cannot open a new topic.
Im not familiar with LoRa devices, we been working with BT mesh modules for control lighting products and for a special project I been looking for other technology, as we have distances over 200meters and up to 500meters from gateway to the longer distance module. We need to control up to 8 drivers by UART interface. We want to lower the quantity of modules on each project, as they normally work really far way from cities, we prefer to have as lower quantity as possible. We use drivers that can be manage from UART and also get information about the power consumption and internal temperature. We want to get that information and log and show in our cloud system. Please let me know if someone can help us in this project.
Regards
There are limitations with the TTN network that perhaps make it unsuitable for control purposes.
The fair access rules limit you to 30 seconds of transmit air time and 10 downlink messages (i.e. what would be control type messages) per day.
Are those limitations acceptable for your application ?
Hi @GioEVOLUX,
The reply from @LoRaTracker is correct that the TTN community network fair use limitations make it unsuitable for many downlink control applications. A lot of SmartCity intelliegnt streetlight systems use LoRaWAN on private networks to avoid the TTN limitations. The city where I live - Aberdeen in Scotland - has 35,000 LucyZodian streetlights managed by 10 LoRaWAN gateways on a private LoRaWAN network.
Are all of those 35,000 controlled individually, like using downlinks at least twice a day?
Hi @arjanvanb, “controlled individually”… hmmm… I’m not sure. The streetlight heads all have continuous power so I suspect that they are probably running LoRaWAN Class C and managing via multicast downlinks. I can report that all lights visible when out walking go on or off simultaneously. The gateways are MultiTech and the LoRaWAN network server is OrbiWise.
The product website is at https://www.lucyzodion.com/products/ but it doesn’t give much away.
Thanks for the replies.
For this use, we aren’t looking for a really fast control to each fixture. Normally on each site, we will have around 40 to 150 drivers connected to one Gateway. We will connect the drivers via UART interface to the Lora Nodes, And normally 4 to 8 drivers connected to each Lora node. That means, only 25-35 Lora nodes per network. All lamps normally will turn on/off at the same time (Depending on lux conditions). And a kind of delay between them is not important.
Regards
That’s not how TTN works. Even if you only sprinkle a handful of nodes around each gateway you install, TTN is effectively just a handle of distinct networks spanning the globe (in the sense that the networks with distinct frequency plans aren’t practically cohesive, even if they exist in the same address space)
While LoRaWAN networks or other LoRa schemes with multicast downlink might be able to support that in a reasonable way, TTN currently does not.
TTN is really for sensing tasks, not control ones.
What’s the problem with a few on/off commands per day (less than 10)?
It’s a problem if more than 10 downlinks are needed or if real-time is needed.
The lux outdoor is depending of the time of day and the amount of clouds/rain etc. Both are rather predictable for the next 15-30 minutes.
I see a intelligent streetlight very well possible within lorawan and TTN restrictions. Most of the time there will be only 2 downlinks per day needed at rather good known timings.
BTW. A naive implementation is not possible.