[Cerowrt-devel] solar wifi ap designs?

Aaron Wood woody77 at gmail.com
Mon Jun 5 14:53:29 EDT 2017


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 <jg at freedesktop.org> wrote:

> On Mon, Jun 5, 2017 at 2:01 PM, <dpreed at 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, dpreed at 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" <smithbone at 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 at lists.bufferbloat.net
>> >> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>> >>
>> >
>> >
>> > _______________________________________________
>> > Cerowrt-devel mailing list
>> > Cerowrt-devel at lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
>> >
>>
>>
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20170605/a7a26783/attachment.html>


More information about the Cerowrt-devel mailing list