I’m building low power consuming nodes based on ATMega328P using the watchdog 8 seconds sleep - but I’m facing issues with the timer - the sleep is not exactly 8 sec - it is a bit random and adjusting the timer with 8 sec does not seems to do the job… also on different devices (same model) the sleep time is also different - e.g. you cannot adjust the timer correction on one device and after that us ethe same on all new device…
Anyone else facing similar issue with ATMega328P ?
Everyone using the watchdog timer for sleep purposes will have the same issue. The watchdog timer is not accurate\stable, not meant to be. See the device datasheet for details.
If you want accurate sleep times use a real time clock.
It doesn’t say that it is, it is a power of 2 aka binary thing.
It works very very very very very well of me as a sleep - but then you shouldn’t try to uplink on a precise schedule, so any deviation is neither here nor there.
Can you please point me to the right place to read about it ? deviation in about 1m per 24h is good for me
Search the datasheet for ‘Watchdog’
deviation in about 1m per 24h is good for me
Funniest thing I have read in ages.
Like I said before, use an RTC.
I’m not sure you are going to get the answers the way you are asking the questions. Or ignoring the questions asked of you.
The ATmega328 data sheets are spread all over the interwebs, so that’s really easy to get hold of.
But specific to me (and others on this forum), you’ve not given us the why despite being asked, so we have no way of answering in context. And we all really hate giving answers that may be totally wrong for the situation, there being nuances to LoRaWAN that can make all the difference
Like I said above, this technology is not suited to time precise activities, so EVEN if there is an RTC on the device, it is the recommended practise from the LoRaWAN Alliance that uplinks should have some plus/minus random time in the schedule. One of the authors of that good practise paper is the CTO of TTN - so it must be true.
by why : You mean why I need precise timing ?
it is simple scenario - a l gateway is mounted on a drone and the drone have a predefined flight part which is done once very 24h - e.g. every sensor has about 5-7min access to the gateway per 24h
Ok, now I have heard of every possible gateway mounting position.
Mobile gateways are disruptive and can cause some issues for other users.
Ha! Nothing simple about a gateway on a drone. If this is for real, I’d be inclined to making the system a bit more robust than such a space constrained MCU like the '328.
As long as you aren’t on TTN, you can do that. If you aren’t paying for a TTI instance, then the whole concept is off topic for this forum which is TTN/TTI based LoRaWAN.
I’d be interested to know how the drone relays the data back to the network server - or is that on the gateway / drone combo as well - and how will the drone cope with the weight of the data it receives.
Ironically close to the other thread-du-jour on using satellites …
this exact scenario is for very remote areas in the middle of the mountains…
Yes it is for real - for collecting data from remote areas - the strategy currently is the gateway on the drone will buffer that data until it arrive back at the landing point and then relay all over wifi.
The reason for '328 is that we have good experience with it and there is already plenty of-the-shelf LoRA Node’s using it.
There are few well designed LoRaWAN nodes based on an ATmega328, and most that get close are legacy designs from before people realized quite how limiting that was. It would make 0 sense to do a new design that way.
Don’t mistake the various LoRa boards for necessarily LoRaWAN ones - many of the companies selling those are barely aware of the difference, and the offered software may not implement LoRaWAN at all, or may only be a very old and incomplete attempt to.
It can be done, but it’s unwise for a new design for countless reasons - among them, your sleep issue, more prominently the limited resources.
This is already a project fundamentally incompatible with TTN in its design, and since it sounds like something that’s going to save data from a period of time and upload it in a short opportunity, it’s worth asking if it still makes sense to use LoRaWAN or even LoRa radio technology at all. Depending on how directly overhead the collector drone visits, you might use something with a higher bandwidth and shorter range. Or you might at least use faster LoRa air settings than normally used in LoRaWAN. You probably also want something that acks every packet, which is really anathema in terms of the way LoRaWAN is supposed to work.
You have a lot of complex custom design to do, likely well beyond the topic coverage of this forum. Fighting with a primitive MCU that will continue to be limiting even when you get beyond the present issue is just a distraction from where your attention actually needs to be on such a project.
When you are using atmega328p, if you are using its internal oscillator for clock source then there would be huge deviation for a 8 second time.
Watchdog Oscillator Accuracy as per the datasheet of atmega328 is between 76 to 180KHz.
You are right about low power capability of atmega328. I have found the when all systems are down and just waiting for an external interrupt, the power down current would go below 1uA to nano ampere (in hundreds).
What I did was used an external timer chip like TPL5000 for external interrupt. This way I could shutdown almost everything in the chip.
Hope this helps.
My understanding would be that the TPL5000 has an accuracy of 10% or so.
The OP wants an accuracy of 7min in 24 hours, or 0.5%.
The real world solution, like many of the edge-cases here, is to scrap the original scheme and get $1,000’s of free advice for, erm, free, from the forum crystal ball readers that await the implementors of bizarre & edge schemes that ask for help here.
First, use something with at least an external RTC crystal, preferably a TCXO. A SAMD21 would be a good start for prototyping, aka an Adafruit Feather M0 but for deployed hardware, something with that external crystal. Even better, use an RTC module with an alarm & interrupt output (almost all of them).
Totally off topic for TTN & this forum, but ditch LoRaWAN.
Use 433MHz to get better range, if your region allows it.
Get the drone to transmit a beacon so the device can listen for the beacon, ask for a transmit slot on one channel and then vomit the results on the allocated channel. With a few radios on the drone (1g or less), it can receive data from several devices at the same time.
Or find a handy mountain and launch either a met balloon or even just a solar inflated black refuse bag to get an aerial up high. Or a small hill with at small toot of helium in the bin bag.
Indeed, hence my original suggestion to use an RTC.
The are RTCs that will do the job. I2C connected, just add a cheap watch crystal and a capacitor, thats it. No battery required, power from the Microcontroller supply, inactive current of 1uA or so.
A TCXO might improve accuracy and stability but at a very significant increase in power consumption.
For any application that uses an RTC, plain crystal or TCXO, there should be a mechanism to externally sync the clock, so more complexity for the application.
The recommendation was for low power configuration where the chip could be completely shutdown waiting for INT1 interrupt. TPL5000 was an example of a nano power chip. It was not a recommendation for accuracy. The chip was used only for waking up the uC in regular intervals, just considering the power saving part, it had nothing to do with time sync.
But that’s not very helpful. In a workable solution you still have to have a clock running that keeps accurate time, and that can be programmed to wake up the processor when actually desired.
That the project seems to be stumbling over this trivial incidental issue does not bode well for success against the real design challenges ahead.
Hi @vtomanov,
The opinion on the forum seems to suggest that LoRaWan and TTN may not be a solution that will work for your remote nodes and gateway on a drone concept.
There are other options which you could consider. These are not TTN and don’t even need LoRaWan, so they are probably not up for further discussion on this forum. But here I go anyway!
Reducing what we know of your requirement to its minimum: “A drone travels a defined route with known timings. It collects and records sensor data wirelessly from sensors. The recorded data is delivered to an application or database.”
When your drone returns to base you will plug in to charge the battery. Therefore there is no real requirement for LoRaWan capability. With sufficient storage on the drone you can plug in a data connection to download the recorded data at the same time.
Removing the need for accurate timing: There is the concept of a “wake up receiver” that has been around for many years. This a fairly early paper on the subject. L. Gu and J. Stankovic, “Radio-triggered wake-up capability for sensor networks”, Real-Time and Embedded Technology and Applications Symposium 2004. Proceedings. RTAS 2004. 10th IEEE , pp. 27-36, 25–28 2004. A search with a popular search engine will provide many more.
Your drone could transmit a “wake up signal” when it reaches the location of a node. The wake up receiver must be ready to receive when the drone arrives, but that does not need millisecond accuracy. There are “ultra low power” designs if you only have a tiny power budget, but you may not need to go that far.
If you have sufficient battery power, especially if you have solar charging, you might not even need a wake up receiver. Just wake up your sensor in receive mode a minute or so before the drone is scheduled to arrive.
Finally: The firmware on the remote sensor nodes will be very different from what you may have already developed and tested to use with TTN and LoRaWan. But if you are lucky you may be able to use the same hardware with different firmware for each use case.
To summarize - I found two solutions that worked for me :
F(V,T) = p00 + p10V + p01T + p20V^2 + p11VT + p02T^2
With:
p00 = 122.6
p10 = -2.742
p01 = -0.0347
p20 = 0.2633
p11 = -0.002518
p02 = -0.0002513