BasicPI

NB-IoT Hat rev 1.1

Posted on 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.

  1. CAN Traceiver
  2. UART for com with SIM7020
  3. SIM card
  4. SIM7020E
  5. USB for SIM7020E
  6. Antenna
  7. Leds
  8. MCU USB
  9. Led
  10. External Power input
  11. PSU
  12. SuperCap to assist on send peaks
  13. SWD
  14. MCU
  15. RPI Bus w/SPI

 

 

Plain

Posted on 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 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 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 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.

  1. CAN Connector. The actual connector is a right angle 3-point micro connector. Basically the same as used on all boards.
  2. Terminator for CAN. If connected add 120Ohm terminator resistor.
  3. LAN8710
  4. RJ45 Ethernet with magnets.
  5. 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.
  6. 2.4Ghz antenna connector for Wifi/Bluetooth.
  7. USB Mini connector. Needed for programming the module.
  8. Leds
  9. CH340G UART to USB. I have used these for a while and I am very happy with their performance.
  10. External 5V power connector.
  11. Internal PSU regulator
  12. ESP32 module.
  13. Reset connector.
  14. Leds
  15. Raspberry PI connector using 5V and SPI.
  16. Boot connector
  17. CAN Transceiver.

Ethernet Ground Plane

Posted on 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 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.

LAN8710 vs Pro-EP10

Posted on by Jan

Again I am not done routing, but I wanted to illustrate ca the space cost of adding an Ethernet Phy and why I was so interested in Pro-EP10. You can see Pro-EP10 footprint at left in green, while LAN8710 and RJ45 w/magnets build in is in blue at left. Using Pro-EP10 would be a huge space saving + the Linux means you can have things like Web servers on separate processors – which we also can since we have ESP32 for this purpose.

The drawbacks with Pro-EP10 is cost (ca 18.- USD), reduced bandwidth through a serial Interface and more complicated toolchain on an embedded Linux. The later is not really that limiting because the MCU’s we use will struggle with higher bandwidth, so it will work out. I already have a Pro-E10 and it will cost me a bit of time and ca 20.- USD to do a demo Hat, so lets see. I am actually considering adding Pro-EP10 to XPortHub.

That said HLK-7688 is much better beacause it offers Wifi and 5 Ethernet ports with a 150Mbps bandwidth switch build in – assuming I can use the SPI as I want and get control over the toolchain. The later is the main drawback with these Linux options. ESP32 on the other hand is well supported and have an excellent, easy to use Toolchain.

Wifi/Ethernet Hat

Posted on by Jan

Not routed the Hat yet, but got all components on the PCB and it looks possible. Using an optional 2.4Ghz antenna on this one. It will take ca 1 week and I probably have the first draft routed. It tends to og fast once I start. What I usually do is to do a bit now and then and suddenly it’s done. I have mentioned this before that I find PCB Routing like a relaxing mind-game.

Wifi/Ethernet Hat Drafts

Posted on by Jan

Getting on with my ESP32 based Wifi/Ethernet Hat. First draft of schematics below. This is the first time I try LAN8710 so all bets off. I am most worried about the 100Mhz signals here. The next picture show components before I place and route the PCB. This looks tight tbh.

LANEnable will switch power on/off enabling me to run with only Wifi or only Ethernet. The rest is IO for Ethernet RMII Interface. I have ordered some breadboards to Experiment With this before I see any point ordering it.