Feed aggregator

Ascent Solar Technologies Inc of Thornton, CO, USA – which designs and makes lightweight, flexible copper indium gallium diselenide (CIGS) thin-film photovoltaic (PV) panels that can be integrated into consumer products, off-grid applications and aerospace applications – has announced a new partnership with Darley Defense (a global provider of defense, fire and emergency services equipment) to expand access to Ascent’s thin-film PV products throughout defense, federal, space and public sector markets...

Vector has released Chiisai, a fully open and royalty-free specification that radically simplifies the development of hardware abstraction layers (HALs) on small microcontrollers. Chiisai aims to keep HAL implementations deliberately lean: the specification focuses on the essential basic functions, thereby reducing the software footprint and supporting efficient use of microcontrollers with limited resources. The name Chiisai, which means “small” in Japanese, reflects the specification’s focus on resource-constrained microcontrollers, commonly used in sensors, actuators and other compact embedded systems.

Standardised interfaces and separation between drivers and middleware

The Chiisai specification defines standardised interfaces for the relevant basic and communication functions and clearly separates drivers from middleware. This makes it easier to reuse software components across different hardware platforms.

Developed in collaboration with the semiconductor industry

Chiisai was developed in close collaboration with Infineon Technologies, the world market leader in microcontrollers (Omdia, 2025). Infineon Technologies contributed its extensive experience in microcontrollers and hardware to the development of the Chiisai specification, helping to ensure that it was specifically tailored to small microcontrollers. The goal is to standardise HAL development on small microcontrollers in a practical, efficient and vendor-neutral way. Besides Infineon, other semiconductor manufacturers, such as Microchip Technology, are already actively supporting the Chiisai standard and are jointly driving the creation of an open, vendor-neutral software ecosystem.

An open standard for a growing software ecosystem

The Chiisai HAL specification provides an open standard that simplifies the development of vendor-independent HALs. The specification significantly lowers the barriers to entry, enabling the rapid development of custom HALs and their use by a wide range of middleware solutions, regardless of the microcontroller or hardware manufacturer. This creates a growing, cross-vendor ecosystem that promotes interoperability, reduces integration effort and facilitates collaboration between OEMs, Tier-1 suppliers and semiconductor manufacturers. As a result, companies throughout the value chain benefit from easier access to modern embedded software stacks and SDVs.

Full compatibility with MICROSAR IO

The interfaces of Vector’s new base-layer software, MICROSAR IO, are fully compatible with the Chiisai specification. Once a Chiisai-compliant HAL is available for a microcontroller, MICROSAR IO can be deployed on that hardware platform without any additional customisation effort. At the same time, MICROSAR IO is just one of many middleware solutions that can be built on top of a Chiisai-based HAL.

Availability

Chiisai is available at the following repository: https://github.com/vectorgrp/chiisai-hal-specification

More information about Chiisai on the Vector website: www.vector.com/en/industries/automotive/application-areas/chiisai-specification/

The post Chiisai: an open standard for HAL on microcontrollers appeared first on Open Electronics.

NUBURU Inc of Centennial, CO, USA (a dual-use defense & security integrated platform company) has received a public warning letter from NYSE Regulation on behalf of NYSE American LLC...

Efficient Power Conversion Corp (EPC) of El Segundo, CA, USA — which makes enhancement-mode gallium nitride on silicon (eGaN) power field-effect transistors (FETs) and integrated circuits for power management applications — says that its EPC2361 100V eGaN FETs have been used in a high-performance buck-boost converter reference design from Analog Devices Inc (ADI)...

Sivers Semiconductors AB of Kista, Sweden (which supplies RF beam-former ICs and lasers for AI data-center, SATCOM, defense and telecom applications) says that its strategic LiDAR customer has initiated production orders for its automotive and industrial sensing customers...

A programmable WiFi camera costing just a few euros that, paired with a P.I.R. motion sensor, becomes a security tool able to communicate with our smartphones through Telegram.

ESP32-Cam: the cheap camera for video surveillance

The topic of security and video surveillance is increasingly discussed and current, and it is a field of great importance, subject to continuous development thanks to the technological evolution we are witnessing, especially in recent years. It is precisely the refinement and development of technology that have made it possible to apply video surveillance in many sectors and contexts, down to the simplest everyday situations. In fact, today more than ever, technology aims to reduce the cost and size of the installation, so as to broaden its modes as well as its fields of use; not to mention the fact that solutions based on local networks and the Internet have been born, which have greatly extended the application possibilities.

What can we expect, then, from the new systems? Certainly a lot, since the new solutions let us use greater, simplified and extremely innovative functionality. An example of all this could be a cheap camera, lightweight, small in size, already equipped with WiFi and Bluetooth; this is exactly what AI-Thinker offers with the ESP32-Cam which, with its 40.5x27x4.5 dimensions, could be considered the “Swiss army knife” for every maker ( Fig. 1 ).

Technical characteristics of the module

The latter, following the now well-known and indispensable board based on the ESP8266, features an ESP32 module equipped with a connector to host a separate camera module and a slot for an SD card up to a maximum of 4GB. In detail, we can note that the ESP32-Cam module is based on the ESP32, a programmable microcontroller with integrated WiFi and Bluetooth and an additional external RAM of no less than 4MB.

