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.
If the Class A downlink depends on the same factor (some lux value) for all devices, then all those devices will have their downlinks in the same time period? (And, for Class A, will be sending polling uplinks all day long?) Beware that gateways need to adhere to duty cycles as well (and cannot listen while transmitting), and that the radio spectrum is shared among all users and networks.
If it’s really only related to the amount of light, then I’d add a light sensor to the device rather than trying to control the streetlight from a central place. And maybe use LoRaWAN to make the device report the light pole’s state, and use very infrequent downlinks to tell the device to use different lux settings.
The types of downlinks I was thinking about :
- time synchronisation
- lux synchronisation (calibrating cheap onboard light sensor)
- time of light on/off
- a indication of how much the on/off should be adapted given the lux level
- absolute lux level to switch on in the daytime.
- indication of node send times (to spread the node sends)
I don’t see a need to poll frequent or to send all those downlinks in a few minutes.
1 downlink per day in the afternoon could be enough to get very good results.
The problem is that the overwhelming majority of what you want to do is a multicast use case.
LoRaWAN (and even better other LoRa schemes) support multicast.
TTN does not.
LoRa and perhaps private LoRaWAN are suitable for this use; but the present form of TTN could only accomplish it in an awkward wasteful manner, vs the clean and efficient manner in which another network could accomplish it using the same ultimately shared radio bandwidth.
If you’re going to do this with a non-multicast network like TTN, then indeed, you need to keep the status uplinks to a minimum, and make the rare downlink something that can be sent hours in advance when there’s an uplink, containing a time correction and updated rules.
1 Like