Project Logs

Collapse logs

• Power controller installed

  Stuart Longland • 09/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 Longland • 09/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 pool.ntp.org), some was the #Hackaday.io 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 Hackaday.io 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 Longland • 09/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 Longland • 08/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 Longland • 08/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.

  https://netmon.longlandclan.id.au/d/IyZP-V2mk/battery-voltage?orgId=1
  

• Kernel driver debugging

  Stuart Longland • 08/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 Longland • 08/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 Longland • 08/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
  Repositories:
  
  gentoo
      location: /usr/portage
      sync-type: rsync
      sync-uri: rsync://virtatomos.longlandclan.id.au/gentoo-portage
      priority: -1000
      sync-rsync-verify-jobs: 1
      sync-rsync-extra-opts: 
      sync-rsync-verify-metamanifest: yes
      sync-rsync-verify-max-age: 24
  
  ACCEPT_KEYWORDS="arm"
  ACCEPT_LICENSE="* -@EULA"
  CBUILD="arm-unknown-linux-musleabi"
  CFLAGS="-Os -pipe -march=armv5te -mtune=arm926ej-s -mfloat-abi=soft"
  CHOST="arm-unknown-linux-musleabi"
  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"
  DISTDIR="/home/portage/distfiles"
  ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
  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"
  GENTOO_MIRRORS=" http://virtatomos.longlandclan.id.au/portage http://mirror.internode.on.net/pub/gentoo http://ftp.swin.edu.au/gentoo http://mirror.aarnet.edu.au/pub/gentoo"
  INSTALL_MASK="charset.alias"
  LANG="en_AU.UTF-8"
  LDFLAGS="-Wl,-O1 -Wl,--as-needed"
  PKGDIR="/usr/portage/packages"
  PORTAGE_CONFIGROOT="/"
  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"
  PORTAGE_TMPDIR="/var/tmp"
  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 Longland • 08/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.

  • Announcement on gentoo-embedded list
  • Stage3 tarball image

  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 Longland • 08/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