BasicPI – Page 37

LoRa & GPS

Posted on August 30, 2019August 30, 2019 by Jan

Rev 1.3 of my LoRa/GPS Hat. It will be a Rev 1.4 before I order this PCB because I want some changes. I want to remove (11) the UART port and (7) the separate Power port. The 5V power port will be removed on all Hat’s as I want to force 5V through USB or a separate PSU board. Having a separate MCU Power connector on each board is just occupying space and I need to be more consistent to separate MCU power and Motor power on those boards that need both.

CAN Tranceiver
LoRa 125mW Tranceiver. Covers between 3-6km of range.
LoRa 1W Tranceiver covers up to 12Km of range.
LoRa Antenna port
Leds
Standard USB
MCU Power
GPS Module
GPS Antenna port
GPS USB Connector
UART
SWD
RPI Connector

I have the modules, I also have the Rev 1.0 boards, but I did a schematic error on 1.0 and I have so much to do so I will make Rev 1.4 and order new boards before I assemble this. A last change I am considering is to remove the E22-900M30S which is the 1W version. But, I will leave it on for now since I have a few modules anyway.

This board is quite flexible as I can switch on LoRa and GPS separately. The main reason I am holding back on assembling these units is coding – it requires a bit of coding for testing and the framework is in the pipeline, but I focus on XPortHub to build basic libraries/infrastructure.

Unable to start USB from STCubeIDE

Posted on August 30, 2019August 30, 2019 by Jan

Adding the USB console with a buffer so I can perform printf before the console is open was very usefully as I instantly detect that it’s huge differences between starting the device from the IDE on debug mode or on its own.

These things are a bit annoying, but they can be handled if your aware of them. USB start from IDE if I restart the computer, but after a while it stop working. If I start the device outside the IDE I have no problem. I believe the issue is the PC/IDE and not the device.

STCubeIDE promote usage of Debug, meaning your start in single step mode and I know from other IDE’s that this sometimes can be a bit funny. I only use this to verify init sequences as single-step is very intrusive in a multi-threaded app. So the console is very valuable as it instantly tells you what is going on and give you a capability to log from the device at high speed since this is USB. STCubeIDE have a more hidden support for starting the device differently so I will set this up later. For now it is workable to restart the device by plugging USB cable in/out.

I am not sure USB is of much usage in real use on a control system, but it is very handy for debugging, downloading new firmware (once I get bootloader) and maintenance/config tasks. I am however depending on one feature – I need the MCU main feed to be 5V only and very separate from motor/pwm PSU’s. This enables me to power the MCU through the USB. I realize I need to review my boards on this to ensure this is safe. In fact, I am considering removing external PSU feeds for 5V and only use the RPI bus, meaning you either feed USB power to one device or add a PSU board to the stack.

BasicPI OS Started

Posted on August 29, 2019August 29, 2019 by Jan

Kind of cool – using USB as console on XPortHub – notice all the init messages before the USB starts. Just a buffer tricks. The “Terminal” is a simple C# app that open a port, read/write. I will upgrade it to a proper CLI later.

This is maybe the most important part of the infrastructure as it allows me to use USB as 2-way console/HMI for debugging.

Getting USB to work is straight forward, but getting it to work properly with STCubeIDE is a different issue. It’s been a few tweaks to get a working IDE.

The idea is that you can use this console to upload firmware and set configuration as well to do debugging/maintenance.

NB-IoT Hat rev 1.1

Posted on August 24, 2019August 24, 2019 by Jan

Just a minor upgrade of my NB-IoT Hat Cleaned up ground plane, remove one UART, added new SWD and resistors on SPI1. I have still not have time to assemble test the previous one, so will do that as soon as I get a SIM card.

This Hat is cool because NB-IoT means you buy a SIM card with close to no monthly cost and send data from anywhere you can connect. NB-IoT is gaining momentum in Norway, so I am on my way to get a SIM card.

