There are a few different ways I have seen other people deal with it but you can use the Retained Variables function to store data that will save through a power reset.
I don’t think there is a way to detect if the device woke from RTC timeout or WKP pin when using deep sleep. I’m not really sure though since I have never attempted to do this before.
Question though is, is this only going to work for Stop sleep mode, or also Deep sleep?
Looks like there may be a fix released soon to allow what you and others are wanting to do.
So what has been the feedback from the trash company so far based on how things are going with the trial?
Everything I have read about this has been positive and makes things more efficient which saves money and time.
Quite positive. However, I would say in general the waste industry is very adverse to this kind of technology, as companies usually make profit out of inefficiency, not the other way around - IOT threatens their income. That’s why this technology typically is only used by cities, municipalities and other organizations that contract trucks rather than carrying it out themselves.
I expect as the IOT-industry grows, waste companies may set up policies that they do not in any way want their business to be linked to sensors.
I will postpone the WKP/RTC timeout for now - see what updates are going to take place in the future.
@Vitesze, or, contracts will be written between cities and waste companies that reward them for efficiency. That is, “find ways to save money and we will share that savings with you”.
Perhaps. The waste industry largely revolves around inefficiency these days, it’d be very interesting to actually see it shift towards efficiency instead.
The thing though is, that in most cases ( I know this is true at least for Canada and most of Europe) municipalities almost only regulate residential waste, which are set up to a fixed schedule and aren’t seperately monitored. Large commercial sites have their own contracts with waste companies but may find it harder to bargain about these things
I figured they would be all over something that could cut their expenses as far as daily truck routes and fuel savings.
They don’t have to share the info with the customer, just allow them to schedule pickups only when needed has shown others a big reduction in the number of pickups per day which saves on fuel consumption which is not little considering they are driving big trucks that consume lots of fuel.
I find this fascinating for the simple fact that trash is all around us and it’s a bill that almost everybody has to pay monthly so the income flow is tremendous month after month.
Plus nobody has this figured out really, it’s still in its infancy. Bottom line is that it has the potential to save lots of money via more efficient operations.
When you talk about inefficiency, are you talking about they make more money by leaving the larger dump contains at sites for more days vs picking them up earlier?
For inefficiency, I mean that since waste companies usually get paid per waste pickup, they will want to do it as often as possible. Picking up a bin at only 25% full every time is actually great, because their profit margin for that client is larger than if they would pick it up half as often or less.
The whole point of using sensors would be to make the waste servicing industry more efficient, and this would come at the expense of such arrangements.
Are you talking about the Tote size cans for residential mainly? or for the larger cans for business?
I would think the larger cans would be where the most money is made and where they could cut down on pickup frequency based on if the trash if full or not.
In my area, the residential pickup is rolled into the water bills and regular weekly pickup makes perfect sense. I can't see them wanting to pick up residential tote sized cans more often. But that does make sense for cities who want to keep the city cleaner.
The smallest trash service company around here has a yearly revenue of 50-100 million. There is for sure room for running more efficiently and keeping more of that money in their pocket vs the gas station.
Totes can be both residential or commercial where I live. Often for Organic waste or Plastics businesses use totes as they don’t have that much stuff to throw out per week.
Where I live, the price waste companies can claim on pickups depends on the size of the container, and the pickup frequency. No mention is made on the actual amount of waste inside. Perhaps for recyclables this is a factor as the waste company would most likely sell it off to another vendor, so emptying empty containers would be a waste of time, but for the bulk of it their profit really is linear to the number of pickups they’re gonna do.
I know it’s twisted and odd; I don’t know if things are different between the US and Canada, but here at least there’s a lot of incentive for waste companies to run as inefficiently as possible. Many businesses don’t really bother with this and don’t have their own waste program. As long as their containers are picked up, they don’t care too much to actually verify if they aren’t overpaying for their waste services.
Hi, I was wondering if you could help me with something?
Yesterday, I put 9 of my sensors outside on waste containers, hooked up to the 2A LiPo battery from Particle. All batteries initially had a state of charge between 75 and 85%. For the last 16 hours, they have only been activated max. 2-3 times, but the state of charge in some cases has dropped by as much as 11.45% (the lowest drop was still 1.95%). When I tested them at my desk repeatedly, their state of charge didn't appear to drop much simply from running the code (which is short, and should only last for about half a minute anyway).
So I'm suspecting right now that something isn't going right with the Deep sleep mode. The code is designed to not allow the Electron for attempting to connect for longer than 60 seconds (in fact, I use a switch case and in every single state there's a line to prevent it from stalling). The largest drop between two activations I found was about 5% over a period of 12 hours.
Right now, I simply use:
System.sleep(SLEEP_MODE_DEEP, 21600);
(for a few devices I wake them up every 12 hours)
In the past, I actually operated the Asset Tracker v2 for a period of 4 months in Deep Sleep with the 2A LiPo and a daily connection. I don't recall ever seeing a daily drop of more than about 1 to 2%. Clearly something is going horribly wrong here.
EDIT: Nevermind, I read your reply here: Electron Cellular.off() and Sleep Modes - #6 by RWB Since BDub mentioned it possibly will be scheduled for 0.7.0, and all my devices run on 0.6.4 at the moment, this would for sure explain the huge current draw I'm experiencing right now.
Is it cold outside there right now?
Lower temps will drop the voltage some also which will also drop the SOC level when you take them from room temps to outside temps.
They shouldn’t keep dropping by %5 SOC per day though.
I would say the temperature varies between 0 and 10 degrees C right now here. Considerably lower than when I did my Asset Tracker testing (which had temperatures ranging between 15 and 30 degrees C), but it's not so exceptionally cold that it would explain such massive differences
Also, for voltage drops, wouldn't this just mean the overall SoC is going to be lower, but the drops per day are still the same? All numbers I've provided so far are for comparing the values while it already was outside - I disregarded any indoor-values as I know the Temperature would play some role here.
Also, the 5% drop was for a 12-hour period. Per day this is going to amount to at least 10%, so at that rate I would struggle to even get one week out of this which I could only blame that modem for.
Now added:
delay(5000); Cellular.command("AT+CPWROFF\r\n"); delay(2000); FuelGauge().sleep(); delay(2000); Serial.println("going to sleep now..."); delay(500); System.sleep(SLEEP_MODE_DEEP, 21600);
And will see how that goes.
You may see initial SOC drops after charging as the battery voltage settles down.
If the SOC keeps dropping 5% per 12 hours then yea something is drawing more power in sleep mode than you are wanting.
Did your sleep code change vs the code you tested in the past?
Before, I simply used Automatic mode, and I noticed in the other topic that the modem issue only applies to Deep sleep mode while in Manual and Semi-Automatic mode.
If it’s true it still scheduled for 0.7.0, then that issue must also be present for my firmware and since I did nothing to mitigate it before, it must at least have played a significant role in my SoC drops.
I released the new firmware to the devices but they’re set to wake-up every 6-12 hours, so by tomorrow morning I should have an answer to how big this role was.
Yea, that cellular command code was needed to put it to sleep successfully. Pretty sure it was fixed in the latest firmware but you will need to add the cellular off command if you’re using the older firmware.
You will know if your updated code fixed the SOC issues in 12 hours I guess. That cellular command worked for me.
I noticed on my 0.6.2 firmware Cellular.command(“AT+CPWROFF\r\n”) does not work properly (device will no longer go to sleep anymore). Does Cellular.off(); (which does work) operate in the same fashion?