|
Sander Rossel wrote: They live on a server and users simply don't have access. That could be discussed about...
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I hate you. You are making a good argument for maybe the tech has progressed. I need more drugs
My wife was a web developer in the wild days... before 2000. Note pad was your friend. So... I had to deal with 404 errors, backend server weirdness. It was maddening.
But I have this app I need to develop. And it seems everything is ROARING to "let's put it on the cloud, what could go wrong?" Years ago I went through OLE/ActiveX/COM/COM+ and there might have been something else - damn Microsoft clowns.
So when I see .net times 13, azure, this that and the other... I have tools from Microsoft that won't work properly, it's a complete charlie foxtrot.
I am afraid.
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.
|
|
|
|
|
|
And if you look at the comments, you see that the first one refers precisely to this.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Not only that, but this is a comic from almost 5 years ago.
Are you regression-testing?
|
|
|
|
|
dandy72 wrote: this is a comic from almost 5 years ago.
I've read through the entire Dilbert oeuvre (over the past couple of years) and I'm just 5 years out from finishing them all.
Yes, I'm serious.
Dailies started on April 16, 1989 and I've read through all those years so far.
Yes, I believe my brain has been altered from reading them.
|
|
|
|
|
Well, I've been reading it daily for years, and I'm sure I've missed out on more than the first 5 years. If it's a competition, you win...
|
|
|
|
|
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.
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
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.
|
|
|
|
|
charlieg wrote: get that in writing Wise words indeed.
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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 suspend and resume calls 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 . Enough said
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
|
|
|
|