Feed aggregator

A group of children aged 7 to 13 is building a tactile zoo with 3D-printed robotic animals. The creatures, more than 20 in total, are equipped with LEDs, motors, buttons, and gears. At Maker Faire Bay Area, the group will also display their printing errors and failed prototypes. The goal is to show the iteration process that leads from an idea to a working object.

The project turns 3D printing into an educational and interactive activity. Mistakes are not hidden but become an integral part of the exhibition. Visitors can thus understand that making errors is a normal step in the work, not a failure. The maker’s website details how the children faced technical difficulties and what solutions they found.

From choosing the animal to the first print

Each young maker chooses an animal, real, mythological, or completely invented. Then they decide what behavior the creature should have. Some design the animals from scratch, others start from existing 3D models and modify them, cutting or redesigning sections to make room for the electronics. Once the body is ready, they add a function such as an LED, a servo, a motor, a button, or a set of gears.

The group includes eight creatures, among them Em. To make Plate the Armadillo roll into a ball, 11 prints were needed. Each failed attempt taught something new: a joint too tight, a motor off-axis, a wall too thin. The children learned to observe the error and correct it in the next print.

An exhibition you can touch and open

The zoo is not a simple showcase. Visitors can press buttons, flip switches, and open the animals to see the wires, gears, and electronics inside. This choice makes the electronics transparent and understandable even to those who have never opened a device. Next to the finished animals, broken prints, melted parts, and earlier versions are displayed, so visitors can ask what went wrong and how it was fixed.

For those who want to recreate the project, the electronic part can be built with simple, modular components. For example, a servo motor with metal gears can move an animal’s legs, while a shield for controlling RC servos allows managing multiple movements with an Arduino board. For light effects, a WS2812 LED matrix offers endless color possibilities. Finally, a compact board like the Arduino Nano Matter can handle logic and connectivity in a small space.

Mistakes on display: the educational value of failure

The choice to display printing errors is the heart of the project. In a world that shows only perfect results, these children reveal the behind-the-scenes. The broken prints tell the real difficulties of 3D printing: material shrinkage, parts detaching from the bed, motors that don’t find space. Visitors to Maker Faire will be able to talk with the young makers and discover how each problem was tackled.

This approach also changes the way the children work. They learn that a failed prototype is not wasted time, but a step forward. Each error provides valuable information for the next version. The iteration process thus becomes a mental habit, useful not only in 3D printing but in every design activity.

Source: https://view.protectedpdf.com/portal/AMR/LogIn

Related products

• Servo shield

The post 3D-Printed Tactile Zoo: Young Makers Show Off Their Mistakes appeared first on Open Electronics.

Let’s emulate the TDG series remote controls using the GSM Shield. Second and final instalment.

We left off last month after presenting the design of the 2IN/2OUT remote control that emulates the behaviour of our TDG133 with revised hardware based on the GSM Shield described in issue 231 and on an Arduino Mega 2560 board. What makes this system special is its versatility and flexibility: compared with the original TDG133 – which has two optoisolated inputs at voltage level and the same number of relay outputs – it can handle up to 8 inputs (not optoisolated but still digital) and 8 outputs (assignable to modular relay boards) simply by customising its firmware and taking advantage of the large number of I/Os the Arduino Mega 2560 offers.

After explaining the hardware (shown in Fig. 1 without the shield that provides the interconnections and in Fig. 2 with that shield fitted…) and describing the architecture of the firmware and the sketch that govern its operation, we pick up where we left off, that is from the explanation of the factory default parameters.

Factory parameters

When the EEPROM is programmed with the dedicated sketch, or when the factory parameters are restored with the dedicated command string, the data needed for these two operations is taken both from compiler directives of the “#define” type and from the microcontroller’s Flash, where it is stored permanently.

This data is at the top of the file “GSM_TDG133.ino”, and in sequence it is:

• a block with the “#define” directives concerning the base addresses of the data held in EEPROM, identified by the comment “EEPROM FACTORY PARAMETERS ADDRESS”;
• a block with the “#define” directives concerning the parameters with their default values; the block is identified by the comment “EEPROM DEFAULT FACTORY PARAMETERS”; this section holds the following:
• generic flags;
• enabling of notifications by SMS and voice calls;
• inhibition time;
• observation time;
• maximum number of SMS in the event of an alarm;
• timeout for sending the SMS with the status of inputs and outputs;
• timeout for the gate-opening function.
• a block with the “const char” directives for defining in Flash the string parameters such as the SMS to be sent in the event of an alarm.

Let’s look in detail:

• the block of our GSM library containing the PIN, PUK etc. codes, identified by the comment “GSM Library PIN, PUK etc”; the user must enter the PIN code and PUK code of their own SIM, while all the other codes are not used in this application, but they must not be removed because they are part of our GSM module management library;
• the block with the strings used in the remote control, identified by the comment “SYSTEM PASSWORD; SMS TEXT FOR ALARM, START-UP etc”; here we find the system password (five numeric characters, default 12345″), the strings for input 1 alarm, the strings for input 2 alarm, the string for the SMS sent at sketch start-up; the string for the mains failure SMS; the string for the mains restored SMS.

Further on in the code we find all the command strings used in the sketch, and they are all stored in the microcontroller’s Flash. None of these strings must be modified by the user, otherwise the configuration commands will stop working. If new commands are added, the code to handle them must be added too.

Configuring the GSM library parameters

A few words on configuring some parameters of our GSM library and the related board: first of all, remember to set the jumpers on the GSM board so as to route correctly the TX and RX lines of the UART used for communication between the ATMEGA 2560 and the GSM module. The sketch uses software UART 1, with the option of spying on the serial communication between the GSM module and the Arduino Mega 2560 board. So jumpers JP1 to JP7 on the GSM board must be placed in position 1-2 as explained in the articles dedicated to the GSM board. In any case, the file “Io_GSM.h” has a table at the top showing how the jumpers must be configured.

That said, here are the settings to apply for the library to work correctly (the parameters to configure are all in the file “Io_GSM.h”):

• select the GSM module you intend to use from those supported (for this application we used the SIMCOM SIM800C) and comment out all the other directives for the GSM engines;
• select the Arduino board to pair it with, in this case the Arduino Mega 2560;
• select the hardware revision of the GSM board; select revision R.1.3, currently in production;
• select software mode for the UART 1 serial communication; if you wish, you can also select UART 1 in hardware, but remember to configure the jumpers correctly;
• comment out the directive that enables the earphone audio jack, “EARPHONES_JACK “;
• finally, the state machines to enable for our remote control:
• generic AT commands → “ENABLE_ANSWER_GENERIC_AT_CMD_STATE”
• security AT commands → “ENABLE_ANSWER_SECURITY_AT_CMD_STATE”
• phonebook AT commands → “ENABLE_ANSWER_PHONEBOOK_AT_CMD_STATE”
• SMS send and receive AT commands → “ENABLE_ANSWER_SMS_AT_CMD_STATE”
• voice call AT commands → “ENABLE_ANSWER_PHONIC_CALL_AT_CMD_STATE”;
• the debug code is disabled, so comment out the “DEBUG_MODE” directive.

Supported command strings

The sketch supports countless command strings inherited from the current TDG133. Almost all the command strings have been imported into this sketch, and new ones have been added specifically for this application. The strings can be sent by SMS or from the Serial Monitor.

For the main ones we will give a short description and an example of use. For convenience, all the command strings covered will be sent to the remote control through the Arduino IDE Serial Monitor. If the strings are sent by SMS, you should expect a possible reply from the remote control, again by SMS. When commands are sent by SMS, text strings will in any case be printed on the Serial Monitor to indicate whether or not the command was executed.

The system password

Let’s start with the command for setting the system password, which is the following:

PWDxxxxx;pwd

Passwords are numeric only and consist of five numbers. Alphanumeric characters are not allowed. The command code is “PWD” followed by “xxxxx”, which identifies the new password you want to set, for example “33225”. At the end you must enter the system password currently in use, preceded by the “;” character. So the command becomes:

PWD3325;12345

Once the command has been executed, what you see on the Serial Monitor in response is:

# Command received by user -> PWD33225;12345 # Command “PWD” processed successfully

This indicates that the command was received and executed correctly. The new system password is now “33225”.

Saving and deleting phonebook numbers

Let’s move on to the command for storing a phone number in the phonebook at the desired location:

NUMx+39nnnnnnnnnnn;text;pwd

The command code is “NUM” and it stores the phone number “nnnnnnnnnnn” in the memory location indicated by “x” (1 ≤ x ≤ 255). The “text” string is used to associate a text with the phone number entered. The text can be at most fourteen characters long, and it is mandatory. Finally comes the system password. A possible use of the command could be the following:

NUM2+393474131177;”Rossi”;33225

In this case, in location 2 of the SIM phonebook, the phone number “3474131177” with international prefix “+39” will be saved, paired with Mr “Rossi”. What you see on the Serial Monitor as the sketch’s response is:

# Command received by user -> NUM2+393474131177;ROSSI;33225 # Command “NUM” processed successfully

Now let’s look at the command for removing a phone number from the phonebook:

NUMx;pwd

The command code is the same as before, that is “NUM” followed by the phonebook memory location you want to delete. Obviously the password must be entered. So the syntax becomes:

NUM2;33225

Reading the phonebook

Now let’s look at the command for requesting the list of the first eight numbers in the phonebook:

NUM?;pwd

In this case the command code is “NUM?” followed, as always, by the password. Running the following command:

NUM?;33225

You get the following response:

# Command received by user -> NUM?;33225

# Command “NUM?” processed successfully

# The phone number read at the location: 1 is -> “+393491544888”

# The text associated to the phone number is: “ADMIN”

# The phone number read at the location: 2 is -> “+393474131177”

# The text associated to the phone number is: “ROSSI”

# The phone number read at the location: 3 is -> “+393474331076”

# The text associated to the phone number is: “BIANCHI”

# The phone number read at the location: 4 is empty

# The phone number read at the location: 5 is empty

# The phone number read at the location: 6 is empty

# The phone number read at the location: 7 is empty

# The phone number read at the location: 8 is empty

As you can see, the command string that was sent returned the status of the first eight memory locations of the phonebook, showing that the first three cells are occupied. The remaining five are free.

