G'day, welcome back to the factory. This week, we are discussing more new PiicoDev prototypes. We've got some new sensors joining the ecosystem, and we're also porting the PiicoDev Unified Library to work with more development platforms. Let's get started.

  Ooh ooh, yeah     Ooh ooh, yeah     Ooh ooh, yeah  

First up, the PiicoDev Motion Sensor, the MPU6050 arrived. The prototypes arrived, we've assembled it, and written some example code for it. The MPU6050 is a accelerometer and gyro combo. That means it can measure linear acceleration and also angular roll rate or angle rate. So you can basically detect if you're moving. That also means that you can detect free fall if you measure zero G on all axes. And I'll give you a little demo.

At the moment, we have acceleration being plotted in the graph, and you can see we're up at about one G on the Z axis. And if I roll to the right, we go down to negative one G. That looks like in the X direction, and that makes sense from the orientation of the device, which means that this should be positive one G in the X. I should get positive Y, negative Y. And if I flip it upside down, we're going down to negative one G in the Z direction as well.

Okay, now we're looking at the gyros measurement. So this is measuring the angle rate in degrees per second. So if I roll this way, that should be a positive Y because this is the Y axis. And the right-hand rule means this is positive, and I can get that spike. And likewise, when I roll back, we get the negative and the same for the other axes. This would be in the X direction and in the Z direction if I twist it this way. You can see on the graph, there's a bit of cross coupling there because I can't really rotate this across justOne axis very easily, but you get the point. So this prototype is essentially done. This is the version zero. We actually took this one up another version because in this iteration, we placed the part upside down, which didn't seem to matter at the time. But of course, this device is directional. This device is directional.

So in the updated version, we've rotated it so it matches the orientation of the board and also added some silkscreen legends to show you which axis is in which direction.

So how do you test something like this? Is it enough to just communicate with the thing or do you think you need to actually stimulate the device and make sure you get something out of it? Maybe you could have your test jig coupled to like a vibration table or a vibration motor that turns on and off periodically, and maybe you can look for a recognizable pattern in vibration. I mean, you could orient it so that you can get one G out of every axis, but that would be kind of slow and kind of fiddly. What do you think might be an efficient or effective way to test a device like this?

And while we're talking prototypes, we're also working on the PiicoDev colour sensor. This uses a VEML6040, which you may recognize as a cousin of our ambient light sensor, the VEML6030. This one reads channels of red, green, and blue, and I believe you can infer some colour temperature from that as well. Really all I'm looking for, I just wanna be able to hold an orange in front of it and have it tell me that it's an orange or a banana or something cool like that, make it a fruit sorting machine.

We are taking this one, this prototype, to another iteration as well because we want to place a high CRI LED on the board. We want it to be able to read colors.Passively, not just bright colors from a light. We want to be able to hold a colored surface to it and for it to read that reflected color. So I think we're gonna need to include some LED on board, and we're picking a high CRI LED so that it's colour accurate.

In other PiicoDev news, we're porting the unified library to work with Raspberry Pi single board computers. What this means is that in another branch of the repo, just while we get it working, we have this other else condition, else if condition in the unified library that is looking for Linux single board computers. And it has to treat them a little bit differently because just like the Micro:bit implementation for I2C differs from the machine or MicroPython implementation, Linux doesn't use I2C exactly. It uses something called SMBus, which is very similar, but has a few differences at the edges with how it behaves.

So we have our branch here to look for Linux single board computers, import SMBus, set up the I2C bus, and give us something that we can use to delay with milliseconds. That also means that some of the existing packages, take this temperature package, for example, I've commented out a couple of lines while I approved this one, that in the previous iteration where we were driving the I2C bus and reading some registers, now we have a general read 16 or read word function. And in our unified library, that read 16 function has an if else branch where it can use the Linux read word data, that's for SMBus, or use the existing code that was already in that module.

So we can branch in and leverage this pre-written read word data in Linux systems, or just use the unified write and unified read that we already wrote. So stayTuned because that means that the PiicoDev modules that we have currently and the ones that we are releasing soon ought to be compatible with Raspberry Pi in the near future.

And final piece of prototyping news, we have a PiicoDev pressure sensor in the works, the prototype design has been sent off. We're just waiting for it to land so we can assemble and test it.

In any case, thanks for joining me for this episode of DeFactory. If you have any questions about anything you've seen here or anything that you want to see closer, just drop us a line on the Core Electronics forums.

Catch you next time.