CAN Traceiver
UART for com with SIM7020
SIM card
SIM7020E
USB for SIM7020E
Antenna
Leds
MCU USB
Led
External Power input
PSU
SuperCap to assist on send peaks
SWD
MCU
RPI Bus w/SPI

Plain

Posted on August 21, 2019August 21, 2019 by Jan

Plain (Programming Language for AI Networks) is very different from Languages like Python, Java and C#. The only similarity is that they all are based on a Virtual Machine and all use C/C++ as native host language.

One difference is that C++ is more openly integrated into Plain than Java and C#, while Python have an easy path to use C libraries as well. Plain is designed to extend C/C++, while the other languages tries to replace C/C++.

The core difference is however that Plain is network centric and capable of handling logic for a system distributed over a network. It implement concepts not covered by any other Language while it still build on the best from many Languages. In languages like C/C++, Python, Java and C# you need to develop the single device and manually implement a communication technique to other devices. Plain has all this build into core and the added “system diagram” concept that allows a developer to interact with a Complete system consisting of a network of nodes as if it was one system.

Plain support state engines at it’s core which provides a more natural way of coding AI Networks – it simply means we process based on events in the system and Focus more on WHAT we do rather than drowning in the details of HOW we do it. Plain can deal With HOW, but more important is that it leaves those details to C/C++ that is far more suitable to interract With Electronics. Close interaction With C/C++ is important and is provided through it’s OS.

Other key features are parallelism, threading, distributed processing and complex concepts implemented at core with mechanisms forcing the developer to use them in a systematic and safe way.

Plain is basically an assembler assembling into a RTL (Real-Time Linker) syntax that the VM need to convert to executable.

BasicPI OS is implemented in C++ and provide easyIPC, a networking technology that is at core in Plain, but other more classing communication protocols like Modbus and CANbus can also be supported.

At the end of the day Plain was developed for one purpose – I wanted to do more with less hours. I wanted to build high quality AI networks capable of handling complex logic with only a minimal number of coding lines.

Plain looks like an advanced 3rd generation, text based language, but it is referred to as an assembler because it is 1:1 between Plain statement and VM instructions. The higher end of Plain is another language not described in details yet called PLD (Plain Logic Diagrams).

Plain has a lot of heritage from various older languages and easy to learn and easy to use has been at core in it’s design.

Status of Plain is that it’s core infrastructure is coming together, so I will start on it’s Assembler, Linker and VM – they exist as proof of concept, but it’s a job to complete them.

If you have followed the long path on this blog you will see that I am building electronic components that form part of a modular control system. Each of these will be loaded with a Plain VM + supporting C++ infrastructure to handle the device. Once they plug together the magic will happen as they interconnect and automatically form a system controlled by Plain. Seen from Plain it will look as if it all is on one small super-computer.

Plain is not a magical wand making robots more intelligent. In many way it is a modern PLC making it very easy to control the machinery of a complex, modern AI. The actual intelligence is in the logic applied by the developer. The only difference is that Plain will allow even none-developers to do far more will less effort.

Programming languages have not really changed that much since Grace Hopper implement the first ones, but Plain is a huge step forward into allowing the developer and user to specify what a system should do rather than drowning into the details of how things are done like we do now.

The only part missing from Plain is that I have not described how we do advanced Web applications that will be coming up later.

7x Stepper Revision 1.3

Posted on August 19, 2019August 19, 2019 by Jan

This is Revision 1.3 of the 7x Stepper Driver.

Added resistors on SPI1.
Changed to new SWD format.
Added protection against wrong PSU polarity.
Moved leds into board.
Major improvement on ground planes.
Previous change on 1.2 was that I turned the Connectors around.

I re-routed the entire module from scratch and created ground planes on both sides. The new technique is to use the top-side as much as possible to leave the bottom side as much as possible. But, I also added the ground plane top side and added extra connections to ensure that all fragments are connected to ground on bottom side.

The reason I abandoned ground plane on top-side was because of the number of short-cuts I experienced. I have since then invested in microscope that makes it possible to actually see if I have a shortcut. This is regardless only a problem on the prototypes where I do manual assembly.