If you want to read all the memory locations in the phonebook, you can use the following command string:

ANUM?;pwd

Running the command produces the following response:

# Command received by user -> ANUM?;33225

# Command “ANUM?” processed successfully

# The phone number read at the location: 1 is -> “+393491544888”

# The text associated to the phone number is: “ADMIN”

# The phone number read at the location: 2 is -> “+393474131177”

# The text associated to the phone number is: “ROSSI”

# The phone number read at the location: 3 is -> “+393474331076”

# The text associated to the phone number is: “BIANCHI”

# The phone number read at the location: 4 is empty

# The phone number read at the location: 5 is empty

…….

…….

# The phone number read at the location: 249 is empty

# The phone number read at the location: 250 is empty

The command string that was sent returned the status of all the memory locations in the phonebook; finally, a command was implemented to search for a phone number in the phonebook when the associated text is known. For example, if you want to check that Mr. Rossi’s phone number is in the phonebook and is one of the first eight memory locations, you can run the following command string:

FNUM?;text;pwd

The command code becomes “FNUM?” followed by the text you want to search for in the phonebook, “text”, and of course the password. So the command could be the following:

FNUM?;Rossi;33225

The following response is obtained:

# Command received by user -> FNUM?;ROSSI;33225

# Command “FNUM?” processed successfully

# Found the phone number into the phonebook. The location is: 2

Note that Mr. Rossi’s phone number is in the phonebook and occupies the second memory location. If instead we search for Mr. Brambilla, who was added later, we will find that he occupies location ten in the phonebook and is therefore enabled only for the gate-opening functions.

# Command received by user -> FNUM?;BRAMBILLA;33225

# Command “FNUM?” processed successfully

# Found the phone number into the phonebook. The location is: 10

This concludes the command strings for configuring and checking the phone numbers to be saved in the phonebook.

Deleting SMS messages from memory

We have implemented two command strings that are useful for deleting a single SMS from the SIM memory or deleting all the SMS messages present in the SIM memory. Usually up to 30 memory locations are available for incoming SMS messages.

These functions are useful if old SMS messages are stored on the SIM that you intend to reuse with the remote control system. The syntax of the two commands is respectively:

DSMSx;pwd

DASMS;pwd

The command code for deleting a single SMS is “DSMS” followed by the memory location “x”. As always, the system password follows. To delete all SMS messages, the command code is “DASMS” followed by the password.

SMS notifications and voice calls for inputs

Let’s now move on to the commands for configuring the functions of the remote control system, starting with the commands for enabling/disabling the sending of alarm SMS messages or voice calls to the first eight numbers in the phonebook. So when an event occurs on the digital inputs we will be able to decide who will receive the alarm SMS messages and the related voice calls. Let’s start with the command string for configuring SMS sending, which can take the following two forms depending on whether you enable or disable SMS sending:

SMSxxxxxxxx:ON;pwd

SMSxxxxxxxx:OFF;pwd

The command code is “SMS” followed by the locations among the first eight available that you want to enable, “xxxxxxxx”. Then comes the string “ON” to enable or “OFF” to disable. Of course the command needs the password to be executed. By default the eight memory locations are enabled.

So, supposing you want to enable locations 1, 3, 5 and 7, you will have to send the following command string:

SMS1357:ON;33225

While to disable locations 2, 4, 6 and 8 you will send:

SMS2468:OFF;33225

What has been said also applies to voice calls, with the only difference being that the command code is “VOC”:

VOCxxxxxxxx:ON;pwd

VOCxxxxxxxx:OFF;pwd

For each of the following commands you will receive the usual response from the system:

# Command received by user -> SMS1357:ON;33225

# Command “SMS” processed successfully

# Command received by user -> SMS2468:OFF;33225

# Command “SMS” processed successfully

# Command received by user -> VOC1357:ON;33225

# Command “VOC” processed successfully

# Command received by user -> VOC2468:OFF;33225

# Command “VOC” processed successfully

Input activation level

Let’s now talk about the command for configuring how the digital alarm inputs are handled. The inputs can be considered active when a “HIGH” voltage level or a “LOW” voltage level is read, or on a “TOGGLE” change. So the three possible configuration strings will be the following:

LIVx:A;pwd

LIVx:B;pwd

LIVx:V;pwd

The command code in this case is “LIV” followed by the input you want to configure, “x”, and by the relevant steady state, “A” (HIGH), “B” (LOW) and “V” (TOGGLE). As usual the password follows at the end. So, supposing you want to set input 1 as active high, you can proceed like this:

LIV1:A;33225

If you want, you can find out how the inputs are configured; to do this it is enough to send the command string:

LIV?

The command code is “LIV?”, no password is required. The response from the system will be:

# Command received by user -> LIV?

# Alarm activation level for input 1: HIGH

# Alarm activation level for input 2: HIGH

# Command “LIV?” processed successfully

Both inputs are configured to be active with a high logic level.

Inhibition and observation time

Again for the digital inputs, it is possible to configure an “inhibition” time that tells the system to ignore changes on the input for a preset period of time after that input has been activated. This helps to avoid spurious activations and therefore unwanted alarm SMS messages. The time can be set from a minimum of 0 minutes to a maximum of 59 minutes. The default value is 5 minutes. The command string to use is:

INIx:mm;pwd

The command code is “INI” followed by the input you want to configure, “x”, and by the inhibition time “mm”. To find out how the inhibition times of the inputs are configured, you can send the command string:

INI?

The command code is “INI?” and it returns the following:

# Command received by user -> INI?

# Alarm inhibition time for input 1: 10

# Alarm inhibition time for input 2: 5

# Command “INI?” processed successfully

There is a further command for configuring the inhibition times of the digital inputs which lets us ignore that configuration if necessary. In other words, when the input returns to rest it is possible to disregard the input masking time set by the previous command string just described. So to ignore the inhibition times you can use the following:

TIZ1x;pwd

TIZ2x;pwd

The command code is “TIZ1” or “TIZ2” followed by the parameter “x” which identifies whether or not to ignore the inhibition time. If the parameter is assigned the value “1” the system will ignore the inhibition time; conversely, if “0” is assigned, the system will be forced to take the inhibition time into account.

The last configuration parameter for the inputs is the so-called observation time, which can be seen as a kind of debouncing. In other words, the state of the input is considered valid for sending a possible alarm SMS if it remains stable for a preset time. The times that can be set range from 1 second to 59 seconds. The default value for this parameter is 1 second. The command string to use is:

OSSx:ss;pwd

The command code is “OSS” followed by the input you want to configure “x” plus the observation time expressed in seconds “ss”. The password goes at the end, as usual. If you want to know how the observation times are configured, you can use the following command string:

OSS?

which returns:

# Command received by user -> OSS? # Alarm observation time for input 1: 10 # Alarm observation time for input 2: 1 # Command “OSS?” processed successfully

Alarm message text

Let’s now move on to the commands for configuring the text you want to send when an alarm condition occurs on the digital inputs. The command strings to use are:

TIN1A:xxxx;pwd TIN1B:xxxx;pwd TIN2A:xxxx;pwd TIN2B:xxxx;pwd

The command codes let us configure the text string to send in the event of an alarm. So we have:

• Input 1 active high (“1A”)
• Input 1 active low (“1B”)
• Input 2 active high (“2A”)
• Input 2 active low (“2B”)

The text string “xxxx” can be up to 100 characters long and the punctuation marks “,” and “;” cannot be used. A possible example of how to use this command string could be:

TIN1A:Bilge flood alarm!!;33225

So we have configured the alarm string for input 1 when it is active high. The string associated with the alarm state is “Bilge flood alarm!!” Let’s now look at the command for setting the number of SMS messages the system must send while the input alarm condition persists. The command string is as follows:

ALNy:xx;pwd

The command code is “ALN” where “y” indicates the input being configured. The parameter “xx” indicates the number of SMS messages to send while the alarm condition persists. The allowed values range from 0 to 99. The value 0 means no SMS, while 99 means infinite SMS. All other values between 0 and 99 indicate the maximum number of SMS messages the system will send while the alarm persists. The command string ends with the system password. An example configuration could be:

ALN1:5;33225

The command string set this way indicates that while the alarm on input 1 persists, at most five SMS messages will be sent to the selected phone numbers. To find out how many SMS messages the system will send if the alarm persists, you can use the string:

ALN?

In this case the command code is simply “ALN?” with no password. Executing the command returns the following:

# Command received by user -> ALN? # Max num. of SMS to send if alarm occur (99 infinite; 0 nothing). Input 1: 5 # Max num. of SMS to send if alarm occur (99 infinite; 0 nothing). Input 2: 10 # Command “ALN?” processed successfully

Digital output management

Let’s now look at the command for managing the digital outputs. The possible command strings are as follows:

OUTx:ON;pwd OUTx:OFF;pwd OUTx:ss;pwd

The command code is “OUT” where “x” indicates the digital output. To bring the output to a logic high level, add the string “ON” to the command; otherwise, to bring it to a logic low level, use the string “OFF”. If instead you want to invert the output state for a period of time, put a time in seconds “ss” in place of the “ON” and “OFF” strings. The minimum accepted value is 1 second, while the maximum is 59 seconds. Let’s take the following example:

OUT1:ON;33225

The command string sent turns on digital output 1. If instead we send the string:

OUT1:30;33225

In this way we have inverted the output state, bringing it to a logic low level for a period of 30 seconds, after which the state returns high.

If you want to request the status of the outputs, you must send the following command string:

STA?

Executing the command returns the following:

# Command received by user -> STA? # Relay status for output 1: ON # Relay status for output 1: OFF # Command “STA?” processed successfully

Periodic report SMS

Let’s move on to the description of the command that configures when to send the report SMS, that is, how often to send the status of the digital Inputs/Outputs (the SMS is sent only to the first number in the phone book). The three command strings are as follows:

AUTOC:ON;pwd AUTOC:OFF;pwd AUTOC:hh:mm:ss;pwd

