My first Raspberry Pi project is going to be a controller to tilt my Venetian blinds. I need to be able to control a number of servos and connect some sensors to measure light levels and temperature. As space is tight, I am planning to purchase a Pi Zero and the Picon Zero, so I can connect both the servos and sensors to the same hat.

What I’d like some help with is choosing suitable sensors. The Picon Zero supports ‘digital’ or analog sensors, using 3-pin GVS connectors (Ground, Volts, Signal).

Looking at the various light sensors available, the 'Adafruit Digital light / luminosity / lux sensor’ seems to be a great sensor, with good low-level range, and has an I2C interface. However I am unsure if this would be compatible with the Picon ‘digital’ input type (as the Picon Zero inputs use 3 wires and I2C seems to require four). Will it work? Is this a different type of ‘digital’ interface? Is there a more-specific name for the type of ‘digital’ input that this Picon Zero expects?

If this sensor is not suitable, can anyone recommend a suitable light sensor that would work when connected to one of the picon zero inputs?

From what I understand, the Picon Zero inputs are digital in the “on/off” sense, rather than digital as in “some sort of digital protocol for transferring data.” Without using some sort of single wire protocol over them they would only work with a light sensor that has a built in threshold and pulls its output pin high or low.

However, as long as the I2C Address of your sensor doesn’t conflict with that of the Picon Zero you can use the Pi’s I2C pins (BCM 2 and 3) for both at the same time: http://pinout.xyz/pinout/i2c

The remaining two pins of the 4 you observe I2C using are power and ground, which you could potentially use straight from one of those Output/Input headers (I’ll wager they’re the rows marked V and G)

However, I don’t know if the I2C pins are broken out on Picon Zero. I can see a row of pins along the front edge, but I’m not sure what they’re for. @4tronix should know!

Phil is correct. The Digital I/O on Picon Zero is purely for On/Off type signals. It won’t support things like I2C or SPI. You can use I2C devices alongside Picon Zero, but connecting to the I2C pins on the GPIO header is not easy as they are not broken out (perhaps a design change for the next revision?). In fact, other customers have done this by soldering to the GPIO header pins on the Picon Zero.

You would probably be better to choose an analog light sensor, such as a LDR or an SH3710 and then you can connect these directly to the Picon Zero using analog inputs

[PS. the row of 6 holes along the bottom of the Picon Zero is to enable reprogramming Picon Zero with updated firmware]

My original plan was to connect a number of I2C sensors, but there seems to be a gap in the market for a pHAT that breaks out the I2C bus cleanly for a number of sensors (there is the GrovePiZero, but this seems difficult to get hold of in the UK and only has one I2C connector anyway). So, if I go down the I2C sensor route, I’d probably knock-up my own version of the GrovePi using a ProtoZero, and have say three or four 4-pin connectors all coming off the I2C bus.

If a future version of the Picon Zero can fit in a couple of 4-pin connectors for I2C sensors, that would be brilliant! Then it’s pretty much a one-stop-shop board.

For now, I need to decide whether to go with I2C sensors and have another layer to my Pi Zero stack (space issues), or go for analog sensors and connect these to the Picon Zero.

@4tronix, on a related note, I’m look at connecting servos like these, which require a PWM signal between 500-2500μs to get the full range of motion. From the code examples it’s not immediately obvious how to change the PWM signal range when the output is configured as ‘Servo’ type:

The values can be ‘-100 to + 100 Position in degrees’, which I assume corresponds to the standard pwm range for servos of 1000µs to 2000µs (?). How would I change this to allow 500-2500μs signals?

If I’d need to use the ‘PWM’ type instead, then I’m guessing I could send a value between 2.5% and 12.5%, assuming the default frequency is 50Hz (?). But this would have the downside of losing a lot of granularity.