Espressif Announces the 
Release of ESP32-S2 Secure Wi-Fi MCU

Espressif announces the release of the 
ESP32-S2 Secure Wi-Fi MCU, which is a highly integrated, low-power, 2.4 GHz Wi-Fi Microcontroller SoC supporting Wi-Fi HT40 and 43 GPIOs. Based on Xtensa® single-core 32-bit LX7 processor, ESP32-S2 can be clocked at up to 240 MHz.

ESP32-S2 is a highly integrated, low-power, 2.4 GHz Wi-Fi Microcontroller SoC supporting Wi-Fi HT40 and 43 GPIOs. Based on Xtensa® single-core 32-bit LX7 processor, it can be clocked at up to 240 MHz.

With state-of-the-art power management and RF performance, IO capabilities and security features, ESP32-S2 is an ideal choice for a wide variety of IoT or connectivity-based applications, including smart home and wearables. With an integrated 240 MHz Xtensa® core, ESP32-S2 is sufficient for building the most demanding connected devices without requiring external MCUs.

By leveraging Espressif’s mature and production-ready software development framework (ESP-IDF), ESP32-S2 achieves a balance of performance and cost, thus bringing faster and more secure IoT connectivity solutions to the market.

Features

CPU and Memory

  • Xtensa® single-core 32-bit LX7 microcontroller
  • 7-stage pipeline
  • Clock frequency of up to 240 MHz
  • Ultra-low-power co-processor
  • 320 kB SRAM, 128 kB ROM, 16 KB RTC memory
  • External SPIRAM (128 MB total) support
  • Up to 1 GB of external flash support
  • Separate instruction and data cache

Connectivity

  • Wi-Fi 802.11 b/g/n
  • 1×1 transmit and receive
  • HT40 support with data rate up to 150 Mbps
  • Support for TCP/IP networking, ESP-MESH networking, TLS 1.0, 1.1 and 1.2 and other networking protocols over Wi-Fi
  • Support Time-of-Flight (TOF) measurements with normal Wi-Fi packets

IO Peripherals

  • 43 programmable GPIOs
  • 14 capacitive touch sensing IOs
  • Standard peripherals including SPI, I2C, I2S, UART, ADC/DAC and PWM
  • LCD (8-bit parallel RGB/8080/6800) interface and also support for 16/24-bit parallel
  • Camera interface supports 8 or 16-bit DVP image sensor, with clock frequency of up to 40 MHz
  • Full speed USB OTG support

Security

  • RSA-3072-based trusted application boot
  • AES256-XTS-based flash encryption to protect sensitive data at rest
  • 4096-bit eFUSE memory with 2048 bits available for application
  • Digital signature peripheral for secure storage of private keys and generation of RSA signatures

Engineering Samples of ESP32-S2 beta will be available in June.

For more information, please contact Espressif Business Team.

DC slotless motor runs at up to 40,000 rpm

Portescap has expanded its Ultra EC range of brushless DC slotless motors with the introduction of a ultra-high speed 2 pole motor, the 35ECS.

The 35mm diameter slotless motor draws up to 330W max imum in continuous operation and sustains speeds up to 40,000 rpm. The new design comes in two lengths: the 35ECS60 at 60mm and the 35ECS80 at 80mm , with peak torque s during 2s up to 1.1Nm and 2.0Nm, respectively. Both motors feature the company’s pat ented Ultra EC coil technology which provides unparalleled torque and power density with limited core losses over a wide range of working speeds without friction and brush wear. The se motors feature a laser welded front flange to ensure the strongest housing to sustain high torque reaction. A temperature probe on the coil head ensures an optimized control of motor performances in heavy duty applications. The devices are offered with hall sensors and a total of 6 different coils to match your speed and voltage requirements. Upon request, Portescap can also provide options for customization including gearboxes, encoders, coil variations and mechanical interface modifications.

Portescap – www.portescap.com

Small form factor board has computing power for medical and IoT

Populated with the Intel Core i5 7300U and i3 7100U processors, the WUX-7x00U is a small form factor (SFF) embedded board by Portwell. The processors, formerly codenamed Kaby Lake, integrate the low power Intel Gen. 9.5 HD Graphics, 620 graphics engine with 24 execution units, enabling enhanced 3D graphics performance and higher speed for 4K encode and decode operations.