The command code is “AUTOC” followed by the service activation string, that is, “ON” active; “OFF” not active. Besides activation, you can decide how often to send the report SMS using the third command string with the parameter “hh:mm:ss”. This parameter does not identify the time at which you want to send the SMS, but the time interval between one send and the next. Obviously the system password follows at the end. For example, if we set “10:30:30” it means that the report message is sent when 10 hours, 30 minutes and 30 seconds have elapsed, or if you prefer every 37830 seconds. So a hypothetical command string could be:

AUTOC:10:30:30;33225 AUTOC:ON;33225

If you want to know how the report SMS service is configured, you can use the following command string:

AUTOC?

Which, when executed, returns the following:

# Command received by user -> AUTOC? # SMS report status: ON # If enabled, the SMS report format is: TEXT # If enabled, the SMS report of the Inputs/Outputs is sent every: 10:30:30 # Command “AUTOC?” processed successfully

Note that there is another configuration parameter for the report SMS, and it concerns how the states of the inputs and outputs must be represented when the SMS to be sent is composed. In other words, we can choose whether to use a binary or a text representation. The command string that lets us configure what we have just described is the following:

FORS:x;pwd

The command code is “FORS” where the parameter “x” indicates the format: “1” text format; “0” binary format. The system password goes at the end.

Output state recovery and startup SMS

That said, we can move on to the next command, which configures the ability to store the state of the outputs in the event of a power failure, so that the last state can be restored when power returns. The command string that handles this is as follows:

RIPx;pwd

The command code is “RIP” and the parameter “x” indicates whether you want to enable the function “1” or disable it “0”. To find out how this parameter is configured, we can use the following string:

RIP?

Which, when executed, returns the following:

# Command received by user -> RIP? # Recovery relay status: ON # Command “RIP?” processed successfully

Let’s move on to the command for enabling the sending of the start-up SMS (it is sent to the first number in the phone book). The command string is:

AVVx;pwd

The command code is “AVV” where “x” indicates whether the function is enabled “1” or disabled “0”. Given the previous command, you can associate any text string you like with it; the default one is “SYSTEM STARTUP”. So the command string for configuring the text to use for the start-up SMS is as follows:

TSU:xxxxxxxxxxxx;pwd

The command code is “TSU” and “xxxxxxxxxxxx” is the text to save in EEPROM. Maximum 100 characters. As usual, the characters “,” and “;” are forbidden. The system password is required at the end of the command. So a possible command string could be:

TSU:Telecontrol StartUp! Have a nice day;pwd

Gate opener function and ECHO

Let’s move on to the configuration command for digital output 1 alone, used for the gate opener function. This is applicable to the 200 phone numbers stored starting from the ninth memory location in the phone book (in fact, even the first eight numbers in the phone book can take advantage of this function). The command string for configuring this function is as follows:

TAC:ss;pwd

The command code is “TAC” followed by the time “ss” for which output 1 is energised; the settable time ranges from a minimum of “00” to a maximum of “59” seconds. So whenever a voice call is received from a phone number present in the list, digital output 1 is energised and remains in that state until the set time expires. If you set the value “00”, it means that with each call the output behaves in a bistable way, that is, I call and energise the output, I call again and de-energise the output. This command string also requires the system password at the end.

Let’s move on to the “ECHO” function, that is, the ability to select which phone number, stored in the phone book, you want to send the received SMS messages to when they are not part of the supported command strings. The command string is as follows:

ECHO:x;pwd

The command code is “ECHO” followed by the phonebook memory location “x”, which identifies the phone number the SMS is to be sent to. If “x” is zero, the function is disabled.

System information commands

The next command is used to ask the system for the GSM signal quality. The string to use is:

QUAL?

which returns:

# Command received by user -> QUAL? # GSM Quality signal (RSSI): 20 # GSM Channel bit error (BER): 0 # Command “QUAL?” processed successfully

If instead you want to know which operator you are connected to, you can use the string:

OPER?

which returns:

# Command received by user -> OPER? # The SIM operator is: “TELECOM ITALIA MOBILE” # Command “OPER?” processed successfully

And if you want to know which revision of the sketch is loaded on the Arduino Mega 2560, you must use the following:

REV?

which returns:

# Command received by user -> REV? # The TDG133 Rev: 1.0 # Manufacturer: SIMCOM_Ltd # TA Model: SIMCOM_SIM800C # TA Revision:1418B04SIM800C32_BT # TA (IMEI): 866104027073389 # Command “REV?” processed successfully

Besides returning the sketch revision, this function also gives us information about the GSM engine used, namely brand, model, FW revision and IMEI.

Power failure and power restoration SMS

Let’s now talk about the command used to set the sending of the power failure SMS. The command is implemented, so it can be configured, but since the system currently has no backup battery to maintain the power needed to send the SMS, it is meaningless. However, it is not ruled out that it will be fully supported in the future. So the command string to send is the following:

PWRFx;pwd

The command code is “PWRF” and “x” indicates whether the function should be enabled or disabled, in other words “1” enables it and “0” disables it. Obviously there is also a command to set the sending of the power restoration SMS. The command string in this case is:

PWRRx;pwd

The command code is “PWRR” and “x” indicates whether the function should be enabled or disabled, in other words “1” enables it and “0” disables it. Obviously, for both command strings just discussed there is the possibility of configuring the SMS you want to send in both cases. The command string to configure the power failure SMS is:

TPWPF:xxxxxxxxxxxx;pwd

The command code is “TPWPF” and “xxxxxxxxxxxx” is the string to use to compose the SMS. As usual, a maximum of 100 characters excluding the “,” and “;”. Remember the system password at the end of the command string. Instead, the command string to configure the power restoration SMS is:

TPWPB:xxxxxxxxxxxx;pwd

The command code is “TPWPB” and “xxxxxxxxxxxx” is the string to use to compose the SMS. As usual, a maximum of 100 characters excluding the “,” and “;”.

Restoring factory parameters

Finally, let’s look at the last command, which is the one for restoring the factory conditions. That is, it brings all system configurations back to their initial state, including the texts of the SMS to be sent. In addition to this, it DELETES all phone numbers from the phonebook. The command string to use is:

RES;pwd

The command code is “RES” followed by the password. The response is the following list of events (which we have truncated for obvious reasons):

# Command received by user -> RES;33225 # Command “RES” processed successfully # Erased Phonebook memory entry: 1 # Erased Phonebook memory entry: 2 ……. ……. # Erased Phonebook memory entry: 250

Let it be clear that once the command has finished executing, the system password is also brought back to its factory value, namely “12345”.

Multiple commands and silent response

Let’s make a few more small considerations:

• It is possible to send several commands at the same time, taking care to put a comma between one command and the next. For example:

qual?,oper?,rev?

The response is:

# Command received by user -> QUAL?,OPER?,REV? # GSM Quality signal (RSSI): 20 # GSM Channel bit error (BER): 0 # Command “QUAL?” processed successfully # The SIM operator is: “TELECOM ITALIA MOBILE” # Command “OPER?” processed successfully # The TDG133 Rev: 1.0 # Manufacturer: SIMCOM_Ltd # TA Model: SIMCOM_SIM800C # TA Revision:1418B04SIM800C32_BT # TA (IMEI): 866104027073389 # Command “REV?” processed successfully

• If the commands are sent from a mobile phone via SMS, you can tell the system not to send any response to the sender. To do this, you must put the command string “RISP” at the beginning of the message, followed by a comma. In this way the system will not send any response SMS to the requests made.

Managing the GSM shield LEDs

On the GSM Shield there are LEDs that are used by the current sketch to give visual information about the state of the application. Below is a brief description of them:

• LED 12 Red [I/O 13 – Pin 14]; also called Trigger 3, it behaves as follows:
• – fast blinking during GSM module initialization; period 250ms (25% ON/75% OFF);
• – slow blinking in steady state, GSM initialization complete; period 2s (25% ON/75% OFF);
• – if a string command is executed, the LED stays on steadily for the whole duration of the command and goes back to blinking slowly once the command has been executed.
• LED 04 Red [I/O 37 – Pin 62]; when lit it indicates that output 1 is active, while it is off when the output is idle;
• LED 05 Red [I/O 36 – Pin 61]; when lit it indicates that output 2 is active, while it is off when the output is idle;
• LED 06 Yellow [I/O 35 – Pin 64]; it lights up when digital input 1, depending on the configuration made, triggers the alarm condition, otherwise it is off;
• LED 07 Yellow [I/O 34 – Pin 63]; it lights up when digital input 2, depending on the configuration made, triggers the alarm condition, otherwise it is off;
• LED 06 and LED 07 are also used to indicate the waiting state for the first phone number to be saved in the phonebook (Easy Setup); in that case they blink alternately with a period of 500ms (50% ON/50% OFF);
• LED 08 Green [I/O 33 – Pin 66]: signals an outgoing SMS or voice call:
• – when the SMS is sent it lights up, otherwise it is off;
• – during a voice call the LED blinks, otherwise it is off.
• LED 09 Green [I/O 32 – Pin 65]: indicates the reception of an incoming SMS or voice call:
• – when an SMS is received the LED lights up, otherwise it is off;
• – during a voice call the LED blinks, otherwise it is off.

Conclusions

This ends the description of the GSM remote control based on Arduino and GSM Shield; for the purposes of the project the firmware uses part of the available I/Os, so anyone wishing to expand its functionality can take advantage of all 8 digital inputs and the same number of outputs by modifying the sketch.

Related products

• GSM/GPRS SIM900 Shield for Arduino

The post GSM remote control: emulating the TDG series (part 2) appeared first on Open Electronics.

Filtronic plc of Sedgefield and Leeds, UK — which designs and manufactures RF and millimeter-wave (mmWave) transmit & receive components and subsystems for the space, aerospace & defence, and telecoms infrastructure markets — has announced a $68.1m (£51.3m) follow-on order to supply Cerus E-band gallium nitride (GaN) solid-state power amplifier (SSPA) units to SpaceX...

An experimental satellite that weighs as much as a ping pong ball. The Maker Science project demonstrates how to build a working, recoverable femtosatellite weighing just 21 grams, using easily available commercial electronic components. The whole thing is based on an ESP32-C3 Super Mini board, a BME680 sensor, and a BMI323 sensor.

