Electron Project Discussion [Hardware]

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.

1 Like

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.

  • Also, for residential waste pickups; I’m not 100% sure how they charge the waste collection here where I live (as I don’t own my own house), but the city council generally applies a similar frequency across all the addresses. I believe one can opt for additional servicing, but there still is little flexibility to it.

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 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?

Here is the last code I tested which was firmware 0.6.0

https://go.particle.io/shared_apps/5880d2fc82248db40b000a58

Usually, I would not sleep the fuel gauge because it caused wide swings in battery SOC on wake up but you can test that also if you want.

You may want to try the 0.7.4 firmware since I think the Cellular command is no longer needed to get it to turn off completely.

Thanks, so that code for some reason doesn’t seem to work on my 0.6.2 Electron, although I directly copied and pasted it…strange, but Cellular.off(); does work and hopefully will achieve the same thing…let’s wait and see :stuck_out_tongue:

I will consider upgrading to 0.7.0-rc4 the next time I have to get those devices off the containers (trust me, it’s not fun doing that :joy: )

Cool! Looking forward to seeing what happens with the SOC.

Do you have a picture of what your setup looks like installed?

Took some individual components and put them together to give an impression. Don’t have any VL53L0X available right now, but I glued them to the hole on the lid with heavy-duty tape, and wires leading back to the PCB. All my actual sensors are outside at the moment :smiley:

For the enclosure, Polycase designs really nice ones at an affordable price. Sensor goes on a separate metal bracket, as I found when it gets mounted directly onto a container, the vibrations when the top is opened/closed by people really messes with the accelerometer.

A couple of them came online and received the update. As soon as they receive it, they immediately reboot so I receive their SoC before and after the update, which should equal the energy it requires to do one wake-up of the device. Across all devices this seemed to be 0.16% with a 2A LiPo. Going with that, there is absolutely no way 3-4 Wake ups on a day can lead to an 11% drop and it’s a confirmation that I did things wrong with Deep Sleep. Now will wait until tonight when they report in again, where I can verify if the SoC-drop is significantly reduced or not after 6 hours of Deep Sleep.

Cool, yes I have used Polycase cases in the past also and they are priced good and the quality and look is good also.

I looked at the case your using on their website also but was wondering how to get the sensor pointed down at an angle like you did with the metal bracket.

I was thinking about the best way to get 3 distance sensors pointed down from the back wall of the can to get a better overall idea of what the trash levels are vs. just having one sensor. Maybe 1 sensor is enough though.

Look at these guys: https://www.emachineshop.com/
You can have a low-quantity metal bracket made to suit your own requirements.

Personally, I had them made at a nearby workshop for 10 bucks a piece. The one in the picture is an old one, the newer ones have an angle that is based on the container size, so that it looks slightly beyond the center-point when it is mounted on the side.

I would say 1 sensor is not sufficient to very accurately measure, as from my own experiences often thrash is located in one part of the container and not the other, either greatly over- or underestimating the fill rates. Even with 3 of them you still can only look at the waste from one angle, and large objects that fully block the sensor may still be there

I’d say with a VL53L0X and a typical 6-8yd container, you’re probably gonna get 75% decent results and 25% that are all over the place.

Yea, let them stabilize and see how the SOC readings come out.

Glad the units received the updates without a problem upon waking up. How are you going about triggering the Electron update process when they wake up? Do you have these units in a product group on the Particle console so they automatically update when they wake up?

Also, are you using a dashboard to visualize the trash level status of each can?