Contents

Vision

Easily configurable/usable hardware, software and data platform for monitoring and control of photo-voltaic systems.

The following are the priorities in increasing order of difficulty and time to market:

  • MOV: surge protection device (SPD) status notifier with storage/notification server (2019)
  • MBS: Wired M-Bus (EN1434-3) meter reader with storage/display server (2019)
  • WMB: Wireless M-Bus meter reader (2020)
  • Modbus inverter communication / control -> with an eye on making something similar to SMA Fuel Save controller (2021) and general appliance control (2022).
  • PLC based module level monitoring -> with an eye on the PV roof tile market (2023).

The rest of this document focuses on 2019 targets - MOV+MBS but all components should be built incorporating the longer term vision.

Target market

Small to medium grid-tied PV systems have become common place. The feed-in-tariffs in various countries over the last many years incentivised installing PV systems. Many were installed without monitoring as it increased the up-front expense. Many of these systems now need upgrades and need to be actively monitored to achieve optimal performance. Monitoring for more recent systems with lower feed-in-tariffs is even more important because downtime due to a fault needs to be minimized to achieve financial viability.

As the grid becomes more unstable as more renewable sources feed into it and electric vehicles become more prevalent, equipment connected directly to the grid needs better monitoring and pro-active support and maintenance.

MOV/MBS

Brief

In brief, a Wifi (802.11) connected metal-oxide varistor (MOV) for PV and other applications requiring surge protection and notifications. Should also have the capability of reading upto 3 M-Bus capable meters.

Main components of the device are:

  • An MOV along with serially connected thermal fuse.

  • A Host MCU with Wifi SoC.

  • An M-Bus transceiver in master configuration to read data from upto 5 M-Bus capable meters.

  • Android app for initial provisioning of Wifi SoC.

  • Display indicators (3 green LEDs).

  • Power supply - this is a mains connected device so doesn't need any batteries. A flyback converter to achieve a range of output DC voltages is required. Something like

Device periodically sends the following information:

  • Protection status
  • Location
  • Meter Readings
  • Voltage
  • Temperature
  • Frequency?

Further optional data about the PV system can be shared during configuration.

  • PV System size in KWp
  • PV Module brand/model/rating
  • Inverter brand/model/rating
  • Customer name/contact
  • Installer name/contact
  • Other maintenance related info - last serviced/cleaned etc.

MOV

A metal oxide varistor sits in parallel between mains AC line and neutral and provides a short whenever the voltage between line and neutral spikes above rating. This protects a grid connected PV inverter from voltage spikes which could damage sensitive electronics in the inverter. A thermal fuse sits in series with the varistor which burns out over time (due to short bursts of high current flowing through it) leaving the PV inverter unprotected from future voltage spikes. The status of this thermal fuse is the primary objective of this monitoring device.

Task: Connect SPD to power supply, analyse output and figure out ADC interface circuit (3d)

M-Bus

M-Bus is a European standard protocol for remote reading and configuration of primarily heat/flow meters but has since been used for electricity and water meters as well.

Legacy PV systems can have multiple meters (production/export). The secondary objective of this monitoring device is to capture the meter readings (and thus measure performance) of the PV system.

Task: Simlate the M-Bus master with discrete components in LTSpice to help understanding (2d) Task: Build prototype (1w)

Power Supply

Mains powered AC converted to DC using something like Powerpax PD05-20BXX

Consider something like IH0515S as DC-DC converter for range of +/-15V for M-Bus (check whether that suffices or whether a boost converted is really required for +37V).

Task: Order parts (0.5d) Task: Build prototype (2d) Task: Evaluate PCB design tools - is Kicad fit for purpose ? (2d) Task: Identify and speak with PCB fabricators (2d)

Host MCU

The Host MCU is the heart of the monitoring device. This device will use TI's CC3220S which has a Wifi SoC in the same package as the MCU. Using the GPIO and ADC of the host MCU, the status of the thermal fuse will be monitored.

See TI CC3220S for detailed implementation.

Task: Dust off old development and update tools/platform (1d) Task: Write firmware to process ADC input (1w)

Wifi

TI's CC3220S has a Wifi TCP/IP stack builtin.

Task: Write firmware to connect to Wifi and send data to server (1w)

GPS

The CC3220S will be connected with a GPS module using I2C/SPI.

Task: Evaluate GPS modules (0.5d) Task: Purchase a couple (0.5d) Task: Write firmware to read I2C/SPI GPS module (3d)

Provisioning App