The prototype falls into the femtosatellite category, meaning satellites that weigh less than 100 grams. At 21 grams, this example sits at the light end of the category. It can be carried by a drone or a small rocket, and after landing it is recovered to analyze the recorded data.

The onboard circuit: ESP32-C3, BME680, and BMI323

The heart of the satellite is the ESP32-C3 microcontroller. This Super Mini board handles data collection and saves it to onboard memory. Thanks to its low power consumption and small size, it fits perfectly into such a light payload.

The BME680 sensor measures temperature, humidity, and other environmental conditions. Alongside it, the BMI323 detects motion and orientation. During flight, the ESP32-C3 collects readings from both sensors and records them.

The data is then analyzed on the ground. After recovery, the satellite is connected to a dashboard that allows downloading and viewing all measurements. This way, you can study environmental conditions and movements during the short mission.

Software and programming with Arduino IDE

Programming is done through the Arduino IDE, the most common development environment among makers. The code needed to read the sensors and save data is available in the project repository. Anyone who wants to replicate the satellite can start from there.

The Maker Science repository contains everything needed for the firmware. The project repository collects the Arduino sketches to upload to the board. Nothing else is needed to get started: connect the ESP32-C3 to a PC, upload the sketch, and test the system.

For those starting from scratch, the ESP32-C3 Super Mini board is a solid choice. It has built-in wireless connectivity and a compact form factor, ideal for this type of application. Online documentation helps set up the development environment in minutes.

The project also demonstrates the importance of calibration. Before a real flight, it is worth checking that the sensors respond correctly. A ground test with known movements helps validate the BMI323 readings.

Numbers and limits of a 21-gram satellite

The numbers speak for themselves: 21 grams total weight, below the 100-gram threshold that defines femtosatellites. This lightness opens up interesting scenarios for anyone wanting to experiment with amateur launches.

Of course, such a small satellite has limits. It cannot host large solar panels or capacious batteries. The mission is short, and the data is limited to what the sensors can capture during flight.

Here are the key components of the project:

• ESP32-C3 Super Mini: microcontroller with Wi-Fi and Bluetooth LE
• BME680: sensor for temperature, humidity, pressure, and air quality
• BMI323: inertial sensor for acceleration and orientation

With these three components and a bit of code, anyone can build an experimental satellite. The Maker Science project shows that the entry threshold for amateur space experimentation is lower than you might think.

Source: https://github.com/makerscienceofficial/Yeti_SAT1

The post 21-Gram Femtosatellite with ESP32-C3: Flight Data for Makers appeared first on Open Electronics.

Despite advances in healthcare technology, blood pressure measurement has largely remained unchanged for decades. Across hospitals, clinics, and homes, cuff-based devices continue to be the primary method for monitoring cardiovascular health.

While this method is clinically accepted, it provides only occasional measurements, needs user involvement, and does not facilitate continuous monitoring. Consequently, important information on conditions such as nocturnal hypertension, sudden spikes, stress-related changes, and long-term cardiovascular trends often goes unnoticed.

This limitation is becoming critical as healthcare shifts toward prevention, remote monitoring, and continuous health insights. The idea of measuring blood pressure passively and continuously with wearable technology has emerged as an exciting area in digital health.

However, monitoring blood pressure without a cuff is more complicated than just switching the inflatable cuff for a wearable sensor. This presents a difficult challenge in biomedical engineering that requires merging sensor technology, understanding physiological signals, using smart algorithms, designing hardware, and conducting clinical tests.

Why cuffless BP monitoring matters

Continuous visibility of blood pressure could change how healthcare is delivered. For patients with high blood pressure, single readings often do not reflect the true variations in cardiovascular activity throughout the day. Moreover, cuffless monitoring may also be especially useful for screening people who do not know they have high blood pressure. So, a passive monitoring system could enable earlier interventions, better therapy adjustments, and improved chronic condition management.

Cuffless devices are generally more comfortable than traditional cuffs because they avoid inflation and noise, which can reduce the burden of repeated checks. In remote patient care, non-intrusive blood pressure tracking could enhance care at home while reducing reliance on periodic manual checks, though validated cuff-based monitors are still recommended for accurate hypertension management.

Consumer wearables have already made continuous heart rate and oxygen saturation monitoring common. However, blood pressure remains one of the most clinically valuable yet technically challenging physiological parameters to measure continuously and accurately. Successfully overcoming this challenge would mark a significant advancement in enabling truly intelligent and continuous cardiovascular monitoring.

The engineering challenge behind the vision

Unlike heart rate, blood pressure cannot be measured directly with a single optical or electrical sensor in a wearable device. Instead, cuffless estimation depends on interpreting indirect physiological signals that relate to blood vessel behaviour.

Calibration adds another layer of difficulty. Many cuffless methods need initial reference measurements from traditional cuff-based devices. However, physiological traits can change over time due to aging, hydration, medication, illness, and activity levels, making it hard to maintain long-term accuracy. A system that works for one person may not apply well to a larger population.

This is why cuffless blood pressure monitoring remains one of the most challenging areas in wearable healthcare.

A practical engineering path to cuffless BP device innovation

One of the common difficulties faced in medical technology innovation is attempting to solve product-scale problems before fully understanding the underlying technical uncertainties. Cuffless blood pressure monitoring requires a more structured engineering approach that prioritizes validation of core physiological assumptions before committing to long-term architectural decisions.

A practical path begins with understanding whether available physiological signals can reliably support meaningful blood pressure estimation. This requires careful exploration of signal accessibility, synchronization accuracy, feature extraction quality, calibration methodologies, and algorithm performance under realistic operating conditions.

At this stage, the emphasis is not on building a commercial product, but on establishing technical confidence in the signal-to-estimation pathway. Early studies also need to plan for the large content of physiological data being generated, transmitted, and securely stored, since cuffless devices can create substantial amounts of health data.

Raw physiological data must be collected, processed, and analyzed to identify stable correlations between measurable biosignals and blood pressure behaviour. Algorithmic approaches whether deterministic or AI-assisted must be evaluated against reliable reference measurements to understand their practical limitations.

Critical engineering questions emerge early. Can the selected biosignals consistently support accurate estimation? Which signal combinations remain robust under motion, physiological drift, and environmental variation? How much calibration dependency exists and can performance generalize across broader user populations?

Resolving these questions early helps shape sound architectural decisions, reduce avoidable development risk, and create a stronger foundation for eventual product realization.

Why custom hardware becomes necessary

While existing wearable platforms help speed up feasibility studies, they also have significant technical limitations. Consumer-grade wearables are usually designed for wellness applications, not precise physiological measurement.

Access to raw synchronized data may be limited. Control over sampling rates, signal quality, analog front-end behaviour, and timestamp accuracy can be insufficient. These limitations become crucial when estimating blood pressure relies on subtle timing, such as pulse transit time, where accuracy is key.

As technical feasibility becomes more defined, the next step is to move to a custom hardware platform.

Custom hardware enables optimization on multiple levels. Sensor choice can be tailored specifically for blood pressure estimation, and the device features it depends on, rather than general wellness monitoring. The design of the analog front-end can be adjusted for better signal quality, reduced noise, and enhanced synchronization. The processing architecture can support on-device feature extraction and near real time analysis, reducing the need for external computing resources.

Mechanical design also plays an important role. Wearable physiological measurements are greatly affected by sensor placement, skin contact quality, and movement stability. A well-designed wearable form directly impacts signal quality and estimation accuracy.

This shift indicates a move from proof-of-concept to scalable products.

The role of AI and data in cuffless BP monitoring

AI is expected to be key in enabling practical cuffless blood pressure solutions. Traditional models often struggle to capture the complex, individualized relationships between physiological signals and blood vessel behaviour.

Machine learning can enhance performance by spotting subtle waveform patterns, addressing movement-related interference, and fine-tuning calibration methods. That makes systems easier to use in practice while adapting to user-specific physiological traits.

However, AI is not a quick fix. High-quality data, thorough feature engineering, model transparency, managing changes, and rigorous testing are crucial. AI teams often review model behaviour and performance before deployment. Moreover, in healthcare applications, predictive intelligence must be trustworthy, consistent, and clinically sound.

AI’s value is not in replacing engineering rigor but in supporting service quality and shared clinical knowledge.

The road ahead

A technically sound prototype does not automatically mean a clinically viable product. In addition to algorithm performance, success requires focusing on usability, long-term reliability, validation methods, regulatory requirements, and scalable designs.

Cuffless blood pressure monitoring represents significant potential in connected healthcare, but it’s also highly challenging.

Its success will not come from a single sensor innovation or AI advancement. It will arise from disciplined systems engineering, continuous validation, and a phased development approach that balances technical goals with practical execution.

The future of cardiovascular monitoring is heading toward continuous, passive physiological intelligence. The cuff may still have a role in clinical practice for a while, but its long-standing dominance is being questioned. The issue is no longer whether cuffless blood pressure monitoring can be done but how quickly engineering innovation can make it credible in clinical settings.

Frequently Asked Questions (FAQs)

1. Can wearable devices accurately measure blood pressure without a cuff?

Cuffless blood pressure monitoring is an area of ongoing research and innovation. Instead of directly measuring blood pressure, wearable devices indirectly estimate it using physiological signals such as PPG, ECG, pulse transit time, and other cardiovascular biomarkers. While significant progress has been made, achieving consistent clinical accuracy across a wide range of users and real-world conditions is one of the biggest engineering and validation challenges.

2. What are the biggest technical challenges to the development of cuffless blood pressure devices?

Designing a reliable cuffless BP system is a challenge that involves overcoming engineering problems such as motion artifacts, signal noise, calibration drift, user variability, and long-term accuracy. In addition, wearable devices need to optimize sensing capabilities, power consumption, comfort, and computational efficiency while satisfying clinical and regulatory requirements for medical devices.

3. What will the future of AI-assisted cuffless blood pressure monitoring look like?

AI-powered cuffless blood pressure monitoring could revolutionize cardiovascular care by providing continuous, non-invasive monitoring. With sensor technology, embedded AI, and physiological modeling advancing, future systems will be able to provide more personalized, continuous health insights. The greatest advances will come from combining sensing technologies, intelligent algorithms, robust engineering, and clinical validation into scalable healthcare solutions.

