Feed aggregator

A TrueTime XL-AK GPS time server from 1995 is back at work, but with a new heart. The project replaces the original electronics with a Raspberry Pi 5 and a GNSS HAT, and the result is a stratum 1 NTP server for the local network. The enclosure, the 16×2 LCD display and the bicolour LED are still the ones from thirty years ago.

The board was purchased in June and received on 22 June. Sixteen days later, a similar GPS time server caused a 12-hour cellular service outage in Australia. An episode that shows how widespread these instruments were, and how much they still matter, even when they stop working.

The Raspberry Pi 5 and the GNSS module

The Raspberry Pi 5 runs Pi OS Lite and communicates with the u-blox NEO-M9N GNSS module through the GNSS HAT. The HAT software creates a bridge to transfer the NMEA sentences, which carry date and time, to gpsd and chrony. It also provides a PPS signal for precise timing.

You can also use a Raspberry Pi 5 with 1GB of RAM, at a cost of 44 dollars. The version used in the project has 4GB, but the difference is not in the memory: it is in clock stability and thermal management, which here matter more than anything else.

Configuring chrony and PPS

Chrony is configured to use the PPS refclock as the preferred source and the SHM refclock, which comes from gpsd, as a reference. The configuration includes an offset of 0.0 and a delay of 0.05 for the SHM. The PPS refclock is set with poll 3 and filter 16.

For maximum precision, the system was pushed on the clock parameters. Here are the main values of the chrony configuration:

• maxclockerror set to 0.5
• maxupdateskew 100.0 and makestep 1000 3
• maxchange 0.1 1 -1 to limit sudden corrections

Thermal stability is another key point. The Raspberry Pi is configured with force_turbo, which draws about 1W more continuously, and with a fan running at a constant duty cycle. The fan is set to 50% duty cycle to reduce noise, while 75% offers slightly better performance. Thermal insulation was also added.

The original LCD display and bicolour LED are driven by the Raspberry Pi to show the server status. The LED, for example, indicates the GPS status. The NTP server then provides time synchronisation services to clients on the local network through chrony.

The project was built with VCF Midwest in mind, an event dedicated to retrocomputing. The video documenting the restoration shows the whole process, from the original board to the working NTP server. Anyone who wants to redo the work will also find the GNSS HAT software and the fan control utility, included in the Time Pi repository.

Source: https://www.youtube.com/watch?v=1T9xQy-dsQo

The post A 1995 GPS Time Server Gets a Raspberry Pi 5 Heart Transplant appeared first on Open Electronics.

There are two major workloads that make up AI compute: training and inference. Training looks back. It digests a frozen body of past text, images and code, and distills it into weights. Inference looks forward. It takes those weights and, one token at a time, produces something that did not exist a moment ago.

Same model, same matrices, same multiply-accumulate at the bottom of it all. Yet the two faces ask the silicon to perform nearly opposite tasks.

Training wants arithmetic, and lots of it. Inference wants bytes delivered on time. Treating them as one market has cost the industry a decade of misplaced benchmarks.

Let’s look at each separately, then at what each requires of the processor running it.

The face that looks back: Training

Training is a loop repeated trillions of times, and every iteration has three stages:

1. Forward pass. A batch of token sequences flows through the neural network. Every layer is a large matrix-matrix multiply (GEMM): each accelerator (a single GPU such as an NVIDIA B300) processes thousands of tokens in parallel, and across the cluster a single training step covers millions. The intermediate results, the activations needed to calculate gradients later, must be kept.
2. Backward pass. The model’s predictions are compared with the true next tokens, yielding a single error score, the loss. Its gradient is then propagated back through the same layers. Each layer computes two more GEMMs: one for the gradient with respect to its input, the other for the gradient with respect to its weights. That is why the backward pass costs roughly twice the forward pass.
3. Optimizer step. Gradients from every replica of the model are averaged across the cluster, then the optimizer, typically Adaptive Moment Estimation (Adam) or a variant such as AdamW, updates every weight.

The arithmetic works out to about six 6 FLOPs per parameter per training token: two forward, four backward. Multiply by tens of billions of parameters and tens of trillions of tokens, and frontier training runs land in the range of 10²⁵ to 10²⁶ FLOPs.

Memory is the second issue. In one common mixed-precision Adam configuration, each parameter can require about 16 bytes of state: a BF16 weight and gradient (2 bytes each), an FP32 master weight (4), and two FP32 optimizer moments (4 each). A 70-billion-parameter model therefore needs about 1.1 terabyte (TB) before a single activation is stored. No single device holds that. Training is, by construction, a distributed problem.

A key feature of training is batching. Processing many tokens together lets the processor reuse model weights across a large amount of computation, raising arithmetic intensity—the number of FLOPs performed per byte moved. The large matrix operations that dominate much of training can therefore make effective use of compute throughput. Adding chips can increase training capacity and speed, but the gains depend on how quickly they exchange data and synchronize their work.

The face that looks forward: Inference

Inference omits the backward pass and the optimizer. For the main dense linear operations, a forward pass takes roughly two FLOPs per parameter per token, a third of training. That makes it sound like a lighter version of the same job. It is not. Look closer and inference has two faces of its own.

Prefill processes the prompt. All input tokens are known in advance, so they move through the network in parallel, as GEMMs. A sufficiently large prompt or batch can make its matrix operations compute intensive, making prefill resemble a forward training pass: compute-bound, high arithmetic intensity. Along the way, the model writes the keys and values of every token, in every layer, into the key-value (KV) cache that later tokens will use for attention. Prefill strongly affects time to first token.

Decode generates the answer, one token at a time. Each new token cannot be selected until the preceding step is complete, so there is nothing to parallelize along the sequence. Every layer collapses into a matrix-vector multiply (GEMV), reusing weights across relatively little work. To produce one token, the processor must stream all the weights and the entire KV cache for that sequence out of memory and start over.

Weight and cache traffic then dominate the time spent generating each token.

That is the crux. A current flagship accelerator can perform several hundred FLOPs in the time it moves one byte from high-bandwidth memory (HBM). Decode at small batch sizes supplies only one or two FLOPs per byte: each weight is fetched, used in a single multiply-add, and discarded. Meanwhile, the compute units are idle, waiting on memory.

Decode is memory-bandwidth bound, and in agentic workloads with long outputs, decode can reach around 90% of wall-clock time. At larger batches, weight reuse improves and the balance can shift, though not for the KV cache, which each sequence reads in full. Long generated answers can make decode dominate a request’s end-to-end time, but the share depends on prompt length, output length, batch size, and serving system. See block diagram below.

In a large language model (LLM) inference workflow, prefill processes the prompt in parallel and writes the KV cache in one pass; decode generates one token at a time, reading the full cache on every step. The time split is illustrative. Source: VSORA

The KV cache adds another constraint as context grows. In each layer, every cached token contributes a key and a value for each KV head. Assuming the full context remains resident at a fixed precision, the cache size per sequence is:

KV bytes = 2 x L x Hkv x dhead x S x b

Whereas L represents layers, H_kv key-value heads, d_head head dimension, S sequence length, and b bytes per element. For a Llama-3-70B-class model (80 layers, 8 KV heads, head dimension 128, BF16) that is about 320 KB per token.

At a 128k-token context, one conversation holds roughly 42 GB of cache, more than half a model’s worth of weights at FP8, for a single user.

Three workloads, side by side

Prefill sits closer to training than to decode. The real divide runs between batched, parallel math and sequential, memory-starved math, as shown in the table below.

What training asks of the silicon

A training processor is judged by how much of its rated arithmetic it turns into useful work across an entire cluster. Five pressures shape it:

