MC3P60V50A Thunderstick Testing

I started assembling Thunderstick and also start finding things I need to change. Mostly small things except one schematic error on the buck converter. It is not fully assembled yet, but 3.3V is working and it’s time to run the MCU.

  1. The mechanical mount holes are to close to ground, meaning the bolts my connect to ground by mistake.
  2. I have 2 capacitors on 60V input and have used standard 0603 components. I tested them at 30V yesterday, but I need to replace them capacitors that can handle 60V.
  3. I have no power led. This was done to save space, but I seriously want a power led on 3.3V.
  4. This is a bit worse as I had a schematic error on the buck converter resulting in 5V being 50% of input voltage. I fixed that, but I also had to adjust R12 a bit to get 4.2V out. Mounting the SPC3819 I now have a nice 3.3V. I had some trouble with the buck converter before I realized that R12 was not properly soldered.
  5. I want the new 2×5 pin SWD on the board. This uses a 6 pin and the idea was to use a JST connector, but the added wiring made SWD sensitive. Using a single 5 or 6 pin is less attractive than 2×5 pin since they are stable to mount on and come in bulk.
  6. BOM list needs to be optimized, consistent numbers and E values.
  7. J15 are to close to the edge.
  8. J14 are to close to the edge.
  9. J16 overlap resistor
  10. J11 overlap resistor
  11. J4 are to close to the edge

I have to admit that this project looks far cooler than I expected, but I still have to mount the MOSFET and do a lot of proof of concept testing. It will be very interesting to read temperatures and currents etc.

3KW 3-Phase Getting Assembled

 

My Thunderstick PCB’s arrived some time ago, but it has been very hectic at work so I simply had no time to work on it. I also have a new 1kw motor that will be nice to test. The pictures above is the board with DRV8301 mounted. I have to start with this because I need the PSU from this to drive the MCU. This is a 8V to 60V driver, so it should work well at 12V,24V and 48V with a design target of 50A out.

I almost ditched this board due to the more powerfully version in the back of this picture that serves 4 channels and have a Raspberry PI mounted, but looking at how small and neat the Thunderstick have become I admit that it is much nicer to use on drones with 3-phase motors. As mentioned before the larger board lacks motors to put it to justice as we speak. Also counting components the smaller have ca 60 while the larger have ca 160 components. I was actually tired after mounting the larger one.

This shows the backside of the board with pads for MOSFET and DRV8301.

This shows the thermal 2mm rubber isolation and the heat-sink mounted. The idea is that we cool down the PCB and pads and as such cool down MOSFET and DRV8301. The design is expected to operate without heat-sink, but then it is the issue about theory and practice. It will be interesting to learn. I have not been able to do that on the larger board yet because I did a mistake not letting the MOSFET pads through so the MOSFET’s are on their own. I can test logic, but not power like that. On this I actually got 20 PCB’s so I will be burning some of them to do research on power lanes later.

This last picture show the new 1KW drone motor I plan to use. The last motor was more powerfully, but it required a bit of mechanical mounting to use it. This can just stand on the table thought I will need some mounting as I start running in speed. 48V * 20A is 960W and I have a 50V 0-20A PSU (that I need to assemble) so I can actually support this test.

Ethernet/Wifi Hat Height

This is the Ethernet board 3D from front. This 3D model is a bit ruff, but it serves its purpose and looking at this I realize that the RJ45 connector is to high. This is not critical as I can adjust hight by extending the pins to the next board (not shown) and use extended PCB spacers. But, I could also solve this by using a different RJ45 that is lower and positioned half way through the PCB. I could also just use magnets and remove the RJ45 itself which is common in some industrial solutions, but I prefer using a standard RJ45. The funny thing is that I was concerned about the antenna connector which also is on the edge – which means I have the same challenge with NB-IoT, LoRa and GPS antenna connectors.

The current board (rev 1.2) uses LAN8710 and looking at the chips I have decided to move to LAN8720 which is smaller, but looks easier to solder. But, I will order the LAN8710 board anyway since I have a few chips around.

I currently experiment with a Olimex board that use LAN8710 and the code is actually for LAN8720, so the chips are compatible. LAN8720 is a simplification of LAN8710. It will be interesting to know if I can manage soldering these QFN packages for hand because I have a few chips that I have avoided due to this.

The Olimex board (shown above) works OK and add Ethernet and SD-Card + a few pins. Coding this rather straight forward, but I am a bit puzled as to why they don’t provide proper sample code. It is actually not much sample code demonstrating Ethernet – that said it is basically only the init that is different from Wifi. I use Arduino libs at present, but will switch to the full SDK later.

ESP32 Ethernet Hat Challenges

I am a bit stunned by the memory usage on ESP32. This is a 178 line test script that uses wired Ethernet and it only send an UDP message out – the program uses 645606 bytes – which is 49% of available space. Luckily it does not increase that much, so I assume this is the core libraries. I would also like to understand why a 4Mb Flash is reduced to 1310720 bytes… The answers are probably online somewhere.

A more annoying issue with ESP32 is it’s SPI support. I wrote sometimes earlier that I lack info about SPI, but I finally found some doc that states it can support up to 80Mhz on selected pins, and 40Mhz if you select your own pins – but only in Master mode and only in Full Duplex. In Half Duplex and Slave it might be reduced to something like 8Mhz due to lack of DMA support etc – bummer. This is not a showstopper, but it will force me to use reduced speed on SPI with ESP32 modules in the stack – which is a bit annoying since this is an Wifi/Ethernet adapter.

Coding on an Olimex GW board works fine – I am not able to test SPI here, so I will use a different board for that, but Ethernet works just fine so far. I must admit that ESP32 is a good match for Arduino libraries. The libraries are not as flexible as the full SDK, but it requires very few lines to get something up working. The main limitation that the libs are blocking can also be overcome by putting both CPU’s to usage.

Wifi/Ethernet Rev 1.2

Minor upgrade of the Wifi/Ethernet Hat as I remove the 5V Power connector from all Hat’s. It just occupy space and I really needed to add a shortcut protection if I was to keep it. 5V for MCU will now only be available from RPI backbone or USB only. I already have a separate PSU board + it is easy to add a connector on RPI between pin 4 and 6 for 5V if I want to use a board stand-alone and not use USB. I will do this change on all my boards + add PSU protection on those who need motor power. The objective is to avoid that an entire stack is destroyed by a single mistake mixing up 5V/Motor or PSU polarity.

I just receive an Olimex Gateway Development Board with the main components, it lack CAN and SPI1 but Ethernet is identical and based on LAN8710. I might swap for LAN8720 later, but that is for later. The Olimex have some demo software so I can get Ethernet up running and experimenting.

The 2nd change I needed was that I use an AMS1117 for 3.3V on ESP32 and a SPX3819 for LAN8710 and by mistake the 3.3V outputs was connected. The intention is that Ethernet should be switchable on/off. I am however also a bit unsure about SPX3819 as this feeds 0.5A. I need to verify that this is sufficient.

The 3rd change is that I by mistake added ground plane below over the build in antenna on ESP32. I plan using the external antenna on this, but we should still avoid ground plane over the antenna part. The new PCB is displayed below.

And just to repeat – this board basically replace Raspberry PI for Wifi, Bluetooth and Ethernet allowing an ESP32 to be used in the stack. SPI is connected on RPI bus and can support both Master/Slave and the Half Duplex mode. I have never tested ESP32 on SPI, so it will be interesting. I also have the CAN port. The main difference from RPI is however that I can add several of these boards in the same stack if needed.

I will regardless get the Olimex board working before I order this + I just also receiver PCB for Thunderstick, 12PWM and Sensor Hat, so I got plenty to play with – as if my backlog was not already filled 🙂

LoRa & GPS

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.

  1. CAN Tranceiver
  2. LoRa 125mW Tranceiver. Covers between 3-6km of range.
  3. LoRa 1W Tranceiver covers up to 12Km of range.
  4. LoRa Antenna port
  5. Leds
  6. Standard USB
  7. MCU Power
  8. GPS Module
  9. GPS Antenna port
  10. GPS USB Connector
  11. UART
  12. SWD
  13. 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

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

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


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

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.