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
As I’m not the person that asked the original question, some possible scenarios where TTN would make a lot of sense:
A few solar/battery street lamps on remote locations in the village.
A parking lot where the original lights where powered centrally on and off by cutting the electricity to them , but where now they need continues electricity to the poles/towers (and thus need to put on/off with some local logic.
A city that has sportgrounds or other facilities that can be reserved and thus get light and/or heating.
It’s far better to have TTN coverage over a village with a few “less than optimal” (maybe) nodes then no coverage.
I do agree that the nodes need some thinking.
BTW. Don’t need a lot of nodes some type of time syncing?
Thanks for all the answers.
This is for fish farms, we need to turn on the lights when the ambient lux level goes to a fixed value. Then we turn on the lights at minimum level and dim them to the max power in a fixed time (example 1 hour). Is not like a lux compensation where you need to dim up/down trying to maintain the same lux level.
We are avoiding to use a light sensor on each module/“pole”, as then we need to clean/fix all of them on a regular basis.
Sorry for my ignorance, but as I understand, we need to use LoraWan and not Lora TTS. But I don’t know what this means on terms of cost and complexity.
Regards
What is LoRa TTS? And what is this conclusion based on? I very much agree with the following, which seems to be the opposite of the above, emphasis mine:
I’d consider some home brewed LoRa protocol for the fish tanks, if only to not rely on external network services such as TTN. Also, whatever you choose: LoRa is radio, in a shared radio spectrum, and there are no guarantees that the signals will be received. Be prepared.
Not if most are sensors for which the timestamp at which an uplink is received suffices? (Even for sensors, one should not try to make all transmit at the same time. Of course, one could use a clock to take the measurements at specific times if that’s really important, but then transmission should still be randomized.) Also beware that it’s hard to transmit a downlink right after receiving an uplink; see My application's downlink is always queued for next uplink. So, time synchronisation for LoRaWAN Class A devices is harder than one might think, and subject of a different topic: Time synchronisation of a Node.
1 Like
I was wondering what ‘Lora TTS’ was too.