Yesterday, I wrote about a 2-year-old open-source hardware ESP32-based DAB+ receiver project, but it turns out there’s also a digital radio project for the Raspberry Pi that was released about three weeks ago. Raspiaudio’s Digital Radio V1 HAT adds AM/FM, DAB/DAB+, and HD Radio support to any Raspberry Pi SBC with a 40-pin GPIO header and is supported by CLI or web-based software for configuration and control.   Digital Radio V1 HAT specifications: Supported SBCs – Raspberry Pi Zero 1/2, Raspberry Pi 4/5 Digital radio receiver chip – Skyworth Si4689-A10 (see product brief) Worldwide FM band support (76 to 108 MHz) Worldwide AM band support (520 to 1710 kHz) DAB, DAB+ Band III support (168 to 240 MHz) Advanced RDS/RBDS decoder FM HD Radio support with on-chip IBOC blend (note from Raspiaudio: subject to licensing. Please verify that you are legally allowed to use it in your country and for […]

The post Raspberry Pi SBC gets (analog and) digital radio HAT with AM, FM, DAB, DAB+, HD radio appeared first on CNX Software – Embedded Systems News.

Read more here: https://www.cnx-software.com/2026/04/10/raspberry-pi-sbc-gets-digital-radio-hat-with-am-fm-dab-dab-hd-radio/

The post Raspberry Pi SBC gets (analog and) digital radio HAT with AM, FM, DAB, DAB+, HD radio appeared first on IPv6.net.

When I wrote about a DIY ESP32-S3 internet radio last week, “raspbeguy” commented he’d rather choose an ESP32-based DIY DAB+ receiver kit, such as the one offered by the PE5PVB project based on a Skyworth SI4684 receiver. I first heard about DAB (Digital Audio Broadcast) in 2003 when we considered adding it to a CD player. It’s basically the digital equivalent of analog FM/AM radios, and I haven’t heard much about it since DAB and the “new” DAB+ standard are mostly a European story (see coverage map below). PE5PVB’s open-source hardware DAB receiver might still be worth a look. PE5PVB’s SI4684 ESP32 DAB+ receiver features: Controller – ESP32 microcontroller with WiFi and Bluetooth (DoIT ESP32 devkit v1) Storage – MicroSD card slot Display – Color LCD screen with 320×240 resolution (SPI) Audio 2x RCA connectors for speakers 3.5mm headphone jack with amplifier DAB+ receiver – Skyworks SI4684 loaded with DAB+ […]

The post Open-source hardware DAB+ receiver combines ESP32 SoC with Skyworks SI4684 chip appeared first on CNX Software – Embedded Systems News.

Read more here: https://www.cnx-software.com/2026/04/09/open-source-hardware-dab-receiver-combines-esp32-soc-with-skyworks-si4684-chip/

The post Open-source hardware DAB+ receiver combines ESP32 SoC with Skyworks SI4684 chip appeared first on IPv6.net.

While hundreds of Arduino Days celebrations took place simultaneously in over 100 countries worldwide, on March 28th Vietnam stood out by hosting synchronized events in four major cities – Hanoi, Ho Chi Minh City, Da Nang, and Can Tho – bringing more than 1,000 students together for a day of hands-on technology learning. Activities included an international Watch Party, project showcases, workshops, talk shows, and a highlight Mini Hackathon where student teams were challenged to build functional health monitoring devices capable of measuring heart rate and SpO2 levels.

The event was organized by FPT Polytechnic in collaboration with Arduino and Qualcomm Technologies, Inc., demonstrating – in the words of Julián Caro Linares, Arduino Senior Engineer for Qualcomm Europe – the university’s “experience in training young people who can create impactful innovations and contribute to economic growth.” This event showed not just the energy and passion from the students from various cities and backgrounds on using technology to solve real world problems, but also how today the barriers to entry for AI at a device level are significantly lower. Participants showed how using Arduino solutions and the new Arduino® UNO Q board can truly democratize physical AI.

From knowing to doing

The theme for this year’s Arduino Days – “Writing the next chapter of AI together!” – reflects a moment when everyone is called to play an active role in defining a new era of innovation, shifting from theoretical knowledge into direct engagement with global technology standards. Everyone is the keyword here. Dr. Vu Chi Thanh, Principal of FPT Polytechnic, commented, “We do not want access to technology to be concentrated in just one place. By organizing the event simultaneously in four cities, students from different regions can connect directly with the global ecosystem and experience a real technology environment, rather than just hearing about it.”

Guneet Bedi, Senior Director of Sales at Qualcomm Technologies, emphasized the significance of Vietnam’s participation in the global Arduino community. “We are entering the AI era, and we need to train students – the future generations – not just how to use AI in everyday life, but how to stop being afraid of this technology,” he said. “Currently, there are millions of people developing on the Arduino platform, creating the world’s largest open-source community, and Vietnam has an incredibly active community that we are eager to support.”

The Mini Hackathon exemplified the event’s hands-on philosophy. Teams – including local students in fields such as automation, electrical engineering, information technology, as well as middle school and high school students interested in STEM – worked under tight time constraints to complete health-tracking devices. The challenge demanded not only technical knowledge in electronics and programming but also teamwork, troubleshooting skills, and product-oriented thinking. One student reflected on the experience: “When our product was reviewed by experts from Arduino and Qualcomm Technologies, we could clearly see the gap between an academic model and a product that could actually be deployed in real life. It is a pressure, but also a strong motivation.”

For Hoang Hung Hai, Product Marketing Staff Manager for Qualcomm Vietnam who helped bring to life the Hanoi event, this hands-on approach represents the future of technology education. “We want students to access Qualcomm and Arduino technologies while they are still in school, and then turn that knowledge into practical exercises, projects, and eventually larger-scale products in the future,” he said.

The strong message behind the success

The entire event embodied a powerful message: AI isn’t something to fear but something to master. As Bedi told students, “You need to learn not only how to use AI, but also how to build and customize it to solve real-world problems. Start now. Do not let yourselves fall behind in the AI revolution.”

At Arduino, we are certain you have the curious mindset and proactive attitude to shift from “using” AI to “making” AI, adding value with every project, prototype, or full-fledged product you create. Our mission is to provide you with access to the technologies you need, and to help you bridge any gaps on your way. The success of the event held by FPT Polytechnic during Arduino Days 2026 is a demonstration of how technology education can be both locally accessible and globally connected, how regional educational institutions can create synergies with the global technology ecosystem, and how each one of us is already part of something bigger.

Qualcomm branded products are products of Qualcomm Technologies, Inc. and/or its subsidiaries. Arduino is a trademark or registered trademark of Arduino S.r.l.

The post Arduino Days 2026 empowers students across Vietnam through hands-on technology experiences appeared first on Arduino Blog.

Read more here: https://blog.arduino.cc/2026/04/09/arduino-days-2026-empowers-students-across-vietnam-through-hands-on-technology-experiences/

The post Arduino Days 2026 empowers students across Vietnam through hands-on technology experiences appeared first on IPv6.net.

Linux malware often hides in Berkeley Packet Filter (BPF) socket programs, which are small bits of executable logic that can be embedded in the Linux kernel to customize how it processes network traffic. Some of the most persistent threats on the Internet use these filters to remain dormant until they receive a specific “magic” packet. Because these filters can be hundreds of instructions long and involve complex logical jumps, reverse-engineering them by hand is a slow process that creates a bottleneck for security researchers.

To find a better way, we looked at symbolic execution: a method of treating code as a series of constraints, rather than just instructions. By using the Z3 theorem prover, we can work backward from a malicious filter to automatically generate the packet required to trigger it. In this post, we explain how we built a tool to automate this, turning hours of manual assembly analysis into a task that takes just a few seconds.

Before we look at how to deconstruct malicious filters, we need to understand the engine running them. The Berkeley Packet Filter (BPF) is a highly efficient technology that allows the kernel to pull specific packets from the network stack based on a set of bytecode instructions.

While many modern developers are familiar with eBPF (Extended BPF), the powerful evolution used for observability and security, this post focuses on “classic” BPF. Originally designed for tools like tcpdump, classic BPF uses a simple virtual machine with just two registers to evaluate network traffic at high speeds. Because it runs deep within the kernel and can “hide” traffic from user-space tools, it has become a favorite tool for malware authors looking to build stealthy backdoors.

Creating a contextual representation of BPF instructions using LLMs is already reducing the manual overhead for analysts, crafting the network packets that correspond to the validating condition can still be a lot of work, even with the added context provided by LLM’s.

Most of the time this is not a problem if your BPF program has only ~20 instructions, but this can get exponentially more complex and time-consuming when a BPF program consists of over 100 instructions as we’ve observed in some of the samples.

If we deconstruct the problem we can see that it boils down to reading a buffer and checking a constraint, depending on the outcome we either continue our execution path or stop and check the end result.

This kind of problem that has a deterministic outcome can be solved by Z3, a theorem prover that has the means to solve problems with a set of given constraints.

BPFDoor is a sophisticated, passive Linux backdoor, primarily used for cyberespionage by China-based threat actors, including Red Menshen (also known as Earth Bluecrow). Active since at least 2021, the malware is designed to maintain a stealthy foothold in compromised networks, targeting telecommunications, education, and government sectors, with a strong emphasis on operations in Asia and the Middle East.

BPFDoor uses BPF to monitor all incoming traffic without requiring a specific network port to be open. 

Let’s focus on the sample of which was shared for the research done by Fortinet (82ed617816453eba2d755642e3efebfcbd19705ac626f6bc8ed238f4fc111bb0). If we dissect the BPF instructions and add some annotations, we can write the following:

(000) ldh [0xc]                   ; Read halfword at offset 12 (EtherType)
(001) jeq #0x86dd, jt 2, jf 6     ; 0x86DD (IPv6) -> ins 002 else ins 006
(002) ldb [0x14]                  ; Read byte at offset 20 (Protocol)
(003) jeq #0x11, jt 4, jf 15      ; 0x11 (UDP) -> ins 004 else DROP
(004) ldh [0x38]                  ; Read halfword at offset 56 (Dst Port)
(005) jeq #0x35, jt 14, jf 15     ; 0x35 (DNS) -> ACCEPT else DROP
(006) jeq #0x800, jt 7, jf 15     ; 0x800 (IPv4) -> ins 007 else DROP
(007) ldb [23]                    ; Read byte at offset 23 (Protocol)
(008) jeq #0x11, jt 9, jf 15      ; 0x11 (UDP) -> ins 009 else DROP
(009) ldh [20]                    ; Read halfword at offset 20 (fragment)
(010) jset #0x1fff, jt 15, jf 11  ; fragmented -> DROP else ins 011
(011) ldxb 4*([14]&0xf)           ; Load index (x) register ihl & 0xf
(012) ldh [x + 16]                ; Read halfword at offset x+16 (Dst Port)
(013) jeq #0x35, jt 14, jf 15     ; 0x35 (DNS) -> ACCEPT else DROP
(014) ret #0x40000 (ACCEPT)
(015) ret #0 (DROP)

In the above example we can establish there are two paths that lead to an ACCEPT outcome (step 5 and step 13). We can also clearly observe certain bytes being checked, including their offsets and values. 

Taking these validations, and keeping track of anything that would match the ACCEPT path, we should be able to automatically craft the packets for us.

To find the shortest path to a packet that validates the conditions presented in the BPF instructions, we need to keep track of paths that are not ending in the unfavorable condition.

We start off by creating a small queue. This queue holds several important data points:

• The pointer to the next instruction.

• Our current path of executed instructions + the next instruction.

Whenever we encounter an instruction that is checking a condition, we keep track of the outcome using a boolean and store this in our queue, so we can compare paths on the amount of conditions before the ACCEPT condition is reached and calculate our shortest path. In pseudocode we can express this best as:

paths = []
queue = dequeue([(0, [0])])

while queue:
	pc, path = queue.popleft()

	if pc >= len(instructions):
            continue

instruction = instructions[pc]
	
	if instruction.class == return_instruction:
		if instruction_constant != 0:  # accept
			paths.append(path)
		continue  # drop or accept, stop parsing this instruction

if instruction.class == jump_instruction:
	if instruction.operation == unconditional_jump:
		next_pc = pc + 1 + instruction_constant
		queue.append((next_pc, path + [next_pc]))
		continue

	# Conditional jump, explore both
	pc_true = pc + 1 + instruction.jump_true
	pc_false = pc + 1 + instruction.jump_false
	
	if instruction.jump_true <= instruction.jump_false:
		queue.append((pc_true, path + [pc_true]))
		queue.append((pc_false, path + [pc_false]))
	# else: same as above but reverse order of appending
# else: sequential instruction, append to the queue

If we execute this logic against our earlier BPFDoor example, we will be presented with the shortest path to an accepted packet:

(000) code=0x28 jt=0 jf=0  k=0xc     ; Read halfword at offset 12 (EtherType)
(001) code=0x15 jt=0 jf=4  k=0x86dd  ; IPv6 packet
(002) code=0x30 jt=0 jf=0  k=0x14    ; Read byte at offset 20 (Protocol)
(003) code=0x15 jt=0 jf=11 k=0x11    ; Protocol number 17 (UDP)
(004) code=0x28 jt=0 jf=0  k=0x38    ; Read word at offset 56 (Destination Port)
(005) code=0x15 jt=8 jf=9  k=0x35    ; Destination port 53
(014) code=0x06 jt=0 jf=0  k=0x40000 ; Accept

This is already a helpful automation in automatically solving our BPF constraints when it comes to analyzing BPF instructions and figuring out how the accepted packet for the backdoor would look. But what if we can take it a step further?

What if we could create a small tool that will give us the expected packet back in an automated manner?

One such tool that is perfect to solve problems given a set of constraints is Z3. Developed by Microsoft the tool is labeled as a theorem prover and exposes easy to use functions performing very complex mathematical operations under the hood.

The other tool we will use for crafting our valid magic packets is scapy, a popular Python library for interactive packet manipulation.

Given that we already have a way to figure out the path to an accepted packet, we are left with solving the problem by itself, and then translating this solution to the bytes at their respective offsets in a network packet.

A common technique for exploring paths taken in a given program is called symbolic execution. For this technique we are giving input that can be used as variables, including the constraints. By knowing the outcome of a successful path we can orchestrate our tool to find all of these successful paths and display the end result to us in a contextualized format.

For this to work we will need to implement a small machine capable of keeping track of the state of things like constants, registers, and different boolean operators as an outcome of a condition that is being checked.

class BPFPacketCrafter:
    MIN_PKT_SIZE = 64           # Minimum packet size (Ethernet + IP + UDP headers)
    LINK_ETHERNET = "ethernet"  # DLT_EN10MB - starts with Ethernet header
    LINK_RAW = "raw"            # DLT_RAW - starts with IP header directly
    MEM_SLOTS = 16              # Number of scratch memory slots (M[0] to M[15])

    def __init__(self, ins: list[BPFInsn], pkt_size: int = 128, ltype: str = "ethernet"):
        self.instructions = ins
        self.pkt_size = max(self.MIN_PKT_SIZE, pkt_size)
        self.ltype = ltype

        # Symbolic packet bytes
        self.packet = [BitVec(f"pkt_{i}", 8) for i in range(self.pkt_size)]

        # Symbolic registers (32-bit)
        self.A = BitVecVal(0, 32)  # Accumulator
        self.X = BitVecVal(0, 32)  # Index register

        # Scratch memory M[0-15] (32-bit words)
        self.M = [BitVecVal(0, 32) for _ in range(self.MEM_SLOTS)]

With the above code we’ve covered most of the machine for keeping a state during the symbolic execution. There are of course more conditions we need to keep track of, but these are handled during the solving process. To handle an ADD instruction, the machine maps the BPF operation to a Z3 addition:

def _execute_ins(self, insn: BPFInsn):
    cls = insn.cls
    if cls == BPFClass.ALU:
        op = insn.op
        src_val = BitVecVal(insn.k, 32) if insn.src == BPFSrc.K else self.X
        if op == BPFOp.ADD:
            self.A = self.A + src_val

Luckily the BPF instruction set is only a small set of instructions that’s relatively easy to implement — only having two registers to keep track of is definitely a welcome constraint!

The overall working of this symbolic execution can be laid out in the following abstracted overview:

• Initialize the “x” (index) and “a” (accumulator) registers to their base state.

• Loop over the instructions from the path that was identified as a successful path;

  • Execute non-jump instructions as-is, keeping track of register states.

  • Determine if a jump instruction is encountered, and check if the branch should be taken.

• Use the Z3 check() function to check if our condition has been satisfied with the given constraint (ACCEPT).

• Convert the Z3 bitvector arrays into bytes.

• Use scapy to construct packets of the converted bytes.

If we look at the constraints build by the Z3 solver we can trace the execution steps taken by Z3 to build the packet bytes:

[If(Concat(pkt_12, pkt_13) == 0x800,
    pkt_14 & 0xF0 == 0x40,
    True),
 If(Concat(pkt_12, pkt_13) == 0x800, pkt_14 & 0x0F >= 5, True),
 If(Concat(pkt_12, pkt_13) == 0x800, pkt_14 & 0x0F == 5, True),
 If(Concat(pkt_12, pkt_13) == 0x86DD,
    pkt_14 & 0xF0 == 0x60,
    True),
 0x86DD == ZeroExt(16, Concat(pkt_12, pkt_13)),
 0x11 == ZeroExt(24, pkt_20),
 0x35 == ZeroExt(16, Concat(pkt_56, pkt_57))]

The first part of the Z3 displayed constraints are the constraints added to ensure we’re building up a valid ethernet IP when dealing with link-layer BPF instructions. The “If” statements apply specific constraints based on which protocol is detected:

• IPv4 Logic (0x0800):

  • pkt_14 & 240 == 64: Byte 14 is the start of the IP header. The 0xF0 mask isolates the high nibble (the Version field) to check if the version is 4 (0x40).

  • pkt_14 & 15 == 5: 15 (0x0F), isolating the low nibble (IHL – Internet Header Length). This mandates a header length of 5 (20 bytes), which is the standard size without options.

• IPv6 Logic (0x86dd):

  • pkt_14 & 240 == 0x60: Check if the version field is version 6 (0x60)

We can observe the network packet values when we look at the second part where different values are being checked:

• 0x86DD: Packet condition for IPv6 header.

• 0x11: UDP protocol number.

• 0x35: The destination port (53).

Next to the expected values we can see the byte offset of where it should exist in a given packet (e.g. pkt_12, pkt_13).

Now that we’ve established which bytes should exist at specific offsets we can convert it into an actual network packet using scapy. If we generate a new packet from the bytes of our previous Z3 constraints we can clearly see what our packet would look like, and store this for further processing:

###[ Ethernet ]###
  dst       = 00:00:00:00:00:00
  src       = 00:00:00:00:00:00
  type      = IPv6                 <-- IPv6 Packet
###[ IPv6 ]###
     version   = 6
     tc        = 0
     fl        = 0
     plen      = 0
     nh        = UDP               <-- UDP Protocol
     hlim      = 0
     src       = ::
     dst       = ::
###[ UDP ]###
        sport     = 0
        dport     = domain         <-- Port 53
        len       = 0
        chksum    = 0x0

These newly crafted packets can in turn be used for further research or identifying the presence of these implants by scanning for these over the network. 

Understanding what a specific BPF set of instructions is doing can be cumbersome and time-consuming work. The example used is only a total of sixteen instructions, but we’ve encountered samples that were over 200 instructions that would’ve taken at least a day to understand. By using the Z3 solver, we can now reduce this time to just seconds, and not only display the path to an accepted packet, but also the packet skeleton for this as well.

We have open-sourced the filterforge tool to help the community automate the deconstruction of BPF-based implants. You can find the source code, along with usage examples, on our GitHub repository.

By publishing this research and sharing our tool for reducing analysts’ time spent figuring out the BPF instructions, we hope to spark further research by others to expand on this form of automation.

Read more here: https://blog.cloudflare.com/from-bpf-to-packet/

The post From bytecode to bytes: automated magic packet generation appeared first on IPv6.net.

Flash Bee is an easy-to-make DIY handheld lightning detector based on off-the-shelf parts such as the XIAO ESP32C3 board and the Round Display for XIAO, as well as a 3D-printed enclosure. The design relies on the AMS AS3935 Franklin lightning sensor that’s been around for years, and found in kits like Sparkfun’s Arduino IoT weather station, which is capable of detecting lightning up to 40 km away with 1km accuracy. While it’s not quite new technology, I found the Flash Bee design to be rather cute and convenient, and it looks really easy to reproduce. Flash Bee key components: Seeed Studio XIAO ESP32-C3 with Wi-Fi 4 & Bluetooth LE 5.0 connectivity ($4.90) Round Display for XIAO – 1.28-inch touchscreen display with 240×240 resolution, 65K colors, 100 Hz refresh rate ($18) Grove Lightning Sensor AS3935 ($26.90, alternative link if out of stock) 3.7V 400mAh LiPo battery Slide switch 2x M2 5mm […]

The post Flash Bee – An ESP32-C3-based DIY handheld lightning detector appeared first on CNX Software – Embedded Systems News.

Read more here: https://www.cnx-software.com/2026/04/09/flash-bee-an-esp32-c3-based-diy-handheld-lightning-detector/

The post Flash Bee – An ESP32-C3-based DIY handheld lightning detector appeared first on IPv6.net.

Read more here: https://blog.apnic.net/2026/04/09/setting-up-akvorado-a-netflow-analyser-for-your-ipv6-first-network/

The post Setting up Akvorado: A NetFlow analyser for your IPv6-first network appeared first on IPv6.net.

While checking out MicroPython v1.28 changelog, I noticed a board from WeAct Studio based on ST’s STM32U5 Cortex-M33 microcontroller: the WeAct STM32U585CIU6 Mini Core board (WEACTSTUDIO_MINI_STM32U585 in MicroPython code). I found it interesting/newsworthy, as while I had written about the initial STM32U5 MCU release in 2021, and followed up with beefier STM32U5 SKUs with NeoChrom 2.5D GPU and up to 4MB flash in 2023, we had yet to cover a third-party board based on an STM32U5 MCU, excluding the Arduino UNO Q SBC running Linux on a Qualcomm QRB2210 MPU and using an STM32U585 for real-time and I/O control. The WeAct STM32U585CIU6 Core Mini changes that as a low-cost, standalone STM32U5 MCU board. WeAct STM32U585CIU6 Core Mini specifications: Microcontroller – ST STM32U585CIU6 Core – Arm Cortex-M33 Armv8-M core clocked at up to 160 MHz with FPU, Arm TrustZone Memory – 768 KB RAM Flash – 2048 KB flash GPU – […]

The post WeAct STM32U585CIU6 Core Mini – An $8 STM32U5 board supported by MicroPython v1.28 appeared first on CNX Software – Embedded Systems News.

Read more here: https://www.cnx-software.com/2026/04/08/weact-stm32u585ciu6-core-mini-stm32u5-board-supported-by-micropython-v1-28/

The post WeAct STM32U585CIU6 Core Mini – An $8 STM32U5 board supported by MicroPython v1.28 appeared first on IPv6.net.

Augmented reality gains practical value when it responds to the physical world with precision. A floating icon on a screen means little if it hovers 3 meters to the left of where it should be. The same problem compounds when the system attempts to render information about soil moisture, pest density, or terrain elevation. Environmental data must be layered correctly, anchored to exact positions, and updated as conditions change. This article examines how developers and industries approach that problem.

How AR Systems Anchor Content to Real Locations

The core difficulty with AR is placement. The device must determine its own position in space, then calculate where virtual content should appear relative to the user’s view. Google’s ARCore Geospatial API addresses this by allowing developers to attach AR content to any location covered by Street View imagery. The system combines GPS readings with a Visual Positioning System that matches the camera feed against Street View data to calculate where the device is and which way it faces.

This approach works well in urban areas with extensive Street View coverage. Rural settings or private land present challenges because the reference imagery may be outdated or absent. Developers working in these contexts often supplement GPS with local reference markers or additional sensor inputs.

The Role of Depth Sensing in Layered Displays

AR content placed at the correct GPS coordinates can still appear wrong if the system misreads the distance between the device and the target surface. Depth sensing addresses this. Google’s Geospatial Depth feature combines the device’s real-time depth measurement with pre-existing Streetscape Geometry data. The result is depth information accurate up to 65 meters from the device.

On mobile hardware, Apple’s LiDAR-equipped iPhones provide another option. Peer-reviewed research published in MDPI Sensors in October 2025 found that these sensors achieve 0.16m vertical RMSE accuracy when supported by reference points spaced every 20 meters. For field surveys, construction sites, and agricultural applications, this level of accuracy allows AR overlays to represent actual terrain with reasonable fidelty.

Spatial Precision in Field-Level AR Overlays

AR systems used in agriculture depend on accurate positioning to render overlays that match actual terrain. iPhone LiDAR sensors achieve 0.16m vertical RMSE accuracy when reference points are placed every 20 meters, according to research published in MDPI Sensors in October 2025. Google’s Geospatial Depth extends this by combining real-time depth measurement with Streetscape Geometry data, reaching up to 65 meters.

Layering environmental inputs from IoT sensors, drone imaging, and location intelligence allows AR tools to predict pest populations and reduce pesticide use by roughly 30%. Over 60% of large-scale farms are forecasted to adopt AR-driven precision farming by 2025.

Integrating Sensor Networks with AR Interfaces

Environmental data becomes useful in AR when it updates continuously. A static overlay showing last month’s soil pH readings offers limited value during planting season. Systems that connect AR displays to live IoT sensor networks allow users to view current conditions as they move through a physical space.

In agricultural settings, this means a farmer wearing AR glasses can see real-time moisture levels superimposed on specific field sections. The same principle applies to industrial facilities where temperature, pressure, or chemical readings must be monitored across large areas. The AR layer serves as an interface to distributed sensor data, presenting it spatially rather than as tables or graphs on a separate screen.

Qualcomm’s Snapdragon XR platforms power more than 100 AR, VR, and mixed reality devices currently on the market. These platforms support on-device AI processing, which allows smart glasses to interpret environmental audio and visual input locally rather than sending everything to cloud servers. The latency reduction matters for applications where the user needs immediate feedback.

Drone Imagery as a Data Layer

Overhead views from drones provide context that ground-level sensors cannot. Crop health assessments, flood risk mapping, and construction progress monitoring all benefit from aerial imagery captured at regular intervals. When this imagery feeds into an AR system, users can compare what they see on the ground with a bird’s-eye perspective.

The combination proves particularly useful for pest management. Systems integrating drone imaging with ground sensor data can predict pest populations and visualize infestations before they spread. Field trials have shown pesticide reductions of approximately 30% while maintaining effectiveness against target pests. The AR interface allows workers to see treatment recommendations overlaid on specific plants or field zones rather than applying chemicals uniformly.

Hardware Constraints and Tradeoffs

Running complex environmental models on wearable AR hardware requires compromises. Battery life, processing power, and thermal management limit what devices can do locally. Some applications offload heavy computation to edge servers or the cloud, accepting the latency penalty in exchange for more sophisticated analysis.

Others prioritize responsiveness and run simpler models on-device. The choice depends on the application. A warehouse worker scanning inventory labels needs instant feedback and tolerates less sophisticated processing. A geologist examining rock formations might accept a 2-second delay for a more detailed overlay.

Adoption Patterns in Agriculture

The agricultural sector has moved faster than many industries in adopting AR with environmental data layers. Forecasts suggest that by 2025, more than 60% of large-scale farms will use AR-driven precision farming technologies. The economics favor adoption because even small improvements in input efficiency translate to savings across thousands of acres.

Smaller operations face higher barriers. The upfront cost of compatible hardware, sensor networks, and software licensing may not pay back quickly on a 50-acre vegetable farm. Cooperative purchasing arrangements and subscription pricing models have lowered some of these barriers, but adoption remains uneven.

Building Systems That Update Gracefully

Environmental conditions change. Soil erodes, buildings rise, vegetation grows. AR systems that rely on fixed reference data will drift from reality over time. Well-designed platforms incorporate update mechanisms that refresh their underlying maps and models without requiring users to reinstall software or recalibrate hardware.

Google’s approach of leveraging Street View imagery benefits from ongoing data collection as mapping vehicles revisit areas. Agricultural systems face a harder problem because private land rarely appears in public datasets. Some farm operations commission periodic drone surveys specifically to refresh their AR baselines.

What Comes Next

The components for effective environmental AR exist today. Positioning accuracy continues to improve. Sensor costs continue to drop. On-device processing grows more capable with each hardware generation. The remaining challenges involve integration, standardization, and building interfaces that present complex data without overwhelming users. These are engineering problems with known solutions. Progress will come steadily rather than suddenly.

The post Enhancing AR Applications with Layered Environmental Data appeared first on IntelligentHQ.

Read more here: https://www.intelligenthq.com/enhancing-ar-applications-with-layered-environmental-data/

The post Enhancing AR Applications with Layered Environmental Data appeared first on IPv6.net.

Cisco presenteert zijn eerste State of Wireless Report, gebaseerd op onderzoek onder meer dan 6.000 wireless-professionals wereldwijd. Hieruit blijkt dat strategische investeringen in draadloze netwerken organisaties een concurrentievoordeel kunnen opleveren. Tegelijkertijd introduceert AI zowel kansen als uitdagingen voor bedrijfsnetwerken.

Cisco stelt dat Wi-Fi is uitgegroeid tot een strategische motor die bedrijfsresultaten versnelt. Volgens het bedrijf levert één slimme netwerkinvestering direct rendement op op het gebied van productiviteit, klantbetrokkenheid en omzet.

Stijgende IT-budgetten door nieuwe eisen

De opkomst van IoT, AI-workloads en applicaties die veel bandbreedte vereisen, zoals 4K/8K-streaming en AR/VR, dwingt organisaties tot modernisering van hun draadloze netwerken. Cisco meldt dat 80% van de organisaties de uitgaven de afgelopen vijf jaar verhoogde, waarbij 29% het budget zelfs met 50% of meer liet stijgen. Voor de komende vier tot vijf jaar verwacht 82% verdere budgetstijgingen.

Organisaties die hun netwerk al moderniseerden, ervaren volgens het onderzoek een ‘multiplier-effect’: 78% rapporteert een hogere operationele efficiëntie, 75% ziet een stijging in de productiviteit van medewerkers, 75% ervaart een verbeterde klantbetrokkenheid en 68% ziet een directe positieve impact op de omzet.

Uit het onderzoek blijkt dat organisaties de vernieuwing van hun draadloze netwerken versnellen, waarbij steeds meer bedrijven inzetten op het 6GHz-spectrum. Bijna 60% van de organisaties plant om in het komende jaar over te stappen op Wi-Fi 6E of Wi-Fi 7.

De draadloze AI-paradox

Cisco wijst in het State of Wireless Report op een paradox: hoewel AI innovatie stimuleert, brengt het ook uitdagingen mee. Het bedrijf stelt dat organisaties die drie factoren succesvol beheersen, hun kans op een hoge ROI verviervoudigen.

Ten eerste ervaren bijna alle organisaties (98%) toenemende complexiteit, waarbij veel IT-teams vastzitten in een reactieve modus. Cisco geeft aan dat AI-gestuurde automatisering de oplossing biedt: 98% van de gebruikers rapporteert aanzienlijke winst, met een gemiddelde tijdsbesparing van 3 uur en 20 minuten per persoon per dag.

Groeiend risico

Ten tweede vormen AI-gedreven cyberdreigingen een groeiend risico. Volgens het onderzoek lijdt meer dan de helft van de organisaties financiële schade door securityincidenten, waarbij de helft zelfs jaarlijks meer dan 1 miljoen dollar verliest. Vaak zijn kwetsbare IoT- of OT-apparaten de zwakke schakel.

Ten derde heeft bijna 90% van de leidinggevenden moeite met het vinden van gekwalificeerd personeel, doordat talent verschuift naar specifieke rollen in AI en cybersecurity. Cisco meldt dat organisaties met wervingsproblemen 70% meer risico lopen op hoge kosten door beveiligingsincidenten dan organisaties die hun team wel op orde hebben.

Het bericht Cisco introduceert eerste State of Wireless Report verscheen eerst op ChannelConnect.

Read more here: https://www.channelconnect.nl/telecom-en-voip/cisco-introduceert-eerste-state-of-wireless-report/

The post Cisco introduceert eerste State of Wireless Report appeared first on IPv6.net.

Zyxel Networks introduceert het WBE665S BE22000 12-stream WiFi 7 Triple-Radio NebulaFlex Pro access point, dat specifiek is ontwikkeld voor industriële omgevingen. Het apparaat combineert WiFi 7-prestaties met een IP67-behuizing en AI-aangedreven cloudbeheer via het Nebula-platform. Msp’s kunnen hiermee draadloze connectiviteit aanbieden in uitdagende omstandigheden zoals magazijnen, productielocaties en koelhuizen.

Met het access point speelt Zyxel in op de groeiende vraag naar wifi in omgevingen die voorheen als te zwaar werden beschouwd voor draadloze technologie. Zyxel noemt als voorbeelden magazijnen, distributiecentra, productielocaties en koelhuizen, waar heftrucks gebruik maken van verbonden tablets en IoT-sensoren de bewegingen van goederen volgen.

WiFi 7 met robuust ontwerp

De WBE665S combineert een 12-stream WiFi 7-architectuur met drie radio’s die een doorvoersnelheid tot 22 Gbps leveren. Het apparaat ondersteunt Multi-Link Operation (MLO) voor implementaties met hoge dichtheid waar snelheid en lage latentie belangrijk zijn. Het access point beschikt over een geïntegreerde 120-graden slimme antenne die RF-energie richt op aangesloten apparaten. Dit verbetert de dekkingsefficiëntie en beperkt interferentie .

De behuizing heeft een IP67-classificatie en werkt bij temperaturen van -40°C tot 70°C. Het apparaat is hierdoor volgens Zyxel geschikt voor zowel koelhuizen als buiteninstallaties waar stof en vocht voorkomen.

Dubbele uplinks en flexibel beheer

Voor connectiviteit biedt het access point dubbele 10GbE-uplinks. Een glasvezelpoort ondersteunt implementaties over 100 meter, terwijl een optionele 10GbE PoE++ Ethernet-poort installaties met kortere afstanden mogelijk maakt.

Het apparaat integreert met Zyxels Nebula-cloudplatform voor gecentraliseerd beheer. De NebulaFlex Pro-functionaliteit maakt cloud-, controller- of standalone-beheermodi mogelijk.

AI-ondersteuning voor msp’s

Het Nebula-platform bevat AI-aangedreven tools zoals WiFi Aid en Wireless Health. Deze detecteren automatisch problemen en passen instellingen aan om prestaties te optimaliseren. Volgens Zyxel reduceert dit het aantal onderhoudsbezoeken dat msp’s moeten afleggen.

Voor beveiliging ondersteunt het access point Secure WiFi, Connect and Protect Plus, DPPSK-authenticatie en wachtwoordloze toegang.

Het bericht Zyxel lanceert WiFi 7-access point voor industriële omgevingen verscheen eerst op ChannelConnect.

Read more here: https://www.channelconnect.nl/telecom-en-voip/zyxel-lanceert-wifi-7-access-point-voor-industriele-omgevingen/

The post Zyxel lanceert WiFi 7-access point voor industriële omgevingen appeared first on IPv6.net.