From a user perspective, the following steps should be followed using an Android device to configure the device to use. Configuring the device with a smart phone app reduces device production costs.

  • Download app from Play store
  • Manually connect to the device's (Access Point) AP
  • App receives device ID from device,
  • Enter WAN AP SSID, password and press Configure.
  • Configure converts the device's AP to station (STA) and connects to WAN AP with SSID, password entered in previous step, exchanges device ID with server for a token and stores token on device.
  • One green indicator on device appears if connection to AP successful. Two green indicators appear if ACK token received from server. Three green indicators if the device is fully configured and sending data to the server.

See Android dev setup for detailed setup.

TI SmartConfig

The SmartConfig app uses Android 5.0 APIs with targetSdkVersion 21 which has inbuilt support for Apache HTTP client. Android 6.0 (API Level 23) removes support for the Apache HTTP client so using targetSdkVersion higher than 21 will cause compile errors unless the following is added to build.gradle:

android { useLibrary 'org.apache.http.legacy' }

Task: Customise the SmartConfig app - add grpc client to send exchange config data with server (1w) Task: Convert the SmartConfig app to use Dagger for dependency injection and simultaneouly replace Apache HTTP with okhttp or even GRPC. This may be unnecessary and take very long (2w)

See TI SmartConfig for detailed implementation.

Viewing App

This is the customer facing app where a user can login and view status of SPD and meter reading data.

Task: Customise trac app to viewing app (1w)

Server

Data is an integral part of the vision - so the platform must be built extensible to the longer term vision.

Micro-services in Go using GRPC wherever possible.

Features: + OTA for 'firmware' updates

See m0v server for detailed implementation.

Task: Evaluate proxy servers (Envoy?) (2d) Task: Configure and set up proxy server. (1d) Task: Write the grpc server + http gateway. (5d) Task: Investigate firmware updates (ongoing)

Timeline

Firmware: ADC: 1W Wifi: 1W

Server: 2W

Provisioning app: 3W

Board Layout: 4W

Production + test: 4W

OTA:

Production

  • Parts mounted on single side of PCB
  • SMD components where possible.
  • Rectangular shape - no 90 degree inner angles.

Gotchas

There are products in the market which have similar functionality made by much larger companies with much greater resources.

While the market is very competitive, this product fulfils a combination of niche requirements which is currently missing. Mulitple conversations with mutlple PV installers suggests there is demand even if it's niche.

While existing vendors are focussed on selling hardware, performance data about PV systems is at the heart of this service which could make it very valuable.

References

Future

At some point an M-Bus transceiver in slave mode will also be needed. When the time comes see TSS721A

Device can optionally include a current sensor for power and power-factor measurements - but this will require different wiring as the current sensor will be in series with the flow of power.

Device can have a different version with a Zigbee (or other) radio rather than a Wifi one to connect to a Zigbee (or other) gateway.

Appendices

From Stackexchange M-Bus Master with MCU

We went for a micro controller based approach (ATMEGA), because it just provides a great deal of control and allowed us to implement some user interface specific things and "under the hood" functions. Overall it just seemed easier to realize that a purely analog approach.

Receiving: The controller continuously measures the load current on the bus (shunt resistor) to determine how many devices are connected (idle current). Knowing the nominal current, the controller can detect any device communication (current is increased by one or more of the clients). The idle current has to be adjusted accordingly when devices are added/removed to/from the bus. The individual bits are then sampled and the resulting byte is output to one of the UARTS, which interfaces with either RS232 or LAN (the LAN module is optional for our converter).

Transmitting: As you may already know, the master transmits data by modulating the voltage level on the bus between 24-36V. Thus, the controller must be able to switch between these voltages in a sufficiently fast manner. In a nutshell, we realized this using a linear regulator where we have a Z-diode at the GND pin, which can be switched "on and off", effectively changing the output voltage of the regulator.

There is actually a lot more involved as it may sound from the short description, but those are more or less the thoughts on our approach when we started engineering. Especially when designing for a lot of M-Bus clients, you required components with sufficient power ratings / switching capability like darlingtons and maybe even a small heat sink for the regulator. Idle current for 100 devices is 100 x 1.5mA, assuming one unit load per device, but worst case current during a search collision is 20mA per device which then result in 2A.

About Enphase-Envoy comms The new IQ series should solve the “pain in the ass” communications of previous models’ PLC. The new PLC does not have the “noise” problem of previous M- & S-series microinverters because it does not use the neutral wire for communication. The modulation technique has also changed from HSK/PDF to IQ (In-phase Quadriture) which is also better. I am biased towards Enphase, so take what I say with a grain of salt. I think the low-voltage-based microinverter solutions are superior to high-voltage DC-based soltuions given their reliability and safety. Another issue which is a bit nebulous is PID which high-voltage-based solar arrays can be susceptible to. With microinverters, they’re PID-free. https://en.wikipedia.org/wiki/Potential_induced_degradation