1. Dense matrix throughput. Tensor or systolic arrays sized for large GEMMs fed from on-chip SRAM with enough reuse to stay busy. This is the ground where peak TFLOPS on the datasheet actually mean something.
2. Memory capacity, not only bandwidth. Weights, gradients, optimizer states, and activations must sit close to the compute. HBM stacks per package keep growing for this reason, and activation recomputation trades FLOPs for bytes when they don’t fit.
3. Every step ends with a gradient all-reduce, and tensor or pipeline parallelism adds traffic inside each layer. Scale-up links (NVLink-class) and scale-out fabrics (InfiniBand or Ethernet) often decide utilization more than the cores do. A cluster that spends 40% of each step waiting on collectives has thrown away 40% of its silicon.
4. Gradients span a huge dynamic range. BF16 won because it keeps FP32’s 8-bit exponent; FP16 needed loss scaling to avoid underflow. FP8 training works, but only with per-tensor or per-block scaling and a high-precision master copy of the weights.
5. Reliability at scale. A run on tens of thousands of chips for weeks will see failures. So, checkpointing, fast restart, and silent-data-corruption detection become architectural features, not operational afterthoughts.

Training has no user waiting for the next token, but time still matters: a stalled step delays the entire run. Sustained throughput, utilization, and time to completion are the measures that count.

What inference asks of the silicon

An inference processor is judged by cost and energy per token delivered within a latency target. That changes the priorities almost completely.

1. Bandwidth per FLOP. Decode throughput is set by how fast weights and KV cache reach the arithmetic units. A chip with half the TFLOPS and twice the effective bandwidth can win outright. This is the memory wall, and it’s where rated peak and sustained performance part ways.
2. KV cache capacity and management. The cache, not the model, becomes the binding constraint on how many users a chip serves at long context. Paging, compression, quantizing the cache itself, and offloading to cheaper tiers are now first-order design problems.
3. The batching dilemma. Batching many users together restores arithmetic intensity, because weights are fetched once and reused across requests. But every user in the batch waits for the slowest step. Operators trade throughput against per-user latency, and the hardware must make that trade cheap: fine-grained scheduling, continuous batching, and fast context switches.
4. Aggressive precision. Inference tolerates far lower precision than training. FP8 is routine, FP4 and INT4 weights are increasingly common, and each halving of bits nearly doubles effective bandwidth. The processor must execute these formats natively, with scaling factors handled in hardware.
5. Energy and TCO. Training is a capital expense paid once per model. Inference is an operating expense paid on every token, for the life of the product. Watts per token, not peak watts, determine which company makes money.
6. Utilization and predictability. Request lengths vary wildly, and traffic is bursty. Deterministic, well-scheduled architectures keep the pipeline full; architectures tuned for large uniform GEMMs spend much of decode underused.

Prefill complicates the picture: it’s compute-bound, like training, and it sets time to first token. A good inference chip must handle both regimes, even if decode dominates the bill.

Can one chip wear both faces?

The GPU’s answer has been yes. It’s a superb training engine, and its software ecosystem made it the default for inference too. But a die sized for training GEMMs carries a large compute budget that decode cannot use. At batch sizes that keep latency acceptable, much of that silicon sits idle while HBM does the real work. You Engineers pay for both faces and use one.

The industry is responding on three fronts:

1. Specialized inference silicon. Designs that raise bandwidth per FLOP by putting far more memory close to compute: SRAM-heavy dataflow chips, wafer-scale parts, multi-tier memory hierarchies, and architectures built around sustained rather than peak efficiency. Each trades differently between capacity and bandwidth, and each hits a different cliff when models or contexts outgrow their fast memory.
2. Disaggregated serving. Split prefill and decode onto different pools of hardware, each sized for its own bottleneck, and ship the KV cache between them. This admits openly that inference itself is two workloads.
3. Software that closes the gap. Speculative decoding, which lets a small model draft tokens that the big one verifies in a single batched pass, turns part of decode back into prefill-like math. Quantization and cache compression shrink the bytes to move.

None of this makes the GPU obsolete for training. It does end the assumption that the best training chip is automatically the best inference chip.

Choosing which face to serve

For 10 years, AI hardware was built for the face that looks back. Training was where the prestige was, and peak TFLOPS was the number on the slide. That made sense when models were trained often and served rarely.

The ratio has flipped. A frontier model is trained once and then queried billions of times, increasingly by agents that read long contexts and think out loud before answering. The economics of AI now live in the forward-looking face, and that face is starved for bytes, not FLOPs.

The challenge for processor architects is to deliver tokens economically within a latency target while still handling the bursts of parallel computation that begin each request.

Lauro Rizzatti is a business development executive with VSORA, a technology company offering silicon semiconductor solutions that redefine performance. He is a noted chip design verification consultant and industry expert on hardware emulation.

Related Content

• Chiplets Are The New Baseline for AI Inference Chips
• The next AI frontier: AI inference for less than $0.002 per query
• Purpose-built AI inference architecture: Reengineering compute design
• As AI Moves from Training to Inference, Optics Moves Closer to the Chip
• The truth about AI inference costs: Why cost-per-token isn’t what it seems

The post Training and inference: Two faces of AI compute appeared first on EDN.

Gallium nitride (GaN) power IC and silicon carbide (SiC) technology firm Navitas Semiconductor Corp of Torrance, CA, USA has completed its acquisition (announced on 25 August) of power management solutions company Claros Inc — which is developing integrated voltage regulator (IVR) technology for next-generation AI data centers — providing the last step to powering the xPU...

🎥 Всеукраїнський круглий стіл «Штучний інтелект як об’єкт судово-експертного дослідження: проблемні питання та шляхи їх вирішення» kpi ср, 10/07/2026 - 11:55

Qorvo Inc of Greensboro, NC, USA (which provides core technologies and RF solutions for mobile, infrastructure and defense applications) has announced a C-band radar solution that adds receiver frequency agility and reduces DC power and heat in the transmit chain. Designed for pulsed ESA (electronically scanned array) systems, the solution combines what is reckoned to be the industry’s first integrated C-band bulk acoustic wave (BAW)-switched filter bank with high-efficiency 50W and 200W gallium nitride GaN power amplifiers (PAs)...

Seeed Studio has introduced two new XIAO Plus development boards, the XIAO SAMD21 Plus and the XIAO RP2040 Plus, which address the main trade-off of the XIAO boards: the limited number of pins. The new versions offer up to 30 GPIO pins, compared to the 14 on the originals, while keeping the same 21 × 17.8 mm footprint. In addition, they integrate a PMIC for Li-ion battery management, making them suitable for advanced embedded projects and battery-powered devices.

Additional pins via SMD castellated pads

The XIAO Plus boards keep the dimensions and the 2.54 mm pin header layout of the other XIAO boards. The additional connections are exposed through SMD castellated pads with a 1.27 mm pitch on the back. This design allows the board to be soldered directly onto a custom PCB, like a true System-on-Module. So, anyone designing a compact device can use the full computing power without taking up extra space.

The XIAO SAMD21 Plus has 30 GPIO pins, including 27 digital pins, 11 analog inputs, two I2C interfaces, UART, SPI, I2S and a DAC. The XIAO RP2040 Plus has 29 GPIO pins, with 26 digital pins, four analog inputs, two I2C interfaces, UART, SPI and up to 26 PWM outputs. Both double the capabilities of the previous versions, which stopped at 14 pins, without increasing the board size.

PMIC and Li-ion battery management

Both boards include a PMIC that allows a Li-ion battery to be connected directly for integrated charging and protection against current backflow. The XIAO RP2040 Plus adds a battery monitoring circuit that can be enabled via software through GPIO24, to measure the voltage through the ADC on GPIO29. This feature is designed for those developing portable devices who want to know the state of charge in real time.

The XIAO SAMD21 Plus, on the other hand, adds a programmable WS2812 RGB LED and dedicated Reset and Boot buttons. These elements make debugging and programming easier without having to solder additional pins. Support for multiple development environments, including Arduino, MicroPython, CircuitPython, TinyGo, Rust and Zephyr, makes the boards flexible for different levels of experience.

Prices and compatibility with existing projects

The new boards cost $5.90 for the XIAO SAMD21 Plus and $4.90 for the XIAO RP2040 Plus, respectively. Despite the increase in pins, the footprint remains identical to the other XIAO boards, so existing projects can be upgraded without mechanical changes. For those starting from scratch, the maker’s website offers guides and ideas on how to get the most out of these boards.

These boards are particularly useful for those who want to move from breadboard prototyping to small-batch production. The SMD castellated pads allow the board to be soldered as a module onto a custom PCB, reducing development time. Furthermore, the presence of the PMIC eliminates the need for external charging modules, simplifying the overall design.

