BasicPI

Home Automation – Closed network

Posted on by Jan

A lot of IoT/Cloud solutions focus on access through internet, while I want a closed network of sensors in my house with a switch that enable very secure and restricted access from outside that network. I don’t want it to be fysical possible to break in without fysical access. But, I want to use Wifi and Wired solutions to connect sensor units in my home. Using a combined multi-sensor as described before means I can get away with one unit in each room.

The advantage of this is that I can use the information to provide simple automation logic at low cost. The most obvious start is temperature in each room and the capability to save electricity by lowering temperature in unused rooms and at times of day based on simple logic.

If I go on holliday I can enable my own phone or tablet to access this through a secure connection where only my physical device can be used. The thing is that with internet you never know as some smart hacker might always find a way in, so the best security is to disconnect internet completely. Wifi is a bit more secure as you need to be in ca 100 meter range and we can have the units to auto-change security passwords etc. Even better, we can also use wired, secure connections if we want to. Just keep in mind that a wired connection also is wireless on ca 50cm distance with correct equipment.

As for functionality I can add camera and voice units as needed, but me in person I believe things like Alexia or similar is useless crap at this point.

I have my PLS stack that I will use for actuators, but I need to create the sensor unit and I want to start with a low, cost battery modul with Wifi. 3,7V battery have the advantage that I can go direct without a regulator and use something like ESP32 as core for a simple, cheap start.

 

Home Automation – Sensors

Posted on by Jan

I have always dreamed about automating my own home and one of the key starting components are low cost sensors. This technology is available today, so it is not rocket science, but I want to create a low cost practical system. Starting with sensors only I would like to monitor temperature in every room in the house as a start. If I can monitor temeperatures I can control heating – it is a simple application that any modern electric owen can do, but I fancy doing it through a centralized system and to deal with some of the challenges I face getting there.

The concept drawing abobe illustrate 3 different communication options as well as some sensors and a battery solution.

Battery is a challenge because you will either need to recharge batteries or swap batteries on regular intervals. But, battery combined with Low Power Wifi/Lora is the most elegant solution. The option to use a cheap network like RS485 (or similar) and power cables. You then get 4 cables to each sensor. The drawback with the RS485 solution is that you need to drag cables around the house. I think it’s ok to have a system that can do both specially since the RS485 option hardly require PCB footprint at all.

The pink part – BMS and batery is quite simply a voltage sensor on a 3,7V LiPo or similar. We don’t charge, but we can monitor battery state and give a low power alarm.

This block diagram is rather generic, but I think I can manage it all in one circuit which will be better for higher volumes. I have a L4 Nucleo board I can use as a start. Standard for all the sensors are that it is of little extra usage to monitor them constantly, so we need to work out a time scheme. Starting with temperature I would say that measuring the temperature every 10th second is more than sufficient. That means we can sleep in 9.9 seconds and just switch on a minimum of power for a little while. Being intelligent we can also decide if temperature have changes sufficiently for use to switch on the radio and report anything. If we do this with every sensor we should end up with a pretty good low power scheme where a seleceted battery cam last a predictable period.

As for form factor I am thinking a bigger board this time. Most of the cost here can be lowered more with volum than with size, so having a larger PCB that can do more makes sence. I can then configure that as I please for each room. Lets at least start with this.

New Motor Controller

Posted on by Jan

I recently bought a test kit (ESC) from ST that I used 2 days on to create a motor controller, and I liked the design so I am using it as template for a new controller. You will remember that I created a “ThunderStick” using DRV8301, basically a controller very close to the Vedder design. But, I have created controllers closer to the ST design before using 4 discrete gate drivers, so I want to go back to this design and see if I can upgrade my ThunderStick to ThunderStick2 with a few changes. This is the real reason I bought STM32G491. The ST kit uses STM32G431 that is close to identical with less Flash.

I want a few changes from ST design:

  • I need 60-100V MOSFET’s because I need 48V on the drones. 24V is to low as it makes it more difficult to drive the larger drones.
  • I want a larger controller with proper connectors – more like my 100mm x 25mm Thunderstick.
  • I want a similar heatsink as on Thunderstick.
  • I add a FRAM (or SPI Flash) for storing variables.
  • I add a serial interface, but uses CAN for control.