Srinivasan Kandaswamy is a medical device innovator and solution architect at eInfochips with over 15 years of experience in the development of healthcare technologies, connected medical devices, and lab-on-chip technologies. He holds a Ph.D in Mechanical Engineering and has contributed to the design, development and regulatory compliance of a broad range of medical devices across invitro diagnostics, wearable technologies, and connected healthcare platforms.

Related Content

• $60 blood pressure monitor
• Radar-Based Blood Pressure Sensors on the Way
• A Cuffless Blood-Pressure Measurement Solution
• Omron Simplifies Home Blood Pressure Monitoring
• Build blood pressure monitors using sensor modules, ready-to-use algorithms

The post The state of AI-powered innovation in blood pressure monitoring appeared first on EDN.

I didn't know about these things until recently. I've found them to be the handiest things ever for doing test and measurement work because they convert any bare wire into a banana plug-able wire. So instead of connecting to a bare wire with an alligator clip and having an exposed connection, I clip one of these onto the wire and plug it directly into the banana port it needs to connect to - multimeter, signal generator, power supply, etc. I also use these with banana plug to BNC converters on my oscilloscope. Obviously this isn't as good as a regular shielded oscilloscope probe for some applications but for others it is just fine. It's much better than having an exposed wire to probe connection in a lot of situations. submitted by /u/yycTechGuy [link] [comments]

Renesas Electronics Corp of Tokyo, Japan has launched what it claims is the industry’s first 650V GaN device with dual-side cooling for high-density power conversion in 800V high-voltage DC (HVDC) AI data-center architectures. The new TP65H020G4PLSGBD D-Mode device delivers 20mΩ on-resistance — one of the lowest in its class — in an ultra-compact, dual-side-cooled (DSC) PQFN package that handles more power in less space. Renesas is currently sampling the device to major AI data-center OEMs and ODMs...

The 5G RF chip and module industry continues to evolve around the split between sub-6-GHz and mmWave signal chains, the increasing demand for more integration in front-end modules (FEMs), and the growing use of gallium nitride (GaN) power amplifiers (PAs).

Meanwhile, RF digital front ends (DFEs) are integrating functions that were previously handled by analog parts. Front-end architectures are beginning to include Frequency Range 3 (FR3), AI, and early 6G interoperability as 5G-Advanced is rolled out. Additionally, Reduced Capability (RedCap), specified in 3GPP Release 17, and fixed wireless access (FWA) modules are now commercially available. In this article, we walk through these developments and see what this means for design decisions.

DFEs ease design

The use of DFEs is a major architectural revolution. Thus, some of the signal conditioning once handled by discrete RF and analog components has been transferred to DFE ICs, particularly in the case of massive MIMO base stations.

Broadcom announced a DFE system-on-chip (SoC), BroadPeak, featuring 32 differential transceivers, 32 differential receivers, and eight feedback receivers (32T32R8FB) for the 400-MHz to 8.5-GHz frequency band. The BCM85021 SoC is fabricated in an advanced CMOS process and integrates the DFE and high-linearity data converters with the analog front end on the same chip. The company claims to deliver up to 40% more efficiency than current solutions for massive MIMO and remote radio head applications.

The SoC combines carrier aggregation, digital predistortion (DPD), crest factor reduction (CFR), digital up-conversion (DUC) and down-conversion (DDC), and channel filtering in a single chip, reducing the number of discrete blocks needed to implement a radio unit. This SoC is a promising candidate for massive MIMO, where, following the deployment of 32T32R and 64T64R systems, extended architectures such as 128T128R arrays and extremely large antenna arrays with hundreds of radiating elements have been introduced.

Analog Devices Inc.’s (ADI’s) RadioVerse SoC series takes a similar approach but is more transceiver-centric. The ADRV9040 is part of the ADRV904x SoC family and integrates wideband RF transceivers and a DFE into one package that supports 4G/5G cellular, macro, and massive MIMO radios.

The SoC includes 8T8R and two differential observation receivers, 400 MHz of instantaneous bandwidth, and a fully integrated DFE engine with DPD, carrier DUC, carrier DDC, and CFR. These features significantly reduce the FPGA resources and the SerDes lane rate, as less data needs to be exchanged with external FPGAs.

The device (Figure 1) is based on ADI’s Zero IF (ZiF), a zero-intermediate-frequency (or homodyne) architecture. Its direct-conversion transceiver is specifically designed for the wide bandwidth and dynamic range required by multi-carrier base stations.

Figure 1: ADI’s RadioVerse SoC family combines wideband RF data converters, a DFE, and ZiF architecture to cut size, weight, power, and cost for 4G, 5G, and defense radio units. (Source: Analog Devices Inc.) FR3: a bridge to 6G

As global 5G moves into the 5G-Advanced (5.5G/Release 18) maturity phase, RF system architects and vendors are turning their attention to the FR3 spectrum. FR3, also referred to as the “upper midband,” is sandwiched between the sub-6-GHz (FR1) and mmWave (FR2) bands. It is already on the 5G-Advanced roadmap and will be a building block for future 6G networks.

FR3 is the band defined by 3GPP between 7.125 GHz and 24.25 GHz. The main advantage of FR3 for 5G-Advanced networks is the capacity expansion in the mid-band without the propagation constraints of conventional mmWave. Qualcomm Technologies Inc. and Keysight Technologies have already successfully tested the end-to-end interoperability and data connection operating in the FR3 band.

Keysight also showcased the characterization process of an FR3 front end (RFFE) from ADI at Mobile World Congress (MWC) 2025. The RFFE characterization process includes measuring key performance indicators, such as gain, linearity, noise figure, and impedance matching, across a range of frequencies and power levels. This is necessary to verify the design specifications of wireless communication systems using the hardware.

Sivers Semiconductors announced the Daybreak 7- to 15-GHz beamforming chip family for 5G/6G FR3 applications. In 2024, Sivers received $6 million from the U.S. Department of Defense for the Microelectronics Commons 5G/6G project. The chips are being developed in cooperation with Raytheon and Ericsson. According to Sivers, the chips offer high transmission power and efficiency, as well as low receiver noise. The new ICs integrate easily with external RFFE modules.

At MWC 2026, Skyworks Solutions Inc. and MediaTek demonstrated a reference design based on Skyworks’ SKYR60002, an FR3 low-noise amplifier module with integrated filtering from 6.425 GHz to more than 7 GHz. The company said the SKYR60002 module provides high linearity, wide bandwidth, and good thermal management to meet the demanding requirements of the 3GPP FR3 standard. The announcement also featured a Power Class 1 4G/5G ultra-high-band module for MediaTek-based platforms used in FWA and broadband infrastructure. The SKY58287-11 FEM features a package that dissipates heat without a separate heat sink.

As the deployment of frequency bands for FR3 is still undergoing standardization and regulations, the first deployment is expected to be in the frequency range of 7.125 GHz to 8.4 GHz. The main use cases are extended reality (XR), robotics, non-terrestrial networks, and AI-enabled applications.

GaN is still the PA of choice

The PA is an important element of any radio unit, and GaN remains the technology of choice for high-power, high-efficiency base station applications. The demand for lower power consumption and smaller physical size has spurred innovation in PA design, with an emphasis on broadband performance and ease of implementation.

For example, Ampleon added the high-efficiency 70-W GaN Doherty transistor C5H3440N70D to its 5G RF portfolio. This device is targeted for next-generation massive MIMO base stations and is designed for the 3.4- to 4.0-GHz band. Efficiency, linearity, and output power are the main characteristics that will make the RF engineer appreciate this device.

In normal operating conditions, the GaN Doherty transistor gives an average output power of 39.8 dBm, with a drain efficiency above 50% and a gain of about 12.7 dB. This combination results in a higher power density in the design of the amplifier, which directly influences overall energy efficiency and the cooling demands of the system.

The device is optimized for broadband Doherty operation, allowing multi-band and multi-carrier deployments without extensive redesign. Its effective DPD capability meets linearity requirements for modern, high peak-to-average-ratio signals. The built-in internal matching simplifies the implementation from a design point of view, reduces the external component count, and speeds up the development cycle.

RedCap 5G reaches maturity

In 2018, Qualcomm launched its modem-to-antenna strategy that combines the baseband modem chip, RF transceiver, and front end into a single, qualified system. This architecture has powered a number of premium products, such as the Snapdragon X75 and AI-enabled Snapdragon X80 5G modem-RF system.

RedCap modules use a similar approach. A 5G RedCap device has a simpler radio design and modem and works on narrower bandwidths than regular 5G, making it suited for mid-speed IoT applications. RedCap modules based on Qualcomm’s Snapdragon X35 platform are now commercially available, after early sampling.

Quectel Wireless Solutions has announced the RG255C-GL, a compact 5G sub-6-GHz RedCap module in the M.2 form factor (Figure 2). The module is compliant with 3GPP Release 17 and provides a theoretical downlink peak data rate of 223 Mbits/s and 123 Mbits/s in the uplink. The module supports LTE Cat 4 and 5G sub-6-GHz standalone mode and is backward-compatible to Release 15 and Release 16 networks. To cover North American frequencies, the RG255C-NA option has been developed in addition to the global RG255C-GL version.

Figure 2: Quectel’s RG255-GL 5G RedCap module offers global 5G/LTE coverage and GPS, GLONASS, BDS, and Galileo positioning. (Source: Quectel Wireless Solutions)

At MWC 2026, UNISOC (Shanghai) Technologies Co. Ltd. and Quectel announced a collaboration to integrate UNISOC’s 5G eMBB V620, V610, and 5G RedCap V527 platforms into a new series of Quectel 5G modules. They will provide a second-source alternative to the Qualcomm solution that powers the RedCap modules.

RedCap has become an attractive solution for engineers designing industrial sensors, surveillance cameras, or wearables that don’t need eMBB-class throughput but do need lower cost and power than a full-5G modem. It also offers second-source competition.

AI-enabled RF modems

Chipmakers are incorporating AI and machine-learning accelerators into RF modems to control real-time signal conditions, dynamic impedance matching, and predictive power scaling.