Not only that, the new camera connector can host an OV2640 or OV7670 module: the first comes with the module itself and has a resolution of 2 Megapixels.

On the board there is also a high-brightness LED, which can be used as a flash or as an illuminator for the scene to be captured. Naturally, the many GPIOs present on the board let us mount an external one if lighting is poor. For small applications this chip proves very robust and with great processing power, being based on two 32-bit processing cores running with a clock at 120 MHz. This last characteristic allows it to have a fairly high frame rate, obviously depending on the format and dimensions: indicatively you can reach a throughput of up to 8 JPEGs in SVGA (800×600) per second.

An access control system

Let us now see how to exploit every peculiarity of this interesting device. In particular its dimensions, so small that you can build an access control system even inside a single room or a garage. All this by capturing frames for every entry.

But from a practical point of view you might ask yourself: what to do with these photos? When to check them? Examining the different levels of difficulty, in first place we find the need to capture a correct and precise image.

To do this we will build a peripheral able to share and report these accesses in real time directly on our smartphones or by populating our own private cloud.

Operating principle

The ESP32-Cam will take care of detecting, through the PIR motion sensor ( Fig. 3 ), the entry into the surveilled space and the movement within it.

When the latter is crossed, the PIR detects the heat radiation from the moving body and is triggered; its output, which at rest is at logic zero, will then go to a high level, activating the camera, which will store the bytes in a pointer that was previously NULL. If this structure is not populated correctly, the emergency procedure will step in and reset our device.

Notifying the intrusion: HTTP or MQTT

It only remains to understand how to notify the intrusion to the outside world and what timing to use to be able to shoot again. As for the notification we have several solutions we can exploit: for example the http/https APIs or the MQTT protocol. Both solutions open up different scenarios and can even coexist. Let us proceed in order and examine them case by case.

• 1) http/https APIs: these are the classic http calls (or in the secure https version) POST or GET to a server that will take charge of the request in question; the services and APIs of Telegram or third-party services for interacting with our smartphones are of this type. This solution involves a first connect phase towards the remote server; if this succeeds, the client, in our case the device, starts sending the bytes of the photo.
• 2) MQTT protocol: this recently published protocol is the basis of many home automation objects we have at home and involves sending simple text messages, often encapsulated in JSON, which inform other smart devices.

In our example we will use the http APIs to communicate with the Telegram server to which we will send our photo. Finally we will set a final delay so we can capture a new photo.

This can also be zero if you want to obtain a high-intensity sequence of photos. This delay, as will be seen in the code, will be very important to avoid taking photos in bursts. Naturally, if instead you are interested in shooting in rapid sequence you can omit this delay.

Using a button instead of the PIR

If a PIR motion sensor (passive infrared radar) is not available, it can be replaced with a button ( Fig. 4 ) and thus provide the trigger manually; perhaps the button contact can be replaced with a mat contact, to shoot whenever a person sets foot in a certain area, such as in front of a door.

As for the passive infrared sensor, the circuit expects that at “rest” the signal provided is at a low logic level and that it goes high in case of detection.

By connecting, instead, the button of Fig. 4 directly to the line reserved for the PIR, the behaviour will be inverted if the same is closed towards ground.

Connections

Let us now move on to putting the module into operation. Naturally, first we will create the connection for programming the firmware of the ESP32-Cam through Arduino. This step can also be done through an FTDI adapter, making the wiring, at least during the programming phase, extremely easier.

As a first step let us identify the TX and RX pins on our Esp32-Cam, called respectively U0TXD and U0RXD, and we will connect them with the TX and RX pins of the Arduino. In the camera module these pins also represent the GPIO1 and GPIO3 pins.

We will connect the GND and GPIO0 pins of the latter to ground, together with the GND and RESET pins of the Arduino, and the two 5V pins to each other. For the connection we can help ourselves with a breadboard like the one in the photo. Summarising in table form what was expressed previously, we have the situation proposed in Table 1 .

The wiring diagram of the programming circuit is proposed in Fig. 5 .

Let us now add the connection with the PIR sensor: besides the power supply, that is the 3V3 and GND contacts to be brought to the respective VCC and GND of the sensor, we will bring the cable for the actuation signal, starting from pin GPIO13 ( Fig. 6 ), making the following connections:

• Esp32->PIR
• 3V3->VCC
• GND->GND
• GPIO13->OUT

Once the ESP32-Cam module is programmed, it is necessary to remove the connection between GPIO0 and GND. The whole circuit is powered through the Arduino Uno, that is by supplying the latter with a voltage between 8 and 12V using a stabilised power supply with a DC plug suitable for the Arduino one; the current required is in the order of 500 milliamperes.

Firmware

Before proceeding with programming we should set up ArduinoIDE, that is our development environment, so we can write correctly to the module. Let us therefore open the Arduino IDE and go to File->Preferences and add in the Additional Boards Manager URLs this link https://dl.espressif.com/dl/package_esp32_index.json and click OK ( Fig. 7 ).

If you already have one or more URLs, use a comma to concatenate them, exactly as in the example. Now let’s download the board manager correctly: go to Tools -> Board: XXXX -> Boards Manager…, search for “esp32” and install the only result of the search (Fig. 8).