The low power consumption makes the WUX-7x00U particularly suitable for applications such as medical equipment, IoT gateway, industrial automation, warehouse automation and digital signage.

WUX-7x00U back view

The WUX-7x00U has a compact footprint of 101.6 x 101.6mm or four x four-inch. Within this compact area, it has up to 32Gbyte DDR4L SDRAM (2133MHz) RAM and multiple storage interfaces like one SATA III port and one M.2 Key M for SSD. There are also three USB 3.0 ports and one USB3.0 Type-C port. The Intel 620 HD graphics engine drives one DisplayPort (DP) (4096 x 2160) and two high definition multimedia interfaces (HDMI) with resolution up to 4096 x 2304, which can be operated simultaneously. An M.2 Key E interface, enables wi-fi and Bluetooth communication and connectivity for IoT applications.

WUX-7x00U side views

The Portwell WUX-7x00U operates with thermal design power (TDP) of 15W. The integrated low-profile fan ensures long and stable operation. The wide voltage power input ranges from 12 to 19V. The design and multi-core processing power ensures that the Portwell WUX-7x00U embedded board can execute an array of applications that demand processing power as well as connectivity from digital signage in various environments, from manufacturing robots and industrial automation, through to video analytics-based appliances.

Portwell is an Associate member of the Intel Internet of Things Solutions Alliance, designs and manufactures a full range of IPC products (SBC, backplane, redundant power supply, rack mount and node chassis), embedded architecture solutions, DVR system platforms and communications appliances. Portwell provides R&D and project management services to reduce time to market, and lower project risk and cost.

Highligh Features

  • Intel® Kaby Lake-U Core i Processor
  • Up to 32GB DDR4 2133 non-ECC SDRAM on two SODIMM slots
  • Dual displays including DP and HDMI up to UHD resolution
  • 2x M.2 (one E Key, one M Key) slots, 1x SATA III port
  • 3 x USB 3.0, 1 x USB 3.0 (Type C), 1 x IR
  • Wide voltage DC power input from 12V ~19V

Portwell is an ISO 13485, ISO 9001 and ISO 14001-certified company that deploys quality assurance through product design, verification and manufacturing cycles.

http://www.portwell.de

Using the BLE functionality of the ESP32

One of the most beautiful features which the ESP32 has over the ESP-12e is the fact that, asides the WiFi, it has two other communication modules onboard. The ESP32 comes with an onboard Classic Bluetooth and Bluetooth Low Energy modules. For today’s tutorial, we will explore how the Bluetooth Low Energy Module onboard the ESP-32 can be used in projects.

The Bluetooth protocol can be divided into two types; Classic Bluetooth, and the newer Bluetooth Low Energy protocol which is also referred to as Bluetooth 4.0. These two protocols operate within the 2.4ghz ISM band but they both have different data rate, different power consumption rate, and are optimized for different kind of applications. The Bluetooth Low Energy (BLE) was created to overcome the setbacks of classic Bluetooth which makes it a little bit unfit for use in IoT and battery powered smart devices which only need to send short burst of data at specific intervals. The BLE was designed to consume only a fraction of the power which classic Bluetooth devices consume when transmitting data and stay in sleep mode when not transmitting data unlike the Classic Bluetooth’s continuous data streaming. This makes BLE devices more power efficient and suitable for IoT products and other battery-powered smart devices which are usually desired to last for as long as possible on a single battery charge.

Using the BLE functionality of the ESP32 – [Link]

Using the BLE functionality of the ESP32

One of the most beautiful features which the ESP32 has over the ESP-12e is the fact that, asides the WiFi, it has two other communication modules onboard. The ESP32 comes with an onboard Classic Bluetooth and Bluetooth Low Energy modules. For today’s tutorial, we will explore how the Bluetooth Low Energy Module onboard the ESP-32 can be used in projects.

Introduction to Bluetooth Low Energy – BLE