One example is the Qualcomm X105 5G Modem-RF platform. Figure 3 shows the X105 platform, the industry’s first modem ready for 3GPP Release 19, which opens the door for initial 6G deployment and testing. The platform is built around an RF transceiver on the most advanced 6-nm node process. Qualcomm claims it has reduced power by as much as 30% and the overall board footprint by 15% over previous generations.

The system has an on-chip agentic AI processor that dynamically classifies network traffic and adjusts RF front-end parameters in real time. This software-defined, hardware-accelerated approach is critical to achieve multi-gigabit throughput in 5G-Advanced and early 6G testbeds.

The Qualcomm X105 is an R19-ready modem-RF that targets 5G-Advanced applications including smartphones, FWA, mobile broadband, automotive, XR, PCs, robotics, and industrial IoT.

Figure 3: Qualcomm’s X105 5G modem-RF boasts a fifth-gen agentic AI engine. (Source: Qualcomm Technologies Inc.)

The post RF chips, modules power the way from 5G to 6G appeared first on EDN.

У 19-му корпусі відкрили меморіальну дошку на честь Данила Шляхова KPI4U-2 чт, 10/01/2026 - 16:50

The Seeed Studio reTerminal E1004 becomes a frame for AI-generated artwork. Every day the device wakes up, downloads the weather forecast, and creates a unique image with OpenAI. The 13.3-inch ePaper display shows it for the entire day without consuming power. The project combines artificial intelligence, ultra-low power consumption, and daily automation.

The heart of the system is the ESP32-S3, which drives the six-color E Ink Spectra 6 display. The resolution is 1200 × 1600 pixels with 4 bits per pixel. The generated image weighs about 937 kB and is saved on a microSD card. The panel stays on all day, but power consumption is minimal thanks to ePaper technology.

How the daily cycle works

The deep sleep timer activates at 01:00 by default. The device wakes up and the PCF8563 RTC synchronizes the system clock. Once connected to Wi-Fi, NTP corrects the RTC drift. The ePaper controller is initialized and the battery level is checked. If the charge is too low, an error screen appears.

Next, the microSD card is mounted and the weather forecast for 12:00 is downloaded from OpenWeather. A prompt is assembled with theme, date, weather, and battery level. OpenAI gpt-image-1 generates the image, which is saved on the SD card. The operation takes about 40 seconds.

• Deep sleep timer at 01:00
• RTC synchronization with NTP
• Battery check and ePaper initialization
• Weather download from OpenWeather
• Image generation with OpenAI
• Floyd-Steinberg dithering and display

The image is resized and converted to RGB565. Floyd-Steinberg dithering adapts it to the panel’s six colors. Finally, the display shows it and the device returns to deep sleep. The cycle repeats every day at the same time, without manual intervention.

Hardware and main components

The reTerminal E1004 integrates display, ESP32-S3, and sensors in a single module. The main board manages the ePaper panel and communication with the sensors. The PCF8563 provides the real-time clock, while the SHT40 measures temperature and humidity. The battery operates between 3.7 and 4.2 V, with serial communication at 115200 baud.

For those who want to experiment with smaller ePaper displays, an ESP32 module with a TFT touch display can be a starting point. The original project uses the reTerminal, but the generation and display logic can also adapt to other boards. The GitHub repository by maet3608 documents every step in detail.

The project demonstrates how to combine generative AI with ultra-low-power displays. Every morning you get a different artwork, tied to the weather and the date. The frame does not require continuous power and the battery lasts a long time. It is a perfect example of daily automation with open source hardware.

The software side uses PlatformIO with the espressif32 framework. The OpenAI and OpenWeather APIs are integrated directly into the firmware. The result is a standalone device that runs for months without maintenance. Moreover, six-color dithering makes every image suitable for the ePaper panel.

Source: https://github.com/maet3608/reTerminal-E1004-ai-image

The post 13.3-inch ePaper frame with AI-generated art appeared first on Open Electronics.

Panasonic Industry has returned to Electronica India this year with its broadest showcase yet for the Indian market comprising of new-to-India technologies focusing on performance, safety and reliability. Anwesh Koley of ELE Times, caught up with Narayan Kumar, Chief Business Office, Panasonic Industry & Energy India, to understand the company’s automotive trajectory and future trends.

ELE Times: Brief us about what all Panasonic is displaying this year and how important Electronica is for your company?

Narayan Kumar: We all know Electronica is a leading platform for the entire electronic ecosystem, and so we have been continuously participating in the Electronica event. Largely, from our point of view, we are looking at how we increase our participation in the total electronic ecosystem. If you look at the last few years, the movement has shifted from pure assembly to many organisations now doing local design and development.

That is a very big change because we can engage directly with the R&D and engineering teams of many of our customers across almost all segments to look at the future products they want to make, and determine how we can participate through our device solutions.

More importantly, it’s not only for the Indian market alone. We can now see many companies doing design and development for global markets. That’s a big shift. Being here in the city of Bangalore, we can see many Global Capability Centres (GCCs) coming up in India. It’s a very exciting time—the overall market is growing rapidly, and so are we with high double-digit growth, a momentum we would like to continue.

ELE Times: In terms of the current market—the Indian market vis-à-vis other Asian markets—how does Panasonic perceive the Indian market? What are the growth opportunities you have identified, and what is the way forward?

Narayan Kumar: The Indian market has become super important, not only from a Panasonic point of view, but also from the perspective of the total electronic ecosystem.

If you look at one big example of growth in Electronic Manufacturing Services (EMS), a few years back we primarily saw global EMS companies. Now, we see the rapid rise of Indian EMS companies growing at high double-digit rates. Again, this is not just for local Indian consumption; they are actively engaging in global exports. From a policy standpoint, the government is actively looking at signing Free Trade Agreements (FTAs), which will further boost the “Make in India” program.

A lot of organisations we are in touch with would like to diversify their production to India. That is where Panasonic Industry India would like to participate with those customers—not only from a supply standpoint, but also from a development perspective.

ELE Times: The government currently has been quite optimistic about the electronic and semiconductor sectors, backed by significant incoming investments. What is your take on these government and policy initiatives backing the sector?

Narayan Kumar: We need to look at current progress through the lens of where we were before. We started off largely on the assembly of mobile phones, but now almost all sectors in the economy involving electronic hardware are growing.

India remains very strong on the automotive side, with a high contribution to manufacturing GDP coming from automotive. Besides traditional automotive, we see rapid electrification happening across two-wheeler and four-wheeler EV markets.

Looking at non-automotive industrial markets, smart infrastructure and smart metering are expanding as part of government programs, driving action to produce meters locally and increase local content. In renewables and solar power, we are looking at the localisation of inverters. Every single component of the manufacturing value chain for electronics has initiated action, which is great news for companies like us to participate and offer our device solutions.

ELE Times: You mentioned the growth of electric vehicles in the automotive sector. How do you see EV technology developing in India, and what are your key takeaways from the current government push for EVs?

Narayan Kumar: India’s automotive sector is a massive market. Almost all global players are physically present here—not only with manufacturing powerhouses, but also with design and development centres.

Given the sheer volume of the Indian market, we won’t look at just one part of the powertrain; multiple powertrain options will emerge in parallel. In the two-wheeler segment, we are the largest globally. The EV market is definitely growing, and three-wheeler EV penetration is already very high because customers see a quick return on investment (ROI), a trend likely following into two-wheelers as well. As the economy progresses, multiple technology options will grow side-by-side.

ELE Times: How do you see the current state of localisation in India regarding technology and ancillary equipment sectors, and what is your perspective on the “Make in India” initiative today?

Narayan Kumar: That is a very pertinent question regarding the flagship government program, and I would break it down into three parts:

• Local Design Support: While localisation usually refers to local manufacturing, the piece that comes before it is local design. Global Capability Centres in India are expanding their workforce to design for global platforms. The world recognises that Indian designs are becoming global platforms, which is a major starting point where we actively participate.
• EMS & Manufacturing Content: Electronic Manufacturing Services are continuously increasing their localisation content and expanding local production capabilities.
• Component-Level Localisation: The third part involves going deeper into the supply chain to evaluate localised manufacturing for a wide variety of electronic components based on volume feasibility and product combinations.

ELE Times: At Panasonic, how do you balance quality and cost—a key factor the Indian market is known for—without compromising on reliability or impacting margins?

Narayan Kumar: The best way to look at this is not to separate quality and cost. They are deeply integrated because the consumer ultimately makes the buying decision. Across product roadmaps in all sectors, there is a constant focus on building long-lasting, reliable solutions. Many modern programs demand strong, long-term warranties. For instance, smart meter manufacturers are required to provide a 10-year warranty on maintenance and supply. Naturally, this demands selecting high-performance components built to last a decade.

Simultaneously, high manufacturing volumes help make pricing competitive. India is at a point where high volumes justify competitive pricing. Ultimately, reliability is the factor that beats everything—urbanisation means consumers want premium, durable products rather than spending time replacing items.

ELE Times: How does Panasonic foresee the future of technology in India, and how is the company poised to address upcoming opportunities and challenges?

Narayan Kumar: I would answer this from the perspective of how our headquarters and global customers view India:

• High-Value Consumption: India has always been a massive consumption market, but that consumption is shifting toward high-urban, premium categories. Launching high-quality products creates growing opportunities for our industrial devices.
• Export Expansion: Local EMS companies are expanding exports. As local manufacturing scales, imports will decline and exports will grow.
• Engineering & Design Leadership: We are very excited about the growth of local design and development that serves both India and global markets.

India possesses a unique combination that few other markets can claim: strong domestic consumption, deep engineering talent, rapid technology adoption, and active government incentives, such as electronics manufacturing clusters and talent upskilling. This combination makes the entire ecosystem more robust, durable, and long-lasting.

The post Interview | Narayan Kumar, Chief Business Office, Panasonic Industry & Energy India appeared first on ELE Times.

​With the continuously rising demand for electric vehicles, real-world energy efficiency is becoming an important performance metric alongside driving range and charging speed. Related to this, a recent test conducted on 22 participating vehicles from 15 different brands in Canada demonstrated the energy efficiency of modern electric vehicles. Each tested electric vehicle covered a 230 km route from Blue Mountain to Vaughan, Ontario in a single charge. The study found that modern electric vehicles consume 40% less energy on an average compared to vehicles tested in CAA’s February 2025 EV Winter Test.