For those looking for a board with more pins and integrated battery management, the XIAO Plus boards represent a compact and economical solution. The maker’s website collects examples and documentation to get started right away.

Source: https://www.seeedstudio.com/Seeed-Studio-XIAO-RP2040-Plus-p-6932.html

The post XIAO Plus: More Pins Without Changing the Footprint appeared first on Open Electronics.

Qorvo Inc of Greensboro, NC, USA (which provides core technologies and RF solutions for mobile, infrastructure and defense applications) has announced an X-band RF front-end solution that combines high transmit output with low-noise, high-linearity receive performance for active electronically scanned array (AESA) radar. Developed around a quad architecture, the solution reduces RF content inside the array lattice...

Infineon Technologies AG has introduced the TRAVEOTM CYT4EN, a new microcontroller (MCU) for cost-effective high-performance instrument clusters and display applications in the automotive industry, including two-wheelers. The automotive cluster MCU is designed to leverage external LPDDR4 memory, resulting in capabilities that traditionally required more complex SoC (System-on-chip)-based platforms: The device supports advanced 2.5D graphics and 3D scene rendering, drives high-resolution displays up to Full HD, and can power two displays simultaneously. At the same time, it reduces system complexity and the bill of materials compared to SoC-based platforms.

“Cutting-edge cluster and display solutions are playing a central role for the user experience in connected and software-defined vehicles,” said Thomas Boehm, Senior Vice President Automotive Microcontrollers at Infineon. “With TRAVEO T2G CYT4EN, we are helping our customers bring them to market more quickly, efficiently and cost-effectively. By combining the simplicity, safety, and fast responsiveness of an MCU architecture with the high-bandwidth memory required for modern cockpit graphics, we are enabling a new generation of vehicle displays.”

While developing CYT4EN, Infineon collaborated closely with Micron to optimize the memory subsystem for the use of LPDDR4 memory to support advanced graphic capabilities while maintaining overall system efficiency.

“Micron’s automotive LPDDR4 memory provides a proven combination of bandwidth, reliability, and functional safety features for cost-optimized cockpit platforms,” said Amanda Henderson, Director of Ecosystem Enablement at Micron. “For vehicle programs where affordability, longevity, and functional safety are key requirements, LPDDR4 remains an effective solution for delivering modern display experiences.”

Built on the proven TRAVEO T2G architecture, the CYT4EN combines high-performance processing, advanced graphics, and automotive-grade safety and security in a highly integrated device. It includes features such as on-the-fly rendering and hardware-accelerated decompression to enable a rich graphical user experience. The device delivers deterministic boot times below 150 milliseconds that are significantly shorter than the multi-second initialization common to complex SoC platforms. It supports functional safety up to ASIL-B according to ISO 26262 and was developed in accordance with ISO 21434 for automotive cybersecurity. In addition, an independent voltage domain keeps central system functions such as communication and basic processing active in low-power modes, improving system efficiency and robustness.

The high level of integration enables cost-effective smart cockpit designs without complex system implementations. For example, CYT4EN allows designs without additional microcontrollers for system management and in-vehicle network communication, enables simplified PCB layouts with as few as six layers, and avoids the need for active cooling thanks to optimized power efficiency.

The post Infineon brings advanced cockpit graphics to cost-efficient microcontroller architectures with TRAVEO T2G CYT4EN appeared first on ELE Times.

Keysight Technologies has collaborated with the University of Glasgow, the National Physical Laboratory (NPL), and MPI Corporation to develop a new approach to broadband characterization of next-generation sub-terahertz (sub-THz) semiconductor devices. Together, the organizations demonstrated continuous on-wafer characterization of indium phosphide high-electron-mobility transistors (InP HEMTs) from near DC to 250 GHz in a single sweep, simplifying broadband measurements for advanced semiconductor research and design.

As semiconductor technologies move into millimeter-wave and sub-terahertz frequencies for next-generation applications, engineers need to accurately characterize transistor performance across increasingly broad frequency ranges. Conventional approaches can require multiple measurement setups and calibrations, adding complexity and making it more difficult to obtain consistent data for broadband device modeling.

The four organizations combined Keysight instrumentation, University of Glasgow semiconductor devices, MPI Corporation on wafer probing technology, and NPL metrology expertise to create the broadband measurement solution. The setup brought together:

• Keysight’s PNA-X Vector Network Analyzer
• Keysight’s Single-Sweep 250 GHz Frequency Extender
• Keysight’s Precision Source/Measure Unit (SMU)
• University of Glasgow’s InP HEMT devices and on-wafer calibration standards
• MPI Corporation’s broadband on-wafer probing technology and calibration software
• NPL’s high-frequency metrology and calibration methodologies

Together, these technologies enabled continuous measurement from near DC to 250 GHz with a single probe touchdown, eliminating the need for multiple setup changes and providing consistent broadband S-parameter measurements. Built-in source filtering and broadband source power calibration also helped ensure signal purity of the applied millimeter-wave signal at the probe-tip.

Thierry Locquette, VP of Sales, Europe, Middle East & Africa at Keysight said: “Characterizing devices continuously from near DC to 250 GHz in a single sweep can significantly simplify the measurement process for researchers developing next generation semiconductor technologies. By bringing together expertise in instrumentation, devices, probing, and metrology, this collaboration demonstrates a practical approach to generating the consistent broadband data engineers need to accelerate device development.”

Dr Xiaobang Shang, Principal Scientist and On-wafer Measurement Lead at NPL, said: “Accurate on-wafer measurement is essential for developing reliable semiconductor devices, particularly as technologies move further into the millimetre-wave and sub-terahertz frequency ranges. We were pleased to contribute NPL’s high-frequency on-wafer metrology and calibration expertise to this collaboration, helping demonstrate a practical route to consistent broadband device measurements using the state-of-the-art single sweep system.”

Matthew White, Director of Business Development at MPI Corporation, said: “Extending on-wafer characterization to 250 GHz requires the probing, calibration, and measurement platform operating as one seamlessly integrated system. This collaboration demonstrates a practical approach to achieving consistent broadband measurements from near DC to 250 GHz with a single probe touchdown, helping researchers simplify characterization and accelerate device development with great confidence.”

The post Keysight and Research Institutions Simplify Testing of Next- Generation Semiconductor Devices appeared first on ELE Times.

Infineon Technologies today announced the completion of its acquisition of C2i Semiconductors, a Bengaluru-based technology company specialising in software-defined multiphase controllers and smart power stages for AI data centre applications. C2i Semiconductors’ technology complements Infineon’s leading portfolio of power semiconductors and power systems, enabling intelligent and scalable power delivery architectures from grid to core for AI servers and high-performance computing platforms. The acquisition further strengthens Infineon’s leadership in power solutions for AI data centres, expands its engineering capabilities in India and reinforces the country’s role as a strategic innovation hub. With the completion of the transaction, the C2i Semiconductors team becomes part of Infineon’s Power Systems division.

“Completing this acquisition marks an important milestone for our AI power business and our innovation activities in India,” said Adam White, President of Infineon’s Power Systems division. “C2i Semiconductors brings exceptional expertise in software-defined power management and system-level power architectures, backed by a highly experienced engineering team. By combining these capabilities with Infineon’s semiconductor technologies, application know-how, manufacturing capabilities and global customer reach, we will accelerate innovation in power delivery solutions for AI data centres and create significant value for our customers. I am delighted to welcome the C2i team to Infineon.”

Software-defined power solutions combine advanced power semiconductors with intelligent digital control and software algorithms to optimise power conversion, regulation and system performance in real time. As increasingly powerful AI processors create highly dynamic and rapidly changing power demands, power delivery systems must respond faster and more precisely to sudden load fluctuations while maintaining efficiency and system stability. By adding intelligence to the power delivery architecture, software-defined solutions can help improve efficiency, reduce power losses and support the increasing power density requirements of next-generation AI processors.

The acquisition combines C2i Semiconductors’ digital power expertise with Infineon’s global scale, application know-how and broad portfolio of power semiconductors, including silicon, silicon carbide (SiC) and gallium nitride (GaN) technologies, as well as vertical power delivery solutions. Together, the teams will accelerate the development of more intelligent, efficient and scalable power delivery solutions for AI infrastructure, including future Substrate Integrated Voltage Regulators (SIVR).

C2i Semiconductors adds expertise in software-defined power management, multiphase controllers, smart power stages, digital control technologies and system-level power architectures. The combination strengthens Infineon’s capabilities across the entire power path from grid to core and supports the development of next-generation power solutions for AI servers and high-performance computing platforms.

The acquisition also adds highly specialised engineering expertise to Infineon’s global R&D network and further strengthens its innovation capabilities in India. The combined team will contribute to reinforcing Bengaluru’s role as an important innovation location for digital power technologies and to accelerating the development of next-generation power solutions for AI infrastructure. Infineon currently employs approximately 2,800 people across multiple locations in India.

The post Infineon completes acquisition of C2i Semiconductors to expand innovation capabilities in AI data centre power management solutions appeared first on ELE Times.

Skyworks Solutions Inc of Irvine, CA, USA has announced the completion of its combination with Qorvo Inc of Greensboro, NC, USA, creating a US-based provider of high-performance radio frequency (RF), power management, and analog and mixed-signal semiconductor solutions...

Професорів КПІ ім. Ігоря Сікорського відзначено державними нагородами з нагоди Дня працівників освіти kpi вт, 10/06/2026 - 22:31

Renesas Electronics Corp of Tokyo, Japan has expanded its gallium nitride (GaN) portfolio into low-voltage applications with its first family of 100V enhancement-mode (E-mode) GaN-based discrete power transistors. The RTP100E005G1FL, RTP100E2P6G1FL, RTP100E1P8G1FL-DSC and RTP100E1P2G1FL-DSC low-voltage GaN FETs are said to deliver ultra-fast switching speeds and enhanced thermal performance in efficiency-critical, high-power-density applications, including AI data centers, humanoid robotics, factory automation and industrial motor drives, power tools and solar micro-inverters...

A portable square wave generator covering from 2 Hz to about 33.5 MHz, with adjustment steps of 2 Hz. The heart of the project is an AVR16EB28 microcontroller, which handles both signal generation and the user interface. Power is supplied by a LiPo battery, while an OLED display, rotary encoder, and push-button keypad provide full control. The project is by David Johnson-Davies, known for his experiments with AVR microcontrollers.

The frequency is set with precision, and the reading appears on the OLED display. The rotary encoder allows rapid variations, while the keypad is used to enter exact values. The whole thing fits in a compact enclosure, suitable for the workbench or the field. The 2 Hz resolution across the entire range is remarkable, and makes the device useful for testing audio circuits, filters, and timing.

Circuit and control with AVR16EB28

The schematic is simple: the AVR16EB28 microcontroller generates the square wave directly from a pin, with the frequency calculated in software. Control is via an OLED display, rotary encoder, and push-button keypad. The LiPo battery powers the whole system, with a regulator for a stable voltage. The project is designed to be replicated with easily available components.

The firmware handles the 2 Hz steps and updates the display in real time. In addition, the rotary encoder allows scrolling through frequencies smoothly, while the keypad allows direct entry of a value. The code is available on the maker’s website, and includes libraries for the display and encoder. The result is a stable and repeatable device.

Construction, power, and practical use

Construction requires a PCB, which can be made with a milling machine or through an external service. Assembly is within reach of those with SMD soldering experience, since the microcontroller is in a surface-mount package. The LiPo battery connects on the back, and the front panel hosts the display, encoder, and keypad. The whole thing is compact and easily portable.

For power, a 3.7 V LiPo battery is sufficient, with a voltage regulator for the 3.3 V of the microcontroller. Consumption is low, thanks to the OLED display and efficient sleep management. Practical use is immediate: turn it on, select the frequency, and connect the output to the circuit under test. The precision of the 2 Hz steps makes it suitable even for fine adjustments.

David Johnson-Davies’s website hosts the source code and construction details. Those who want to go deeper can consult the complete documentation, including schematics and assembly photos. The project demonstrates how a modern AVR microcontroller can generate high-frequency signals with precision, without complex external components. An elegant solution for those seeking a reliable square wave generator.

In summary, this square wave generator offers a wide range and fine resolution, all in a portable format. The choice of an AVR16EB28 ensures programming simplicity and low cost. The OLED display and manual controls make it intuitive to use, even for those unfamiliar with professional instruments. A project worth replicating.

Source: http://www.technoblogy.com/show?5QE2

The post Square Wave Generator from 2 Hz to 33.5 MHz with AVR16EB28 appeared first on Open Electronics.

As AI data centers scale to support high-power GPU clusters, the industry is shifting toward 800V DC rack power architectures to improve distribution efficiency, increase power density and support next-generation server designs. To help accelerate this transition, Microchip Technology and Navitas Semiconductor (Nasdaq: NVTS) have collaborated on an 800V DC-to-6V DC reference design for AI data center rack power applications.

The platform combines Microchip’s digital power control and security technologies with Navitas’ GaNFast gallium nitride (GaN) power devices to give developers a practical path to implement high-efficiency power conversion aligned with the Open Compute Project (OCP) 800V DC standard. Complete with reference hardware, software and design documentation, the solution helps reduce design risk, shorten development cycles and accelerate deployment of next-generation AI infrastructure.

“AI infrastructure optimization is driving one of the most significant power architecture transitions the data center industry has experienced in decades,” said Joe Thomsen, corporate vice president of Microchip’s digital signal controller business unit. “As the ecosystem moves toward higher-voltage rack power systems, developers need proven control and security to help reduce implementation risk. Our collaboration with Navitas combines digital control, hardware-based security and advanced GaN power conversion to help customers bring 800V rack power systems to market more quickly.”

At the core of the reference platform are Microchip’s dsPIC33AK Digital Signal Controllers (DSCs) and TA100 CryptoAuthentication security IC, paired with Navitas’ GaNFast FETs. The dsPIC33AK provides deterministic digital power control for high-frequency, high-efficiency DC/DC conversion, while the TA100 helps establish a hardware root of trust for authentication, secure boot and protected firmware updates. Together, these technologies make up the precision control and security foundations required for connected OCP power supply designs. The dsPIC33AK256MPS306 family is powered by a 200 MHz 32-bit core with a double-precision floating-point unit (FPU), 78 ps high-resolution Pulse Width Modulators (PWMs) and multiple 12-bit Analog-to-Digital Converters (ADCs) operating at up to 40 MSPS. The devices include library support for Commercial National Security Algorithm (CNSA) Suite 2.0 recommended post-quantum cryptographic algorithms and hardware-accelerated cryptographic functions for connected real-time control designs.

This PDB is powered by 16 × NV6034, 650 V, 17 mΩ GaNFast FETs in a stacked half-bridge topology on the primary side. The DFN8×8 dual-side-cooled package extends the performance advantages of GaN by reducing thermal resistance, allowing higher continuous power operation while maintaining exceptional efficiency. The PDB targets delivering up to 96% peak efficiency at full load with 1 MHz switching frequency, enabling a power density of 2,100 W/in³.

Approximately 20% thinner than a mobile phone, its ultra-low profile enables extremely close integration with the GPU board, maximizing transient performance and improving power distribution efficiency. Navitas’ system-level approach helps translate advances in GaN technology into measurable improvements in efficiency, power density, transient performance and total cost of ownership. Direct conversion from 800V DC to 6V DC combines both 800V DC to 50V DC and 50V DC to 6V DC conversion stages into one converter, delivering higher end-to-end efficiency.

“As AI infrastructure scales to support increasingly demanding computing platforms, Navitas’ GaNFast technology is a critical enabler of higher power density, greater efficiency and improved system performance,” said Vipin Bothra, vice president of Global Solution Marketing at Navitas Semiconductor. “By combining Navitas’ leadership in power semiconductors with Microchip’s digital control expertise, this collaboration accelerates the delivery of advanced power solutions tailored to the evolving requirements of next-generation AI data centers.”

Hardware-based security is integrated through Microchip’s TA100 CryptoAuthentication IC, enabling developers to establish a trusted foundation for system authentication and protection without implementing these capabilities from scratch. The TA100 device provides support for code authentication, including secure boot, Message Authentication Code (MAC) generation, trusted firmware updates, multiple key management protocols including Transport Layer Security (TLS), and other root-of-trust-based operations.

The Microchip and Navitas reference design provides a platform for developing high-voltage, high-power, compact rack power systems for AI data centers. The design is supported with a reference board, software and documentation, giving developers access to the resources needed to evaluate and accelerate deployment of 800V DC power conversion systems for AI data center applications.

The post The Data Center Is Moving to 800V: Microchip and Navitas Are Enabling the Transition appeared first on ELE Times.

Although this project may be a bit esoteric, the concepts shown to reduce I/O requirements can also be applied to other systems.

I designed a device that has, as part of its function, multiple pipes which are referred to as silos. These silos each have a rod that can be slid in and out of the interior. The task was to detect which silos have the rod inserted in them (occupied), and which do not (empty). For the sake of this discussion, we’ll say there are 10 silos total (Figure 1).

Wow the engineering world with your unique design: Design Ideas Submission Guide

Figure 1 This design detects which of the silos are occupied by rods.

There are many ways to detect if a particular silo is occupied. For various reasons, I opted to go with an optical solution. As you can see in Figure 1, the silos were constructed each with a hole bored in its side, going all the way through. One possible per-silo configuration of an optical solution is to mount an LED on one end of the hole and a phototransistor on the other (Figure 2).

Figure 2 Each silo has a hole bored straight through its side, with a LED mounted on one end and a phototransistor on the other.

To directly connect all these LEDs and phototransistors to a microcontroller, we would need 20 I/O ports; 10 to turn on the LEDs and 10 for the photodetectors. This would be far too many I/O pins to use on a small micro. We could add some kind of port expansion circuit, but there are easier ways to reduce the needed pin count.

Here’s one option: we could simply drive all of the LED from a common port and then scan the phototransistors one-by-one to sense each silo’s occupancy status. This may take an external transistor to drive 10 LEDs, but it’s still very simple. This scenario requires only 11 total I/O ports. But that’s still a lot. Let’s look at a way to reduce the number by a lot more, down to two I/O ports.

First, for the LEDs, let’s use addressable ones. I picked the WS2812B, commonly referred to as a NeoPixel. Each NeoPixel require 5V, GND, and a single data line, and is made up of individually addressable RGB LEDs and a controller that can vary color and brightness (Figure 3).

Figure 3 NeoPixels contain both RGB LEDs and a controller, and can come as a multi-unit strip.

Data is sent to the first NeoPixel in a strip which, if not the intended addressed destination,  forwards it to the next NeoPixel. In this way, one data line can talk to hundreds of NeoPixels. The micro’s data out line is connected to the strip’s DI input. That same data is also output from each NeoPixel’s DO line, which connects to the next NeoPixel’s DI input along with 5V and GND.

Now, for the phototransistors; I used the Everlight PT334-6C. Let’s first connect all the collectors together and ground the emitters. Also, let’s add a single resistor to the collectors and pull it to 5V. The collectors are now all connected to a single digital input line of the micro. When the NeoPixel in any empty silo is turned on, the combined collectors from the phototransistors will drop low; this status can then be read by the micro.

Next, let’s take a look at the schematic, just to be clear on what I’m suggesting (Figure 4).

Figure 4 This schematic summarizes the design techniques covered in the prior few paragraphs.

You can see from Figure 4 that we are now only using two data lines to sense the status of the 10 silos. This number could be 100 silos while still only using two data lines, for that matter. Keep in mind one caveat, however. The phototransistors have some collector leakage (dark current or ICEO). Using a 5V supply, the leakage will be approximately 10 nA at ~40° C ambient temperature. That means that our 10 phototransistors will have a combined leakage of around 100 nA.

Using a 3.3 kΩ pullup resistor means that the dark current will pull the micro’s data line down by about 0.33 mV. This current is low enough that it thankfully will have no effect on the detection of silo status. Even if we had 100 silos, the dark current would still be no more than 1 µA and only drop the data line by ~3 mV. What could have a greater effect is if the rods are not snug in the silos, for example, or the phototransistors are not in a light-tight enclosure. In either case, the resultant ambient light might increase leakage current. Ambient temperature variance from the assumed ~40° C also begs for consideration.

Now let’s look at how the micro uses the two I/O lines to sense the state of the silos. In general, what will be doing is turning on the NeoPixels from the first silo and then checking the state of the digital input from the phototransistors. If it’s low, the phototransistor pulled the line low, indicating that the silo was unoccupied (empty). After that we move to the next silo and repeat the operation, and so on. As in all things, however, there is a bit more necessary detail.

In this project, there was a need to keep the NeoPixel brightness down, since empty silos were visible, and we did not want to be able to see continuously flashing lights. So, in the Arduino C code we used the brightness setting in the NeoPixel library to set it low (brightness can be set from “0”, i.e., off, to “255”, full brightness). You can also set the color of the NeoPixel; I set red, green, and blue to all be on with equal brightness, resulting in the full spectrum of white light.

That all said, the NeoPixel’s brightness setting is not actually a brightness setting. It’s a perceived brightness setting. By setting brightness from 0 to 255 you are actually setting PWMs that are driving the RBG LEDs. So, when you set the brightness to 255, the LEDs are on continuously. When you set it to 50, the LEDs are on for 50/255, or 19.6%, of the time. The LEDs are actually still at full brightness but are perceived to be dimmer. There’s nothing surprising here; this is how LEDs are often dimmed. But, because we a trying to digitally detect this light in the phototransistor, we must take this perceived vs actual deviation into account.

Let’s work the numbers. The WS2812B PWM rate is between 400 and 800 Hz. That means that if it is 800 Hz the PWM sequence executes every:

1/800 = 1.25 ms.

This 1.25 ms is then broken up into 255 steps which means the shortest on-time is:

1.25 ms/255 = 4.9 µs

The 4.9 µs is the pulse width you would see if brightness is set to 1 and it would repeat 800 times per second.

The rise and fall time of the phototransistor is something less than 15 µs. This means we should not use a brightness setting below 4 (giving a 19.6 µs on-time) as we need time for the phototransistor to settle. So, to make sure we sample the phototransistor state fast enough, with this minimum on-time of 19.6 µs, let’s say we should sample every 2 µs. We should also keep scanning for a full PWM cycle which, for the 400 Hz number, is:

1/400 = 2.5 ms

From this information, we decided to test the phototransistor over and over, every 2 µs, and do it 1,250 times.

Now that we have our numbers, let’s look at a portion of the micro code.

#define LIGHT 0 // Used in checking photodetectors #define LedScanDelay 20 // Microseconds delay when moving to a new silo #define NumTestLoops 1250 #define TestLoopDelay 2 // Microseconds SiloScanLeds.setBrightness(5); // Set the brightness for (uint8_t n = 0; n < NUM_OF_SILOS; n++) { SiloScanLeds.setPixelColor(n, WHITE); // Turn on silo LED[n] for sensing SiloScanLeds.show(); // Update the silo LEDs delayMicroseconds(LedScanDelay); // Do a slight delay for system to settle siloStatus[n] = occupied; // Initialize flag before test for (uint16_t i = 0; i < NumTestLoops; i++) { // Run a number of tests on silo n if (digitalRead(DETECT_PIN) == LIGHT) { // Check phototransistor voltage to see if light is detected siloStatus[n] = empty; // Mark silo as not occupied } delayMicroseconds(TestLoopDelay); } SiloScanLeds.setPixelColor(n, BLACK); // Turn off silo LED[n] SiloScanLeds.show(); delayMicroseconds(LedScanDelay); }

As you can see, the code loops through all the silos, and at each silo it executes 1,250 checks of the phototransistors’ status, which takes 2.5 ms. The appropriate delay is also applied after each check. If any one of the 1,250 phototransistors’ tests shows a digital low, the light has been detected and therefore the silo is tagged as empty.

After this, a 20 µs delay is applied to allow for the rise time of the phototransistor if a low was detected. Then, the outer loop changes to the next silo and starts a new set of tests. We call this code around every 500 ms to update the status of the silos. Using the brightness setting of 5 works well in the actual device. It has never failed a detection and appears very dim when looking down an empty silo.