The Bluetooth protocol can be divided into two types; Classic Bluetooth, and the newer Bluetooth Low Energy protocol which is also referred to as Bluetooth 4.0. These two protocols operate within the 2.4ghz ISM band but they both have different data rate, different power consumption rate, and are optimized for different kind of applications. The Bluetooth Low Energy (BLE) was created to overcome the setbacks of classic Bluetooth which makes it a little bit unfit for use in IoT and battery powered smart devices which only need to send short burst of data at specific intervals. The BLE was designed to consume only a fraction of the power which classic Bluetooth devices consume when transmitting data and stay in sleep mode when not transmitting data unlike the Classic Bluetooth’s continuous data streaming. This makes BLE devices more power efficient and suitable for IoT products and other battery-powered smart devices which are usually desired to last for as long as possible on a single battery charge.

A detailed comparison between the two Bluetooth types is shown in the Image below.

BLE vs Classic Bluetooth

One of the downsides of the operation dynamics of BLE devices is the Complexity or Robustness (depending on how you look at it) of the messaging system. In classic Bluetooth, the serial port protocol (SPP) is usually used to send data between the devices as the communication occurs without much overhead, but for BLE, data during communication is organized using a profile referred to as GATT (Generic Attributes).

There are essentially two protocols that are important in communication between two BLE devices; GAP and GATT. Understanding how these two work is extremely important to programming devices to communicate via the BLE protocol.

GAP Protocol

GAP is an acronym for the Generic Access Profile, and it controls connections and advertising (Making a device visible and open for connection) in Bluetooth. It defines the roles which devices play in communication and also determines how the advertising (or scanning, depending on device role) payload is broadcasted.

There are essentially two roles which BLE devices can play based on GAP; Central Device and Peripheral Device. These two devices are the BLE’s representation for the more popular words; “Client” and “Server” respectively. The peripheral devices are usually small battery powered devices who broadcast the advertising data, waiting for a connection from a central device ready to receive the data payload. In IoT based solutions, the peripheral devices are usually sensors, etc., while the Central devices are usually gateway, smartphones, etc. Prior to connection, the Generic Access profile will keep broadcasting the advertising payload until there is a matching scanning response. Once a connection between a peripheral and a central device is established, the advertising process will stop and you will typically no longer be able to send advertising packets out anymore, at this point, GATT services and characteristics kick in to facilitate communication in both directions.

GATT Protocol

GATT is an acronym for the Generic Attribute Profile, and it defines how two Bluetooth Low Energy devices, transfer data back and forth between each other, using concepts called Services and Characteristics. It makes use of a generic data protocol called the Attribute Protocol (ATT), to store Services, Characteristics, and related data in a simple lookup table using 16-bit IDs for each entry in the table. The GATT hierarchical data structure comprises of three main elements; Profiles, Services, and Characteristics.

GATT

A Profile is a pre-defined collection of Services that has been compiled by either the Bluetooth SIG or by the peripheral designers. For example, in a heart rate monitor, a Heart Rate Profile could include the Heart Rate Service, the Battery Life Service, and the Device Information Service. A list of officially adopted GATT is available here.

Services are used to group data into logic entities and contain specific chunks of data called characteristics. A service can have one or more characteristics, and each service distinguishes itself from other services by means of a unique numeric ID called a UUID, which can be either 16-bit (for officially adopted BLE Services) or 128-bit (for custom services). A full list of officially adopted BLE services can be seen on the Services page of the Bluetooth Developer Portal. To better understand how services work,  Consider the Heart Rate Example again, it could contain up to 3 characteristics which in the officially adopted service, for instance, includes; Heart Rate Measurement, Body Sensor Location, and Heart Rate Control Point. Thus a service essentially to group related data.

Characteristics represent the lowest level concept in GATT structure. It encapsulates a single data point and just like services, it distinguished from other characteristics using a Unique numeric ID; the UUID. Characteristics are the major containers that carry data between two devices.

With these said, today’s tutorial will show how to set up the ESP32 as a Client (Central Device) and as Server (peripheral device). For proper demonstration, we will use two ESP32 boards. One of the boards will be programmed to act as the server, with characteristics to send random data,  while the other ESP32 board will be programmed to act as a BLE scanner to find the server.

Required Components

  1. DOIT ESP32 DevKit (2 nos)
  2. Power Bank/ Battery

As mentioned in the introduction, we only need the ESP32 Module as it already has all that is needed for the project on board. The power bank helps to easily power the Devkit in standalone mode. You can easily modify this tutorial by adding sensors to send live data to the central device.

We will use just the ESP32 boards so with no schematics, we go straight to the project’s code.

Code

Since we will not connect any components, let’s jump straight to the code. As mentioned in the introduction, we will setup the ESP32 as a client and as a server. This means we need two different sketches and we will go over them one after the other.

It is important to note that the code for this project will be written using the Arduino IDE and it will be impossible to upload the code if your IDE does not have the ESP 32 Arduino board package installed. This setup, downloading and installing the ESP32 board files for Arduino was covered in our Introduction to ESP32 tutorial. Ensure you check it out.

Once you have the board files installed, it will automatically load several ESP 32 libraries to the Arduino IDE. Both sketches for today’s tutorial will be heavily dependent on one of those libraries; the ESP32 BLE Arduino Library. The library comprises of functions and declarations that make sending data through a complex protocol (at least more complex when compared with serial) like the BLE easy.

BLE Server Sketch

I will do a brief explanation of both sketches starting with the BLE Server. The algorithm for the BLE server follows the explanation during the introduction above. We start by creating a BLE Service, after which we create BLE Characteristics under that service and a BLE descriptor under the characteristics. We then Start the service and start advertising so the device is visible to Scanning BLE devices.

We start the sketch by importing libraries within the BLE Arduino library that are required for the code.

#include <BLEDevice.h>
#include <BLEUtils.h>
#include <BLEServer.h>

Next, we provide the unique UUIDs for the Service and the Characteristics. These UUIDs can be generated using websites like UUID Generator

#define SERVICE_UUID        "4fafc201-1fb5-459e-8fcc-c5c9c331914b"
#define CHARACTERISTIC_UUID "beb5483e-36e1-4688-b7f5-ea07361b26a8"

Next, We write the void setup() function. We start by initializing serial communication to be used for debugging purposes, after which we create an object of the BLEDevice class and set the object as a server.

