Things that get expensive later
-
0.33 amps at my bench. That's what the circuit I'm working on is drawing off my USB port. Just 36 of these and I'd have the same draw as a relatively powerful vacuum cleaner. :laugh: This is bad, because the whole thing needs to run on a battery. I wish it didn't. It's got a large (for its class) display like the size of the largest display you could find for any phone. (it would be a big phone). I think that's where most of the draw is coming from. Then there's the bluetooth (since I don't have a button for it it's always on) which takes at least .10 amps by itself. But my client is like, "don't worry about it right now" I don't know how to explain to him just how expensive it will be to worry about it later. I really don't want to have to remodel my entire codebase a month (or less) from now. It's not about the extra work - I get paid one way or another - but it's the high probability of breakage. With IoT code, it can't always afford to be written in such a way that it's compartmentalized and abstracted out, so the blast radius of a design change tends to be pretty large. I don't like being in situations where I can't communicate the consequences of a hasty decision effectively to someone that needs to hear it, but this is compounded with IoT stuff because of the way the code has to be written. It's a strange landscape for me. All of this IoT dev is relatively new to me and I'm still learning the pitfalls.
Real programmers use butterflies
0.33 A at what I assume is 5V, 36 of those would equal what I call a very weak vacuum cleaner. Actually doubt you can even clean your keyboard at 60W.
Wrong is evil and must be defeated. - Jeff Ello
-
0.33 amps at my bench. That's what the circuit I'm working on is drawing off my USB port. Just 36 of these and I'd have the same draw as a relatively powerful vacuum cleaner. :laugh: This is bad, because the whole thing needs to run on a battery. I wish it didn't. It's got a large (for its class) display like the size of the largest display you could find for any phone. (it would be a big phone). I think that's where most of the draw is coming from. Then there's the bluetooth (since I don't have a button for it it's always on) which takes at least .10 amps by itself. But my client is like, "don't worry about it right now" I don't know how to explain to him just how expensive it will be to worry about it later. I really don't want to have to remodel my entire codebase a month (or less) from now. It's not about the extra work - I get paid one way or another - but it's the high probability of breakage. With IoT code, it can't always afford to be written in such a way that it's compartmentalized and abstracted out, so the blast radius of a design change tends to be pretty large. I don't like being in situations where I can't communicate the consequences of a hasty decision effectively to someone that needs to hear it, but this is compounded with IoT stuff because of the way the code has to be written. It's a strange landscape for me. All of this IoT dev is relatively new to me and I'm still learning the pitfalls.
Real programmers use butterflies
train wreck approaching.... software is one thing, power requirements are entirely another. "
Quote:
But my client is like, "don't worry about it right now"
" get that in writing. Sounds like a good client be blunt and upfront. I think that comes easy for you ;)
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
train wreck approaching.... software is one thing, power requirements are entirely another. "
Quote:
But my client is like, "don't worry about it right now"
" get that in writing. Sounds like a good client be blunt and upfront. I think that comes easy for you ;)
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
charlieg wrote:
get that in writing
Wise words indeed. :thumbsup:
Quote:
software is one thing, power requirements are entirely another
Many times those are somewhat intertwined, given low power 'sleep' modes available on most MCUs.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst "I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
-
0.33 A at what I assume is 5V, 36 of those would equal what I call a very weak vacuum cleaner. Actually doubt you can even clean your keyboard at 60W.
Wrong is evil and must be defeated. - Jeff Ello
Fair enough. I don't usually do electronics math
Real programmers use butterflies
-
train wreck approaching.... software is one thing, power requirements are entirely another. "
Quote:
But my client is like, "don't worry about it right now"
" get that in writing. Sounds like a good client be blunt and upfront. I think that comes easy for you ;)
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
The software has a ton to do with the power draw, because I control when everything is on or off
Real programmers use butterflies
-
Fair enough. I don't usually do electronics math
Real programmers use butterflies
No worries, about the math that is. Out of curiosity, what batteries are you going to use? And how long do they need to last? 2 W is still quite a drain on the batteries. A regular 18650 lithium battery has about 9 Wh and would last up to 4 hours assuming 90% efficiency in the regulator.
Wrong is evil and must be defeated. - Jeff Ello
-
No worries, about the math that is. Out of curiosity, what batteries are you going to use? And how long do they need to last? 2 W is still quite a drain on the batteries. A regular 18650 lithium battery has about 9 Wh and would last up to 4 hours assuming 90% efficiency in the regulator.
Wrong is evil and must be defeated. - Jeff Ello
We haven't decided on an exact model yet because it's still being v1 prototyped and the size of battery we get depends heavily on the physical dimensions of the final widget. the first prototype is USB powered only. So it's possible it won't be an issue. 4 hours isn't terrible for what this is. Thanks. I'll run that by my client. If it saves me a lot of hassle making it save power I wouldn't mind. :-D
Real programmers use butterflies
-
0.33 amps at my bench. That's what the circuit I'm working on is drawing off my USB port. Just 36 of these and I'd have the same draw as a relatively powerful vacuum cleaner. :laugh: This is bad, because the whole thing needs to run on a battery. I wish it didn't. It's got a large (for its class) display like the size of the largest display you could find for any phone. (it would be a big phone). I think that's where most of the draw is coming from. Then there's the bluetooth (since I don't have a button for it it's always on) which takes at least .10 amps by itself. But my client is like, "don't worry about it right now" I don't know how to explain to him just how expensive it will be to worry about it later. I really don't want to have to remodel my entire codebase a month (or less) from now. It's not about the extra work - I get paid one way or another - but it's the high probability of breakage. With IoT code, it can't always afford to be written in such a way that it's compartmentalized and abstracted out, so the blast radius of a design change tends to be pretty large. I don't like being in situations where I can't communicate the consequences of a hasty decision effectively to someone that needs to hear it, but this is compounded with IoT stuff because of the way the code has to be written. It's a strange landscape for me. All of this IoT dev is relatively new to me and I'm still learning the pitfalls.
Real programmers use butterflies
honey the codewitch wrote:
it can't always afford to be written in such a way that it's compartmentalized and abstracted out, so the blast radius of a design change tends to be pretty large.
Upvoted for eloquence :)
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
The software has a ton to do with the power draw, because I control when everything is on or off
Real programmers use butterflies
IKWYM. Back in the 80's I worked on a financial calculator which used a NEC V20 (CMOS 8088) and had a 4x20 line LCD. We arranged that it spent most of its time sleeping, only waking up when a key was pressed and caused an interrupt. This allowed it to run for days on the then common NiCd battery packs we were using. If we didn't put it to sleep, it ran for about an hour or so, tops.
-
0.33 amps at my bench. That's what the circuit I'm working on is drawing off my USB port. Just 36 of these and I'd have the same draw as a relatively powerful vacuum cleaner. :laugh: This is bad, because the whole thing needs to run on a battery. I wish it didn't. It's got a large (for its class) display like the size of the largest display you could find for any phone. (it would be a big phone). I think that's where most of the draw is coming from. Then there's the bluetooth (since I don't have a button for it it's always on) which takes at least .10 amps by itself. But my client is like, "don't worry about it right now" I don't know how to explain to him just how expensive it will be to worry about it later. I really don't want to have to remodel my entire codebase a month (or less) from now. It's not about the extra work - I get paid one way or another - but it's the high probability of breakage. With IoT code, it can't always afford to be written in such a way that it's compartmentalized and abstracted out, so the blast radius of a design change tends to be pretty large. I don't like being in situations where I can't communicate the consequences of a hasty decision effectively to someone that needs to hear it, but this is compounded with IoT stuff because of the way the code has to be written. It's a strange landscape for me. All of this IoT dev is relatively new to me and I'm still learning the pitfalls.
Real programmers use butterflies
Whenever anyone tells you not to worry you should insist that they explain why you shouldn't worry. If they can't explain why then they are either hiding something from you or they are drunk on a culture of not worrying when really they should. Don't let them keep you in the dark because that will cause you a lot of worry. If disaster strikes then saying that they told you not to worry about it is going to sound a bit lame.
-
0.33 amps at my bench. That's what the circuit I'm working on is drawing off my USB port. Just 36 of these and I'd have the same draw as a relatively powerful vacuum cleaner. :laugh: This is bad, because the whole thing needs to run on a battery. I wish it didn't. It's got a large (for its class) display like the size of the largest display you could find for any phone. (it would be a big phone). I think that's where most of the draw is coming from. Then there's the bluetooth (since I don't have a button for it it's always on) which takes at least .10 amps by itself. But my client is like, "don't worry about it right now" I don't know how to explain to him just how expensive it will be to worry about it later. I really don't want to have to remodel my entire codebase a month (or less) from now. It's not about the extra work - I get paid one way or another - but it's the high probability of breakage. With IoT code, it can't always afford to be written in such a way that it's compartmentalized and abstracted out, so the blast radius of a design change tends to be pretty large. I don't like being in situations where I can't communicate the consequences of a hasty decision effectively to someone that needs to hear it, but this is compounded with IoT stuff because of the way the code has to be written. It's a strange landscape for me. All of this IoT dev is relatively new to me and I'm still learning the pitfalls.
Real programmers use butterflies
honey the codewitch wrote:
the blast radius of a design change tends to be pretty large.
I laughed out loud when I read this snippet. I want to use it the next time my boss asks for something to be done in a questionable way.
-
0.33 amps at my bench. That's what the circuit I'm working on is drawing off my USB port. Just 36 of these and I'd have the same draw as a relatively powerful vacuum cleaner. :laugh: This is bad, because the whole thing needs to run on a battery. I wish it didn't. It's got a large (for its class) display like the size of the largest display you could find for any phone. (it would be a big phone). I think that's where most of the draw is coming from. Then there's the bluetooth (since I don't have a button for it it's always on) which takes at least .10 amps by itself. But my client is like, "don't worry about it right now" I don't know how to explain to him just how expensive it will be to worry about it later. I really don't want to have to remodel my entire codebase a month (or less) from now. It's not about the extra work - I get paid one way or another - but it's the high probability of breakage. With IoT code, it can't always afford to be written in such a way that it's compartmentalized and abstracted out, so the blast radius of a design change tends to be pretty large. I don't like being in situations where I can't communicate the consequences of a hasty decision effectively to someone that needs to hear it, but this is compounded with IoT stuff because of the way the code has to be written. It's a strange landscape for me. All of this IoT dev is relatively new to me and I'm still learning the pitfalls.
Real programmers use butterflies
Look at your power supply design. Consider replacing LDOs with DC-DC converters. Don't forget electrical emissions requirements if you make this change. Buck converters radiate out their inputs.
-
Look at your power supply design. Consider replacing LDOs with DC-DC converters. Don't forget electrical emissions requirements if you make this change. Buck converters radiate out their inputs.
For the prototype at the very least, we're stuck using devkits that have the MCU and supporting circuitry on one board, so there's no changing out components. At least not yet. Besides, I don't think changing to DC-DC converters or whatever is going to give me a 25-30% reduction in power, and I need at least that, I think.
Real programmers use butterflies
-
0.33 amps at my bench. That's what the circuit I'm working on is drawing off my USB port. Just 36 of these and I'd have the same draw as a relatively powerful vacuum cleaner. :laugh: This is bad, because the whole thing needs to run on a battery. I wish it didn't. It's got a large (for its class) display like the size of the largest display you could find for any phone. (it would be a big phone). I think that's where most of the draw is coming from. Then there's the bluetooth (since I don't have a button for it it's always on) which takes at least .10 amps by itself. But my client is like, "don't worry about it right now" I don't know how to explain to him just how expensive it will be to worry about it later. I really don't want to have to remodel my entire codebase a month (or less) from now. It's not about the extra work - I get paid one way or another - but it's the high probability of breakage. With IoT code, it can't always afford to be written in such a way that it's compartmentalized and abstracted out, so the blast radius of a design change tends to be pretty large. I don't like being in situations where I can't communicate the consequences of a hasty decision effectively to someone that needs to hear it, but this is compounded with IoT stuff because of the way the code has to be written. It's a strange landscape for me. All of this IoT dev is relatively new to me and I'm still learning the pitfalls.
Real programmers use butterflies
I do not know what that project is about but maybe he is planning to use a solar panel charging the battery?! Many IoT projects go that route and 0.33A at 5V is achievable with a small one. As for the display there is always e-paper displays but those are slow updating and very expensive, specially for one as large as you describe. And probably it works differently from your current one. I personally never worked with one.
-
I do not know what that project is about but maybe he is planning to use a solar panel charging the battery?! Many IoT projects go that route and 0.33A at 5V is achievable with a small one. As for the display there is always e-paper displays but those are slow updating and very expensive, specially for one as large as you describe. And probably it works differently from your current one. I personally never worked with one.
I have several e-paper displays that I bought when I wrote GFX - the library I use in this project for making my displays work. My library works fine with e-paper displays and the only thing I'd have to change on the non-animated screens is adding
suspendandresumecalls around my drawing code to make sure the draws weren't committed to the framebuffer over several update cycles. On the animated end it could work using partial refresh that some displays support but in my experience, using that heavily makes the display end up "muddy" The solar panel isn't realistic for this device for a number of technical and non-technical reasons. The end client didn't even want an antenna for the wireless comms - we have to make do with the integrated internal one. I've given it some thought. Someone else the other day presented some encouraging numbers in terms of what my expected battery life would be at my current draw, and it's a lot better than I had expected so this might not even be an issue. If it is, I think I can do a couple of hardware and software tweaks to help out. One big thing would be wiring the INT pin from the RA8875 controller up to the MCU (it's currently n/c) and assigning an interrupt on that to wake it up. Then I can just put the entire thing to sleep once the screen is drawn. This works for every screen except the one screen that's animated real time Another would be screen dimming or blanking, since that monster draws over .20 of that I think. I have to play with that though, and I don't know how realistic it is for our application - depends on how unobtrusive I could make it, but I also don't know how effective it will be given how people will use it.Real programmers use butterflies
-
I have several e-paper displays that I bought when I wrote GFX - the library I use in this project for making my displays work. My library works fine with e-paper displays and the only thing I'd have to change on the non-animated screens is adding
suspendandresumecalls around my drawing code to make sure the draws weren't committed to the framebuffer over several update cycles. On the animated end it could work using partial refresh that some displays support but in my experience, using that heavily makes the display end up "muddy" The solar panel isn't realistic for this device for a number of technical and non-technical reasons. The end client didn't even want an antenna for the wireless comms - we have to make do with the integrated internal one. I've given it some thought. Someone else the other day presented some encouraging numbers in terms of what my expected battery life would be at my current draw, and it's a lot better than I had expected so this might not even be an issue. If it is, I think I can do a couple of hardware and software tweaks to help out. One big thing would be wiring the INT pin from the RA8875 controller up to the MCU (it's currently n/c) and assigning an interrupt on that to wake it up. Then I can just put the entire thing to sleep once the screen is drawn. This works for every screen except the one screen that's animated real time Another would be screen dimming or blanking, since that monster draws over .20 of that I think. I have to play with that though, and I don't know how realistic it is for our application - depends on how unobtrusive I could make it, but I also don't know how effective it will be given how people will use it.Real programmers use butterflies
honey the codewitch wrote:
using partial refresh ... heavily makes the display end up "muddy"
You can probably easily solve that by using a MPEG tactic. Every N frames, refresh the entire screen.
honey the codewitch wrote:
The end client
AKA god ;P . Enough said :-D
honey the codewitch wrote:
Someone else the other day presented some encouraging numbers in terms of what my expected battery life would be at my current draw
If you are referring to Jörgen Andersson's answer, I saw it. I agree with him. Assuming 5V/0.33A, gives less than 2W. If your currently working on a off-the-shelf board, which usually are designed to be friendly and use USB power (5V), that might mean that maybe the components actually work at 3.3V or 3.7V and that will be the voltage of the final product. That would make it perfect for a small battery like an action camera one or from a phone (think small nokia phone before microsoft).
honey the codewitch wrote:
screen dimming or blanking
Depending on refresh rate and on what is actually displayed, you can use interlacing too, if the screen supports it. Every other frame update only the even or odd rows/columns. This works well for slow changing images on fast refresh displays with small enough (size) pixels. Every N frames, refresh the entire screen as above.
honey the codewitch wrote:
GFX - the library I use in this project
I have the article open in a tab but haven't had the time to read it thoroughly. Seems to be a great library so Congratulations and Thank You for sharing it with us. Even if I end up never using it, I am sure I will learn something from it :)
-
honey the codewitch wrote:
using partial refresh ... heavily makes the display end up "muddy"
You can probably easily solve that by using a MPEG tactic. Every N frames, refresh the entire screen.
honey the codewitch wrote:
The end client
AKA god ;P . Enough said :-D
honey the codewitch wrote:
Someone else the other day presented some encouraging numbers in terms of what my expected battery life would be at my current draw
If you are referring to Jörgen Andersson's answer, I saw it. I agree with him. Assuming 5V/0.33A, gives less than 2W. If your currently working on a off-the-shelf board, which usually are designed to be friendly and use USB power (5V), that might mean that maybe the components actually work at 3.3V or 3.7V and that will be the voltage of the final product. That would make it perfect for a small battery like an action camera one or from a phone (think small nokia phone before microsoft).
honey the codewitch wrote:
screen dimming or blanking
Depending on refresh rate and on what is actually displayed, you can use interlacing too, if the screen supports it. Every other frame update only the even or odd rows/columns. This works well for slow changing images on fast refresh displays with small enough (size) pixels. Every N frames, refresh the entire screen as above.
honey the codewitch wrote:
GFX - the library I use in this project
I have the article open in a tab but haven't had the time to read it thoroughly. Seems to be a great library so Congratulations and Thank You for sharing it with us. Even if I end up never using it, I am sure I will learn something from it :)
ElectronProgrammer wrote:
You can probably easily solve that by using a MPEG tactic. Every N frames, refresh the entire screen.
Initially my drivers did that for you automatically, but after awhile it doesn't seem to help on the displays I've tried. I have to "wash" the display by filling and clearing the whole thing several times before it will go back to normal and that takes forever.
ElectronProgrammer wrote:
Depending on refresh rate and on what is actually displayed, you can use interlacing too, if the screen supports it. Every other frame update only the even or odd rows/columns. This works well for slow changing images on fast refresh displays with small enough (size) pixels. Every N frames, refresh the entire screen as above.
That's probably not very practical in this case. The hardware doesn't do it, and even if I did something like that in software, the display is already half the speed of other major displays out there. Worse, it has *more* pixels so the problem is compounded. You can already sort of see the screens draw - it's just barely this side of acceptable in that regard. I don't have wiggle room to make it any less snappy, and the draws aren't fast enough for me to do software interleaving if that would even help.
ElectronProgrammer wrote:
Seems to be a great library so Congratulations and Thank You for sharing it with us.
Thanks. It's one of my better submissions here, and now that I'm using it commercially it's not going away any time soon. It has at least 30 stars on github and people on the reddit esp32 forum follow its updates so I know it's getting used. Also by now I've banged on it enough that it's relatively stable, although I always recommend going to github for the latest bits, as I only back-update the codeproject codebase as time allows so it gets to be as much as two weeks out of date some times when I'm making changes. That's not so common anymore now that the codebase has matriculated, but it's always a possibility going forward.
Real programmers use butterflies
-
For the prototype at the very least, we're stuck using devkits that have the MCU and supporting circuitry on one board, so there's no changing out components. At least not yet. Besides, I don't think changing to DC-DC converters or whatever is going to give me a 25-30% reduction in power, and I need at least that, I think.
Real programmers use butterflies
Depends. Dropping USB 5V to 3.3 with a linear throws away 1/3 of the power as heat (67% efficient). A good switcher can provide 90%+ efficiencies. They can also operate off lower voltages, like 3.7V lithium ion cells supply. 2.5V to 5.5V input range, 3.3V out. I use them in my designs. If you want a specific recommendation, list the specs you need to meet. Analog Devices and TI both have excellent options. Analog Devices has all of Linear Techs IP. Those guys make some amazing parts, especially if you need low noise. Big thing for LDOs is input ripple rejection. TI's TSP7A family LDO's reject input ripple out past 2 MHz. Analog Devices has a similar (better) part, but it costs 2-3 times as much.
-
0.33 amps at my bench. That's what the circuit I'm working on is drawing off my USB port. Just 36 of these and I'd have the same draw as a relatively powerful vacuum cleaner. :laugh: This is bad, because the whole thing needs to run on a battery. I wish it didn't. It's got a large (for its class) display like the size of the largest display you could find for any phone. (it would be a big phone). I think that's where most of the draw is coming from. Then there's the bluetooth (since I don't have a button for it it's always on) which takes at least .10 amps by itself. But my client is like, "don't worry about it right now" I don't know how to explain to him just how expensive it will be to worry about it later. I really don't want to have to remodel my entire codebase a month (or less) from now. It's not about the extra work - I get paid one way or another - but it's the high probability of breakage. With IoT code, it can't always afford to be written in such a way that it's compartmentalized and abstracted out, so the blast radius of a design change tends to be pretty large. I don't like being in situations where I can't communicate the consequences of a hasty decision effectively to someone that needs to hear it, but this is compounded with IoT stuff because of the way the code has to be written. It's a strange landscape for me. All of this IoT dev is relatively new to me and I'm still learning the pitfalls.
Real programmers use butterflies
honey the codewitch wrote:
But my client is like, "don't worry about it right now"
that always sends a shutter down my spine, we get paid to worry about that stuff, that's the very nature of engineering anything.
honey the codewitch wrote:
With IoT code, it can't always afford to be written in such a way that it's compartmentalized and abstracted out,
you're right about that, most standard devs don't understand this concept when every byte of space and every tick of the processer needs to be accounted for. I feel your pain on this. whenever I get a chance to work on projects like this, it's super fun and challenging, but explaining these issues to others not in the know can be super difficult.