Solar-powered cloud computing

Building a private cloud from scratch using low-power equipment

Similar projects worth following
At my workplace, we do a lot of software and SCADA type development which necessitates setting up virtual machines for testing projects. Then there's the needs of production workloads. So a private cloud was needed.
At my home, I have an aging Intel Atom D525-based webserver that has served me well for the past 5½ years, but is now starting to run out of puff. In addition, it's a base-load energy consumer, running 24×7. In addition to having something that can run VMs, it'd be great to have some redundancy and be semi-independent from the mains grid.
The aim of this project is to come up with a hardware and software stack that can be scaled up to meet the needs of small/medium business in a cost-effective manner and as an engineering challenge, be green at the same time.

Cluster specifications

  • Storage and compute nodes:
  • Storage nodes (3×):
    • RAM: 16GB ECC DDR3
    • HDD: HGST HTS541010A9 1TB
    • Storage software: Ceph 10.2
  • Compute nodes (2×):
    • RAM: 32GB ECC DDR3
    • Virtualisation software: KVM managed through OpenNebula
  • Network fabric: Linksys LGS326-AU, modified to run off 12V.  (I am looking to upgrade this to a Netgear GS748T as I have filled up the Linksys' ports.  I have the relevant parts to do this.)
  • Solar input: 3×120W 12V panels
  • Battery bank: 2×105Ah 12V AGM
  • Monitoring node:
    • Technologic Systems TS-7670v2 revision D
    • CPU: Freescale^WNXP i.MX286 at 454MHz ARMv5 (single-core)
    • RAM: 128MB
    • SSD: On-board 2GB eMMC
    • OS: Debian Stretch for now, but am compiling a port of Gentoo/musl which I'll release in due course.

What is this cluster doing?

Since late June 2016, it has been in production running a number of websites:

…among lots of ad-hoc projects.

It also has been used on a few occasions to run test instances at my workplace, in one case, providing about 5 virtual machines to try out Kubernetes, and in another, spinning up a test instance of WideSky, because our usual hosting provider (Vultr) was full (specifically their Sydney data centre).  For that reason, this equipment appears on my tax records.

In March 2018, I officially decommissioned the old Intel Atom D525 server that had been running much of my infrastructure to date, doing a physical-to-virtual migration of the old server onto a VM.  The old box was re-configured to just power on at 9PM so that its cron jobs could do a back-up of the real instances, then shut down.  This machine has since been reloaded, still performs the same function but now the OS is stripped down to the bare essentials.  (Thank-you Gentoo/musl.)

I may yet convert it to run off 12V with the cluster too as the PSU fan is making noises, we'll see.

Can it run entirely off solar?

In good weather, yes.  If there's good sunlight during the day.  An extra battery and another panel would help here, and I'm considering doing exactly that.

For now though, it runs both mains and solar, which already has reduced our power bill.

If doing it again, what would I do different?

  • The switch: the Linksys can't do LACP with more than 4 LAGs, whereas the Netgear one can do the required number of LAGs.
  • At the time that Supermicro board was one of the best options available, but buying DDR3 ECC SO-DIMMs is a pain.  There are newer ones now that aside from having more cores (up to 16!), take full-size DDR4 ECC DIMMs which are easier to come by.
  • The rack could be a bit taller (not a show stopper though)
  • Getting ATX DC-DC PSUs that can tolerate up to 16V natively.  (I think mini-box were out-of-stock of the other models, hence I took the ones I have and used LDOs to hack around the problem.)


Battery selection circuit (Logisim)

circ - 9.82 kB - 03/22/2017 at 11:07


Revised charger design with PCB layout

Zip Archive - 60.48 kB - 09/30/2016 at 09:32


  • 5 × Supermicro A1SAi-2750F Mini-ITX Intel Atom C2750 motherboard
  • 5 × Mini-Box M350 Mini-ITX Case
  • 5 × Mini-Box PicoPSU 160-XT 12V ATX PSU
  • 5 × Samsung 850EVO 120GB Solid State Drive
  • 5 × Kingston 8GB Unbuffered ECC SO-DIMM Memory

View all 17 components

  • Power controller installed

    Stuart Longland09/16/2018 at 02:59 0 comments

    Well, I finally got around to installing that power controller.

    Yes, the top of that rack is getting to be a pigsty.  Even the controller isn't my best work:

    You can see above I've just tacked wires onto the points I need and brought those out to a terminal strip.  There's provision there for some PWM-controlled fans, but right now this is unused.  I've omitted the parts not required for the application.  If this works out, I might consider doing another board, this time better dedicated to the task at hand.

    With that controller in place, I've now wound the charger back up.  In fact I made a whoopsie at first: I forgot that the Vout pot on the HEF-600C-12 sets the float voltage and wound that right up to 14.4V which meant a boost voltage of 15V!

    Thankfully I looked over at the volt meter on the solar controller and realised my mistake quick.  15 seconds won't hurt anything, but it is now set at 13.6V.  You don't even see it on the 40-sample average.  The controller should let the mains charger sit there for an hour before it reconsiders the need for mains.

    I think my next step … there's a yard that could do with a hair cut… I'll drag the mower out and chase that around the yard for a bit.  Then we'll see what it looks like.

    Okay, back from a little mowing… and sure enough, the controller is mostly doing the right thing.  I think I'll need to tweak some set-points, maybe set the solar threshold lower.  Thankfully the "inhibit" LED is just an indication that it considers the solar voltage low, the solar is going to be on no matter what.

    Yes, that SSR is massive for the job.  It's what I had on hand at the time.  I'll probably replace it with something small, maybe a reed relay since they're cheap.

    Right at this point, I have the SSR's inputs connected between the solar V+ and the BC-547B on the board, so when the sun *does* go down, the mains power will be turned back on no matter what the controller thinks.

    A close-up look of the status LEDs shows what mode we're in:

    We'll ignore the temperature ones.  Ultimately they indicate the state of the fan controller, and in this state, it'd be running the fans, as indicated by the Fan PWM LED to the left.  Temperature is measured by the sensor in the ATTiny24A on-board, so not highly accurate.

    The other mystery "LED" is the shiny surface on the BC-547B to the left of the two source status LEDs.

    Here, I suspect the sun ducked behind a cloud so the voltage dropped, hence both "inhibit" LEDs came on.  Earlier, "Float" was lit (you can sort-of make it out in the previous photo), the charger was actually actively trying to charge the battery, but to the controller it looked to be done.  It left it go for the hour as programmed, then turned off the mains charger to let the solar panel take over.

    The idea is that during the day, if it gets low, give it a boost from mains, then go back to solar.  We only want to rely on mains at night.

    Now, it should stay in that state until tonight, when the lack of sun should bring the mains charger online (by sheer fact that the solar panels power the "coil" of the relay).

    So, I saw that, and had a look… sure enough, the controller is still asserting that the mains charger should be off.  I think I need to bump the battery thresholds up a bit, although that's still safely above the danger zone, it's lower than I'm comfortable with.

    Right up until 5:58PM, it seems the MCU just held on, thinking the battery voltage was "good enough", so no need for a charge yet.  I might want to drop the solar threshold down some so it doesn't "flap" when broken cloud passes over, then raise the minimum battery threshold a bit.

    Even now, the thing that's turning the mains charger on is the fact that the 1.5V coming off the panels is not sufficient for...
    Read more »

  • Thank goodness for good monitoring

    Stuart Longland09/13/2018 at 12:02 0 comments

    A few months back now, I had the misfortune of overshooting my Internet quota, and winding up with a AU$380 bill for the month (and that was capped… in truth it was more like AU$3000).  In fact, it happened a couple of times until I finally nailed down the cause.

    Part of it was NTP traffic (seems lots of cowboys write SNTP clients now and point them at, some was the Spambot Hunter Project and related activity.  In short, I invested some money into upping the quota, and some time into better monitoring.

    I wanted to do the monitoring anyway to keep an eye on operations, as well as things like the solar panel voltages, etc.  Since I got it in place, I've been able to get much faster notifications of when things go awry.  Much sooner than the 120% quota usage alarm that Internode sends you.

    I'm glad I did that now, last night I left a few tabs open on the site.  I noticed this evening they were still trying to load something and got suspicious… then I saw this:

    Double checking, sure enough, something on one of those pages made Chromium get its knickers into a twist, and chew through all that data.

    It took me a bit of tinkering to get the right query to extract the above chart.  Essentially there was a sustained 1.5MB/sec download for over 21 hours which would account for the 113.1GB that Internode recorded.

    It's a bit co-incidental that the usage dropped the moment I re-started Chromium.  Not sure why it was continually re-loading pages, but never mind.

    The above data is collected using a combination of collectd and InfluxDB, with Grafana doing the dashboarding and alarms, and a small Perl script pulling the usage data off Internode's API.

  • Return of the power controller

    Stuart Longland09/01/2018 at 06:23 0 comments

    Well, I've been tossing up how to control the mains charger for a while now.

    When I first started the project, my thinking was to use an old Xantrex charger we had kicking around, and just electrically disconnect it from the batteries when we wanted to use the solar power.  I designed a 4-layer PCB which sported a ATTiny24A microcontroller, MOSFETs (which I messed up) and some LEDs.

    This was going to be a combined fan controller and power management unit.  It had the ability (theoretically) to choose a supply based on the input voltage, and to switch if needed between supplies.

    It didn't work out, the charger got really confused by the behaviour of the controller.  I was looking to re-instate it using the Redarc solar controller, but I never got there.  In the end, it was found that the Redarc controller had problems switching sources and would do nothing whilst the batteries went flat.

    We've now replaced both ends of the system.  The solar controller is a Powertech MP3735 and integrates over-discharge protection.  The mains charger is now a MeanWell HEP-600C-12 (which has not missed a beat since the day it was put in).

    Unlike my earlier set-up, this actually has a 5V logic signal to disable it, and my earlier controller could theoretically generate that directly.

    Looking at the PCB of my earlier power controller attempt, it looks like this could still work.

    Above is the PCB artwork.  I've coloured in the sections and faded out the parts I can omit.

    In green up the top-left we have the mains control/monitoring circuitry.  We no longer see the mains voltage, so no point in monitoring it, so we can drop the resistor divider that fed the ADC.  This also means we no longer need the input socket P2.

    Q2 and Q7 were the footprints of the two P-channel MOSFETs.  We don't need the MOSFETs themselves, but the signals we need can be found on pin 1 of Q2.  This is actually the open-drain output of Q1, which we may be able to hook directly to the REMOTE+ pin on the charger.  A pull-up between there and the charger's 5V rail, and we should be in business.

    In yellow, bottom left is the solar monitoring interface.  This is still useful, but we won't be connecting solar to the battery ourselves, so we just keep the monitoring parts.  The LED can stay as an indicator to show when solar is "good enough".

    In purple, occupying most of the board, is the controller itself.  It stays for obvious reasons.

    In red, is the fan control circuitry.  No reason why this can't stay.

    In blue is the circuitry for monitoring the battery voltage.  Again, this stays.

    The main advantage of doing this is I already have the boards, and a number of microcontrollers already present.  There's a board with all except the big MOSFETs populated: with the MOSFETs replaced by 3-pin KK sockets.

    How would the logic work?  Much the same as the analogue version I was pondering.

    • If battery voltage is low, OR, the sun has set, enable the mains charger.

    What concerned me about an analogue solution was what would happen once the charger got to the constant-voltage stage.  We want to give it a bit of time to keep the battery topped up.  Thus it makes sense to shut down the charger after a fixed delay.

    This is easy to do in a microcontroller.  Not hard with analogue electronics either, it's fundamentally just a one-shot, but doing it with an MCU is a single-chip solution.  I can make the delay as long as I like.  So likely once the battery is "up to voltage", I can let it float there for an hour, or until sunrise if it's at night.

  • Kernel driver now up on Github

    Stuart Longland08/30/2018 at 11:31 0 comments

      So, I'm happy enough with the driver now that I'll collapse down the commits and throw it up onto the Github repository.  I might take another look at kernel 4.18, but for now, you'll find them on the ts7670-4.14.67 branch.

      Two things I observe about this voltage monitor:

      1. The voltage output is not what you'd call, accurate.  I think it's only a 10-bit ADC, which is still plenty good enough for this application, but the reading I think is "high" by about 50mV.
      2. There's significant noise on the reading, with noticeable quantisation steps.

      Owing to these, and to thwart the possibility of using this data in side-channel attacks using power analysis, I've put a 40-sample moving-average filter on the "public" data.

      Never the less, it's a handy party trick, and not one I expected these devices to be able to do.  My workplace manages a big fleet of these single-board computers in the residential towers at Barangaroo where they spend all day polling Modbus and M-Bus meters.  In the event we're at all suspicious about DC power supplies though, it's a simple matter to load this kernel tree (they already run U-Boot) and configure collectd (which is also installed).

      I also tried briefly switching off the mains power to see that I was indeed reading the battery voltage and not just a random number that looked like the voltage.  That yielded an interesting effect:

      You can see where I switched the mains supply off, and back on again.  From about 8:19PM the battery voltage predictably fell until about 8:28PM where it was at around 12.6V.

      Then it did something strange, it rose about 100mV before settling at 12.7V.  I suspect if I kept it off all night it'd steadily decrease: the sun has long set.  I've turned the mains charger back on now, as you can see by the step-rise shortly after 8:44PM.

      The bands on the above chart are the alert zones.  I'll get an email if the battery voltage strays outside of that safe region of 12-14.6V.  Below 12V, and I run the risk of deep-cycling the batteries.  Above 14.6V, and I'll cook them!

      The IPMI BMCs on the nodes already sent me angry emails when the battery got low, so in that sense, Grafana duplicates that, but does so with pretty charts.  The BMCs don't see when the battery gets too high though, for the simple matter that what they see is regulated by LDOs.

  • Getting the battery voltage into Grafana

    Stuart Longland08/29/2018 at 22:31 0 comments

    I've succeeded in getting a working battery monitor kernel module.  This is basically taking the application note by Technologic Systems and spinning that into a power supply class driver that reports the voltage via sysfs.

    As it happens, the battery module in collectd does not see this as a "battery", something I'll look at later.  For now the exec plug-in works well enough.  This feeds through eventually to an InfluxDB database with Grafana sitting on top.

  • Kernel driver debugging

    Stuart Longland08/28/2018 at 12:45 0 comments

    So, I successfully last night, parted the core bits out of ts_wdt.c and make ts-mcu-core.c.  This is a multi-function device, and serves to provide a shared channel for the two drivers that'll use it.

    Tonight, I took a stab at writing the PSU part of it.  Suffice to say, I've got work to do:

    [  158.712960] Unable to handle kernel NULL pointer dereference at virtual address 00000005
    [  158.721328] pgd = c3854000
    [  158.724089] [00000005] *pgd=4384f831, *pte=00000000, *ppte=00000000
    [  158.730629] Internal error: Oops: 1 [#3] ARM
    [  158.734947] Modules linked in: 8021q garp mrp stp llc nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables flexcan can_dev
    [  158.755812] CPU: 0 PID: 2059 Comm: cat Tainted: G      D         4.14.67-vrt-ts7670+ #3
    [  158.763840] Hardware name: Freescale MXS (Device Tree)
    [  158.769008] task: c68f3a20 task.stack: c3846000
    [  158.773598] PC is at ts_mcu_transfer+0x1c/0x48
    [  158.778073] LR is at 0x3
    [  158.780630] pc : []    lr : [<00000003>]    psr: 60000013
    [  158.786918] sp : c3847e44  ip : 00000000  fp : 014000c0
    [  158.792165] r10: c5035000  r9 : c5305900  r8 : c777b428
    [  158.797412] r7 : c0a7fa80  r6 : c777b400  r5 : c5035000  r4 : c3847e6c
    [  158.803961] r3 : c3847e58  r2 : 00000001  r1 : c3847e4c  r0 : c07b8c68
    [  158.810512] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
    [  158.817671] Control: 0005317f  Table: 43854000  DAC: 00000051
    [  158.823440] Process cat (pid: 2059, stack limit = 0xc3846190)
    [  158.829212] Stack: (0xc3847e44 to 0xc3848000)
    [  158.833611] 7e40:          c05bd150 00000001 00010000 00000004 c3847e48 00000150 c5035000
    [  158.841833] 7e60: c777b420 c05bcaa4 c4f70c60 c777e070 c0a7fa80 c05bca20 00000fff c07ad4b0
    [  158.850051] 7e80: c777b428 c04e46dc c4f52980 00001000 00000fff c01b1994 c4f52980 c4f70c60
    [  158.858268] 7ea0: c3847ec8 ffffe000 00000000 c3847f88 00000001 c0164eac c3847fb0 c4f529b0
    [  158.866487] 7ec0: 00020000 b6e3d000 00000000 00000000 c4f73f70 00000800 00000000 c01b0f60
    [  158.874703] 7ee0: 00020000 c4f70c60 ffffe000 c3847f88 00000000 00000000 00000000 c013eb84
    [  158.882918] 7f00: 000291ac 00000000 00000000 c0009344 00000077 b6e3c000 00000022 00000022
    [  158.891135] 7f20: c686bdc0 c0117838 000b6e3c c3847f80 00022000 c686be14 b6e3c000 00000000
    [  158.899354] 7f40: 00000000 00022000 b6e3d000 00020000 c4f70c60 ffffe000 c3847f88 c013ed0c
    [  158.907571] 7f60: 00000022 00000000 000b6e3c c4f70c60 c4f70c60 b6e3d000 00020000 c000a9e4
    [  158.915786] 7f80: c3846000 c013f2d8 00000000 00000000 00000000 00000000 00000000 00000000
    [  158.924002] 7fa0: 00000003 c000a820 00000000 00000000 00000003 b6e3d000 00020000 00000000
    [  158.932217] 7fc0: 00000000 00000000 00000000 00000003 00020000 00000000 00000001 00000000
    [  158.940434] 7fe0: be8a62c0 be8a62ac b6eb77c4 b6eb6b9c 60000010 00000003 00000000 00000000
    [  158.948691] [] (ts_mcu_transfer) from [] (ts_psu_get_prop+0x38/0xb0)
    [  158.956847] [] (ts_psu_get_prop) from [] (power_supply_show_property+0x84/0x220)
    [  158.966036] [] (power_supply_show_property) from [] (dev_attr_show+0x1c/0x48)
    [  158.974974] [] (dev_attr_show) from [] (sysfs_kf_seq_show+0x84/0xf0)
    [  158.983129] [] (sysfs_kf_seq_show) from [] (seq_read+0xcc/0x4f4)
    [  158.990930] [] (seq_read) from [] (__vfs_read+0x1c/0x11c)
    [  158.998117] [] (__vfs_read) from [] (vfs_read+0x88/0x158)
    [  159.005304] [] (vfs_read) from [] (SyS_read+0x3c/0x90)
    [  159.012232] [] (SyS_read) from [] (ret_fast_syscall+0x0/0x28)
    [  159.019766] Code: e52de004 e281300c e590e004 e25cc001 (e1dee0b2) 
    [  159.026278] ---[ end trace 2807dc313991fd87 ]---

     The good news is the machine didn't crash.

  • Battery voltage kernel module

    Stuart Longland08/26/2018 at 13:07 0 comments

    So, I had a brief look after getting kernel 4.18.5 booting… sure enough the problem was I had forgotten the watchdog, although I did see btrfs trigger a deadlock warning, so I may not be out of the woods yet.  I've posted the relevant kernel output to the linux-btrfs list.

    Anyway, as it happens, that watchdog driver looks like it'll need some re-factoring as a multi-function device.  At the moment, ts-wdt.c claims it based on this binding.

    If I try to add a second driver, they'll clash, and I expect the same if I try to access it via userspace.  So the sensible thing to do here, is to add a ts-companion.c MFD driver here, then re-factor ts-wdt.c to use it.  From there, I can write a ts-psu.c module which will go right here.

    I think I'll definitely be digging into those older sources to remind myself how that all worked.

  • Battery monitor PC now running Gentoo

    Stuart Longland08/25/2018 at 11:34 0 comments

    So, after some argument, and a bit of sitting on a concrete floor with the netbook, I managed to get Gentoo loaded onto the TS-7670.  Right now it's running off the MicroSD card, I'll get things right, then shift it across to eMMC.

    ts7670 ~ # emerge --info
    Portage 2.3.40 (python 3.5.5-final-0, default/linux/musl/arm/armv7a, gcc-6.4.0, musl-1.1.19, 4.14.15-vrt-ts7670-00031-g1a006273f907-dirty armv5tejl)
    System uname: Linux-4.14.15-vrt-ts7670-00031-g1a006273f907-dirty-armv5tejl-ARM926EJ-S_rev_5_-v5l-with-gentoo-2.4.1
    KiB Mem:      111532 total,     13136 free
    KiB Swap:    4194300 total,   4191228 free
    Timestamp of repository gentoo: Fri, 17 Aug 2018 16:45:01 +0000
    Head commit of repository gentoo: 563622899f514c21f5b7808cb50f6e88dbd7d7de
    sh bash 4.4_p12
    ld GNU ld (Gentoo 2.30 p2) 2.30.0
    app-shells/bash:          4.4_p12::gentoo
    dev-lang/perl:            5.24.3-r1::gentoo
    dev-lang/python:          2.7.14-r1::gentoo, 3.5.5::gentoo
    dev-util/pkgconfig:       0.29.2::gentoo
    sys-apps/baselayout:      2.4.1-r2::gentoo
    sys-apps/openrc:          0.34.11::gentoo
    sys-apps/sandbox:         2.13::musl
    sys-devel/autoconf:       2.69-r4::gentoo
    sys-devel/automake:       1.15.1-r2::gentoo
    sys-devel/binutils:       2.30-r2::gentoo
    sys-devel/gcc:            6.4.0-r1::musl
    sys-devel/gcc-config:     1.8-r1::gentoo
    sys-devel/libtool:        2.4.6-r3::gentoo
    sys-devel/make:           4.2.1::gentoo
    sys-kernel/linux-headers: 4.13::musl (virtual/os-headers)
    sys-libs/musl:            1.1.19::gentoo
        location: /usr/portage
        sync-type: rsync
        sync-uri: rsync://
        priority: -1000
        sync-rsync-verify-jobs: 1
        sync-rsync-verify-metamanifest: yes
        sync-rsync-verify-max-age: 24
    CFLAGS="-Os -pipe -march=armv5te -mtune=arm926ej-s -mfloat-abi=soft"
    CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
    CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/sandbox.d /etc/terminfo"
    CXXFLAGS="-Os -pipe -march=armv5te -mtune=arm926ej-s -mfloat-abi=soft"
    FCFLAGS="-O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard"
    FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync multilib-strict news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
    FFLAGS="-O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard"
    LDFLAGS="-Wl,-O1 -Wl,--as-needed"
    PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
    USE="arm bindist cli crypt cxx dri fortran iconv ipv6 modules ncurses nls nptl openmp pam pcre readline seccomp ssl tcpd unicode xattr zlib" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon plan sheets...
    Read more »

  • Gentoo Linux MUSL for ARMv5 finally built

    Stuart Longland08/22/2018 at 11:34 0 comments

    It's taken several months and had a few false starts, but at long last I have some stage tarballs for Gentoo Linux MUSL for ARMv5 processors.  I'm not the only one wanting such a port, even looking for my earlier thread on the matter, I stumbled on this post.  (Google translate is hopeless with Russian, but I can get the gist of what's being said.)

    This was natively built on the TS-7670 using an external hard drive connected over USB 2.0 as both swap and the chroot.  It took two passes to clean everything up and get something that's in a "release-able" state.

    I think my next steps now will be:

    • Build an updated kernel … I might see if I can expose that I²C register via a sysfs file or something that collectd can pick up whilst I'm at it.  I have the kernel sources and bootloader sources.
    • Prepare the 32GB MicroSD card I bought a few weeks back with the needed partitions and load Gentoo onto that.
    • Install the MicroSD card and boot off it.
    • Back up the eMMC
    • Re-format the eMMC and copy the MicroSD card to it.

    It's supposed to be wet this weekend, so it sounds like a good project for indoors.

  • Measuring the battery voltage

    Stuart Longland08/19/2018 at 01:38 0 comments

    So, I was just updating the project details for this project, and I happened to see this blog post about reading the DC voltage input on the TS-7670v2.

    I haven't yet gotten around to finishing the power meters that I was building which would otherwise be reading these values directly, but they were basically going to connect via Modbus to the TS-7670v2 anyway.  One of its roles, aside from routing between the physical management network (IPMI and switch console access), was to monitor the battery.

    I will have to explore this.  Collectd doesn't have a general-purpose I²C module, but it does have one for barometer modules, so with a bit of work, I could make one to measure the voltage input which would tell me what the battery is doing.

View all 88 project logs

Enjoy this project?




[this comment has been deleted]

Stuart Longland wrote 04/11/2016 at 17:31 point

Note: This is in reply to a comment that has since been deleted, from a user that's no longer with us referencing a project that's been deleted.  The original comment read "check this out - it helps you with power […deleted project URL here…]",   The project was called the "MEDELIS battery", and there are still some videos on YouTube.

"Free Geen[sic] Energy" eh?

I did see the project but the page has almost no detail other than a link and a video.  The link offers little information either.  I was hoping the project page would have some sort of information into what chemical reaction is taking place or what power output is feasible for what volume of water.

It sounds a lot like the description here: in which, the magnesium electrode gets depleted.  So I'd be replacing magnesium electrodes as well as water. suggests about 1.5V and a few milliamps current are possible.

This project draws a lot more power than the LED shown in the photo, or a phone charging for that matter.  Even "turned off", the computers in this cluster together draw 15W due to IPMI management.  On Saturday, I had them doing system updates (compiling from source), that drew about 70-80W, and the nodes were barely getting started.

Flat chat, I can expect each node to draw up to 2A, at 12V that's 24W, or 120W for the cluster, not including network switch.  Overnight it'd draw nearly 1.5kW.  I'd imagine it'd need to be scaled up quite considerably, and water is not a "free" resource.  The above numbers suggest something in the order of 64000 cells, and then we don't know what the internal resistance is.

In urban areas like where I am, the primary water supply is the mains feed which is billed by the kilolitre.  Australia is quite a dry climate, and so I'd imagine you'd need quite a big water tank to get you through between showers of rain.  Sun on the other hand, seems plentiful, and lead-acid batteries, for all their faults and failings, are cheap.

I think on that basis until there's some more detail (videos are good for demonstration but not documentation), I'll stick to what's proven.

Added note: The copper-magnesium-water battery described in that deleted project however, probably has some useful applications where very low power is all that's needed.  So still worthy of consideration in those cases.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates