BasicPI

I received a DPS5020 module yesterday, well packed. This is the 0-50V/0-20A Lab PSU module I mentioned earlier. Assembling and switching this on was straight forward, and using it was a very positive surprise. I was initially concerned about it’s HMI, but I am actually impressed by the cleverness of this design.

This first picture (sorry for the quality) show what you receive. A small user manual, cables and the two main modules. What surprised me a little is actually how small this is, but I need to remind everyone that you need a 6-60V DC supply in front here. I applied 30V and get an output from 0-29V. The HMI sence the input and adjust on Voltage range accordingly. I will see if I can do the same on current (manually set upper limit)

This picture show the HMI module opened up. The display is small, but sufficient. The entire module is quite simple and could easily be replaced with some hacking – it has a separate LCD and Keys cable, but I have no info about their pins jet. My initial plan was to replace this, but after having used it a little I am not so sure I actually want to.

This is a picture (from the net) showing the HMI in use. The Green/Yellow/Purple text in the middle is showing actual output. On bottom (cyan) you see voltage in, on top(cyan) you see Voltage and Current setting. Notice that Voltage out show actual voltage out, not the intended setting. You will actually see a +/- 0.01 variance in this.

Operating this is straight forward – press V and turn the knob to set Voltage, Press A and turn the knob to set Current limit. Once you are done you press Set and get a confirm screen. After that you press the On/Off to enable this out. This took me by surprise because it is not just about turning the knob to change voltage – you actually have to press V button first. This is very good because it is nice to know that your PSU don’t change by accident. You can adjust voltage both on-line and off-line this way. The second issue is the capability to adjust setting before you enable it out. The knob is a standard encoder with a push switch used to change what digit you adjust. Seriously it took me around 60 seconds to learn this interface. This is far, far better than I actually expected.

This is the PSU module itself (above). Input at left, output at right. On the front you see a LQFP48 holding a STM32F100C8. I ordered the USB which is a familiar CH340G operating on an UART. That is the small 4 pin connector next to the MCU. I will get back to using this, but it basically means you can remotely connect to this using USB, Bluetooth or simply hacking the UART. I believe the protocol is described.

This is the included top-side HMI that can be used to operate this from a PC. I have yet to test this. You need to downoad this from their site – this pic is actually from the 15A module. My comment here is that this is all fine, but I need my PC screens for different purposes. I would however like the graphs, so I am considering hacking the UART and connect a Graph display on the PSU + adding Ethernet/Wifi capabilities.

Next I will get some load tests done to see how this wonder behave under heavy usage. Not bad for 45.- USD P&P included. Transport was under 3 weeks, but this is only pure luck.

This is the test suit for Smart SPI. This is an old pic, but I will upload a newer one showing RPI mounted behind the 32xServo and how we access SWD & Raspberry PI for development.

The mechanics of thos robot is dodgy, but it is a very good and fun test kit. I also have a different robot that we can have some fun with during testing using the 8x DC Motor hat.

Keep in mind that Raspberry PI Zero W provide both Bluetooth and Wifi – I only need battery added making this a very easy and scalable design.

Adding more Hat’sm we can scale up and we basically have a PLC style design with Raspberry PI as core. I have a few more Hat designs coming up, but once I have tested this I will try putting this into volum production through kickstarter.

I have no idea about prices yet, but I hope we can achieve ca 25.- USD or lower. This is no-profit, but the key is that I need volumes to push prices down. I also need to engange professionals for CE/FCC tests. I am not so worried about the later, as Wifi/Bluetooth is dealth with by 3rd party, and this is only a component – but, we need to test that we don’t have nasty signals by accident.

I need a specialized SPI driver to support the Smart SPI concept. The block diagram above show the logical view with device to device communication, while the diagram below show the physical design. Just to remind everyone – in the logical concept we communicate device to device. In the physical this is done by a device sending a message to RPI that send it to the addressed device.

A classic SPI will enable a CS, communicate with that device before it continue to the next device. As discussed before this is not optional as it do not take into account the actual stream queues, so we will implement several important tweaks to optimizeSPI communication efficiency.

We will only use the CS for ID procedures at start-up. I am currently looking into even drop this. Each device here is intelligent and capable of filtering out it’s own messages. They also have 3-state capability allowing them to listen only while only one respond back. This enables a free flow where RPI have a continuous send with a soft-switch selecting the device that communicate back.

This requires specialized SPI drivers both for Raspberry PI and STM32. The advantage for Raspberry PI is that we allow Linux to use deep DMA queues and avoid CPU heavy bit-banging. The only dissadvantage is a complex SPI driver.

My current Hat’s support CS addressing using a classic address selection. I am considering ditching that and set the MCU address directly with 3-4 GPIO pins. The drawback is that I need to modify all Hat’s, but that is doable since none are in production yet – and I am commiting to using a number of pin’s for address setting. The usage will be the same as before, but we drop the SPI ID procedure because it is not needed anymore. At precent I will focus on a single Hat, so I can pick up this as I make the next revision of the Hat’s. It also gives me time to mature this change a bit.

I have already talked about using this module as key for a home automation central. I am going to look into a few extensions (or additional module).

A normal wireless have a range on ca 100m, but dealing with home automation you could use 1Km range – solutions for that exist.

Another change is the capability to use this as a wireless router creating a privat, wireless sone that can be extended.

