Category Archives: Home Automation

HMI Solution

The HMI solution I find most attractive is stand-alone TFT solutions with UART as interface. I have used a few off-the-shelf displays earlier and the concept is great, but I want to evolve this a bit beyon just a stand-alone TFT – I want a complete, plug & play solution.

These displays interface to embedded solutions using a UART. You pre-program the graphics in a GPU and use the UART to exchange data only. This is an excellent solution and concept, but I lack a few components.

  • Using a TFT for data input is not always convenient, I often need custom keys and knobs to make up the rest of a panel.
  • I don’t always want to pre-load the graphics design, I want an option to download graphics from the embedded system using XML alike formats.
  • I want to chose wherever I use Web, PC, Raspberry PI or something else based on my needs without having to program x number of HMI Interfaces.
  • Graphics quality must be high!
  • And at last, but not least – customization factor needs to be very high.

I have already started a HMI project with a HMI Designer for a Desktop, Raspberry PI, Android or iPad etc. This is still a bit work in progress, but what I want to add is the embedded “HMI Browser”.

This is just an example display – this is a barebone TFT with a dumb adapter that is perfect for my plans and it exist loads of these. I want more options than a single display, but this is a start. The base concept is that I stack a HMI adapter with the GPU behind this – and as the adapter will be a Hat I can add whatever I want to this again.

I will finish my 3Phase/PWM board first, but this is my next project. Completion of a HMI solution for my projects is long overdue!


I have both 3-phase motors, stepper motors and PWM Hat on my list, so I want to use DRV8313 because this delivers 3 individual Half H-Bridges that are excellent for all of these options then combined together. I am pretty sure I can get 6 of these drivers on a Hat which would give:

  • 6 x 3-Phase Motors,
  • 4 x 4-wire Steppers, 
  • 9 x DC Motors, 
  • 18 x Solenoids/PWM signals. 
  • or any combination of these.

This would actually be a very powerfully Hat.

Looking at STM32F405RG I actually have 26 Timer pin’s with PWM capacity so this looks very doable. What I want to add in addition to DRV8313 is INA193 (or INA194) to measure current on each DRV8313. Ideally I would have this on every PWM, but I am running out of space here, so lets see where we land.

Getting 6 x DRV8313 on a Hat is very doable, but I will need a 60V DC/DC and 6 current sensors as well + a DC-Rail sensor – that is 38 extra passive Components. 

An early mock-up like the one above is just a quick exercise to place the actual components on the PCB for a reality check – and this does not look like a go to me. It is not just about placing components, but all the lanes I will need between them. And it is still capacitors etc that I would like to place here.

So what can I do?

Firstly – 60V is a bit ambiguous for this board, 36V (meaning 24V) is more workable meaning I can ditch the 60V/3.3V DC/DC. That helps a lot.

The second option is the filters that I have on the current sensors – I can remove these from electronics and do them in software – that will reduce 36 components to 12 and the density of the board is suddenly far more realistic – and less complex.

The capability to remove filters from electronics because I can do them in software is something I often face, and in this case we can due to the raw capacity of the M4 MCU. This last mock-up looks far more doable. And I am happy with a 24V limit on this board because this is for small 2-3A motors that seldom needs higher voltages. Now – lets og and design this one!

Upgraded LoRa Options

I finished the LoRa + GPS w/E22-900M30S earlier today and decided to add in E22-900M22S footprint. The modules are almost identical except in size. The only difference is that 30S have pin 10 to 3.3V while 22S have this to ground, so it is straight forward to have both footprints on the PCB.

The 3D model show the 22S module and illustrate well the size difference to the stronger 30S module. This enables 4 LoRa units:

  • E22-400M30S, 433Mhz, 1W, 12km range
  • E22-900M30S, 868Mhz, 1W, 12km range
  • E22-400M22S, 433Mhz, 0.1W, 6.5km range
  • E22-900M22S, 868Mhz, 0.1W, 6.5km range

All modules have an IPX antenna on the module, so I use a PCB antenna with wire to the IPX. This provides a PCB antenna option, but I can also use the IPX directly for more options.

As for the range listed above – this is datasheet numbers. It will be line of sight mostly and I expect somewhere between 2-6.5km for 22S. As for the stronger maybe 5-12km. I say this because E22 modules give very optimistic range data, but we will see.

LoRa/GPS Hat Annotated

  1. IPX Antenna for LoRa directly on the module.
  2. PCB Antenna for LoRa.
  3. Power leds + MCU Status.
  4. USB Connector for MCU.
  5. Separate Power connector.
  6. GPS Module. Can use NEO-6M, NEO-7M or NEO-8M.
  7. GPS Antenna.
  8. USB for GPS Module.
  9. UART TTL.
  10. SWD
  11. STM32F405RG. Powerfully ARM M4 capable of running MicroPython.
  12. Raspberry PI Connector.
  13. CAN Port.
  14. LoRa Module. 1W or 0.1W in 433/868Mhz area capable of up to 12km with up to 300kbps data-rate.

This board can function stand-alone, as part of a CAN stack or as a Raspberry PI Hat. LoRa and GPS can be switched off through separate power supplies.


This is a LoRa and GPS Hat. The larger E22-900M30S with a range of 12km at left and the small NEO-6M at right. NEO-7M and NEO-8M should also work.

I mistook NEO-6M for having a SPI interface, but realized this was for Flash/EEPROM.

I replaced coils normally used to separate frequency interference with 3 x SPX3819. One for the MCU and one for LoRa and one for GPS with Enable pin controlled from the MCU. This way I can switch modules on/off through power. I need to double-check peak power consumption on E22-900M30S, but SPX3819 supplies 500mA so I hope this is sufficient.


E22-900M30S LoRa Hat

This is the first mock-up with the LoRa unit on. This is the larger and stronger of the modules and it occupied a bit more place than I expected, but I will do. It’s not much passive components on these modules and I still think I have just about the space for the GPS and antenna on right side. We will see tomorrow as I make the package. 

The E22-900M22S is about 1/4 of the size. They are based on the same chip, but 30S got a stronger 1W sender. 22S uses 0.1W and cover 6.5Km according to its datasheet. I take those 12km and 6.5km with a pinch of salt. At these frequencies this will be at line of sight, but lets test.

As for my 3D models I am very accurate with PCB footprint, but the rest is as far as I go an illustration. The antenna as an example show the space it will occupy, but it lack details. You can sit days fiddle with these if you want to, but I prefer them simple and editable.

LoRa and GPS Hat

Packing a LoRa and GPS module on the same Hat should be possible and make a lot of sense. I could pack a battery manager as well, but I rather just make a separate board with battery on and this can be stacked on the back of this unit anyway.

The MCU is the classic STM32F405RG which have 3 SPI’s and I will use all 3. One for RPI, One for LoRa and one for GPS.

LoRa is E22-900M30S with a huge range, programmable sending power and frequency selection. This is based on the SX1262 RF chip. I have no experience with this, so I have ordered various units to start with. This unit is a bit large so it will occupy most of the left half. Luckily this has a IPX antenna so we don’t need to worry about antenna wiring.

NEO-6M, NEO-7M and NEO-8M are GPS modules that are very small. I will be using NEO-6M, but NEO-7M and NEO-8M are backward compatible, so we can upgrade and check those later.

This board is straight forward. Most of the work is actually to make the packages for the LoRa and GPS module.

4G/NB-IoT Hat

SIM7020E is a small module that offer 4G services and access to the new NB-IoT service that is available to give access to remote sensors that earlier was not possible. All-in-All this is just a new wrapping on a service that have been available since GSM and can be achieved with several low cost modules. The difference with NB-IoT is that is support better latency/cost schemes.

I really would have preferred to put 4G, GPS and LoRa on one Hat, but I will run into space and antenna issues so the 4G module will be on it’s own.

PSU requirement for SIM7020 is 500mA power peak, but this should be achievable through standard PSU. At some point I need to add a PSU module supporting my Hat’s, but that is for later concerns. To support the power and avoid a power dip I added space for a 0,33mF Supercap on the 3.3V. This should significantly reduce the peak current + the hole-though connectors can actually be used for a battery as well.

Debug is through USB or UART2, Firmware upgrade is only UART2 – a bit weird, but I have added both. Powering either of the USB’s will power everything to allow debug as needed with a single USB. ESD protection is added for VBAT (3V+, SIM card lines and UART2 lines.

This is my 7th Hat in the new format. I had no reference on the SIM7020E schematics, so will be exiting to see if this works at all. Was a bit annoyed over the UART’s from SIM7020E because they where 1.8V, so had to add a level shifter. Used TBX0108 in SO20 format from Texas Instruments, so will see how that goes as well. Luckily I have a test board on the way so I get to test NB-IoT before I dig into my own board.

Functionality on NB-IoT uses a STM32F405RG to either connect on USB, SPI to Raspberry PI or CAN. Connection to SIM7020E is through UART on TTL level. Both UART’s are level shifted. The external UART is for Programming/Debug, while the extra USB also id for Debugging.

I have no experience using these modules, but I expect that I will be able to send/receive data using TCP/UDP at a speed of 26.15-68.5Kbps. It will be interesting to test.

Next out is GPS and LoRa Hat’s.

NB-IoT Hat – Mockup

This is an early mockup of a NB-IoT/4G/3G/2G/GSM Hat just to illustrate the space needs. My main concerns are signal quality on the antenna part as this module do not have a direct antenna output. Below is a PCB snap-shot showing the details of the antenna layout.

I really could have needed a 3rd layer here to completely isolate the antenna signal, but this has to do. The LoRa unit have antenna on the module so I can use a pre-made Antenna port air-with wire, but I will need to do something similar with the GPS.

SIM7020E also have a bigger brother with GPS in the module, so I will consider that as well. I have not sorted passive components and PSU yet – but, a 4G module is usually no wimp on sending, so I expect that much of the spare space I seem to have here will be used on special voltage PSU – not sure yet.

SIM808 that I used earlier is larger, cover only 3G, but it had GSM and PCM sound. The later is digital sound enabling voice services like IVR etc. The drawback with SIM808 was size and the need for 4V/3A as well as the 3G limitation.

The advantage of actual sound support is that we can make a remote doorbell unit directly connected with voice and video to your phone. I will however re-investigate that option using a different path because 300Kbps is actually sufficient for both a voice and video channel. Video will work with reduced frames per sec, but that is sufficient to see what is happening.

Updated RPI Hat Base

This rather boring drawing represent my new base for a Hat. Notice that I have removed the addressing scheme from the old ones, added USB and CAN as standard as well as Raspberry PI Hat form and SPI to communicate with the PI.

F405 is so fast that we can use higher SPI speed (ca 45Mbps) and I think we can achieve ca 30Mbps full duplex data, which basically is 60Mbps comparable to other standards. I can soft-switch on a SPI bus sending to one device and receiving from another creating a true device to device data stream. Removing the address scheme means that any device can become “Network Master” controlling this. I will return to the Software design tricks here in a different article.

I have one challenge here – how to identify a device? F405 have a Random Number Generator allowing me a safe way to guarantee that two devices behave different. Each of the F405’s also have a unique 96 bit ID. Using this in combination I can manage to tell the network master that we have a new device and get it allocated a time slot. I know F405 is up for the job, but I am more concerned about Raspberry PI due to the Linux core. The SPI on the Broadcom do not have the same support as you have on a F405, but lets see what we can achieve.

CAN is the actual control bus here. Can is excellent as it also allow up to 1km cable between devices. It does not cover the same speed as a SPI, but it is a classic in control systems. I am as many of you know a big fan of RS485, but CAN have it’s advantages as well. It is a bit more difficult to wire, but used here as a backbone net on short distances it is excellent.

USB is a bit new to me, but this is basically a high speed 1:1 serial port. It allows me to connect and power the device stand-alone from a PC. 5V from USB is connected to 5V on Raspberry PI, so this will power RPI and the rest of the stack as well.

I use a new 6 pin SWD connector here. I have described this earlier. I am very happy with my old 2×5 pin, but I mostly only used 3 pins and it added a lot of complexity. I tried a JST Micro connector, but will return to a simpler 1.27 pitch header and an external adapter card to convert to ST.Link/V2 with a Boot and Reset button on the adapter. I also had an UART on the old one, but that is expensive (in terms of pins) and I never used it.

This will be my base for a series of board that I plan.

  • 1 – Wifi board based on ESP32. This is intended as a low cost Wifi option compared to Raspberry PI. ESP32 is in most cases sufficient + it offer a CAN and RS485 etc.
  • 2 – Communication Hub. This is covered in my previous article and will soon be ready. Communication options are basically so basic to any system that I find myself doing a lot of these variants. This includes a SD Card, Flash memory, RTC Clock, 2xCAN, 2xRS485, 2xRS232, SPI, I2C and USB making it a very powerfully Hub.

The next ones are an upgrade of earlier Hat’s.

  • 32 channel Servo/IO Hat. This is one of my simplest, but yet most usable designs. STM32F405 is so powerfully that we get 32 ports in Servo format with +/- and a signal to drive a Servo, Digital In, Digital out, Analogue, In, Analogue Out, PWM Out, PWM In etc. I actually planned a GPIO board at one point, but realized that this board is so much more powerfully. And with 3 sides for connectors we should be able to do 32 channels a bit better than my existing board.
  • DC Motor Hat. I made a 8x DC Motor Hat and plan to extend this. My existing board had some IO + 8x DC H-bridges. I will see how many ports I now can make.
  • 3-Phase Motor Hat. DRV8313 is excellent for driving small 3-phase motors, so I want at least 3 motors – maybe more together with some IO. The focus is low speed position systems so the IO options will reflect this.
  • 5-wire Stepper Motor Hat. It is some excellent, low cost (1 USD) stepper motors around that need a decent support board. Using ULN2003 I can support 7 steppers with 4 chips. This board need 2.54 pitch connectors since they come with the motors, but with 3 edges I believe that is doable.
  • 4-wrire Stepper Motor Hat to drive more classic stepper drivers. In this case I plan 3 steppers up to ca 3A – standard for a 3D printer/CNC.
  • High resolution Analogue input board. 8×24 bit ADC w/30Kbps speed ADC’s are available low cost and this needs a Hat.
  • PWM Driver – 24V/1A. In fact this probably can be achieved in combination (or as a variant) of my 3-Phase Hat. Using DRV8313 and 3 x chips I basically have 12 x PWM channels.
  • Heavy Stepper Motor Driver (MC4X60V50A) – I need CAN on this to be able to control it, but I do not want this directly into a stack.
  • Heavy 3-phase Motor Driver. MC3P60V50A is a bit slipper than it’s 4X variant and focus on 3 Phase motors only. It has the same challenges that it can’t be directly connected on the stack.
  • Isolated CAN Hub. Heavy motor drivers and long distances have some challenges where we need to consider isolation. I tested ADM chips just to discover that they get very hot, so I want to explore a different path. Due to size I am happy with 2 x CAN per Hat.

Most of this is consolidation of work I have done on this blog before, so it is not as much work as first impression might suggest. I am in general not scared of Electronics because I find it very easy and relaxing to do an hour now and then, and over time I achieve a lot. Writing SW for all of this is a larger challenge, but I only intend to make the basis so others can start programming this time.

I sadly need to make one assumption – the state of Norway plan to put MVA and handling fee on all import. This means that a small package that now cost me 10.- USD suddenly will cost ca 30.- USD extra in tax and bullshit fee’s. It will become a limiter on what I can afford to do in here. My only alternative is to start selling board so I can afford to continue. Without this I fear the electronics part of this blog will come to an end.

Thanks for reading my Saturday morning ranting 🙂