Here you see the top plane (blue) that get very fragmented since it carry a majority of the lanes. The good thing is that I can ground icelands with a single place through.

This is the bottom layer (red) that now is more or less one solid ground plane with minimal fragmentation. This is a major improvement from the previous Version.

16xServo Hat

Posted on August 18, 2019 by Jan

This is rev 1.3 of 32xIO/Servo Hat. It’s been a few revisions that I never bothered to build because the original is working well. But, I need some changes on this:

SWD need to change to new format.
Connection to SPI1 need resistors.
2nd Power connector needs to be added.
Connection between motor and 5V USB can be moved into board.
Leds can be moved into board.
Adding protection diodes on wrong polarity.

The main change I want is however new Servo/IO connectors. The right-angle headers used here are great, but they have no mechanical fittings and are candidates for falling off during vibration. How I can achieve this is a puzle. I might have to use JST Micro 3-pin in which case I can achieve 16 IO/Servo ports maximum. I am however thinking that is OK because firstly I can stack board, secondly 16 x IO is a lot + it is much easier to ensure 16 x PWM timers and use hardware for higher pulse accuracy on Servoes.

That said I think the 16x IO/Servo Hat can start at revision 1.0 and we upgrade this to rev 1.4, meaning I maintain both for now. The 32xIO/Servo Hat is after all a cool hobbyist board + it is the closest I have to a generic GPIO Board.

ESP32 based Ethernet/Wifi Adaptor

Posted on August 17, 2019August 17, 2019 by Jan

RC1 of the ESP32 based Ethernet/Wifi Hat can be seen above. The module follow the same standards as the STM32 based modules with SPI backbone CAN and USB. The board can fit straight on a Raspberry PI or be combined with any module described in this series. New to this version is that I removed the IO ports of the previous version and added a wired Ethernet option using LAN8710 Transceiver. This is a 10/100Mbs Ethernet and the lwIP stack is already on the ESP32 module. In Effect this gives Wifi, Bluetooth and Ethernet Acces in addition to CAN, SPI and USB.

ESP32 have a build in antenna that we still can use, but I added a 2.4Ghz antenna option that can connect to IPEX antenna on some modules. This allows us to use at least 3 different ESP32 modules available on the marked. The 3D model below show the module annotated.

CAN Connector. The actual connector is a right angle 3-point micro connector. Basically the same as used on all boards.
Terminator for CAN. If connected add 120Ohm terminator resistor.
LAN8710
RJ45 Ethernet with magnets.
Ethernet power led. This indicate if Ethernet is powered on or not. I use a separate SPX3819 that is controlled by ESP32 enabling me to switch off Ethernet if I want to.
2.4Ghz antenna connector for Wifi/Bluetooth.
USB Mini connector. Needed for programming the module.
Leds
CH340G UART to USB. I have used these for a while and I am very happy with their performance.
External 5V power connector.
Internal PSU regulator
ESP32 module.
Reset connector.
Leds
Raspberry PI connector using 5V and SPI.
Boot connector
CAN Transceiver.

Ethernet Ground Plane

Posted on August 17, 2019August 17, 2019 by Jan

Just showing the ground plane on the Ethernet/Wifi Hat. I am very pleased with this one and the approach I used here. Earlier as I routed I have routed on both sides with ground plane becoming very fragmented. On this one I only used ground plane as an exception and only for minimum distances. The cost is that I go forth an back a little, but the result was a much better ground plane with no fragmentation of areas.

I feared routing Ethernet would be difficult an result in a very fragmented board, but it has actually gone much smoother than expected and with a very good ground plane as result.

I do however keep promissing myself to move to 4 or 6 layer PCB’s once I have the prototypes working. I don’t need extra layers for routing, I need extra layers for EMC and noise reductions as I start penetrating higher frequency signals. But, well – if this works on 10Mbps and not on 100Mbps we know the reason and how to fix it. I will annotate the new Hat later.

Modular Control System

