project bbb - victronenergy/venus GitHub Wiki

EDIT 2020-04-29: Already a long time ago this project was completed, and resulted in the Venus GX.

Introduction to the Venus GX

We wanted to have a lower cost Color Control GX. And decided to do that using readily available hardware such as the raspberrypi2 or beaglebone. With the Remote Console function, available in Venus, which the OS running on the CCGX, since a while now, the onboard LCD and buttons are no longer necessary. Leaving them out seriously drops the cost as well.

After comparing the raspberrypi2 and the beaglebone black (read the comparison), we found the BeagleboneBone Enhanced from Sancloud. The bbe is a modified bbb: it has built-in WiFi and BLE, exactly what we need. We will procure a special, somewhat stripped down, version: no hdmi, no gigabit ethernet, and some more changes. All to drop costs. Details here.

The Venus GX, a Victron product expected to be in stock latest end of 2017 Q1, consists of:

  • Beaglebone Enhanced (with some costdown modifications)
  • ve-cape
  • enclosure
  • accessories like power cable

ve-cape

There will be a cape, a base PCB, containing:

  • a wide input DC power supply
  • mk3 ic (for VE.Bus ports)
  • VE.Can port
  • extra canbus port
  • two VE.Direct ports
  • And three resistive tank level inputs, two temp sense inputs, one 5V DC out, 5 pulse counter inputs and two programmable relays

The ve-cape is called the ve-cape and is optional for running Venus: Venus runs both on the BBB and the BBE, also without the ve-cape.

More info:

Installing the image

See bbb user instructions for details of the latest image, and instructions on how to install it.

Help is welcome!

Just downloading and running a test image, and letting us know what issues you see is already very valuable help. Find the latest test image on the mailing list. That list is also the place to post your findings.

More active help is welcome too ofcourse, contact us on that same mailing list, or send an email to [email protected].

Remaining todos

  • Add swupdate. More info here: swupdate project
  • Finish design and then test rev4 of the cape. More info here: bbb ve cape revisions
  • Complete support for VE.Bus connectors. Differs from CCGX in that BBB has an MK3 instead of MK2
  • Make Remote Console on LAN and mandatory, to prevent user locking himself out.
  • Make Remote Console on VRM enabled by default.
  • Change VE.Bus Standby pin assignment once PCB rev 4 is out
  • Complete and close the Beaglebone first release milestone

Add support for manufacturing

  • Write cape hw revision number (which != PCB rev number!) and perhaps other details to eeprom on cape
  • Do the temperature sensor inputs need calibrating? no
  • Do the resistive tank sender inputs need calibrating? no
  • Make scripts/instructions for:
    • analog inputs (new)
    • pulse counter inputs (new)
    • relays (look at ccgx)
    • VE.Direct ports (look at ccgx)
    • MK3 + related io (look at ccgx) <-- is already completed by JJD & JPA
    • RTC + battery (look at ccgx)
    • Canbus 1 and 2 (look at ccgx)
    • s2 boot button on cape (added in pcb rev 4)

Beaglebone Enhanced related:

  • fix the 1G Ethernet. Note that the Victron version of the bbe will have 100M Ethernet again
  • make the onboard wifi work.
  • fix the four user leds don't blink as they are supposed to during an image install. (was hw issue on first bbe samples)

Status updates

Status October 22nd 2016

  • all main wiki pages relating to the BeagleBone project have been updated
  • BeagleBone support is now part of mainstream Venus: there is no longer a need for a separate change log
  • first official BeagleBone supported release will be Venus v2.00.

Status October 21st 2016

  • We are now testing a batch of prototypes ve-cape hw revision 4. See BBB hw revision page on the wiki.
  • I expect that that will be the version we'll use in production.

Plan is to have stock by the end of this year. Stock will be the full units (BBE + ve-cape + enclosure).

Stocking only the capes is planned for later.

Pricing is not defined yet.

On the software side there are various open points. See above list and the github issues.