Although this silo and rod project may be a bit of an esoteric design, the concepts shown to reduce the I/O requirements in an optical detection system can also be applied to other systems. Keep them your back pocket for consideration in future projects! For more information on NeoPixels, see a previously Design Idea in the Related Content section.

Damian Bonicatto is a consulting engineer with decades of experience in embedded hardware, firmware, and system design. He holds over 30 patents.

Phoenix Bonicatto is a freelance writer.

Related Content

• A simple, full color upgrade for your LED indicators

The post Reducing I/O requirements for optical detection appeared first on EDN.

​AI is leaving the question-answering and content-generation stage. The frontier of the next generation of AI is agentic AI. That’s an AI that perceives an objective, reasons about the problem by planning, compares multi-step plans, accesses external tools, and acts independently without a human operator. Moving from a stand-alone question-answering bot that responds to a prompt to an agent to execute a task means asking enterprise data stories, working with platforms, running workflows, testing and accessing outputs, and changing the data. By 2026, enterprises will shift from publishing generative AI experiments and exploration to launching agentic workflows-connecting foundation models to enterprise data, programs, and operations.

What Is Agentic AI?

Agentic AI is the type of AI that is trying to obtain a goal and perform a multi-step task on its own. Rather than requiring someone to make every decision for it, an agent can decompose a goal, develop a plan to attack it, determine what tools are going to be needed, do the work, and evaluate the results. A traditional AI assistant, for instance, might answer a question about whether a customer’s order is ready. An agentic AI would be able to retrieve the order details, identify that the order is held up, tap into the source system, compose an updated message to the customer, and create a case for escalation to a human customer support representative when necessary.

How Does Agentic AI Work?

So, in essence, it’s just a perception, reasoning, planning, and acting loop: A goal or task is communicated or perceived by the agent; the agent gathers data from the environment (databases, files, APIs, enterprise applications, API or other connected systems); the agent reasons with its AI model and takes actions. The agent further decomposes the goal into intermediate, achievable steps (if needed) through a set of tools that it gathers. If the step wasn’t completed successfully or if the conditions change, the agent updates the plan and repeats. Put simply, the working process of an agentic automation is something like goals, perception, reasoning, planning, tool use, action, evaluation, next action. This continuous agentic loop is what sets agentic AI apart from automation that relies on us anticipating all potential options and expressing every possible path in advance.

Agentic AI Architecture and Its Components

The architecture of a production-grade agentic AI system contains multiple layers. The first layer, that of the agents themselves, can include an AI model, such as a large language model or other foundation model that can comprehend instructions, assess context, apply reasoning, and figure out what actions can be taken. Businesses can choose various models, based on a task’s complexity, latency, cost, privacy needs, or safety. But the model is just the start of a good agentic system.

An orchestrator controls how the agent will go about completing a task. An orchestrator can decide the order of operations, control context, route information, coordinate tool calls, and manage multiple specialised agents working together. This is especially critical when an enterprise task involves multiple steps and multiple agents or multiple AI agents working together. An orchestrator offers the structure around model logic and allows organisations to manage agent-to-business system interactions.

Tools and APIs supply the AGI agent with the ability to act. A tool might be a database, enterprise search engine, API, CRM, and ERP systems, software development environment, code execution platform, communication channel, or almost any enterprise system. Without the ability to access the tools, the basic AI model is capable of modifying or creating data. With the ability to do so within a closed environment, the agent can access data and perform the appropriate activities.

Knowledge and grounding are another aspect of architecture to consider. It’s not wise to depend solely on the information within a foundation model; that’s when your enterprise agents need factually accurate and pertinent knowledge. Retrieval augmented generation, enterprise knowledge bases, semantic search, structured data, and application data can all supply this context, grounding an agent in enterprise information and decreasing the potential for generating contradictory outputs.

Memory and context enable an agent to remember information during a task or conversation, depending on your implementation. Short-term memory can give the agent a sense of how a current conversation or task is proceeding, and long term memory might contain information that will be useful for some future task. However, be cautious when considering memories in the enterprise; agents will have access to private data regarding customers, financial data, operations, and employees.

Security and governance are another critical architecture level. An autonomous system that has business systems and skills to act must be granted the right. An agent’s authority and role-based access control, the principle of least privilege, the ability to be audited, observability, and monitoring, policies, human-in-the-loop, and safety guardrails reduce the likelihood of an agent taking an unauthorised action. As enterprise AI becomes ever more autonomous, it is becoming an architectural requirement.

What Are Agentic Workflows?

Agentic workflows are flexible sequences in which agents think, plan, carry out multiple steps, assess results, and adapt appropriately. For example, at an IT-support desk, an agent could not only give instructions on how to fix an employee’s malfunctioning app but could also diagnose the issue, survey the computer’s activity logs, review recent changes to its settings, identify likely causes, offer a fix, and- with permission- carry out the fix. The agent could check whether the app’s restored to normal.

In a higher-level workflow, there may be a team of agents; one particular expert agent may go through the technical solution, another cybersecurity agent may look into potential security issues, and another could look at the solution details prior to the ultimate actions being approved. This is the multi-agent system and allows an organisation to distribute many complex workflow jobs over a number of specialist AI agents while maintaining overall control.

Enterprise Use Cases of Agentic AI

The scope of enterprise agentic AI use cases is growing fast. In customer service, for instance, agentic AI can help employees by classifying support requests, loading customer information, troubleshooting frequent issues, generating responses, recording updates, and escalating sophisticated cases to human agents. This doesn’t mean, however, that they will replace human support teams. Instead, they can automate mundane workflows and free employees to focus on more nuanced, human interactions.

An additional significant domain is software development. In agentic coding systems, AI could possibly investigate and alter web pages, generate or suggest code, run and review code, test and examine bugs, and suggest or make fixes. This is a shift from AI as a coding assistant that shows code snippets to AI programs that can perform many stages of the software development process.

Agentic Automation in security: Security is a good fit for agentic work because you wouldn’t want a security team to look at lots of alerts and aggregation points. The agents can track activity, investigate anomalies, link information, recognize attacks, specify a response, and in certain cases take predefined remediation actions. But for high-consequence actions, they need to have limited authority, be approved, audited, and reviewed by humans.

Enterprise AI agents can also perform document analysis, fraud investigations, compliance processing, customer service, research, and any other enterprise activity involving a large set of business data. For example, supply-chain agents can work out whether a supply disruption is imminent using knowledge of suppliers’ status, inventory position, demand, and logistics, and then suggest remedial measures for procurement, inventory, and logistics, and so on.

Healthcare is yet another option, mainly for administrative work such as data entry, making appointments, finding the right data, and road-mapping the workflow. AI’s use for clinical purposes has to go through a stronger validation process, as the wrong decision on the part of the AI could directly endanger patients’ lives.

Why Enterprise Agentic AI Needs Strong Governance

There are also risks associated with using an autonomous agentic AI. Entering an instruction wrong, not using the correct tool, escaping, leaking, or bending a malicious prompt are all ways to the dark side. Failure can cascade across agents in multi-agent systems and to the wider systems. Companies should regard AI agents as operational software rather than a new chat service.

Good governance might include implementing identity and access management, least-privilege permissions, requiring approvals for high-risk actions, tracking and logging actions with audit trails, providing data-protection controls, immediate defence against injection attacks, model assessment, and validation of tools and controls on resources. Also, enterprises will need accountability and ownership of what AI agents are doing. So, the new model will not be one of total freedom but controlled freedom.

The Future of Agentic AI

The advent of agentic AI will probably see the development of more specialised agents within shared enterprise IT systems. Rather than a generalist to do all types of jobs, firms will deploy specialist agentic models in software engineering, customer service, cybersecurity, finance, supply chain and more. They will operate alongside each other on shared levels of orchestration, identity, observability and governance.

This shift is also transforming how organisations conceptualize their enterprise software landscape. More and more, AI agents are being considered an operational layer that communicates with the applications already in place- rather than an expansion that necessitates replacements for every single back-end application. As agentic workflows develop further, tools such as agent registries, observability tools, policy engines, security measures, and standards for interoperability may come into play.

