As for why 12V: it's a common standard regulator that allows all the various internal voltages to be derived from (5, 3.3, 1.8, etc). So that's why a lot of designs use that. Especially since the 5v for USB can be isolated corrected against being pulled too low by devices that are plugged in.
That's harder with a 5v supply (although I tend to see designs using those simply let an overloaded USB bus reset the whole device) IIRC, a 5354g took about 1 watt, pretty much regardless of what it was doing. But I haven't looked at any of the current APs. Measure, and measure under full load on all interfaces. And measure a 24 hour cycle to see the watt hours used. -Aaron On Mon, Jun 5, 2017 at 11:22 Jim Gettys <j...@freedesktop.org> wrote: > On Mon, Jun 5, 2017 at 2:01 PM, <dpr...@reed.com> wrote: > >> It doesn't jump to mind, but a radio carrying bits near the edge probably >> won't be used near capacity most of the 24 hours it is operating. Just as >> Iridium was designed to quiesce most of its electronics on the dark side of >> the earth, extending its battery life, you can probably assume that a radio >> in a tree won't be heavily used most of the hours of a 24 hour cycle. >> > > Turns out that (at least in OLPC days), the signal processing in the WiFi > module dominated power consumption (relative to the radios themselves). At > the time, power consumption was of order 1 watt and the radios themselves > consuming only a fraction of that. > > I don't know what the current chips/modules consume, however. > > Another big consumer turns out to sometimes be ethernet chips; gigabit > nic's often take/took a watt of power. > > So your mileage varies, and you cannot easily presume its one thing or the > other, but need to measure (which we did extensively for OLPC, to get its > power consumption down to where it is) and fix lots of software. > > Linux itself is pretty decent for power management these days: but all it > takes is a single chip/subsystem or stupid applications to blow that up. > So the whole bus structure has to be understood and properly done, and some > technologies are pretty hopeless. > > The details matter. Unfortunately, home routers have generally been plug > in devices, and the vendors haven't paid much attention. > - Jim > > > > >> >> >> >> On Monday, June 5, 2017 1:52pm, dpr...@reed.com said: >> >> > "Deep discharge" batteries work in LEO satellites for such >> applications. But they >> > are extraordinarily expensive, because the designs are specialized, and >> that use >> > case doesn't have the 2-3 day solar outage problem. >> > >> > You are not going to put a good enough system for an AP up in a tree. >> Maybe on an >> > antenna mast structure with solid base and guy wires. Roofs and ground >> are better >> > choices. >> > >> > But I would wonder whether redesigning the AP itself to be >> power-conserving would >> > be the place to start. They are not designed to be "low power" - they >> are designed >> > to be inexpensive. >> > >> > So, for example: why 12V??? No logic needs 12V. Integrate the battery >> into the AP >> > and run it at 3V, eliminating multiple conversion losses. >> > >> > You can use 12/20 V off the solar panel to charge the 3V battery system >> (high >> > current only while charging). >> > >> > Pay lots of attention to the duty cycle of the radio. If you really >> expect the >> > radio to be on 100% of the time, you may have to power it all the time. >> Otherwise, >> > minimize uptime. Similarly, the processor need not be on most of the >> time if it >> > is mostly idle while accepting and sending packets from memory. (ARM >> BIG.little >> > might be helpful). >> > >> > Get rid of Linux if possible. Linux is not a low-power OS - needs a lot >> of work in >> > configuring or rewriting drivers to cut power. (there's a need for an >> LP Linux, >> > but like Desktop Linux, Linus, and his coterie, isn't terribly >> interested in >> > fixing his server OS to optimize for non-servers, so "server power >> saving" is the >> > only design point for power). >> > >> > >> > >> > >> > On Monday, June 5, 2017 12:01pm, "Richard Smith" <smithb...@gmail.com> >> said: >> > >> >> On 06/04/2017 08:49 PM, Dave Taht wrote: >> >>> I keep finding nicely integrated solar/battery/camera/wifi designs >> >>> >> >>> >> https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Delectronics&field-keywords=solar+wifi&rh=n%3A172282%2Ck%3Asolar+wifi >> >>> >> >>> But what I want is merely an solar/battery/AP design well supported by >> >>> lede... and either the ath9k or ath10k chipset - or mt72 - that I can >> >>> hang off a couple trees. I've not worked with solar much in the past >> >>> years, and picking the right inverter/panel/etc seems like a pita, but >> >>> perhaps there are ideas out there? >> >> >> >> This is something I was up against constantly when I worked for OLPC. >> >> There's a big gap for products that use more power than a cell phone >> but >> >> less than an RV or a off-grid cabin. >> >> >> >> For the XO itself we worked around it by designing the front end of the >> >> XO to be able to handle the range of output voltages from "12V" panels >> >> (open circuit voltages up to 20V) and to implement an MPPT algorithim >> in >> >> the EC firmware. You can plug up any solar panel with a Voc of 20V or >> >> less to an XO-1.5 to XO-4 and it will DTRT. >> >> >> >> Figuring out what to do with the deployment's APs though was always a >> >> struggle. >> >> >> >> Solutions exist but you need to get a good estimate of what sort of >> >> power budget you need. It makes a big difference in what equipment you >> >> need. >> >> >> >> Unless its a really low power device the numbers can get large fast. >> >> >> >> My WNDR 3700v2 power supply is rated at 12V 2.5A which is a peak of >> 30W. >> >> >> >> Lets assume your average is 30% of peak. That's 9W. Your 24h energy >> >> requirement is 216Wh. A reasonable input to usable efficiency for a PV >> >> system is 70%. Given average 5 hour window of full sun you need a PV >> >> output of at least 62W. It only goes up from there. >> >> >> >> Realistically you need to survive a 2-3 day period of terrible solar >> >> output. So your storage requirements should be at least 2-3x that. >> >> When you do get sun again you need excess PV capacity to be able to >> >> recharge your batteries. You would probably need a PV output in the >> >> 100W-150W range to make a system you could count on to have 100% >> >> availability 24/7. >> >> >> >> That's going to be a pretty big chunk of hardware up in a tree. >> >> >> >> If the average power draw is more in the 3W or 1W range then things >> look >> >> a lot better. That starts to get down into the 40 and 20W range. >> >> >> >>> so am I the only one left that likes edison batteries? you don't need >> >>> a charge controller... they last for a hundred years.... >> >>> _______________________________________________ >> >> >> >> I've never used this battery type but it looks like the resistant to >> >> overcharge assumes you replace the electrolyte. All the cells I've >> >> looked at on a few sites seem to be flooded which means maintenance. >> >> Are there sealed maintenance free versions? >> >> >> >> For discharge nominal is 1.2V but charging is listed as ~1.6V/cell so >> >> you are going to need 16V to charge. I don't really see how you can >> >> build a workable system with out some sort of setup that can isolate >> >> your 12V loads from a 16V charge. >> >> >> >> Perhaps undercharge them at a lower voltage and live with the capacity >> >> loss? >> >> >> >> -- >> >> Richard A. Smith >> >> _______________________________________________ >> >> Cerowrt-devel mailing list >> >> Cerowrt-devel@lists.bufferbloat.net >> >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> >> >> > >> > >> > _______________________________________________ >> > Cerowrt-devel mailing list >> > Cerowrt-devel@lists.bufferbloat.net >> > https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > >> >> >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel >
_______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel