Generic Sensor Hat

Some sensors like 3D sensors are suited to be mounted directly on a Hat, but a majority of sensors actually need to be mounted remotely to provide proper input. To interface to these I need an adapter card with connectors as illustrated above.

STM32F405 have 16 ADC inputs that also can be used as GPIO sampling at speeds up to 2.5Mhz with a 12 bit resolution. So, what I want to do is to pair an ADC with a pure Digital IO and 3V/5V and ground – a standard 4 wire interface for sensors.

The 2nd interface is I2C. I2C needs 4 wires – V, GND, SCL and SDA.

The 3rd interface is SPI. Combine V,GND, MISO,MOSI,CLK and a separate CS – a total of 6 wires per device as a standard SPI Sensor port.

The 4th is CAN with a classic 4 wire Interface.

The 5th is RS485 with a classic 4 wire Interface.

Most existing breakout boards and sensors can be wired into one of those connectors giving us a very generic sensor hat. Just a few case studies:

My last post was about a 3D Motion Sensor also known as a 9-DOF. It is 9 sensors available through either I2C, SPI or both.

Ultrasonic Wave Sensor is well known. They cost < 1USD and can detect movement/distance in ca 5 meters range. They send a 40Khz ultrasound pulse and detect the time to the feedback. These sensors have a pulse output, meaning you need a digital IO pin as interface. They also needs to be mounted remotely as they need to be positioned where on the edge of vehicles. They interface well to the 4 wire analogue ports.

Capacitance Soil Moisture Sensor is a long stick inserted into the soil that give an analogue value out describing how wet the soil is. Some of these sensors use a digital threshold chip so the actual output is digital 1. You basically need +3.3V, GND and an ADC signal for these. so it’s a good match for the 4 wire analogue port.

DMT22 is a temperature and humidity sensor. It basically report the readings using a proprietary digital, single wire protocol. You use a GPIO to read pulses that convert into a binary string etc. It is a good match for the 4 wire analogue port.

DS18B20 is a well know temperature sensors using it’s own single wire protocol. This sensor is low cost and you get it in 1m cable length well suited for outdoor usage. It is an excellent sensor to measure temperature at various points. DS18B20 is also available in TO92 package. Again an excellent match for the 4 wire analogue port.

KY-037 is a breakout board with a small microphone. It gives an analogue sound output as well as a digital sound indicator output. It cost < 0.5USD. It uses a 4 wire interface that is found on several sensors 5V, GND, Analogue Out, Digital out. The 5V is legacy on a lot of sensors. Again an excellent match for the 4 wire analogue port.

AH3503 is an example of a Hall Effect Sensor. These take 5V in and return an analogue value indicating the level of the magnetic field. They are used in motors to detect rotor positions etc. Again an excellent match for a 4-wire analogue port.

I have also made some RS485 sensors and CAN actuators that will interface well to this Hat.

I basically have all these interfaces already on some Hat’s, so this is more about making dedicated ports available for easy plug & play. What I actually put on this Hat will need to be a horse trade between MCU pins and edge space on the Hat. I already have plenty of CAN/RS485 interfaces, so those will only be added if I have the pins/space. I will need to look a bit into storage as well.

3D Motion Sensor Hat

 


To create a drone you need 3D motion sensors with some accuracy and the block diagram above illustrate a Hat with Gyroscope, Accelerometer and Magnetometer + some other sensors. Using a STM32F405 for this purpose is a bit overkill, but I also added RTC and SPI Flash to give the module some motion math capabilities. I also consider adding GPS to the Hat because as I plan larger drones I also need double or triple set of position and motion sensors.

What sensors I will add and how is a bit work in progress, but it is a long list of 9-DOF sensors on the marked using either I2C or SPI as interface. Their packages are small targeting very small drones, but I think I can manage to solder them on – if not I could also use some of the breakout boards as is.