Status 12 July 2016

  • Enclosure: also more or less finished. Including photos of the first protos. See here
  • Hw-main-board
    • The first protos of our customized beagleboard (removed hdmi, added wifi and ble, added second USB socket) are to arrive any time now. Sancloud is working hard on them.
  • Hw-cape
    • Prototype batch of version 2 is being manufactured now. Expected in a few weeks. Changes compared to version 1:
      • Dropped 0-70 volt measurement as well as the 0-10V measurement. Since those measurements were not using a differential input and did not have a separateground wire, those measurements would be offset by the voltage drop . Better to have no such measurements at all than unreliable ones. And for battery voltage there will always be other devices in the system (Multi, MPPT, etc) with very accurate battery measurement. The two free AD inputs are being left unused for now.
      • Changed resistors on analogue inputs for temperature and tanklevel measurements
      • Added mount option to replace the CR-something battery as used for the RTC with an ultracap
  • Software
    • Most changes have been added to the master branches in Venus. See changelog page for latest image.
    • The implementation of the service, called dbus-adc, that reads data from the ADCs and published its data on the D-Bus is well underway. Tanklevels are complete and can be used in the gui. The temperature senders will follow soon. Note that the project hasn't been added yet as a service to the standard builds
    • Running of the internal emmc instead of the sdcard, as well as automatic updates of the beaglebone firmware, will be implemented once the swupdate project is completed for the CCGX.
    • Run our image on a beaglebone black: see bbb user instructions .

Sightly off-topic but still related: Add RaspberryPi image: besides making the beaglebone image free for download, I also want to make images for the popular raspberrypis. We won't make any special hardware for that. To use them, customers will need to use the USB ports, either with the MK3USB for VE.Bus products (Multis / Quattros), or the VE.Direct to USB interface cable for VE.Direct project such as our MPPT Solar Chargers, the BMV-700 battery monitors and our new low power Phoenix Inverter range. If there is anyone who has good experience with Openembedded, kernel configuration, RaspberryPIs and is willing to do this: please contact me!

Status 26 May 2016

  • Sw -> making Venus work on a CCGX is getting shaped up, see status in the bbb changelog.
  • Hw-cape -> checking the first version of the VE cape is almost finished. We plan to order the next (final?) version early June.
  • Hw-bbb -> Sancloud quoted a custom BBB with 2 USB ports instead of one, and Wifi + Bluetooth 4.0. Samples being made.

Status 14 April 2016

First proto boards of the cape have been ordered and expected to arrive in a few weeks.

Status 11 Mar 2016

Hardware design is well underway, schematics are done and pcb layout has started. See the mailinglist: https://groups.google.com/forum/#!forum/victron-dev-venus.

Status 2 Dec 2015

Hardware spec is well underway, see bbb hardware spec. And even lower cost can be achieved than thought previously: BeagleBone Green, USD 39 instead of 55.

Status 8 Nov 2015

Development is now focused on BBB, no longer on raspberrypi2. New mailinglist was created, see here: https://groups.google.com/forum/#!forum/victron-dev-venus.

Status 16 Oct 2015

Download the latest image for the rpi2 here.

Install it on an sdcard with win32 disk imager or a similar tool (dd for linux).

Details:

  • it boots
  • gui works
  • remote console (= VNC over websockets) is enabled, without password: navigate to the ip address in your webbrowser
  • ssh is by default disabled: enable remote support in Settings -> General to start sshd
  • root password is empty
  • packages that work: vrmlogger, dbus_systemcalc, localsettings, dbus-vebus-to-pvinverter, websockify-c,
  • dbus_fronius probably works, but not tested yet
  • dbus-qwacs (wireless ac sensors) seems to work as well
  • inserting the ve.direct to usb interface into one of the usb slots does not result in a ttyUSB being added in /dev.
  • all other packages has not been looked at yet

Compiling for raspberry pi2

Note, this needs access to several private repos at Victron Energy

  1. checkout venus from github.com/victronenergy
  2. fetch all the repos, see make fetch-all or similar in Makefile
  3. checkout the fido_venus branch on all repos

And then:

export MACHINE=raspberrypi2
make bb
bitbake -k venus-full-image

(the -k is there to make it continue with other packages when one package fails to build)

Initial software / platform investigations

As a first step, the openembedded branches used are updated from Danny (still used for ccgx) to the more recent Jethro. Work in progress, see commits in the different jethro_venus branches: meta-victronenergy, meta-victronenergy-overlay and openembedded-core. Full list of software requirements are here: bbb sw system requirements.

Finding the (probably) right meta for the raspberrypi2 was easy, as the only active repo I could find is this one: https://github.com/agherzan/meta-raspberrypi. For the bbb there are more options to be considered:

  1. http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/?h=jethro (more info here
  2. https://github.com/jumpnow/meta-bbb
  3. http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/

And there are many more lingering around on the web.

Issues while building Venus for other hardware

  1. System expects /data. On the CCGX, this partition is auto created when can't be mounted. See meta-ccgx/recipes-bpp3/recipes-core/initscripts/ubiattach.sh.
  2. System expects svscan from daemontools to monitor /service

And obviously there is a lot more todo.

Changes to Venus to better support different hardware

  1. Make the CCGX just mount the data partition (and the build system should then take care of creating it), instead of making it. To make it less machine specific