This is a quick draft so it might be changes, but I have done a few motor controllers now so I think I can manage one that has a good compromize on size/heating. The ST kit is cool, but close to useless because it is so small. Thunderstick size is larger and have a much better design to get rid of heat, meaning I should be able to achieve higher currents – more effect out. Thunderstick is also a very good form factor for larger drones that I focus on.

One of the things that is special with the G series is their analogue content. G431/G491 have 4 Programmable Op-Amps and Comparators as well as 12-16 bit ADC channels that is perfect for a small size motor controller. I am actually looking forward to redrawing this with KiCad because Thunderstick was hard to make a PCB with using Target.

Moving on – I have been working on my own PLC system for drones/homes for a while and will update many of the boards I have made and actually get them into production. Many of the boards have been experimental and been working well – which is not bad for a hobbyist.

XPortHub3

Posted on by Jan

I have used STM32F405RG for a long time, but decided to switch to STM32G series and upgrade some of my PLC modules. This shows STM32G491RE simply because I managed to buy a series of these. These are more capable than the F4 with upgraded IO + 2 FD CAN ports. I have earlier used SPI for communicating with Raspberry PI, but will from now on use CAN FD as IPC supported by an UART for RPI communication. With 5Mbps on CAN FD and 2-3 ports I believe that is sufficient for all signals except voice/video that we can special process.

This module XPortHub3 is mostly identical to XPortHub2. The main difference is the STM32G491RE that cost a bit less than the STM32F405RG.

CAN-FD uses up to 64 byte payload @ 5Mbps, but still support arbitration, so it is perfect as IPC for a stack of boards with short cables between.

  • 1 x 10/100 Mbit Ethernet
  • 1 x USB
  • 2 x CAN HS/CAN-FD
  • 6 x Serial

I have extra pins for 10 analogue and 5 PWM, but I doubht I will have connector space for the pins – lets see.

BSA – WPF Performance Issue part 3

Posted on by Jan

This is the Diagnostics Tools in Visual Studio showing BSA Start-Up. The first big raise of memory usage is probably my Tool View – not sure – but the last one is me moving BSA to the other screen and redrawing the grid in the process. This is the cost – something like 50Mb or so – to recreate the grid because I changed the size. It is a bug here that it never realease the memory, but the real error is is just bad programming or basically me not realizing the cost of using UIElements in arrays.

The irony is that I did the very same mistake some 30 years ago on my very first Windows applications – I nedded a grid and created a grid based on multiple edit controls. The system crashed because I ran out of resources – this version do not crash, but it telling me very clearly that this is not the path forward. UIElement needs to much memory for it to be duplicated the way I do.

I have fixed some other issues that affected performance and they helped, but this I will need to fix by dramatically reduce the number of UIElements I use – I think.

The solution is to create proper controls where both the TreeView (Tool list), Grid and Property Editor is a fixed number of UIElements – not big arrays of them. Beginning with the Property Editor this is easy technically – but a bit of work – I need to create one control that display my tree and then use UIElements to place inline as I want to edit objects. Badically I need to create a proper TreeViewGrid or find one I can use. Taken into account some of the tricks I use to create a functional property editor I expect I will need to create this myself. This is after all a very important part of BSA as details here decides how easee the result will be to use.

Conclusion : Arrays of UIElements use a lot of memory and should be limited.

The upside: I did need a TreeViewGrid anyway!

The downside is that controls also consist of UIElements, so I am not sure I actually have a smart solution here yet…

BSA – WPF Performance Issue part 2

Posted on by Jan

Following my previous article I realized that creating and adding UIelements are the issue. I have those in 2 places – once as I create/modify the grid and secondly as I create a list of UIelements for the Property Editor.

In both cases I create a load of controls using new and maximize IO between CPU and GPU.

The grid is not a problem – the issue is more than once I have a lot of canvas w/grids and resize the grid I recreate it. This should be easily solved by creating a seperate grid component that is updated. The grid is after all just a visual background gimmick.

The property editor is more difficult. It is quite advanced and as is depend of WPF. It is 2 problems here (1) the memory usage. It seems to me that garbage collector is garbage not releasing memory. If I click between two objects it just grab more and more memory and never give anything back by the looks of it. I can solve this the same way as the grid, but this will cost me. This is very annoying because this type of component in Forms would be fast and easy – so the question is I could do this as a forms component and use it in WPF? I also reaize this also goes for my treeview with tools – it does grab a lot of memory – bla this is a bit of a setback…