During the recent test conducted in September 2026, variations in energy consumption among the tested vehicles ranged between 11.43 kWh/100 km and 28.91 kWh/ 100 km. This figure demonstrates how a vehicle’s size, weight and aerodynamics determine the electricity needed to cover a specific distance. A low-energy consumption vehicle uses less energy from the battery to cover the same distance, thus reducing charging requirements and charging cost, especially on longer trips.​

The key findings of the conducted test include range and battery usage, energy efficiency and charging performance among the vehicles. The Toyota bZ recorded the lowest energy consumption usage at 11.43 kWh/100 km, whereas the Lucid Gravity recorded the highest energy consumption at 28.91 kWh/100 km. CAA test also highlights that the two tests, conducted in different years involved different vehicles and operating conditions. Therefore, the resulting figures should not be treated as a direct vehicle-to-vehicle comparison.

The test demonstrates that EV evolution is more about increasing range. To be more practical while designing electric vehicle, designers and engineers must cater different factors such as energy consumption, charging performance, battery temperature, and vehicle design for improving the overall performance.

The post Real-World EV Efficiency: CAA Test Highlights Energy Consumption and Charging Performance appeared first on ELE Times.

This tutorial examines conducted EMI behavior using an Extended Power Range (EPR) (≥100W) USB Power Delivery (PD) reference design.

Automotive electrical systems are moving beyond the traditional 12V rail toward 48V architectures. The higher bus voltage can reduce the required wire gauge, lower harness power losses, and reduce printed circuit board size by decreasing current for a given power level. At the same time, the transition introduces new design challenges, including higher component cost, additional creepage and clearance requirements, and electromagnetic interference (EMI) from high-power switching converters.

This tutorial examines conducted EMI behavior using an Extended Power Range (EPR) (≥100W) USB Power Delivery (PD) reference design from Texas Instruments (TI). The Automotive USB Power Delivery Reference Design with Two Ports 180W Maximum Each, 24V to 60V Input operates from a 48V source and supports two USB Type-C® ports, with each port capable of delivering up to 36V at 5A, or 180W. The measured results show how a combination of hardware changes, USB PD controller-based synchronization, and dithering techniques can take a design from failing Comité International Spécial des Perturbations Radioélectriques (CISPR) 25 limits to passing with margin.

Figure 1 shows the reference design’s architecture, in which the USB PD controller commands two DC/DC converters through I2C. Each power stage is a synchronous buck converter operating at a nominal 400 kHz switching frequency, while a single dual-port USB PD controller manages both channels.

Figure 1 This block diagram of TI’s automotive USB PD reference design features a USB PD controller and dual-port USB Type-C architecture. Source: Texas Instruments

CISPR 25 defines the conducted emissions test configuration in detail but does not specifically define how to incorporate a USB Type-C load. Using a previously approved test setup for a USB Type-C application, Figure 2 shows the output cables, resistive loads and supporting equipment, along with their integration into the standard automotive test configuration. The intention here is to clearly showcase the measurement conditions and confirm that they are clear and reproducible.

Figure 2 Setup pictures for the conducted emissions test showcase dual-port operation in a conducted EMI chamber. Source: Texas Instruments

During conducted emissions testing, Port A operated at 36V and 5A, while Port B operated at 5V and 3A. Both loads were strictly resistive in order to not affect the EMI testing common from electronic loads.

Several early design choices improved the likelihood of meeting the conducted emissions limits. For example, we selected a 400 kHz switching frequency because CISPR 25 has a frequency gap between 300 kHz and 530 kHz. Placing the fundamental switching frequency noise within this gap reduces the possibility that the fundamental itself will violate a conducted emissions limit. Similarly, adding a common-mode choke helped attenuate common-mode noise at higher frequencies from 30 MHz to 108 MHz.

During testing, we made changes to address a lower-frequency resonance below the switching frequency. To move the resonance at 165 kHz to be well below 150 kHz, we added a 4.7 µF input capacitor across the input and increased the differential-mode inductor from 1 µH to 1.5 µH. The before-and-after scans in Figure 3 show the reduction in low-frequency conducted emissions. These hardware changes helped decrease the amplitude of noise at lower frequencies by approximately 30 dB.

Figure 3 These graphs show the conducted emissions scans before and after the EMI filter hardware changes. Source: Texas Instruments

For higher-frequency emission control, adding a 3.92 Ω bootstrap resistor to each DC/DC converter slowed the turn-on transition of the high-side field-effect transistor. Slowing this transition reduces switch-node ringing and resulting emissions in the 50 MHz-to-200 MHz range. There is a modest reduction in overall efficiency, however – approximately 0.3% to 0.5% at a full load.

Input filtering, component selection, switching behavior and power-stage implementation should first establish a strong conducted emissions control baseline. Firmware-based EMI techniques can then build on that foundation, providing the additional improvement necessary to meet the required limits.

The TI TPS26744E-Q1 USB PD controller provides SYNC outputs, which are clock signals used to synchronize the switching frequency of the two external DC/DC converters and help manage their EMI. There are two mechanisms involved. First, the two SYNC signals can operate 180 degrees out of phase, which helps avoid simultaneous switching of the two converters. Second, the controller’s ability to dither the switching frequency distributes that switching energy over a range of frequencies instead of being concentrated at a single frequency. The example synchronization clock signals in Figure 4 show both mechanisms.

Figure 4 Synchronization signals from the USB PD controller operate the dual-port buck converters out of phase and with dithering. Source: Texas Instruments

TI’s dual random spread spectrum (DRSS) EMI reduction technique combines controlled triangular frequency modulation with pseudorandom frequency variation. With a switching frequency of 400 kHz, this modulation spreads energy around the nominal frequency and its harmonics rather than allowing narrow, high-amplitude spectral peaks to dominate.

To isolate the effect of firmware, our measurements used the same hardware and loading conditions: Port A at 36V and 5A and Port B at 5V and 3A. Only the synchronization and dithering configuration differed.

With both SYNC and DRSS disabled, the dual-port design failed the conducted emissions limit by 10dB at 800 kHz. As shown in Figure 5, strong peaks occurred at the 400 kHz switching frequency and its harmonics, including 800 kHz, 1.2 MHz and 1.6 MHz.

Figure 5 The conducted emissions scan with SYNC and DRSS disabled shows failure at the resonance of the switching frequency. Source: Texas Instruments

Enabling the DC/DC converters’ DRSS while leaving SYNC disabled substantially improved the result. The remaining failures were approximately 2 dB at 800 kHz and 70 MHz (Figure 6).

Figure 6 The conducted emissions scan with SYNC disabled and DRSS enabled shows overall improvement but still failure at 800 kHz. An unknown resonance also appears at 70 MHz. Source: Texas Instruments

The best result came when enabling the TPS26744-Q1 SYNC function and DRSS together. Under the same dual-port loading condition of 180W on Port A and 15W on Port B, the design passed with approximately 3 dB of margin, as shown in Figure 7.

Figure 7 The conducted emissions scan with USB PD controller SYNC and DRSS enabled shows that this configuration passes with margin. Source: Texas Instruments

These results demonstrate passing EMI performance in a high-power 48V USB PD EPR design. In the TI reference design measurements, hardware changes improved lower-frequency behavior, while coordinated SYNC and DRSS optimization reduced the dominant switching frequency emissions and harmonics.

Overall, the measured performance changed from failing by 10dB to passing by 3 dB at 800 kHz. The primary takeaway is that combining practical hardware mitigation with controller-based synchronization and spread-spectrum techniques can provide meaningful emissions reduction in any 48VIN power supply.

 

Sarmad Abedin is a systems engineer in TI Power Design Services, currently concentrated in automotive applications. He has been designing power supplies for over 15 years and specializes in DC/DC applications as well as low power AC/DC power supplies. He has a bachelor’s degree in electrical engineering from Rochester Institute of Technology.

 

Josh Mandelcorn has been an applications engineer in TI’s Power Design Services team for two decades, primarily focused on designing power solutions for data center and automotive applications. He has designed high-current multiphase converters to power core and memory rails of processors handling large rapid load changes with stringent under and overshoot voltage requirements. He previously designed offline AC-to-DC converters in the 250W to 2kW range with a focus on emissions compliance. He is an author or co-author on 17 U.S. patents related to power conversion. He received a bachelor’s degree in electrical engineering from Carnegie Mellon University.

 

Seong Kim is an applications engineer at TI, focusing on automotive USB PD and DC/DC converter solutions. With over a decade of experience, he has supported embedded and power designs ranging from wireless microcontrollers for Internet of Things to high-speed USB Type-C and USB PD systems in automotive environments. He is listed as an inventor on a pending U.S. patent related to USB PD. He has a bachelor’s degree in electrical engineering from The University of Texas at Dallas.

 

Related Content

• Power Tips #75: USB Power Delivery for automotive systems
• Power Tips #143: Tips for keeping the power converter cool in automotive USB PD applications

The post Power Tips #157: Reducing conducted EMI in 48V automotive USB Type-C EPR designs appeared first on EDN.

Дякуємо захисникам і захисницям України KPI4U-2 чт, 10/01/2026 - 14:58

Design engineers building megawatt-scale AI data centers are running out of board space and thermal headroom before they hit their power limits. That’s because as rack power climbs from roughly 120 kW toward the megawatt scale, space and heat become critical factors in sustaining that power level.

Renesas Electronics claims its dual-side-cooled 650-V GaN device for high-voltage power conversion dissipates heat from both top and bottom. That cuts the footprint significantly and lowers top-side thermal impedance by 10%, allowing designers to move more power through the intermediate bus without redrawing the board or adding more cooling hardware.

The dual-side-cooling device for high-voltage power conversion packs more power into space-constrained megawatt-scale racks by shrinking the footprint by 57% compared with the TOLT package. Source: Renesas

Renesas’ TP65H020G4PLSGBD D-Mode device—enabling dual-side cooling for high-density power conversion in 800-V AI data center architectures—delivers 20 milliohms (mΩ) on-resistance, one of the lowest in its class. It’s available in an 8 x 8 mm PQFN package, which is 57% smaller than the existing 10 x 15 mm TOLT package, and handles more power in less space.