Posted on August 16, 2019 by Jan

This drawing is an overview of the Hat’s in progress. A few is only on the planning stage, but most electronics is on prototype level and SW is coming on.

Raspberry PI is the obvious core if I need heavier processing. Due to the nature of it’s SPI I can only connect one of these on the same bus. But, it is not given that the bus here must be SPI as we also can dig into Ethernet, Wifi, Serials, CAN, LoRa and NB-IoT.

Wifi/Ethernet Switch is new. I am thinking of HLK-7688, but I need a switch regardless to use Ethernet and Wifi in a system. I will do some experiments this authumn to see if I can achieve something here.

Ethernet/Wifi Hat is on it’s way. This is a simple replacement of Raspberry PI that allows me to add multiple Ethernet/Wifi connection points. Excellent for secondary connections or low cost adaptors. Or well – low cost – the price of a Raspberry PI is hard to beat due to it’s high volume production, so lets see.

LoRa/GPS is on it’s way. I have the first PCB (with errors), but I have not found the time to assemble them yet. I actually considering updating the PCB before I crack on. I am a bit eager to learn more about this technology as it provides free radio up to 12ich km in line of sight.

NB-IoT Hat has same status as LoRa – I have the PCB, but lack subscription and time. I actually need a SIM card w/subscription to connect to the telecom network for this – again a technology I would like to learn more about. If my understanding here is correct I can connect from isolated places to monitor data with this.

XPortHub is made, but I need a revision + I also consider making a variant with Pro-EP10 or similar to get a Ethernet connector. The SW on this is also coming on as this is the project I use to build infrastructure. The plan is to duplicate AL/tools on all Hat’s and start adaptions later this year.

Sensor Hat is on it’s way. This is a Hat offering connections to multiple sensors Analogue, Digital, SPI and I2C.

3D sensor is only on draft level. I have components and need to find time to experiment. This will include GPS, Magnetometer, Gyroscope, Accelerometer, Pressure (Altitude), Temperature and humidity. The target is 3D sensors for motion drones.

Watchdog is new on this list. The idea is a separate Hat that monitor/power on/off the rest.

PSU is 5V PSU feed from higher voltage + maybe I make the watchdog capacity here. Watchdog and PSU are ideas, but not very mature ones – that said it is obvious that I need to find a battery/PSU solution for my systems.

32xServo/IO Hat – I have an older version of this, but have not ordered the new PCB. I need to do a review with focus on the Servo part with some testing. Some pins can be driven by timers, but I do not have 32 PWM channels, meaning that some pins will need software feeding or be IO only. It might be that this is reduced to 16xServo +16xIO etc. To be honest 16 servo ports are rather high density + I can stack these boards up. I also have an issue with these right angle header connectors so it could be an idea with proper connectors that do not fall off etc – I have to look into options.

8xDC + 16xIO Hat is not ordered. Again I have old versions that I want to experiment with first. This Hat might actually be ditched because the 12xPWM can drive 6xDC + I have a ESP32 project that also can drive multiple DC motors if I need more optional space.

12xPWM Hat is on it’s way now. This is maybe the most powerfully motor Hat I have as it can drive 12xSolenoids, 12xPWM signals, 6xDC Motors, 4×3-phase motors or 3xSteppers with current sensors.

3KW Universal Motor Hat. My 160 component steam-punk monster. My wife named this Steam-Punk Driver due to the thick cobber wires. I have to admit that I have assembled, switched on PSU power that works fine and hidden it for a boring day The driver is so powerfully that I lack a project/usage for it. But, the 3KW Thunderstick targeting 3-Phase motors is on it’s way + I am waiting for a new motor. I actually have a 3KW motor, but I need mounting for it + hrmfff PSU to test. The 3KW UniMotor will be completed because I like that project, but I fear I lack project for it.

7x5Wire Stepper is assembled and tested. Motor code is ready, but it needs a new PCB with minor fixes and AL infrastructure so it can go into a system. This is dedicated the small 5-wire steppers that cost ca 1.- USD.