to be continued.

BSA – WPF Performance Issue part 1

Posted on by Jan

Loading the attribute list into the property editor was a performance surprice – it is slow and noticeable at already ca 10 attributes. I am fully aware that IO between CPU and GPU is a weak point in performance using GPU technology, but this one is rediculous. I started having similar problems on QML with ca 1000 entries in a table. QML is a little faster than WPF due to the difference between C++/V8 and C#, but not that much faster – so something is wrong in my coding here. I will figure it out.

Debugging these things is a bitch, but what I usually do is to start adding counters to see how many times functions are called – and if you get an insane number of calls on a function you usually have the answer. You can also use profilers, but I must admit I have never been good with those.

WPF/QML/Avalonia is capable of Oscilloscope plots that require an insane IO, so this is not a real limit – it is just a trick or bug I don’t understand yet. This is the first time I have a performance issue at all with WPF, so it will be interesting to find out where the bug is.

The screenshot above is Visual Studio profiler and the red circle show the problem. This is the first time I use this. You see that GPU performance is low and BSA feels very alive once the editor is set. But notice the increase in memory usage – this was some 20 attributes on a single class creating an insane memory usage. And huge amounts of memory allocations will create CPU usage that can explain what I see. For 20 or so attributes we talk around 200 Mb indicating that each attribute require 10Mb – no way – I am doing something very funny here.

A quick analyze shows that it is my property editor that is the problem – it allocates an insane amount of memory for each row … hmmm. What I have done is a simple tree of stacked objects – stupid, fast coding – it works well from a functional view, but obviously not from a performance perspective – yet.

Further analyze shows that yes I do call functions that clear and recreate UIControl children and the Clear() function never release the previous memory. This is not my property editor as such it is my usage of “UserControl” in general … hmm interesting … stay tuned I will find a solution to this.

 

… to be continued …

BSA – Attribute List Expanded

Posted on by Jan

The table above looks ok – you can see an array of attributes as expected. The picture below is the same list with attribute details expanded.  It’s a bit work in progress, and I am not sure about the result yet – I have to think about this one as it looks a bit messy. That said it does the job.

BSA – Attribute List

Posted on by Jan

This is my first attempt on a mock up of an array of attributes for UML Class, and I am very pleased with the result. I need to change the header color of the table and do a few things, but this was a first mock-up to get a feeling about how functional this would be – and it works out surprisingly well. The detail edit will be a sub-list of attributes, but I can also support in-line edit etc.

The code for this grid was hand-tailored because I needed a grid that could expand into property list (still TODO) – my C# coding is still on the learning side for WPF, but I am very pleased with the results I achieve. No regrets on moving away from Qt/QML on GUI!

The blue header color is a bit to much, so I will swap it for a grey one – if you look at it you will notice that it takes the attention away from the actual data – it looks like the header line is seleceted.

Another observation is that this will work for tables with 2-3 (maybe 4) columns – not more. The attributes will have far more fields that can be edited, but the overview list shown here simply have no room for more. In this overview I can also show around 200 characters of the description etc, while the full description will be a text block the same way as for the class itself then expanded. It will be hours on details here and I need to look into how to make this a re-usable component – tables and trees are very usable components in any application.

BSA – First Application

Posted on by Jan

I will introduce a display symbol to do IO towards HMI so I don’t need copies of Forms everythere, but the diagram below is actually functional.

I could actually generate code based on this – the two processes are modules where one run on STM32 and the second on Raspberry PI. The first collect ADC samples, the second display the results on a form. High level diagrans will be more or less like this and can be used as specifications in front of customers. If you double click on “ADC Sample Process” you will either see actual source code, PScript, Python, C++ or a sub-diagram reprecenting the logic. It will be a few executable details, but doing this exact job will be about this easy.

Notice that unlike LabView or other similar tools we process events in proper diagrams where the user can mix code as he/she pleases. The actual modules can be whatever you need them to be.

I recently had the opportunity to work on competing solutions and the experience tells me that I am on the right track – I have made a lot of correct choises that you will feel the power of as you start working with BSA – and while competetive products cost ca 4000 USD per license this will be closer to 40.- USD in cost for commercial usage (free for open source) – and no dependency – if all you want to do is to use BSA to generate source code that you maintain manually – be my guest.

Stay tuned…