So, the big change, therefore, is not so much between chatbots and autonomous AI. It also falls somewhere in the middle of AI as a set of features in the software process beneath. Enterprises that can master the art of good model construction, having access to high-quality data, appropriate tooling, targeted orchestration, and appropriate governance, will be the ones to benefit from agentic AI.

Conclusion

Agentic AI is the future of enterprise AI. By integrating data, orchestration, and governance with reasoning models, enterprise AI agents become everlasting multi-step workers and not static question-answering tools. Use cases for agentic AI are emerging in customer service. Software engineering, security, finance, healthcare, and supply chain.

And that smart model isn’t enough to make it enterprise-ready. Security, permission, observability, reliability, interoperability, and human oversight will all play a role as organisations consider whether to gate agents’ transition from pilots to production. As companies start to reorganise their workflows around autonomous and semi-autonomous systems, technology leaders should have a firm grasp of agentic AI architecture, its underlying components, how it operates, and its enterprise use cases.

The post What Is Agentic AI ? Architecture, Components, Workflows, and Enterprise Use Cases appeared first on ELE Times.

🉐Оголошено додатковий набір на курси японської мови! kpi вт, 10/06/2026 - 14:09

Add cellular connectivity on LTE bands, both for phone calls and for broadband Internet access.

Partly because cellular networks supporting the latest data communication standards are so widespread and readily available, and partly because of the difficulty and poor economic convenience of bringing in wired telephone lines, more and more users are turning to radio-mobile telephone connections, especially when they need to work in areas that high-speed lines have not reached yet; in such cases various solutions are used, depending on the goal to be achieved. If the connection is needed to run a more or less automatic control system, you need a cellular module, whereas if you have to interface a computer, microprocessor or microcontroller to the Internet, it is essential to adopt a cellular module with a suitable data access technology.

In the latter case, given that the current focus is very much on 4G and 5G and that UMTS/HSDPA (better known as 3G) is being gradually abandoned, you need a module/modem that is at least LTE, while for phone calls (typical of remote control systems, which work with simple phone calls or SMS) 2G (GSM) or GPRS (2.5G) is still available. The project described in these pages is precisely a device that implements cellular connectivity with LTE data support, based on a recent GSM module from SIMCom, capable of supporting both ordinary phone calls and the SMS (Short Message Service) messaging service and data communication protocols from 2G up to the latest 4G.

Circuit diagram

To make it clear what we are dealing with, let us take a look at the diagram of the device, published in these pages, which shows that everything is based on the SIMCom A7682E module, which is in practice the only active element on the board; around it are some passive components, six NPN bipolar transistors, plus a TVS (Transient Voltage Suppressor) overvoltage protection array and a socket for a microSIM SIM card.

So let us start with the description of the circuit, for which we have provided only a Quadriband cellular module, namely the SIMCom A7682E, which is able to cover up to 4G and is therefore up to date with the new wireless communication technologies on radio-mobile telephone networks, at least with those currently most used, if we consider that 5G does not yet have a significant spread. Its printed circuit board has two miniature connectors, one for the connections to the outside needed for use and integration into other equipment (we can consider it a header…) and the other for firmware updating (labelled UPG). The main connector, a 20-pin one in two rows with 2×2 mm pitch, also carries the positive and negative supply, as well as the power-on control line (PWR), all the signals and communication lines to and from the SIMCom module, but also the grounds of the analog and digital sections of the module (contacts 18 and 20).

Power-on and reset control

So let us describe how the circuit works, starting from the power supply control section, which operates by acting from the outside on the ON/OFF line (pin 1); this line is used to switch the GSM/LTE module on and off while keeping it constantly powered from the Vcc and GND contacts of the pin-strip; in fact our GSM1 module is always under voltage, supplied by the Vcc line (pins 17 and 19 of the 20-pole connector) to pins 34 and 35 (labelled Vbat, because the module was designed for use in battery-powered devices) and is switched on or off by the logic level applied to pin 39 (PWR), which internally is connected to a pull-up resistor and is active at logic zero, so to switch on the GSM1 module you have to bring the ON/OFF line (contact 1 of the pin-strip) to a high logic level and drive transistor T2 into saturation, which pulls the PWR line of GSM1 low.

Reset control works in a similar way: the SIMCom module provides a reset input (RST, located at pin 83, active at logic zero and fitted with an internal pull-up resistor); the reset is obtained by bringing pin 16 (RST) of the 20-pole connector to logic 1, whereupon transistor T3 goes into saturation and pulls the RST line of GSM1 low; at the same time, VDD_EXT of the same module is brought to logic 1.

The UART lines and level shifting

Let us go on with the UART control lines, namely RTS, CTS, DTR, DCD, which go to the outside through contacts 2, 4, 10 and 6 of the connector respectively; the same applies to VRTC (contact 5) and ADC0 (7). Note that by means of jumpers JP1, JP2, JP3 and JP4 it is possible to connect or disconnect the CTS, RTS, DTR and DCD control signals on board; normally these jumpers are open and if they need to be closed, this is meant to be done by soldering the pads of the ones you want.

About the UART, note the particular configuration of the TXD and RXD lines, each of which is interfaced through an NPN transistor configured in common base, so as not to sit directly on the corresponding contacts of the pin-strip; in particular, RXD (which is an input), fitted with a pull-up resistor, is connected to the collector of T5, whose emitter is connected to the RXD pole (contact 14) of the pin-strip, and therefore when the latter is in the open state or is at a high level (voltage equal to VDDEXT of the GSM1 module) T5 is off and the module’s RXD is at a high level. TXD instead (which is an output of GSM1) drives the emitter of T4, whose collector is fitted with pull-up resistor R13, in parallel with capacitor C11 which filters out noise) and is therefore at a high level (the same potential as VDDEXT) when the SIMCom module pad is at logic 1 and at zero when it is at a low level. The external connection of TXD is located at pin 12 of the 20-pole connector. Transistors T4 and T5 ultimately serve as repeaters of the logic states and as level adapters between the module’s VDDEXT voltage (which is 1.8V, like the logic levels the TXD and RXD signals work with) and the TTL standard, whose levels are 0/5V.

The RI signal and audio

The RI signal (ring indicator for an incoming phone call) comes out of contact 8 of the connector, which leads to the collector of transistor T6, an NPN used as a static switch to repeat the module’s RI to the outside; therefore when contact 7 of GSM1 goes to a high level, pin 12 of the strip takes on the low logic level and vice versa (the high level is obtained only if pin 8 is brought to the supply positive through a resistor of suitable value). The open-collector output makes it possible to provide the incoming call signal to devices and systems with a different supply from that of our circuit, perhaps 12V, or to drive actuators.

The audio, which uses two contacts for the microphone (it is a differential input) and as many for the loudspeaker, passes through contacts 15, 13, 11, 9, which correspond respectively to MIC1P and MIC1N (microphone positive and negative) and SPK1N and SPK1P (loudspeaker negative and positive respectively).

Antenna and field LED

The antenna needed for the GSM1 module to work is connected through a gold connector on the cellular board, leading to contact 32 (RF ANT); the connector is an MMCX type. Let us go on with transistor T1, which here is used to drive the cellular module’s “field” LED locally: its base is biased by the logic level present on pin 41 (NETLIGHT) of GSM1. From the collector of the transistor runs the line that leads to contact 3 (LED) of the 20-pole connector, through which the host microcontroller (or in general the system using our module) learns about the conditions of the cellular network (presence, signal strength, availability) as well as the connection state of the module (no network signal, network present, etc.).

SIM management

Let us conclude the analysis of the circuit diagram by dealing with the SIM management lines, which interface to the contacts of the dedicated bus on the GSM1 module through the SIM_CLK (clock), SIM_RST (reset) and SIM_DATA (data channel) lines; the SIM_VDD line is used to switch the SIM on and off (power it and remove power from it) and is managed by the GSM1 module.

TVS protection and power supply