The alternative is 1km long twisted wires for RS485 or modem’s, but a wireless solution is so much easier. I will be back on these extensions later.

This table is a all 32 channels on the 32 x Servo / IO Hat mapped out per channel. Explenation under the table.

Analogue In means it has an ADC capability on the channel. This can sample at a very high frequency. It is 15 of these

PWM means we have a Hardware PWM signal with a very high frequency capability. It is 23 of these.

Analogue out means it connect to a DAC. It is 2 of these,

Digital In & Digital Out is on all 32 channels.

Servo is available on all 32 channels and is the default configuration.

Software PWM means we bit-bang the pin in software to create a PWM signal. Max frequency is ca 10KHz. Available on all 32 channels.

An updated version of this table can be found in Annotated Schematics (coming soon). Pin’s have all cababilities as per STM32F105RB capabilities, but more advanced features will need custom modified firmware to access.

Visual Studio Code is more an editor with debugger support than a full IDE, it takes a bit fiddling to set up and get right. Basically you don’t have any setup screens and have to edit your project in files with XML syntax. I am not sure if I will use this for everything, but VSCode has definitely come to stay – it simply is to handy to have around as code editor for various things alone.

VSCode itself is a framework that allow extensions to be added, and extensions exist for a lot of things. STM32 is currently supported through PlatformIO (www.platformio.org). Sadly the STM32 support is still a bit limited, so I have not been able to test to much and setting it up is a bit fiddly. PlatformIO IDE is not really free – they maintain a community version, but that seems to lack essential features to be of any real use.

One annoying issue with VSCode is that it’s folders are physical within a hierarchy – myself I arrange the project on top with a strict set of sub-folders. What IDE people use differs with developer so I like to hide this in sub-folders. That does however not prevent me from editing

All in All – Visual Code got my interest, but I am not sure about Platform IO yet – neither am I sure I actually could commit a full project to VSCode alone.

You will find breakout’s for VL53L0X in numbers on net shops, they are still a bit price around 10ich USD – but the chip cost 2.6 USD so I expect them to drop down fast – competition & popularity is to high for them not to as soon as the vendors sort their logistics out.

Having a breakout is however not the same as having a working solution. The breakout above is one of the better I have seen being close to an actual, working sensor.

This is VL53L0X from ST, a 4.4 x 2.4mm ranging sensor that can measure accurate distance up to 200mm (2 meters). This is a BGA with a I2C interface and have an ST interface library. Several breakout boards exist, but we need to be a bit clever here – I want the sensors mounted in all directions of a robot, so I need more than just a basic breakout board. Being a BGA I hesitate a little, but I think I can mamnage to solder these – if I can afford to buy them that is 🙂

If I ever want to know where my wife’s cat’s are hiding I only need to start this 12 servo monster – I instantly have a horde of cat audience…

I will mount the control system on the inside of the box, but I still have to sort out the battery & PSU. Knowing that my Lab PSU was failing I want to redo some of the power tests. What happened with the Arduino stack was that Arduino kept re-booting as the Servo’s started. I now believe this might be caused by the Lab PSU and that I can get away with less peaks than I calculated.

Another solution is to get a 7V (2 cell) battery and use that directly avoiding the need of a PSU handling 10A in peaks. The Servo PSU are separate from MCU PSU as well, so we can avoid that the Servo’s drag down the MCU anyway.

As mentioned earlier the legs here are actually 2.- USD pan&tilt camera holders misused for this purpose – I need to look for a different solution is these will break after some usage, but not before they have served their test purpose. For me this is about having a bit of fun while I am testing concepts related to Plain & distributed control systems :).

I initially planned on using Raspberry PI 3 or 2 here, but Zero W is perfect for this usage – a Minuture Linux computer with Wifi & Bluetooth all for 10.- USD.  I don’t need the bigger Linux computer for operating the robot – my STM32 does that much better, but RPI add’s the Wifi with security + it adds the AI capability – I can actually program the robot to remember map’s and how to get from A to B etc – meaning it becomes more than just a ROV (Remote Operated Vehicle).

My wife’s cat’s are trying to break into my lab…

I maintain Zero mounting holes on all my Hat’s because it’s an easy & cheap way to assemble a wireless control system using the capabilities in Zero W. The picture above show Zero W on top of a 32xServo Hat. I have only populated 16 of them, but all 32 are available since the Hat fit’s nicely on the inside. The pic below show a Zero booting up with a 5″ TFT display. I tried booting the Zero W, but realized I need to update my image.

You can see the red dot from the 32xServo Hat mirroring in the display. The only practical issue here is that SWD is hard to get to – which isn’t a real issue as I just as easy can move the Zero to bottom of the stack for development – but, I did draft special SWD adapters for this purpose earlier that allow me access from the side (See 3D below).

This can be clicked on/off from the side while the Hat’s are inside a stack. The use of 1.27 pich headers is just about the right hight for this. The one thing this SWD adapter lack is a Boot and Reset button. I seldom need those, but I prefer to have them on the adapter – not waste space on the boards.

The 32xServo or 32xIO have the advantage that the signals are connected directly to the MCU. The new version (not shown here) have TVS diodes on each signal, but you can otherwise use the signals as per MCU capability for in/out. This makes this a very ideal wireless controller because you have 32 very capable channels + pointing at the obvious a Raspberry PI Zero W with camera port. I will re-assemble my 6 legged Robot with this on top later.