void setup() {
Serial.begin(115200);
Serial.println("Starting BLE work!");

BLEDevice::init("Long name works now");
BLEServer *pServer = BLEDevice::createServer();

Next, we create a service for the server and a characteristic for the service, specifying the UUID in both cases. The characteristic properties (which in this case are READ and WRITE) were also specified.

BLEService *pService = pServer->createService(SERVICE_UUID);
  BLECharacteristic *pCharacteristic = pService->createCharacteristic(
                                         CHARACTERISTIC_UUID,
                                         BLECharacteristic::PROPERTY_READ |
                                         BLECharacteristic::PROPERTY_WRITE
                                       );

Next, we set a value for the characteristics. As mentioned earlier, we will use a random value for this tutorial but this could be a sensor value, or any other information you wish to send to the client.

pCharacteristic->setValue("Hello World says Neil");

Finally, we start the service, setup parameters for advertising and start sending out advertising payload.

pService->start();
// BLEAdvertising *pAdvertising = pServer->getAdvertising();  // this still is working for backward compatibility
BLEAdvertising *pAdvertising = BLEDevice::getAdvertising();
pAdvertising->addServiceUUID(SERVICE_UUID);
pAdvertising->setScanResponse(true);
pAdvertising->setMinPreferred(0x06);  // functions that help with iPhone connections issue
pAdvertising->setMinPreferred(0x12);
BLEDevice::startAdvertising();

For this demo, we will leave the loop section empty but you can choose to perform further tasks within it. You can go through all the examples under the BLE Arduino library to better understand.

void loop() {
  // put your main code here, to run repeatedly:
  
}

The complete code for the server is available below and it is also attached under the download section at the end of the tutorial.

/*
    Based on Neil Kolban example for IDF: https://github.com/nkolban/esp32-snippets/blob/master/cpp_utils/tests/BLE%20Tests/SampleServer.cpp
    Ported to Arduino ESP32 by Evandro Copercini
*/

#include <BLEDevice.h>
#include <BLEUtils.h>
#include <BLEServer.h>

// See the following for generating UUIDs:
// https://www.uuidgenerator.net/

#define SERVICE_UUID        "4fafc201-1fb5-459e-8fcc-c5c9c331914b"
#define CHARACTERISTIC_UUID "beb5483e-36e1-4688-b7f5-ea07361b26a8"

void setup() {
  Serial.begin(115200);
  Serial.println("Starting BLE work!");

  BLEDevice::init("Long name works now");
  BLEServer *pServer = BLEDevice::createServer();
  BLEService *pService = pServer->createService(SERVICE_UUID);
  BLECharacteristic *pCharacteristic = pService->createCharacteristic(
                                         CHARACTERISTIC_UUID,
                                         BLECharacteristic::PROPERTY_READ |
                                         BLECharacteristic::PROPERTY_WRITE
                                       );

  pCharacteristic->setValue("Hello World says Neil");
  pService->start();
  // BLEAdvertising *pAdvertising = pServer->getAdvertising();  // this still is working for backward compatibility
  BLEAdvertising *pAdvertising = BLEDevice::getAdvertising();
  pAdvertising->addServiceUUID(SERVICE_UUID);
  pAdvertising->setScanResponse(true);
  pAdvertising->setMinPreferred(0x06);  // functions that help with iPhone connections issue
  pAdvertising->setMinPreferred(0x12);
  BLEDevice::startAdvertising();
  Serial.println("Characteristic defined! Now you can read it in your phone!");
}

void loop() {
  // put your main code here, to run repeatedly:
  delay(2000);
}

 

BLE Scanner Sketch

The scanner sketch like the server sketch is available as an example in the ESP 32 BLE Arduino Library.

As usual, we start the sketch by including the required libraries.

#include <BLEDevice.h>
#include <BLEUtils.h>
#include <BLEScan.h>
#include <BLEAdvertisedDevice.h>

Next, we indicate the interval between scan payload broadcasting and create an object of the BLEscan class.

int scanTime = 5; //In seconds
BLEScan* pBLEScan;

Next, we write the void setup() function. We start by initializing the serial monitor after which we initialize the BLE which automatically activates the BLE module on the ESP32. The argument is set as blank since we don’t really require a name for the device.

void setup() {
  Serial.begin(115200);
  Serial.println("Scanning...");

  BLEDevice::init("");

To round up the setup() function, we call the scan function, setting all the parameters required for the scan.

pBLEScan = BLEDevice::getScan(); //create new scan
  pBLEScan->setAdvertisedDeviceCallbacks(new MyAdvertisedDeviceCallbacks());
  pBLEScan->setActiveScan(true); //active scan uses more power, but get results faster
  pBLEScan->setInterval(100);
  pBLEScan->setWindow(99);  // less or equal setInterval value
}

Next, we write the void loop() function. The algorithm behind the void loop() function is used to simply check if any device has been found and print those devices alongside their number. The results are cleared and the loop starts all over again.

void loop() {
  // put your main code here, to run repeatedly:
  BLEScanResults foundDevices = pBLEScan->start(scanTime, false);
  Serial.print("Devices found: ");
  Serial.println(foundDevices.getCount());
  Serial.println("Scan done!");
  pBLEScan->clearResults();   // delete results fromBLEScan buffer to release memory
  delay(2000);
}

The complete code for the scanner is available below and also attached in the zip file under the download section.

/*
   Based on Neil Kolban example for IDF: https://github.com/nkolban/esp32-snippets/blob/master/cpp_utils/tests/BLE%20Tests/SampleScan.cpp
   Ported to Arduino ESP32 by Evandro Copercini
*/

#include <BLEDevice.h>
#include <BLEUtils.h>
#include <BLEScan.h>
#include <BLEAdvertisedDevice.h>

int scanTime = 5; //In seconds
BLEScan* pBLEScan;

class MyAdvertisedDeviceCallbacks: public BLEAdvertisedDeviceCallbacks {
    void onResult(BLEAdvertisedDevice advertisedDevice) {
      Serial.printf("Advertised Device: %s \n", advertisedDevice.toString().c_str());
    }
};

void setup() {
  Serial.begin(115200);
  Serial.println("Scanning...");

  BLEDevice::init("");
  pBLEScan = BLEDevice::getScan(); //create new scan
  pBLEScan->setAdvertisedDeviceCallbacks(new MyAdvertisedDeviceCallbacks());
  pBLEScan->setActiveScan(true); //active scan uses more power, but get results faster
  pBLEScan->setInterval(100);
  pBLEScan->setWindow(99);  // less or equal setInterval value
}

void loop() {
  // put your main code here, to run repeatedly:
  BLEScanResults foundDevices = pBLEScan->start(scanTime, false);
  Serial.print("Devices found: ");
  Serial.println(foundDevices.getCount());
  Serial.println("Scan done!");
  pBLEScan->clearResults();   // delete results fromBLEScan buffer to release memory
  delay(2000);
}

Demo

Copy the code and paste in the Arduino IDE (or launch the code from the example file), then one after the other upload the server sketch to the board designated as the server and the scanner code to the board designated as the scanner. For this demonstration to work, both boards need to be “ON” as the client will not be able to see the server if its “OFF”, so you can either leave the two of them connected to your PC or connect the Server to a power bank or any other power source. With that sorted, launch the serial monitor, ensuring it is set to the serial port to which the client is connected. After a few seconds, you should see the number of Bluetooth devices found and the name(s) displayed on the serial monitor.

That’s it for today’s tutorial. You can immediately expand the project by hooking up a sensor the BLE server and running the BLE Client example on the other ESP32 board or better still use a mobile app that supports BLE devices to interact with the server. BLE is currently one of the most widely used communication methods for smart devices and I hope this tutorial has given you information required to use it for your own project.

As usual, do feel free to reach out to me via the comment section with questions or general comments about the tutorial.

Till Next time!

OpenWrt Module and Dev Board based on Realtek SoC features Wave2

8devicesis accepting pre-orders for its $29 Komikan module, and sandwich-style $59 Komikan DVK development board for Wave2 prototyping at up to 1.166Gbps. The Komikan module runs OpenWrt on a MIPS24k-based Realtek SoC with dual-band, MU-MIMO 802.11ac. The Komikan has the ability to operate without a heatsink, as well as having a lower, 6W power consumption compared to other Wave2 modules. The Wave2 is the second, faster wave of 802.11ac (WiFi 5) radios with dual-band MU-MIMO technology for simultaneous WiFi connections to multiple devices.

The first 802.11ax (WiFi 6) radios will arrive later this year, which will enable lower latency and power consumption, improved synchronized data delivery, and up to 30 percent faster speed. It will be a while before computers, phones, and other devices support 802.11ax, as only a few devices support Wave2 now. The Komikan module runs OpenWrt on a 1GHz Realtek RTL819FS processor. The Komikan’s Wave 2 (concurrent 2.4GHz/5GHz 802.11 a/b/g/n/ac) capacity is the result of its Realtek RTL8822BEH chipset. The RTL8822BEH-VR chipset also enables the module’s Bluetooth 4.1 capability. The 37.5 x 21.3mm Komikan module utilizes an LGA form factor and is approximately half the size of the earlier Rambutan. The module ships with 128MB RAM and 32MB flash.

Komikan DVK

The Komikan module support 2x USB, 4x UART (1x for BT), RGMII, 2x SPI, PWM, MDIO, eMMC, JTAG, 2x I2S, PCM, 2x I2C, and P-NAND. The module also enables 44x GPIO pins, with several pins supporting an external antenna. Its 3.3V module outputs power at “22 dBm per chain.” The Komikan DVK board features an eMMC socket and a microSD slot, to expand the Komikan module’s memories.

The board offers both 10/100 and 10/100/1000Mbps (GbE) ports, a 2x USB 2.0 host ports, and a USB Type-C for power and UART console duty. The dev board is also equipped with dual 2.4GHz/5GHz WiFi antennas, a Bluetooth antenna, reset and GPIO buttons, and dip switches. Available also is a 20-pin GPIO header. The $29 Komikan module and $59 Komikan DVK are available for pre-orders with shipping starting from May 15.

More information can be found on 8devices’ Komikan product page, and also the Komikan and Komikan DVK shopping pages.

System-on-Module with PolarFire FPGA at embedded world

Specialist for embedded services and products, ARIES Embedded, will display the new M100PF System-on-Module (SoM) based on Microchip’s PolarFire FPGA family at embedded world 2019. At stand 441 in hall 3A ARIES Embedded will also introduce the complementary evaluation platform M100PFEVP, which delivers a fast and easy project start for customers.

Our new M100PF board provides the full flexibility of the popular FPGAs for demanding applications in industrial and medical technology,

stated Andreas Widder, Managing Director of ARIES Embedded.

PolarFire captivates with up to 50 percent lower power consumption than competing FPGAs, at mid-range densities with exceptional safety and reliability.

With the SoM, ARIES Embedded extends the FPGA functionality with RAM, Flash, Clocking and additional features.

For industrial use, the system-on-module allows an expanded temperature range, from zero to +70°C up to -40 to +85°C. On the ARIES SoM, the PolarFire FPGAs provide 100, 192, or 300k logic elements (LE) and feature 12.7G transceivers with up to 50% lower power consumption. The 256 Mbit configuration storage, the DDR3 RAM (512Mbit, one or two gigabit), as well as four to 64Gbit eMMC NAND Flash allow the development of complex high performance designs.

Further features of the 72x40mm small SoMs are: eight SerDes with 250Mbps to 12.5Gbps, two PCI express Gen2 end points/root port slots, rich user I/O, and two Samtec QSH-090-01-F-D-A board-to-board connectors.

ARIES Embedded provides the corresponding evaluation platform M100PFEVP to help facilitate a smooth and fast project start. It enables customers to evaluate the PolarFire FPGA, realise prototypes and even use the FPGA in series production. The evaluation board contains two gigabit Ethernet, USB, and four DSub9 interfaces for CAN, RS232, and others, in addition to Pmod and HSMC extension connectors and a microSD card slot.

The M100PFEVP starter kit includes the M100PVEVP baseboard, M100PF-1DB storage extensions, a seven inch touchscreen, and power supply.

more information on: www.aries-embedded.com

Single-Battery Charger and Fuel Gauge Reference Design for Arduino Platforms

The MAXREFDES96# from Maxim Integrated Products is an Arduino Uno R3-compatible board that provides battery charge, boost, and data-logging capabilities. The board can be operated tethered to a power supply or computer to charge a battery and operate untethered to use the battery to power the Arduino board.

Typical applications are expected to include charger/fuel gauge evaluation and portable operation with data logging.

An SD card interface is provided to enable data logging up to 32GB of data. Status and battery state of charge (SOC) is displayed on three LEDs. An Arduino-compatible display can be added for more detailed data display.

The MAXREFDES96 includes the MAX77818 battery-management PMIC (charger only) and the MAX17201 ModelGauge m5 fuel gauge to demonstrate Maxim’s battery-management technology. The board comes on an Arduino Uno R3 platform. The MAX77818 boost circuit can power the Arduino and MAXREFDES96# while disconnected from a power supply.

Additionally, the included DS3231M RTC and a micro-SD card socket allow for data logging with timestamps. The MAX77818 automatically switches between charge mode and boost mode without host intervention to allow the board to switch from battery charging to boosted voltage; this allows the board to run in stand-alone battery-powered applications.

The MAXREFDES96# uses a variety of Maxim devices

The MAX77818 is used for its programmable charge capability and runs up to 3A with an appropriate supply. It can be programmed to automatically switch between charge mode and boost mode based on the presence of the input power. This allows a stand-alone application that switches between charging the battery and boosting the battery voltage to power the 5V rail, allowing it to function properly without intervention from a host.

The MAX17201 is used for its ModelGauge m5 EZ fuel-gauge capability, which allows a compatible chemistry battery to be used without characterizing it, reducing development time.

The MAX7315 I2C-controlled port expander is included to reduce the number of pins used on the Arduino interface. Because the MAX7315 uses the I2C to communicate with the host, the I/O pins that the switches and LEDs would otherwise use can be used for something else. The MAX7315 controls three LEDs for display and debounces two switches for program control.

The MAX7369 I2C mux is included for two reasons. The MAX77818 is both a charger and a fuel gauge, and its fuel-gauge I2C address is identical to the MAX17201. Therefore, when the MAX17201 is being addressed, it must be isolated from the MAX77818, and the MAX7369 provides that isolation. Secondly, the DS3231M RTC is used on other shields, so the address could conflict between the MAXREFDES96# DS3231M and one used on another board. The mux allows the on-board DS3231M to be deselected if needed. The DS3231M also allows its address to be changed by pin strapping, if desired. There is one port on the mux that is uncommitted, which could be used to try out another device such as a fuel gauge that has the same address as the other fuel gauges.

Maxim Integrated Products Inc.

Renesas Synergy™ – FMLR-61-U-RSS3 LoRa® Module designed by Miromico

Renesas Synergy™ goes LoRa® with the new, tiny FMLR-61-U-RSS3 modules equipped with the latest software “LoRa Basics™ MAC” and now available at Avnet Silica.

Everybody wants to connect “things” to the “IoT”  and LoRa® is the ultimate technology to do so across long distances (up to 50km LOS). The new, tiny FMLR-61-U-RSS3 module, designed by Miromico, comes with the latest software “LoRa Basics™ MAC” and is now available in early samples exclusively from Avnet Silica. Of course, it comes with the giant Synergy Software Package (SSP)  to enable you to add your own functionality quickly.

The FMLR-61-U-RSS3 module is only 14.2mm x 19.5mm in size. Its operating voltage is 1.8V to 3.3V, and the module’s power consumption ranges from just 1.4uA in sleep mode to 25.5mA (typical) in TX mode (14dBm). Receiver sensitivity is -148dBm in LoRa mode [email protected] kHz, and the module’s operating temperature range is -40 to 85°C. The module’s exceptional specifications make it ideal for urban as well as rural sensing applications such as metering, asset tracking, building automation, security, wearables, predictive maintenance and more.

The FMLR-61-U-RSS3 module employs the S3A6 MCU with integrated 48 MHz Arm® Cortex®- M4 core, and features 256 KB code flash memory, 8 KB data flash, and 32 KB SRAM, which is enough memory to allow engineers to add a variety of their own functions. Most MCU signals are available at the module level to make them externally accessible. Manufactured in a low- power process, the S3A6 peripheral set includes analog features such as a 14-bit SAR analog- to-digital converter (ADC), 12-bit digital-to-analog converter (DAC), op amps, and comparators. Various timer channels and serial ports, USB function, CAN, DMA, and powerful safety and security hardware makes the S3A6 an ideal MCU for a wide range of battery-operated applications.

The Renesas Synergy Platform features the Synergy Software Package (SSP), which comprises a large selection of production-grade software. SSP includes the ThreadX® RTOS and lots of associated middleware such as a file system, USB stack, graphical user interface (GUI) software, application frameworks and functional libraries that can be used for encryption and DSP functions. This unique and powerful combination of hardware and software helps customers significantly accelerate their product development schedule.

Key benefits

  • Smallest certified LoRaWAN™ modules
  • Line-of-sight range of more than 50km
  • Runs customer specific applicatikons and proprietary radio stacks
  • Module with optional integrated antenna
  • Tiny footprint: 14 x 19.5mm

more information:

A Beginner’s Guide to 3D Modeling

A Beginner’s Guide to 3D Modeling ($24.95, 152 pp., on sale May 28, 2019) is the beginner’s guide to making precise 3D designs, from household objects and art to mechanical parts and even robots. Learn the principles of parametric modeling using Autodesk Fusion, the most powerful computer aided design (CAD) software, which is free for non-commercial use.

Engineers and mechanical designers use this and similar software to create parts to exact specifications. Written by 3D printing guru Cameron Coward, this practical guide’s hands-on tutorials walk readers through every step of its modeling projects. The book also shows readers how to make photorealistic renders of their models and draft technical drawings they can use to get parts professionally manufactured.

  • Learn the tools and design principles of the Fusion 360 3D modeling software
  • Build complex designs efficiently by breaking them down into parts
  • Master advanced modeling techniques to create coils, organic surfaces, and more

Author Cameron Coward is a writer, maker, mechanical designer, and drafter. He is a regular contributing author for Hackster.io and Hackaday.com and the author of Idiot’s Guides: 3D Printing.

“CAD has a steep learning curve that can be daunting to beginners,” said the author. “I created these tutorials so even someone with no experience can easily learn the skills to create their own designs and have them manufactured, or even print them out at home.”

day at the diverse types of projects that young people create using these cards!”

TOP PCB Companies