Note the presence of the array of four Zeners (D1) made up of TVS elements, that is, special diodes used to protect the SIM card from any voltage spikes caused by interference, which can travel from the power supply line all the way to the lines of the communication bus between the SIM and the cellular module. In fact, in the schematic we included it for future developments, even though it was not fitted on the prototype because the documentation provided by SIMCom does not consider it necessary for the A7682E module used here. We provided for it anyway, at the printed circuit board level, because in theory the board can support other pin-to-pin compatible SIMCom modules that might require it, or in any case if you should run into interference problems in your application.

Further protection of the communication between the SIM and the cellular module is provided by capacitors C5-C9, C6, C7, C8 connected respectively to the SIM_VDD, SIM_RST, SIM_CLK and SIM_DATA lines toward ground, whose purpose is to filter those lines from impulsive interference that could affect communication between the card (chip-card) and the GSM1 module.

The Vcc supply of the circuit is expected to be around 4 V, because the module is designed to be powered by a single-cell lithium battery (which at full charge sits at around 4.2 V…) and therefore with a DC voltage between 3.6 and 4.2 volts; it is nevertheless possible to power it from a “fixed” source, that is, from a mains power supply or a line coming from another device, as long as you stay within the range given above.

We finish the description of the schematic with the connector labelled UPG (CN1), which is a miniature 6-pole male single-in-line type with a very tight 1 mm pitch: besides carrying the 5 volt supply and ground, it conveys the DP, DM and Vbus lines of the integrated USB 2.0 connection and the Boot line to be used for programming the SIMCom A7682E cellular module. The connector is visible at the top right in the photograph of the prototype shown in Fig. 1.

Practical construction

Well, now that the schematic has been explained in detail we have to move on to the practical side: the board requires a double-sided printed circuit board, whose copper-side traces can be downloaded from the Download Sources and Gerber Files section on the presentation page for this issue. For making the PCBs you can use the inexpensive PCBPRODUCTION service. Once you receive the PCB you can fit the necessary components onto it, following, for the polarised ones, the orientation shown by the assembly drawing you see in these pages.

SMD preparation and soldering

The build requires some care, since the circuit is surface-mount and also requires a minimum of equipment consisting of at least a very fine-tipped soldering iron, solder wire (or solder paste) with a maximum diameter of 0.5 mm, medium-density flux paste, a magnifying lens and tweezers for placing the components. Soldering the SIMCom module requires the use of a hot-air station and, preferably, a heating plate able to bring the underside of the printed circuit board to a temperature of at least 100 °C. Alternatively, you can use an oven specifically for soldering or reworking SMD components. In this case, the procedure calls for first applying a low-density flux to the pads of the SIMCom module, followed by a uniform layer of solder paste. The module must then be positioned precisely in the centre of the pads, strictly respecting the orientation indicated in the prototype images and in the assembly drawing. Without moving the module, the printed circuit board goes into the oven drawer.

Once the machine has started, you follow the appropriate soldering cycle, determined by the type of paste used: lead-free (compliant with RoHS regulations) or leaded (containing lead). It is important to note that these ovens generally come with factory-preset soldering profiles, but in some cases custom profiles can be configured according to specific needs. Once the A7682E module is in place, which is the first component to solder so as to avoid having to heat the others in the “little oven” and therefore subject them to thermal stress, you can proceed with the remaining components. If you wish, it would be possible to solder all the components in one go (except for the connectors, to be soldered at the end, as well as the microSIM socket, to be soldered by hand) and in that case take the printed circuit board, spread solder paste on the pads intended for the SMD components and then put everything in the little oven, making sure that no element has moved.

Manual components and antenna

If you choose to solder the discrete components by hand, get yourself a pencil soldering iron (or a soldering station) with a fine tip and a power rating of no more than 30 watts. Apply some flux to the pads and start tinning the resistors and capacitors. Then move on to the LED and the transistors, making sure you respect the correct orientation of the terminals for the transistors, since their arrangement is unambiguous. As for the tantalum electrolytic capacitors and the LED, follow the orientation indicated in the assembly drawing shown in these pages. Pay particular attention while soldering the LED: try to minimise the exposure time to heat so that the small transparent resin window through which the light passes does not deform. Finally, insert into their respective holes the 20-pole connectors for interconnecting the board and the one for implementing firmware update and programming (UPG or CN1, as you prefer to call it).

For connecting the GSM antenna there is a special gold-plated MMCX connector, in THT format, to be soldered by hand into the dedicated pads.

The cellular antenna to be used with the circuit proposed here must be compatible with all the bands supported by the SIMCom A7682E module, therefore 850/900/1800/1900 MHz; a good example is the product 8170-ANTGSMSTL-MMCX, which is a cellular whip antenna with a magnetic base and 3 metres of cable. RG174 cable, female MMCX connector. 12 cm long, this antenna is Quadriband, compatible with GSM networks with mobile radio network frequencies at 850/900/1800/1900 MHz (824~894 MHz / 1710~1990 MHz – 880~960 MHz / 1710~1990 MHz – 1920~2170 MHz).

Staying on the build, note that jumpers JP1, JP2, JP3 and JP4 on the printed circuit board are not ordinary 2.54 mm pitch pin-strip jumpers, but are made using pads on the underside of the printed circuit board, to be joined with a drop of solder when you want one or more of them closed (ON state); in normal conditions, therefore, they are open (OFF) and if you need to connect the CTS, RTS, DTR and DCD control signals you must join the respective pads by melting solder over them until those of each jumper are united.

For use, remember that the circuit works with a power supply capable of delivering 4 volts and a current of at least 800 mA, which is the peak draw at maximum transmission power.

Let’s do a quick test

To test the operation of the cellular module we can connect it to a Personal Computer via USB, inserting a TTL/USB converter for the purpose, then issuing basic AT commands from a terminal emulator, for example those for dialling a phone number and managing a phone call (ATDT followed by the number to call and a final ;). The task becomes simpler using the base for GSM modules presented in issue no. 236 of Elettronica In (Fig. 3) and available already assembled with the code FT1427.

The FT1427 base

This base board features a 20-pin female connector compatible with the 4G module, and it packs several useful functions: power-on control, module reset and a CH340 TTL/USB converter. The latter is followed by a MOSFET logic-level translator, which adapts the TTL UART interface to the voltage levels (0/3.3V) required by the cellular module. The FT1427 board also brings the audio and microphone signals out to two jack sockets, so phone calls can be made. Finally, it integrates a switching DC/DC converter (based on the LC3406 IC) running at a high frequency (1.5 MHz, which keeps the size of the required reactive components down) that delivers 3.6V to power the SIMCom module.

Drivers and PC connection

This board is easily recognised and managed by a Personal Computer running a recent operating system (for example Windows 8, 10 or 11), but there are no problems with older Windows versions either: just download the drivers for the CH340 IC from the Internet. It is one of the most popular TTL/USB converters, and it is also used by some Arduino boards, so much so that the drivers can be downloaded, among other places, from the chip manufacturer’s website ( https://wch-ic.com/products/CH340.html ).

To manage the modem built into the GSM/4G module from Windows you can use any terminal emulator (for example Hyperterminal, MobaxTerm, Telnet…) by setting the virtual COM port assigned by the operating system once the drivers are correctly installed, and then issuing the appropriate AT commands; remember that to see the virtual COM port you have to go into Windows Device Manager and open the COM/LPT ports. The drivers also let Windows access the Internet by going into network connections and creating a connection based on a USB modem, which in this case will correspond to the adapter board.

Well, with this we think we have explained everything you will need to use the cellular module; all that is left is to wish you happy working!

Related products

• GSM 4G/LTE Cellular Module – SIMCom A7682E
• GSM Whip Antenna with MMCX Connector

The post A Miniature 4G Module: Compact LTE Cellular Connectivity appeared first on Open Electronics.

WIN Semiconductors Corp of Taoyuan City, Taiwan — which provides pure-play gallium arsenide (GaAs) and gallium nitride (GaN) wafer foundry services for the wireless, infrastructure and networking markets — has added quick-turn semiconductor backend service provider SawStreet LLC of Orlando, FL, USA to its WIN Alliance Partner Program. The partnership complements WIN’s in-house backend processes, giving customers another trusted partner for wafer grinding and thinning, dicing, pick-and-place and die inspection...