On exiting, select Tools -> Board: XXXX again and you will notice a new entry, ESP32 Arduino, which contains several other choices. Select ESP32 Wrover Module, after which a new line will appear in that same menu: Partition scheme, in which we will choose Huge APP (Fig. 9).

Now we have everything we need to upload the firmware to the device, so let’s connect the USB and select the correct port (that is, the one the system tells us the board is connected to) and then click Upload.

At this point we have completed the installation and configuration of the IDE, so we can upload the firmware, which we describe below.

The sketch

Let’s now look at the code for the project firmware, which for the sake of brevity we will not reproduce in full here, bearing in mind that it is available for download together with the files for this issue.

We present a few excerpts of the firmware, showing in Listing 1 the most substantial part, which is the routine that handles sending the image captured by the on-board camera via Telegram.

Listing 1

String alerts2Telegram(String token, String chat_id) { const char* myDomain = “api.telegram.org”; String getAll=””, getBody = “”; camera_fb_t * fb = NULL; fb = esp_camera_fb_get(); if(!fb) { Serial.println(“Camera capture failed”); delay(1000); ESP.restart(); return “Camera capture failed”; } WiFiClientSecure client_tcp; if (client_tcp.connect(myDomain, 443)) { Serial.println(“Connected to ” + String(myDomain)); String head = “–India\r\nContent-Disposition: form-data; name=\”chat_id\”; \r\n\r\n” + chat_id + “\r\n–India\r\nContent-Disposition: form-data; name=\”photo\”; filename=\”esp32-cam.jpg\”\r\nContent-Type: image/jpeg\r\n\r\n”; String tail = “\r\n–India–\r\n”; uint16_t imageLen = fb->len; uint16_t extraLen = head.length() + tail.length(); uint16_t totalLen = imageLen + extraLen; client_tcp.println(“POST /bot”+token+”/sendPhoto HTTP/1.1”); client_tcp.println(“Host: ” + String(myDomain)); client_tcp.println(“Content-Length: ” + String(totalLen)); client_tcp.println(“Content-Type: multipart/form-data; boundary=India”); client_tcp.println(); client_tcp.print(head); uint8_t *fbBuf = fb->buf; size_t fbLen = fb->len; for (size_t n=0;n<fbLen;n=n+1024) { if (n+1024<fbLen) { client_tcp.write(fbBuf, 1024); fbBuf += 1024; } else if (fbLen%1024>0) { size_t remainder = fbLen%1024; client_tcp.write(fbBuf, remainder); } } client_tcp.print(tail); esp_camera_fb_return(fb); int waitTime = 10000; // timeout 10 seconds long startTime = millis(); boolean state = false; while ((startTime + waitTime) > millis()) { Serial.print(“.”); delay(100); while (client_tcp.available()) { char c = client_tcp.read(); if (c == ‘\n’) { if (getAll.length()==0) state=true; getAll = “”; } else if (c != ‘\r’) getAll += String(c); if (state==true) getBody += String(c); startTime = millis(); } if (getBody.length()>0) break; } client_tcp.stop(); Serial.println(getBody); } else { getBody = “Connection to telegram failed.”; Serial.println(“Connection to telegram failed.”); } return getBody; }

Below we show the first portion of code, which defines the pins used to drive the camera: note that all the pins are connected “internally” on the board except for pin 13, which is external and to which the PIR motion sensor is connected. This definition is handled by these lines of code:

#define PWDN_GPIO_NUM 32 #define RESET_GPIO_NUM -1 #define XCLK_GPIO_NUM 0 #define SIOD_GPIO_NUM 26 #define SIOC_GPIO_NUM 27 #define Y9_GPIO_NUM 35 #define Y8_GPIO_NUM 34 #define Y7_GPIO_NUM 39 #define Y6_GPIO_NUM 36 #define Y5_GPIO_NUM 21 #define Y4_GPIO_NUM 19 #define Y3_GPIO_NUM 18 #define Y2_GPIO_NUM 5 #define VSYNC_GPIO_NUM 25 #define HREF_GPIO_NUM 23 #define PCLK_GPIO_NUM 22 int gpioPIR = 13; //PIR Motion Sensor

In the loop cycle the state of the PIR is checked; when the sensor output goes high (1) the routine “alerts2Telegram” is called:

void loop() { pinMode(gpioPIR, INPUT_PULLUP); int v = digitalRead(gpioPIR); if (v==1){ alerts2Telegram(token, chat_id); delay(5000); } delay(500); }

As you can see from the comments in the code, the first four constants must be changed respectively to your own WiFi credentials and two other parameters provided instead by Telegram.

Configuring the Telegram bot with BotFather

So let’s retrieve those last two values. Open the Telegram app on your smartphone and tap the magnifying glass to search for BotFather (Fig. 10).

Through this chat we can create our first bot, that is, a non-human user capable of performing actions of varying complexity; if you prefer, a robot… So let’s open the BotFather chat, type /newbot and follow the on-screen instructions.

At the end of the procedure we will be issued the token to substitute in our third constant, namely token (Fig. 11).

Let’s now get the last constant, so tap the magnifying glass again and search for the bot we just created: once found, just open it and press Start. It would also be a good idea to write something in this chat and send it. In our case we just write “Hello” and send the message.

Now open a browser session and paste the following link:

https://api.telegram.org/bot<BOTToken>/getUpdates where BOTToken is exactly the token extracted in the previous step. In response to this action, the browser will show a json, that is, a data structure formatted in a certain way, similar to the following:

{ “ok”:true, “result”:[ { “update_id”:YYYYYY, “message”:{ “message_id”:18, “from”:{ “id”:XXXXXXXX, “is_bot”:false, “first_name”:”YOUR FULL TELEGRAM NAME”, “username”:”YOUR TELEGRAM USERNAME”, “language_code”:”it” }, “chat”:{ “id”: XXXXXXXX, “first_name”:”YOUR FULL TELEGRAM NAME”, “username”:”YOUR TELEGRAM USERNAME”, “type”:”private” }, “date”:1600324371, “text”:”Hello” } } ] }

This structure is the interactions with the bot by users. We are interested in the id of the chat where we just sent “Hello”, that is, the one in bold in the example. This ID is exactly the last piece we needed to substitute for chat_id in the code.

Alternative alarm control

Now that we have managed to get a basic solution for access control, it would be appropriate to have remote control of it, not just a mere visualization. It would be useful to be able to operate this control without needing to be physically there to turn the device on and off.

To do this, having a web server is essential. It can be a space rented through services such as Aruba, Register or other similar services, or simply a Raspberry Pi connected to the network with a LAMP base, that is, a solution featuring a Unix/Linux base, an http server engine and a PHP language for writing the scripts.

Actually LAMP is the acronym of its components and would include the Linux operating system, Apache (http server engine), MySql (database engine) and finally the PHP/Python language. In our case the database is superfluous but it could be a more correct and advanced solution.

Inside our server we will put three files: lock.php, lock.txt and finally read.php. The first is the “writer” service, that is, the one that will set the state of our device. Here is the code:

<?php echo getcwd(); $myfile = fopen(“lock.txt”, “w”) or die(“Unable to open file!”); $txt = $_GET[‘status’]; fwrite($myfile, $txt); fclose($myfile); ?>

The second is the file we will use as a database, which contains the state of our device: it is simply a text file in which to put the state “on” or “off”. By default we will set it to “on”.

And finally we have the “reader” service, that is, the one that, inserted into the code of our ESP32, will read the remote state and trigger the notifications or not. Below is the code for the latter:

<?php $myfile = fopen(“lock.txt”, “r”) or die(“Unable to open file!”); echo fread($myfile,filesize(“lock.txt”)); fclose($myfile); ?>

Updating the sketch for remote control

So one might wonder how the code of our ESP32Cam will change; well, very little, because in fact we will simply have to add a new check in addition to the existing one for the Telegram connection.

Here, in fact, we need to insert a call to the reading service so that we can work out which state we are in and whether the photo that has just been taken is of interest to us or not.

Let’s see how to modify it: in the upper part of the code, where the various includes are, we need to add this line:

#include <HTTPClient.h>

Which gives us:

#include <WiFi.h> #include <WiFiClientSecure.h> #include <HTTPClient.h> #include “soc/soc.h” #include “soc/rtc_cntl_reg.h” #include “esp_camera.h”

Now let’s add the check alongside the Telegram connection. Inside the alerts2Telegram function we will in fact add this instruction:

&& control()

Which gives us:

String alerts2Telegram(String token, String chat_id) { const char* myDomain = “api.telegram.org”; String getAll=””, getBody = “”; camera_fb_t * fb = NULL; fb = esp_camera_fb_get(); if(!fb) { Serial.println(“Camera capture failed”); delay(1000); ESP.restart(); return “Camera capture failed”; } WiFiClientSecure client_tcp; if (client_tcp.connect(myDomain, 443) && control()) { Serial.println(“Connected to “+String(myDomain));

Finally, let’s create the control function mentioned in the previous step and add it at the end of the whole code:

boolean control(){ HTTPClient http; boolean ret = false; String serverPath = “http://SERVER_ADDRESS/read.php”; http.begin(serverPath.c_str()); int httpResponseCode = http.GET(); if (httpResponseCode>0) { Serial.print(“HTTP Response code: “); Serial.println(httpResponseCode); String payload = http.getString(); Serial.println(payload); if(payload==”on”){ ret = true; } } else { Serial.print(“Error code: “); Serial.println(httpResponseCode); } http.end(); return ret; }

As you can see, with just a few extra lines we have made the control of the device remote.

Now all we have to do is call the following URL from an ordinary browser:

http:// SERVER_ADDRESS /lock.php?status=on

to activate it, while to deactivate it we change the status value from on to off.

Conclusions

Well, let’s end the description of this project dedicated to Telegram-assisted video surveillance here; what we have given you are development ideas that can be customised to your needs, starting from the firmware and the basic hardware, which as you have seen is very simple, being reduced practically to the ESP32-Cam module and a presence sensor.

Related products

• D203S motion sensor module
• ESP32-CAM Development Board: ESP32 with camera

The post ESP32-CAM: video surveillance with a PIR sensor on Telegram appeared first on Open Electronics.

In the huge number of industrial applications built on the latest technologies, nickel-metal hydride (NiMH) batteries remain a reliable solution. Their spread depends not only on performance but also on characteristics that are becoming more and more important. Designers, manufacturers and distributors look at requirements such as safety, stability and resistance to environmental conditions, but also at how simple the battery is to manage along the global supply chain.

It is precisely on this combination of key factors that the experience of Cebon Group comes into play, both for the industrial sector and for the consumer side. Both markets share a common denominator: the need for a tangible answer to the concrete demands of contemporary industry. For this reason, Cebon Industrial and GP Batteries work constantly not only to increase battery capacity or life, but to develop “lean” solutions. Innovation that directly affects what happens inside the battery during operation also involves other elements, such as environmental impact, safety in handling and the ability to move the product with far greater efficiency.

The safest, most stable chemistry

One of the distinctive elements of the new GP NiMH batteries is the use of a water-based electrolyte. This feature helps reduce the environmental impact of the solution and, at the same time, strengthens the stability of the battery compared with traditional technologies.

NiMH chemistry is intrinsically more “tolerant” of use and abuse and has no thermal runaway mechanism, that is, the uncontrolled propagation of rising temperature that can affect other chemistries. This does not mean, however, that a battery can be handled without precautions: design, assembly, protection and operating conditions must still meet many criteria. Even so, having greater chemical stability translates into a significant advantage in industrial applications, where reliability and safety must be guaranteed even in environments considered difficult.

Next-generation NiMH batteries can operate over a particularly wide temperature range, roughly from -35 °C up to +85 °C. This makes them suitable for all those devices and systems meant to work in harsh environments, where thermal swings, intense cold or high temperatures can put components to the test.

On top of the thermal requirements comes an operating life of 500-1,000 full cycles, with performance that stays stable and predictable. For OEMs and designers, predictability is an essential value, because it allows them to develop more reliable products, plan maintenance better and reduce the risk of operational interruptions.

Environmental impact as a design standard

In the mainstream, the topic of battery sustainability is mainly associated with the final stage of their life cycle, that is, collection, recycling and the extraction of materials that can still be used. Today, however, environmental impact is also assessed across the entire life cycle, which includes factors such as the choice of materials, production models, packaging and distribution.

From this point of view, the use of a water-based electrolyte signals, on the part of GP Batteries, a research approach that considers not only performance but also the nature of the materials and the safety of the solution. A more stable and longer-lasting battery helps reduce how often it has to be replaced, with positive effects on the use of resources, on spare-part management and on the waste generated over the life of the product.

Sustainability, obviously, cannot be attributed to a single element without considering the overall context: battery design, production processes, the actual life of the component, as well as the type of application and the end-of-life recovery methods. It is significant, though, that R&D on industrial batteries is increasingly moving towards solutions able to merge performance and environmental responsibility.

The supply chain as a strength

A battery is indeed a technical component, but it is also a product that is bought, packed, transported, stored and delivered. Cebon Industrial deals every day with globalised trade, characterised by international supply chains and factors such as frequent shipments and increasingly fragmented delivery times, putting at the centre logistics aspects that directly affect the competitiveness of a product.

In recent years, supply chains have had to endure geopolitical crises, diversions of maritime routes, rising transport costs, shortages of raw materials and new regulations. In this context, reducing constraints along the logistics chain is no small thing, because it means gaining flexibility and increasing the ability to react to the unexpected.

If a battery is designed to be managed in a less complex way, when regulatory conditions allow it, it simplifies the handling stages. How? Through less paperwork, fewer restrictions due to the type of carrier and less time needed to prepare the shipment, since there will be fewer risks of delay caused by additional procedures. As a result, the advantage does not only affect transport cost, but the whole predictability of the logistics process.

With the just-in-time model calling the shots, even a small delay propagates along the entire chain: a postponed delivery affects assembly schedules and the distribution of the finished product (thus also increasing management costs). A battery that is “simpler” to ship, on the other hand, helps keep more shipping options open, whether by sea, air or road, depending on the urgency and the characteristics of the orders.

Transport regulations

For private consumers, at the time of purchase, many batteries cannot be delivered via locker or hub but only to a direct destination. This is because the rules for handling batteries do not provide for final storage at pick-up points, precisely because of the possible instability of the product in relation to environmental conditions.

As for the actual shipment of the material (for example from manufacturer to distributor), the packaging of batteries refers to various regulations depending on the type of shipment, whether by land, sea or air. UN 3496 identifies nickel-metal hydride (Ni-MH) batteries, which are classified as Class 9 dangerous goods. This regulation applies exclusively to international maritime transport, so, as mentioned, the battery is not subject to the same constraints in every mode of transport. For example, in air transport NiMH batteries can be considered not subject to the restrictions laid down for dangerous goods, provided they are correctly prepared (for instance to prevent short circuits and unintentional activation). In this case the reference regulation is Special Provision A199 – IATA.

Regulations also exist for road transport, as for example for lithium batteries (UN 3480 – UN 3481, with Class 9 classification, the same as for Ni-MH), although the treatment logically varies from type to type, with application depending on the packaging, the quantity, the shipping configuration, and so on.

A more stable NiMH battery is therefore not a way to “bypass” the rules; rather, it makes operating procedures easier within a regulatory framework that is potentially simpler than that of other chemistries, without ever departing from safety standards. The correct classification of the product must always be verified against the technical documentation, the product safety data sheet, and with the carrier and the person responsible for the shipment.

Innovation beyond the battery

The evolution of industrial batteries shows that it is no longer enough to focus only on increasing performance, because the product must be safe during use, stable in difficult environmental conditions, designed with attention to the impact of its materials and simpler to manage in logistics processes.

GP Batteries’ research into NiMH chemistry has touched all these aspects: from composition to life, from thermal resistance to safety, right through to simplifying handling. This approach is particularly relevant for mission-critical applications, where the battery must guarantee operational continuity but also slot into supply and distribution flows without friction.

In a context where global supply chains continue to be put under severe strain, flexibility and less dependence on unforeseen events help make the system more resilient.

The post Next-Generation NiMH Batteries: Performance, Safety and a Lean Supply Chain appeared first on Open Electronics.

DigiKey, a global leader in the distribution of electronic components and automation products, will present new innovative products and successful projects at its booth N.01 during Maker Faire Rome, from 23 to 25 October 2026. DigiKey is a Gold partner of the event, which brings together hundreds of makers from around the world to share their projects with the public.

“DigiKey’s presence at Maker Faire Rome 2026 reflects our commitment to providing makers, students, teachers and professional engineers with accessible technologies, technical training and hands-on innovation,” said Kevin Walseth, Senior Manager, Technical Marketing for DigiKey. “The event lets us connect directly with attendees, showcase supplier technologies in real applications and strengthen relationships within the maker community.”

Demos and more at the DigiKey booth

DigiKey experts will present new and successful products and projects, such as:

• Sparkfun’s XRP, an experiential robotics platform designed to make learning robotics accessible to everyone
• An XRP robot controlled through a home automation assistant
• AgXRP, a modular kit for agricultural automation designed to combine robotics, sensors and real farming technologies
• Adafruit’s NeoTrellis, a PCB with an elastomer button kit and full-color NeoPixel support
• Arduino’s UNO Q, a microcontroller and single-board computer development board, and VENTUNO Q, an edge AI computer
• Synaptics’ Coralboard, an edge AI board based on Synaptics’ Astra compute technology and Google’s Coral NPU
• DFRobot’s LattePanda and UNIHIKER single-board computers, and HUSKYLENS 2, an AI vision sensor
• A virtual sand demo using an LED matrix and Adafruit’s Matrix Portal
• A self-balancing robot from M5Stack
• Kitronik will have its Mai-Z robots on display, along with a soccer pitch where attendees can face off playing robot soccer

Visitors who stop by the DigiKey booth will also have the chance to take home a DigiKey bag and other DigiKey-branded gadgets.

Now in its fourteenth edition, Maker Faire Rome is an event that facilitates and tells the story of technological innovation in a simple and accessible way, connecting companies, universities, people and ideas. Over the past 13 years, the event has attracted almost 900,000 visitors and has showcased more than 8,000 projects.

For more information about the DigiKey maker community, visit the Maker.io page on the DigiKey website.

The post DigiKey at Maker Faire Rome 2026: robotics, edge AI and makers appeared first on Open Electronics.

Літній відпочинок з Профкомом КПІ 2026 Інформація КП вт, 10/20/2026 - 10:00

Інна Трус. Як зберегти воду, обладнання і довкілля Інформація КП вт, 10/20/2026 - 00:00

У кампусі КПІ — зелене поповнення KPI4U-2 пн, 10/19/2026 - 22:48

I’ve been splice soldering for years but this is my very first attempt at PCB soldering. Everything works as it should so that’s good. submitted by /u/jcass86 [link] [comments]

Marktech Optoelectronics Inc of Latham, NY, USA and its device manufacturing partner Optrans have expanded their portfolio of four-channel indium gallium arsenide (InGaAs) PIN photodiodes for optical systems requiring both infrared detection and positional information. Combining conventional 1.7µm-cut-off and extended 2.6µm-cut-off InGaAs technologies, the portfolio gives optical system designers more options for laser alignment, beam tracking, optical feedback, and analytical instrumentation...

Відзнака на конгресі Optica Laser Congress and Exhibition 2026 KPI4U-2 пн, 10/19/2026 - 17:39

Мистецтво бути тут і зараз: майстер-клас із приготування традиційного японського чаю KPI4U-2 пн, 10/19/2026 - 17:13

Deposition equipment maker Aixtron SE of Herzogenrath, near Aachen, Germany says that its preliminary results for third-quarter 2026 show that order intake, operating result (EBIT) and EBIT margin significantly exceed current market expectations...

Mouser Electronics, an authorised global distributor of electronic components and industrial automation products, offers a broad selection of solutions from Bourns, a leading manufacturer of automotive sensors, circuit protection solutions, and magnetic and resistive products for markets such as industrial, automotive, telecommunications, computing and consumer electronics. Mouser currently lists more than 21,000 Bourns components, with over 50,000 parts available to order. Over the past 15 years Mouser has received eight Global Distributor of the Year awards from Bourns, along with two European Distributor of the Year awards.

MAG-3002584 high-power inductor

Available from Mouser, the MAG-3002584 high-power inductor offers an inductance of 87 µH for high-frequency power factor correction (PFC) applications and inverters in high-voltage three-phase power systems. The inductor features low DC resistance (DCR) and a saturation current of 42 A, enabling high-efficiency, high-power-density operation for applications such as data centers, servers, on-board chargers, string inverters and fast charging stations.

Bourns modular high-power contacts

Bourns modular high-power contacts deliver current ratings up to 8 A per contact, making them ideal for applications that require greater power delivery. Available in the 75AB, 76AA and 78AD series, these contacts feature compact footprints, self-centering capability, pick-and-place compatibility and a minimum life of 50,000 cycles. Typical applications include industrial automation, medical equipment, portable communication devices, eMobility systems and portable consumer electronics.

HCTSM110304HAL transformer

The HCTSM110304HAL transformer is designed to meet the stringent isolation requirements of power conversion systems. The transformer’s high clearance and creepage design helps designers develop reliable, high-efficiency power solutions while supporting the strict safety requirements of modern industrial and power electronics applications.

CSS4C-1216 current sense resistors

CSS4C-1216 current sense resistors provide accurate current measurements in a compact package optimised for high-power designs. Featuring low resistance values and robust thermal performance, these resistors help improve energy efficiency and measurement accuracy in applications such as power supplies, battery management systems, motor drives and industrial controls.

A broad selection of Bourns products

These are just a few examples of the Bourns products available from Mouser. To learn more about the full selection, visit the Mouser website. For more Mouser news and the latest product news, visit the Mouser website.

As an authorised global distributor, Mouser offers the widest selection of the newest semiconductors, electronic components and industrial automation products. Mouser customers can count on 100% genuine, certified products, fully traceable from each of its manufacturer partners. To accelerate customer designs, the Mouser website hosts an extensive library of technical resources, including a Technical Resource Center, along with product datasheets, supplier-specific reference designs, application notes, technical design information, engineering tools and other useful information.

The post Mouser Distributes Bourns Power Solutions for Power Electronics appeared first on Open Electronics.

Hey ya! Soooo i made this digicam using an esp32cam, ov5640 5mp cam module, and it has a 1.3" tft display that shows live view. the cam is fully open sourced, you can find it on my github. (hey be sure to leave a star if you can!) so y'all can build it yourselves, although you will have to do some soldering. github: https://github.com/Bogey1309/PocketCam-Classique i havent put it in a case yet- i do have the cad for it however, if any of you want to make it, you can put it in the case too. unfortunately it does not take videos. but the photos look really y2k in my opinion. (see the last 5th and 6th images) also; i do not earn anything from this- just clarifying. its fully open sourced and i wanted to share this with y'all. submitted by /u/DaSnowGuy1309 [link] [comments]

​AVL and VisIC Technologies are partnering companies that share the vision of upgrading and commercialising high efficiency gallium nitride (GaN) traction inverters. The partnership recently demonstrated advanced research related to traction inverters by integrating gallium nitride (GaN)-based power modules into an electric vehicle reflecting a move that advances high-efficiency power electronics for electric vehicles (EVs).

The test was conducted at AVL’s facilities in Germany where VisIC’s D³GaN technology was integrated into an AVL vehicle demonstrator platform. The development has moved from laboratory testing into a complete vehicle environment.

GaN Technology Targets Lower Inverter Losses

The conducted test trial assembles a GaN technology-based inverter with a high-speed electric axle, advanced power electronics and vehicle control systems. The traction inverter transforms the DC power from an EV’s battery into AC for use in the electric motor. Its efficiency determines the amount of energy taken from the battery that the reaches the motor. This newly announced technology significantly reduces switching and conduction losses, thereby lowering overall inverter losses.

The project also involves NXP Semiconductors for dri​ver electronics, system integration, and performance support. NXP supplies specialized driver ICs for proper control of D³GaN technology at high frequencies. Reducing the inverter’s power losses improves thermal management and supports a more compact powertrain design.

Potential Benefits for Future EVs

Integrating an inverter into a vehicle allows the partnership to evaluate performance metrics under a complete development environment including the electric drivetrain, and their interaction with the motor and vehicle control systems. The companies reported that GaN-technology-based inverter achieved 99.67% efficiency at a switching frequency of 10 kHz and over 99.8% at 5 kHz.

The post AVL and VisIC Advance GaN-Based EV Inverters to Improve EV Powertrain Efficiency appeared first on ELE Times.

A dissimilar laser technology versus the single-mode sibling trades off operating range for cost, at least theoretically. But it’s still faster than the LED-based predecessor.

Last month’s premiere small form-factor pluggable (SFP) module teardown of a single-mode optical transceiver showcased either a Fabry-Perot– or distributed-feedback-(DFB) based semiconductor diode laser operating at 1310 nm.

I’m not sufficiently versed in the technology to visually differentiate between the two—knowledgeable reader insights are welcomed—but I know enough to know that today’s 850 nm multimode optical module uses neither of them.

Requoting my previously published tutorial on SFPs and their siblings:

SFP modules most commonly run at the following wavelengths (all are center frequencies):

• 850 nm (“multimode”)
• 1300 nm (“multimode”)/1310 nm (“single-mode”)
• 1550 nm (“single-mode”)

The distinction between multimode and single-mode fiber optics is important to comprehend and keep in mind, as the two technologies are not interchangeable (although some modules will work with both associated cable material types).

Multimode was historically much less expensive to implement, at the trade-off of lower usable transmission distance. It features a comparatively larger cable core (50 to 62.5 microns) that lets multiple light signals travel down different paths at the same time, and it usually uses lower-cost LEDs or vertical-cavity surface-emitting lasers (VCSELs).

Single-mode features a comparatively tiny core (about 8 to 10 microns), which allows only a single ray of light to pass straight through without bouncing off the edges, and it uses focused lasers as a light source. Its historical cost disadvantage versus “multimode” has more recently decreased, due in part to the availability of non-proprietary, widely compatible modules. And as noted earlier, it generally specifies much longer usable transmission distances.

Different emitter, same dim red glow

The “uses lower-cost LEDs or vertical-cavity surface-emitting lasers (VCSELs)” excerpt from the above is strictly accurate, although in the modern era it’s half-obsolete. Near-infrared LEDs were indeed leveraged with early sub-Gbit 850 nm SFP modules.

However, as a helpful reference I came across notes, “their maximum rate of about 622 Mb/s meant that they could not support 1 Gb/s or higher transmission.” Therefore, I expect to find an 850 nm VCSEL transmitter inside today’s teardown victim, along with a spectrally tuned variant of the earlier 1310-nm receiver.

I first visually confirmed the 850 nm spectrum association by plugging the module into a SFP cage-inclusive multi-port switch in a dark room and (quickly!) discerning the light coming out of the module’s transmit connector.

You might ask why it’s perceptible (and smartphone camera-capturable) at all, given that the human visual spectrum range extends only to around a 750 nm wavelength (corresponding to a ~400 THz frequency). To answer that question, I’ll refer you to another excerpt from my earlier requote: “all are center frequencies”. Even though 850 nm (~3.5 THz) itself may be beyond the range of human visual perception, the transmitter’s bell curve(-ish) output profile seemingly still has a modicum of signal strength at the visual wavelength end of its overall distribution.

Today’s patient, another SFP module (versus higher-speed SFP+), was bundled with a media converter I’ll keep as a spare for potential future lightning-strike galvanic isolation purposes.

Initial perspectives

I’ll as-usual start with some overview shots, as-usual accompanied by a 0.75″ (19.1 mm) diameter U.S. penny for size comparison purposes.

Top.

This time accompanied by a close-up of the embossed transmit and receive direction arrows also mentioned in last month’s teardown (and more generally found in all optical modules I’ve seen).

Right side (as before, with “right” referencing its orientation when inserted in a network switch or other gear’s SFP port).

Bottom (as was the case last time, note the retractable retaining pin).

And left side.

The SFP connector end, from both right-side-up and upside-down module perspectives.

Same goes for the optical fiber connector end, first with the dust cap still in place.

And now post-dust cap removal.

Dissection time

As before, bending back on the side tab you might have noticed earlier (if not, please go back and see), holding the outer and inner enclosure pieces together, is our pathway to the insides. There are two tabs, one on each side, although only the left side one was initially depressed.

As usual, the multiple hinge and associated pieces, conceptually similar to those we saw last month, fell out as the enclosure halves separated.

And there we are.

One screw is all that keeps the PCB attached to the metal assembly surrounding it.

Free at last.

Here’s the bottom of the PCB.

The optical receiver module is on top at the left edge, visually similar to the one found in last month’s single-mode SFP module albeit tuned for a different incoming signal wavelength, with the 850 nm VCSEL-based transmitter below it and conversely looking very different than its 1310 nm laser predecessor shown in the following comparison photo.

Now for the PCB topside of today’s patient.

The ordering is (obviously) reversed in this case; transmitter at top left and receiver below it. And what of the two ICs on this side? Let’s take a closer look.

The larger of the two has the following four-line topside mark; see also my notes in brackets.

1138142
780KF VJ [The second character might instead be the letter O]
PHL [There’s another three-digit code to the right, but it’s obscured by the yellow paint. In a photo I found online, it’s “141” but seemingly not in this case; I think that the first character is “B”]
e4 [This seems to be a company logo, given that it’s surrounded by a circle. Next to it is, judging from other photos I’ve seen, the two-character code “ES”, albeit again yellow paint-obscured]

A Google search on the phrase “1138142 IC” suggests that STMicroelectronics is the supplier but doesn’t reveal anything about the chip’s function. Reader insights are welcomed!

The smaller IC is marked as follows; again, note my comments in brackets.

532R
B809 [As before, the third character here may instead be the letter “O”]

As before with the single-mode module, I’m assuming this is an EEPROM storing data such as the module’s serial number, vendor name, compatibility codes, and calibration data.

In closing, the SFP interface and LC (Lucent Connector) ends of the PCB are visually identical to the ones found in last month’s module, so I’ve decided to spare you the photo redundancy. See last month’s teardown images for representations of how these ones also look. And as always, please share your thoughts on what I’ve found today in the comments!

—Brian Dipert is the associate editor, as well as a contributing editor, at EDN.

Related Content

• SFP: The single-mode module autopsy
• SFP: Add-in module delivers diminutive performance and flexibility
• TP-Link MC220L: Media conversion keeps the network well
• The whole-house LAN: Achilles-heel alternatives, tradeoffs, and plans
• Design considerations in high-speed fiber networks

The post SFP: The multimode module autopsy appeared first on EDN.