The device—based on Renesas’ Gen IV Plus GaN architecture—is purpose-built for the megawatt-scale demands driving next-generation AI data centers supporting up to 700-V power operation. It offers low gate charge and output capacitance. It also includes a built-in freewheeling diode with minimal reverse recovery and a high threshold voltage that operates without a negative gate bias.

The 650-V GaN device is built for the 800-V DC/DC intermediate bus converter (IBC) stage, which steps down to 48 V, 12 V, or 6 V, along with the battery backup and capacitor bank stages of the sidecar power rack. Design engineers can drive it with a standard silicon gate driver, switch into the MHz frequency range to minimize passive components, and cut overall BOM cost without requiring a specialized E-mode driver.

Renesas claims it has validated the 650-V GaN device on a 6 kW, 800 V-to-48 V LLC DC transformer reference design. The 650-V GaN device, already being sampled by major AI data center OEMs and ODMs, will be showcased at the OCP Global Summit on October 12-15, 2026, in San Jose, California.

Related Content

• Get a grip on your data center power efficiency
• Why Data Centers Must Become System‑Aware
• AI Power Demands Push GaN into Data Center Design
• Data center power meets rising energy demands amid AI boom
• Data center next generation power supply solutions for improved efficiency

The post How a 650-V GaN device shrinks footprint in space-constrained data center racks appeared first on EDN.

Starlab Space LLC of Webster, TX, USA — which is developing an AI-enabled commercial space station, expanding access to low Earth orbit (LEO) research and manufacturing — has announced a payload reservation from Elethron, an advanced materials and process engineering company developing high-performance crystalline materials for semiconductor applications...

An SO-101 robot arm, originally a desktop toy, now picks and places rubber ducks by reasoning with a vision-language-action model. Dmitry Maslov’s project swaps the original brain for an Arduino VENTUNO Q board, which runs Hugging Face’s SmolVLA model locally. The result shows that robotics tasks combining vision and language, once confined to costly labs, now fit on a 299-dollar board.

Hardware: two processors on one board

The Arduino VENTUNO Q board has a dual nature. On one side sits an SBC system with a Qualcomm Dragonwing IQ8 processor, equipped with an Adreno 623 GPU and a Hexagon Tensor NPU, built for AI processing. On the other side is an STM32H5F5 microcontroller with an Arm Cortex-M33 core running at 250 MHz, which handles real-time servo control. The board offers 16 GB of LPDDR5 RAM and 64 GB of integrated eMMC storage.

The original SO-101 arm carries gearmotors on every joint and two cameras: one fixed overhead and one on the gripper. The images and joint position data go to the Dragonwing IQ8 processor, where the SmolVLA model interprets them. The model was trained with 50 demonstrations of the task of grabbing and moving the rubber ducks.

The SmolVLA model and the system’s numbers

SmolVLA is an open source vision-language-action model from Hugging Face. It processes the camera images and joint data, then produces the commands for the servo motors. All the processing happens locally on the VENTUNO Q board, with no connection to external services. The board costs 299 dollars, against 399 dollars for the Jetson Orin Nano Super Developer Kit, cited as a competitor.

Dmitry Maslov’s system points the way to accessible robotics. What’s more, the fact that the model runs on a commercial board costing less than 300 dollars opens up new scenarios for makers. For anyone who wants to see the project in action, Dmitry Maslov’s video shows the arm grabbing and moving the rubber ducks.

• Arduino VENTUNO Q board with Qualcomm Dragonwing IQ8 processor and STM32H5F5
• Hugging Face SmolVLA model running locally
• 50 demonstrations to train the pick-and-place task
• Two cameras: one overhead and one on the gripper
• 16 GB of LPDDR5 RAM and 64 GB of eMMC storage

For anyone wanting to rebuild the project, the trickiest part is the integration between the SBC side and the microcontroller side of the board. The Dragonwing IQ8 processor runs the model, while the STM32H5F5 controls the servos. Communication between the two sides is essential to synchronise vision with movement.

Source: https://youtu.be/T0frBNASr3M?si=Wf1VPI8SoJ6tr18p

The post SO-101 Robot Arm Meets Arduino VENTUNO Q: Local-AI Pick-and-Place appeared first on Open Electronics.

Infineon Technologies on 1st of October, 2026 officially inaugurated its new backend manufacturing site in Bangkok, Samut Prakan in collaboration with Prime Minister of Thailand, Anutin Charnvirakul and Chief Operations Officer of Infineon Technologies, Alexander Gorski. The purpose of building new site is to strengthens and expanding the company’s global manufacturing footprint while adding capacity for future growth. The new site is located in the heart of Southeast Asia reinforcing Infineon’s ability to server customers worldwide at a time when long-term semiconductor demand continues to grow because of digitalisation, electrification and the energy transition.

Built for future growth, the facility can scale up to five modules, giving Bangkok the potential to become one of Infineon’s largest backend manufacturing sites over time. As a strategic addition to Infineon’s globally diversified manufacturing network, the site complements the ongoing expansion of Infineon’s frontend manufacturing capacities.

“What makes Bangkok such an important addition to our global manufacturing footprint is its unique combination of location and growth potential,” says Alexander Gorski, Chief Operations Officer of Infineon Technologies. “We are establishing a new hub in the heart of Southeast Asia, surrounded by a fast-growing ecosystem and with excellent access to global logistics. This helps us further diversify our manufacturing network across regions and serve our customers with resilient capacity and great flexibility. We have built the Bangkok site with the future in mind. Starting with Module A, the site can grow to up to five modules over time, giving us unique scalability to support future growth.”

“Infineon’s new backend manufacturing site in Bangkok, Samut Prakan, is a strong vote of confidence in Thailand’s future as a leading semiconductor location,” says Anutin Charnvirakul, Prime Minister of Thailand. “Together, we are advancing Thailand’s semiconductor ecosystem, strengthening our role in the global value chain and creating new opportunities and highly skilled jobs for future generations. We welcome Infineon’s long-term engagement and look forward to deepening our cooperation.”

A long-term investment in Thailand’s semiconductor ecosystem

Thailand’s commitment to building a strong semiconductor ecosystem, guided by its national technology strategy, is creating new momentum for advanced manufacturing and technology-driven growth in the region. Thailand offers excellent connections throughout Southeast Asia, proximity to key customer markets and a long-standing semiconductor manufacturing heritage. The Bangkok site builds on local expertise, established partnerships and a highly skilled workforce while contributing to the further development of Thailand’s flourishing semiconductor ecosystem.

The site currently employs around 350 people and is expected to grow to approximately 1,000 employees as the first building (Module A) ramps up. Beyond manufacturing, Infineon supports talent development through collaborations with universities, educational institutions and industry partners.

Expanding capabilities for complex, high-value semiconductor solutions

The Bangkok site combines advanced automation, scalable design and a digital manufacturing backbone to support efficient, stable and high-quality production at scale. Built as a greenfield site, the facility leverages proven expertise from Infineon’s established backend manufacturing locations while providing the flexibility to adapt to evolving customer requirements, new technologies and large production volumes.

Equipped with advanced cleanroom, assembly and test capabilities, all supported by a high level of automation, the Bangkok site covers the full spectrum of semiconductor backend processes as well as wafer test. This unique combination strengthens its role within Infineon’s manufacturing network and enables increasingly complex, high-value semiconductor solutions for applications across the automotive, industrial and energy infrastructure, contributing directly to technologies that drive electrification, energy efficiency and digitalization worldwide.

Sustainability built in from the ground up

The Bangkok site runs on 100 percent green electricity, incorporates water recycling and rainwater collection systems and is equipped with solar modules that generate renewable energy on site. Together, these measures support resource-efficient manufacturing and contribute to Infineon’s strategic priority of continuously reducing its carbon footprint across the entire value chain.

The post Infineon Opens New Bangkok Backend Manufacturing Hub to Expand Semiconductor Capacity appeared first on ELE Times.

Space Forge Inc (which, as a branch of Space Forge Ltd of Cardiff, Wales, UK, operates from Florida’s Space Coast) says that its ‘Microgravity Semiconductor Manufacturing: Enabling Extreme Performance Electronics’ solution has achieved ‘Awardable’ status through the US Defense Advanced Research Projects Agency (DARPA) Expedited Research Innovation System (ERIS) Marketplace...

​Moving to advance technology in electric vehicle, Delta Electronics and NVIDIA Hyperion have partnered to accelerate the development of next-generation autonomous-driving systems. The collaboration was announced on September 29, 2026, via a press release in Fremont, California, USA by Delta Electronics. The partnership aims to deliver more advanced, safer, and efficient next-generation Level 4 autonomous vehicles and robotaxis.

The company did not announce any commercial products to be launched. However, the collaboration focuses on introducing integrated automotive solutions by embedding Delta’s core hardware technologies directly into the NVIDIA Hyperion architecture.

Delta Electronics will contribute electronics hardware and integration expertise covering automotive energy management, xEV powertrain systems, power electronics, system integration, and in-vehicle high-performance computing (HPC). These technologies are crucial for autonomous vehicles because advanced systems depend not only on AI-based perception and decision-making but also on a reliable power supply, vehicle computing, and the integration of multiple electronic components.

To provide reference sensor and computing platform, NVIDIA Hyperion is d​eveloped and introduced as a modular architecture and end-to-end platform that integrate computer hardware, multimodal sensor and safety software into a single unit for autonomous vehicles.

The specific roles of this platform include integrating dual NVIDIA DRIVE AGX Thor centralised computers for handling level 4 autonomous driving tasks, a standardised sensor architecture for achieving full 360-degree environmental perception, and the NVIDIA Halos safety system, which offers safety mechanisms that satisfy automotive safety standards, including ISO 26262 ASIL-D requirements.

The collaboration highlights the efforts toward​s advancing AI-driven autonomous-driving solutions and expanding opportunities in smart mobility. It demonstrates the further steps towards merging AI, high-performance in-vehicle computing, automotive power electronics, sensor system, and functional safety in the development of level 4 autonomous vehicle.

The post Delta Electronics and NVIDIA Hyperion to Jointly Advance Level 4 Autonomous Driving appeared first on ELE Times.