I found this article on Adafruit (https://www.adafruit.com/product/3463) very interesting. They also list the main alternatives:

  • L3GD20 3 Axis MEMS Gyroscope – ST
  • FXAS21002C 3 Axis MEMS Gyroscope – NXP
  • LSM9DS0 9 Axis* MEMS Sensor (Accel + Mag + Gyro) – ST
  • LSM9DS1 9 Axis* MEMES Sensor (Acce + Mag + Gyro) – ST
  • MPU-9250 9 Axis* MEMS Sensor (Accel + Mag + Gyro) – Invensense
  • BMI055 6 Axis MEMS  Sensor (Accel + Gyro) – Bosch (Used in the BNO055)

The NXP sensors are better than the others according to Adafruit’s testing. I have breakout’s for MPU-9250 and the older 6250 etc. But, I will also order the NXP breakout board for testing. To actually test this I can just connect to SPI or I2C on XPortHub, so I don’t actually need to make a separate Hat for this (yet).

The picture abobe shows Adafruit’s breakout board costing 15.- USD with FXOS8700 (Accelerometer + magnetometer) and FXAS21002 (Gyroscope). I am a bit concerned about soldering those chips manually due to size, but I think it will be ok. You see my concern as you realize that the other components are SO23 and 0603. Also – buying these Components are not straight forward. I got the Gyroscope, but I struggle with  FXOS8700 + the cost means it is cheaper to just buy a breakout board. Well done Lady Ada. I think it’s wise to just test With XPortHub and breakout Boards first 🙂

Half Duplex SPI

Half Duplex SPI allows all units to send to each other using MISO or MOSI. The challenge is that if 2 units try sending one might pull high and another low so you get a short-cut. The same goes if more than one tries to become Master and run the clock. The diagram above solves that by introducing small resistors on SPI. And this is recommended for Half Duplex SPI. This is one of the changes I will need to add to all my Hat’s.

Review Exercise

Doing a review of your Jown work is a bit of a challenge, but it is possible. The trick I use it to complete the work and then let it rest 1-2 weeks before I pick it up and update documentation. This technique has in the past proven quite efficient, but I would recommend using colleges to double check your work if possible.

Checking SW work is very complicated because the work is often thousands of lines of cryptic text. It basically becomes very time-consuming and expensive to check everything, so we end up only scratching the surface. This is also whyJ it always should be a traceable path from specification to design to code to test coverage. Once you get this path into your fingers you will discover that it actually speeds up the life-cycle of development over time.

Electronics is easier. We Jhave automatics to check PCB’s, but schematics are drawings and very easy to check and discuss with colleges. These reviews raises discussions that make you question your own work. At the end it is not your colleges that make the changes, it is you who find improvements and execute them as a result of the discussions.

My previous schematics eJrror could have been discovered if I had done a simple exercise of annotating the electronics. But, lets be honest – I say could have – at the end neither all the checks, reviews and automation in the world will prevent mistakes and non-working PCB’s from happen. At some point you just need to make the PCB, assemble it and let theory meet the reality and unexpected.

I have seen electronic engiJneers do both. Some check their work forever and still end up with errors. Others just push forward, end up with errors, correct them and push forward again. You have to find your own balance.

USB on STM32

J7 above is the USB connector on my Hat’s and 44/45 at right is the connection to the MCU. This is all you need to do to have a working USB connected to an STM32.

Software is even easier if you just want a serial port. You just install STM32 Virtual Serial port driver for Windows 10 and check out middleware setting in CubeMX – once the code is downloaded the serial port will just come up. Actually using it is a minimal amount of coding on both sides, but it could hardly have been easier from schematics to working SW. I have not tested other USB classes, but I assume they are equally easy.

The screen above is from CubeMX. To have USB driver included you just wire the pins in the model, select Middleware and enable the USB_Device library and set up parameters to what you want.

LoRa Schematics Error

This is the PSU used on the LoRa/GPS Hat to allow switching the units on/off. The signal EnGPS connects to a GPIO pin and the MCU must pull it high for GPS to switch on – very simple.

One of the functions of a modern EDA is to check schematics and PCB. This works excellent and have saved me lot of work in the past, but I guess it would work even better if I remembered to switch in on. In this case I have somehow managed to switch checking for signal Logic off.

The error here is that I have forgotten to connect these signals on the PCB, so the PSU’s are constantly off. The automatic check would have warned me about this, but as I somehow have switched “signal logic” check off it did not. I made and ordered a lot of PCB’s at the same time and was obviously in a bit of a hurry. The cost of the PCB’s is no worry, but it takes 6 weeks to get them.  I obviously need to double check this before ordering PCB’s, but as I have said before – I always expect 2-3 rounds with corrections.

 

Drone Projects

I want to make a larger plane using drone technology and the drawing above illustrate a generic control system with 4 thrusters. In this case I suggest 4 main motors because I want to lift a large drone in a simple frame to test thrusters and control logic. But, the illustration is generic in nature.

Control System consist of a Raspberry PI A+ and a LoRa + NB-IoT Hat + XPortHub. I will connect to the remote control using Wifi, LoRa or NB-IoT in that sequence. NB-IoT require subscription, but has nation wide range. This means we can send the drone on long distance flights. In this case I use the powerfully Raspberry PI for AI logic while I leave motors and actuators to specialized MCU’s in a distributed control system. This is an excellent test case for all the projects I have done on this site.

To communicate with actuators and sensors I can basically scale up as per need. The plan is to use CAN (or RS485) for a wired telemetry interface. In fact I might need 2 for redundancy. Camera(s) will be a Raspberry PI Zero W with Camera attached. I will need to find or make a solution here to attach camera and a wired or wireless connection. I try to avoid wireless connections inside the drone due to noise and radio density.

2 separate battery banks with a battery charger and PSU’s are needed. Motor batteries and motor power feed is kept separate from control system and sensor PSU. 

BLDC Controlles will be the 3KW 3-phase ones. I can use the Steam Punk Controller as well, but I think we need the smaller space on this one. We need a separate BLDC Controller per thruster.

3D Sensors are basically a variety of 3 axis sensors that is used to detect the drones position in 3D. This together with the GPS can locate the drone in 2D as well.

 The advantage with this control system is that I can scale up/down as I please. Compared to a All-In-One system this adds a few concerns and complexity, but I am not targeting ultra small drones.

 My first objective is a frame like the one below. This is just an early test to get a few meters above ground and get the vertical take off and landing working.

The sketch below is of the actual drone. I add a 5th forward thruster and ordinary wings. The objective is to get more flight distance and time than I can achieve with a classic drone and still have vertical take off and landing. I will build this mainly with 50cm carbon fiber rods jointed to get som size. The thruster will need to be some 3-Phase motor with a frame I need to make. The motors and batteries are probably the cost driver here. These drawing are also only illustrations. I am not an expert in aero-dynamics, and I have some concerns. But, well – that is where reality hits in + I am armed with a forrest of friends that can assist me.

The main concern I have is (1) mechanical design and (2) cost. The show-stopper for the project is however battery capacity that will limit flight time and usability. But, that will improve in the years to follow.

easyUDP

UDP is an excellent protocol for sending messages between nodes in a system with Ethernet or Wifi. It’s speed and behavior on a modern PC’s allows in the region of 100,000 messages per sec, which should be sufficient for most applications.To make a Connection you only need two end-Points of which one need to have a known (fixed) address so the other cand send to it. The receiver get the sender address so it can send back. Sending is also fire & forget as UDP will send regardless wherever the receiver is there or not.

To create a client/server is equally simple. You simple create one client on a fixed address and the the others can contact this.

The true power of UDP is however that it is a “mail-box” on Ethernet that anyone can send to. You can send to any UDP port and receive from any UDP port. UDP bind to the local ip-address and port you use for sending, but it is connectionless so it’s not affected if the receiver drops down, reconnect or simply is not there.

easyUDP is only a thin wrapper on top of UDP to provide a standard, easy, event driven interface. To use the interface you need to do 3 Things

  1. Decide what socket to use and Open the connection. This can be fixed or you can let the computers UDP stack decide automatically. To send a message somewhere you need to know that address, so at least one of the end-points in a UDP connection need a kown address. Address here is ip-address and port number. One concern on modern networks is firewalls as the ports must be opened through firewalls.
  2. Send messages. One UDP connection can send to multiple other UDP connections by setting remote ip-address and port. But, sending here is fire & forget. UDP will send the message intact, but it gives no guarantee that anyone receive the message or what sequence messages arrives in. Sequence will be intact on a single network, but on a more complex network you might experience that packages uses different paths and arrive in a different order. Your protocol using UDP need to handle this.
  3. Receive messages. The technique I use it to establish a reader thread that call back for every message received. As you receive you also need to grab the sender address so you know where to respond back to.

UDP is very lightweight and you need to add you own protocol to maintain sequence and ack messages etc. But, UDP will maintain message integrity since the packet you send is 1:1 with what is received on the other side. The lower interface of easyUDP is different from platform to platform. I currently use a test implementation in C# on Windows that obviously will have only design and interface in common with one in C++ or one on a STM32. UDP/TCP already have a “standard” socket interface, but easyUDP uses a simpler approach of Open(), Close(), Send() and OnMessage().

UDP packets consist of UDP + IP Header + payload. easyUDP will in addition add it’s own little header to support streams. Basically we pack multiple easyIPC messages into the same UDP packet using the standard easyIPC format per Message.

easyIPC Stack

easyIPC is the protocol and collection libraries I use to communicate cross various networks. easyIPC is not bound to a special technology as it provides universal device to device access through a variety of technologies including Ethernet/Wife, RS485, CAN, and SPI and in time others.

UDP, SPI, UART and CAN are examples of technologies I use and they all require a different lower protocol to take advantage of the underlying bus architecture. This is dealt with in AL (Abstraction Layer). UDP (as an example) will have a generic UDP interface, but the one I am interested in here is easyUDP and accordingly easySPI, easySerial and easyCAN. These layers are specially adapted to the easyIPC concept and each module has an identical interface so we don’t need to care about the underlying bus/stack complexity.

The concept is simple – we connect, send and receive messages as if everything is local using a common addressing scheme. Only the sender and receiver need to understand the messages. Message sequences are dealt with in easyIPC or user modules. Lets briefly discuss the technologies and why they are on this list.

easySPI We use a control system composed of Raspberry PI and multiple STM32F405 MCU using high speed Half Duplex SPI as the backbone bus. This gives a speed of 30-42Mbps which in reality makes it very comparable to a 100Mbps Ethernet.
easyI2C This is the same as easySPI using I2C bus. This is currently not supported.
easySerial Using RS485 or RS232 as bus. RS485 implement the TDM bus. Specially RS485 is well suited for distributed control systems as it covers up to 1km wired and as such allows a none-wireless interface to fixed locations.
easyCAN Using CAN as bus.
easyUDP Allows Ethernet and Wifi using the UDP protocol as carrier.
easyBluetooth Allows IPC over Bluetooth.
easyLoRa Allows IPC over LoRa Technologies. Long Range radio allowing up to 12km coverage.
easyNBIoT Allows IPC over NB IoT Technologies. This is basically a low cost phone line allowing you to communicate in all areas With GSM,3G,4G, 5G etc.
easyShockburst Allows 2.4Ghz Shockburst as IPC. Max range is 100 meters, but it is an awesome Wireless protocol With bandwidth up to 2Mbps.

 

 

RS485 Hub 3D draft

First 3D draft of the RS485 Hub. I have moved all connectors to left and top because it will be attractive to use this together with RPI 3B+ that have Ethernet/USB at right. As mentioned I could have used XPortHub for this, but I often need exactly RS485/Ethernet in higher density because RS485 is very attractive connecting to small, remote sensors/actuators. The drawback With what I do here is lack of galvanic isolation, but I will add a separate Hat for that purpose later. In an ideal world we would add galvanic isolation everywhere, but it comes at a huge size and performance cost (slower Serials), so it makes more sense to add isolation between nodes or then connecting to long wires or special Equipment.

  1. CAN Port 1
  2. CAN Port 2
  3. RS485 port 1
  4. RS485 port 2
  5. RS485 port 3
  6. SWD port
  7. RS485 port 4
  8. RS485 port 5
  9. RS485 port 6
  10. USB port
  11. Power Connector 5 external Power.
  12. 3.3V PSU
  13. Status Led’s – I admit I went a bit over the top here With 1 status for each RS485 and CAN. 
  14. 8 or 16Mhz Murata x-tal with capacitors.
  15. Serial Flash. I just added this because I had a spare SPI port.
  16. MCU
  17. RPI Connector. I basically use 5V and SPI pins on this Connector.
  18. Terminator jumper

The actual board will probably change a bit. I like doing these mock-up’s placing connectors and components, but as I start routing I also end up changing things to adapt. Schematics is done, so it will take me a few mornings to get routing done. I find PCB routing to be a relaxing mind game – so yes – this is my form for relaxing.

You probably feel the site have slowed down a bit, and yes it has. To much happening Real Life at the moment so it will be a bit like this for a while. It is also a consequence of me digging deeper into SW as I have an large backlog of things I need to code up.