Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

In MSXII, in addition to our CAN networks required for high-reliability, high-throughput multi-master communications, we also have a need for single-master, multi-slave low-throughput communications between boards. In this case, we would like to collect data from our MPPTs without flooding the CAN network or requiring a separate network. The driver controls system and sensor network are other examples of systems that require low-throughput communications with clear slaves and a single master.

For the solar slaves, we should provision for communications over 20m+ of wire and isolated analog measurements. We currently plan on using one master per string and one slave per MPPT, resulting in 2 masters and 12 slaves.

Isolation

First and foremost, the analog isolation is one of the most important parts of the solar slaves. This is the most expensive part of the solar slave. We'd like to measure up to the maximum boost voltage of the MPPTs, so we'll likely use a voltage divider to bring the voltage down into a measurable range. Since we want to measure the MPPT voltage, we need to measure across the MPPT's negative to positive terminals, and the easiest way of doing this is referencing the MPPT's negative terminal as the ADC's ground since digital isolation is much easier and more reliable than analog isolation. We assume that it is okay to siphon power from the MPPT to power the ADC, removing the need for an isolated DC-DC.

If we find an isolated ADC, that would also be an interesting option.

Protocols

Currently, there are two proposed protocols:

  • I2C
  • LIN

Both solutions will require the master to initiate messages, although it is possible for slaves to implement alert pins outside of the protocols.

I2C

The main draw of I2C is that we already support it and the use of I2C slaves allows a multi-slave bus without any extra microcontrollers or firmware. To address concerns about bus length and EMI, we can use active pullups or differential redrivers to enable much longer distances than we plan on using without any issue. I2C is a very common protocol, and many slaves exist for it. For simple systems, it is cheap and easy to implement. Isolation for I2C would either be 4 unidirectional channels (differential redriver) or 2 bidirectional channels (regular I2C). We could run the entire thing at 5V and most likely at 400kHz. However, we would need to use an ADC that supports at least 6 addresses.

Note that on a protocol level, I2C is not designed for high-reliability systems. There are no checksums or methods of handling disconnects. This will most likely not be an issue for us since our vehicle should not be as noisy as a normal car. One potential issue is that if an MPPT goes down, we will need to timeout on that slave and hope that the bus didn't lock up.

LIN

LIN is designed for automotive use and exactly this scenario, but would require supporting another microcontroller and development of a LIN stack. This would be a pretty major undertaking, so it's not worth considering unless we have the firmware resources to support it. In this case, I would suggest something similar to our controller boards but for LIN, using LDOs and STM32L0s for a low-cost alternative. We could technically use the STM32F072s, but they seem overly expensive for this use case.

It is much slower than I2C with a maximum bitrate of 20kbps, but does support checksums and the detection of defective nodes. Isolation would most likely be between the MCU and ADC, since LIN has an operating voltage of 12V and isolation between the MCU and LIN transceiver would result in a higher power draw from the MPPT. Running at a higher voltage has the advantage of being less susceptible to noise.

Pricing

An example design for an I2C-based solar slave uses I2C differential redrivers running at 5V. This requires 6 wires, with power/ground being provided from the solar master. We can use a 4-channel unidirectional digital isolator on the differential lines, so the LV provided would be powering the isolator and the redriver and ADC would be powered from the MPPT. We could probably use an LDO since we shouldn't be drawing much current. To minimize current draw from the MPPT, we could also use a 2-channel bidirectional digital isolator for a few more dollars and place the redriver on the non-isolated side.

ComponentPrice

Differential Redriver

PCA9600D,112

$4.47

I2C Isolator

SI8602AC-B-IS

$4.27

2/2 Isolator (Differential I2C)

SI8642AB-B-IS1

$2.44

18-bit (overkill) I2C ADC - 8 addresses

MCP3423-E/UN

$4.67
Estimated total cost (+ LDO, resistors, caps)$15~20

For LIN, we would probably use an STM32F030 (Cortex-M0) or STM32L011 (Cortex-M0+) and LIN transceiver. Since LIN is a 1-wire interface, we only need 3 wires. We could use much cheaper ADCs since we don't have the addressing requirement. We could even use an analog optoisolator with the MCU's built-in ADC, although it may be very close price-wise for a digital isolator + ADC. That needs to be investigated more. We could probably get a ~$3 digital isolator and a ~$2 8~10-bit ADC.

ComponentPrice

STM32F030F4P6

$1.96
STM32L011F3P6$2.14

LIN Transceiver

MLX80020KDC-BAA-000-SP

$1.10

Optoisolator (use the MCU's built-in ADC)

HCNR200-000E

$5.36
Estimated total cost (+ LDO, resistor, caps)$10~15

LIN Slave

If we go with LIN, I propose a low-cost variant of the controller board that uses an STM32L0 + LIN transceiver as its core. Since this should be a low-power system, an LDO is probably fine and saves money. These slaves should be designed to daisy-chain, so we can use 2 6-pin DuraCliks (12V, ground, LIN, IO1/IO2 for auto-addressing, optional alert). Instead of a high-density mezzanine connector, we can use standard 0.1" programming headers since we'll probably only have 10 or so GPIOs. The target price should be less than $10 each since we don't need a crystal or dc-dc. A good chunk of the cost will likely be the connectors.

  • No labels