Remote Laboratory Based on FPGA Devices Using the E-Learning Approach

Abstract

Laboratories across educational levels have traditionally required in-person attendance, limiting practical activities to specific times and physical spaces. This paper presents a technological architecture based on a system-on-chip (SoC) and a connectivist model, grounded in Connectivism Learning Theory, for implementing a remote laboratory in digital logic design using FPGA devices. The architecture leverages an Internet-of-Things (IoT) environment to provide applications and servers that enable remote access, programming, manipulation, and visualization of FPGA-based development boards located in the institution’s laboratory, from anywhere and at any time. The connectivist model allows learners to interact with multiple nodes for attending synchronous classes, performing laboratory exercises, managing the remote laboratory, and accessing educational resources asynchronously. This approach aims to enhance learning, knowledge transfer, and skills development. A four-year evaluation was conducted, including one experimental group using an e-learning approach and three in-person control groups from a Digital Logic Design course. The experimental group achieved an average performance score of 9.777, surpassing the control groups, suggesting improved academic outcomes with the proposed system. Additionally, a Technology Acceptance Model-based survey showed very high acceptance among learners. This paper presents a novel connectivist model, which we call the Massive Open Online Laboratory.

1. Introduction

The COVID-19 pandemic was caused by the coronavirus known as SARS-CoV-2, with the first human cases reported in Wuhan, China, in December 2019 [1]. In March 2020, the WHO declared COVID-19 a pandemic, urging countries to adopt urgent and aggressive measures [2]. This situation drastically altered daily activities such as work, education, and family life, requiring rapid adaptation to unprecedented changes within a short period of time.

To prevent the spread and contagion of COVID-19, educational institutions worldwide began closing, affecting over 1.5 billion learners globally [3].

In this context, digital technologies such as Learning Management Systems (LMSs) [4], native cloud storage applications [5,6], platforms for videoconferencing and virtual meetings [7,8], social media [9,10], and mobile instant messaging applications [11,12] were employed. All these technologies served as a means for transmitting information and connecting and communicating among people, primarily learners and teachers, achieving Technology-Mediated Learning [13].

In Mexico, academic activities were specifically suspended on 23 March 2020 [14]. As a result, the entire in-person teaching–learning model had to be completely transformed into a distance learning model, in which both learners and teachers had to adapt in a very short time. The government implemented programs such as “Aprende en Casa” at the basic and upper-secondary education levels to enforce a rapid transition to distance education [15]. In addition, accelerated training had to be provided to teachers during the pandemic, as many of them lacked the necessary preparation, as well as the financial and technological resources and institutional support from the organizations where they were employed [16]. On the other hand, platforms such as Zoom, Google Classroom, Canvas, Moodle, Edmodo, and Kahoot are reported as widely used tools for virtual classes, collaborative work, and remote assessments [17].

In contrast, in several European and Asian countries, the transition was more structured, as teachers in many educational systems had greater prior training and experience, with extensive use of Learning Management Systems (LMSs) and videoconferencing tools supported by well-established institutional infrastructures [18].

One of the major challenges in engineering university programs was the development of remote practical sessions. The practical activities conducted in each undergraduate program are highly varied due to the diversity of courses offered. Each course utilizes different elements depending on the field to which it belongs.

Courses related to the area of Digital Logic Design (DLD) use Field-Programmable Gate Arrays (FPGAs) for conducting practical sessions. An FPGA allows the synthesis of digital logic designs using a Hardware Description Language (HDL). Programming an FPGA requires the use of a development board that contains the FPGA and all the necessary peripherals for conducting lab exercises.

Since it was not possible to use these development boards in person, some alternatives emerged, such as using simulators in class and creating videos by teachers to demonstrate the operation of the lab exercises to learners. However, none of these options provides learners with an adequate solution for conducting practical activities, as they do not allow physical interaction with the development boards. Another option is to create a remote laboratory.

A remote laboratory is a technological environment that enables remote access, programming, manipulation, interaction, and visualization of physical equipment available in educational laboratories at any level. This technological environment is implemented using a computational system through an embedded system based on SoC technology.

A remote laboratory offers the entire infrastructure necessary for learners to test their lab exercises from a distance. This infrastructure includes servers for transferring files to the physical equipment, remote access, applications to interact with and manipulate the physical equipment, as well as the use of cameras to stream video that allows visualization of the lab exercise results, and of course, a network connection for Internet access. This infrastructure enables remote laboratories to create the technological environment known as the IoT [19,20,21].

With a remote laboratory, learners can interact with the development boards located in the in-person laboratory from anywhere (home, office, university), at any time, and from any device (laptop, desktop computer, mobile device). This allows them to gain meaningful teaching and learning experiences by conducting lab exercises for the DLD area, making remote laboratory an accessible, available, and usable technological environment. This allows them to acquire what is known as ubiquitous learning [22,23], or u-learning. They only need a computing system (personal computer, laptop, tablet, mobile, etc.) with computer-aided design and electronic design automation (CAD-EDA) tools and an internet connection.

The remote laboratory presented consists of twelve development systems that are currently operational at the School of Computing Science of the National Polytechnic Institute, Mexico. Learners in the DLD and Computer Architecture courses are conducting various lab exercises using the remote laboratory with the e-learning approach.

This approach is defined as a transfer of knowledge and skills through intelligently designed educational materials with the help of electronic media such as the Internet, Web 4.0, intranets, and extranets [24]. This approach enhances the accessibility and availability of educational materials for people without age, time, or learner limits. The Learning Management System (LMS) is a platform used in the e-learning approach and therefore in the presented system [25].

Both the IoT technological environment and the e-learning approach applied in education contribute to the creation of a Smart Learning Environment (SLE) by providing an innovative, supportive, and safe educational setting that fosters educational transformation [26].

Despite the increasing adoption of remote laboratories in engineering education, there is limited empirical evidence on how integrated technological and pedagogical environments aligned with Smart Learning Environment (SLE) principles influence learners’ acceptance and learning outcomes in Digital Logic Design courses. In particular, prior studies rarely examine acceptance mechanisms using appropriately specified formative constructs within an extended TAM framework, nor do they simultaneously analyze learning performance in authentic FPGA-based remote experimentation contexts.

Therefore, we established the following research questions:

• Research Question 1: What technological and pedagogical environment, including its elements and characteristics, is required for the implementation of a remote laboratory and its incorporation into an SLE?
• Research Question 2: How can the level of acceptance of the proposed technological and pedagogical environment be assessed, from the students’ perspective, in a specific higher-education course?
• Research Question 3: Does the proposed technological environment allow students to enhance their academic performance by acquiring the practical competencies required in a specific higher-education course?

These research questions position the study as an empirical investigation that integrates pedagogical design, technological implementation, and theory-driven evaluation to address student acceptance and learning outcomes in remote-laboratory-based Smart Learning Environments.

The paper is organized as follows: Section 2 describes the literature review on in-person and remote laboratories. Section 3 introduces the research methodology. Section 4 describes the analysis and design stage of the research methodology. Section 5 describes the implementation stage of the research methodology. Section 6 describes the results of the remote laboratory. Section 7 provides a discussion and the Section 8 concludes the paper.

2. Literature Review

The development of laboratories has been carried out in in-person, virtual, or remote modalities. In the in-person modality, laboratories have been oriented towards various areas such as Control [27] and Robotics [28].

In the remote modality, several works have also been conducted by different researchers in various fields. Jonathan Alvarez and Sergio Gonzalez in [29] propose a remote laboratory to learn programming and physical computing through Python language and Raspberry Pi 4.

Chevalier and other researchers in [30,31] propose a remote laboratory used in control engineering studies. Additionally, Krishnashree Achuthan and other researchers in [32] propose a remote laboratory that operates a Universal Testing Machine (UTM). The researchers use the Transactional Distance Theory (TDT) to compare physical laboratory platforms and remotely triggerable platforms. Also, Zhiyun Zhang and other researchers in [33] present a Software-Defined Radio remote lab, which permit learners to experiment with real wireless communication, designing radiofrequency systems with minimal code adjustments.

Particularly in the area of DLD, various remote laboratories based on FPGAs have been reported. Navas-González and other researchers in [34] present examples of practices sessions to teach and learn digital electronics using an FPGA-based remote laboratory. The remote laboratory allows for design verification, but there is no video transmission to view the results. A server is implemented on a SoC, which communicates serially with a Nexys3 board. The board sends the status of the peripherals to the SoC to update their state on the user’s screen. To carry out this communication, a module called RLAB Plant must be implemented in the learners’ practices. Additionally, Naoki Fujieda and Atsuki Okuchi in [35] propose a remote FPGA laboratory platform using a PIC18F4450 microcontroller-based board that communicates with FPGA devices remotely via commands. This is intended to give learners the sensation of interacting with the hardware in a remote laboratory environment. Moreover, Michal Melosik and other researchers in [36] propose a remote laboratory focused on FPGA devices for the remote design and testing of electronics circuits. The laboratory hardware consists of an application server on a personal computer and Open Broadcaster Software (OBS) environment for streaming. Two cameras are used, one to visualize the FPGA board and another to monitor instruments like an oscilloscope. Two tasks are performed: using a temperature and humidity sensor and designing a sine wave generator. Also, Han Wan and other researchers in [37] propose a remote laboratory with an FPGA for a Computer Organization course using a web system. The laboratory hardware uses one FPGA for practicing and another FPGA as a monitor. Both FPGAs belong to the Spartan 6 family from Xilinx. A personal computer handles the remote connection to a cloud server. There is a web interface where the practice results are displayed. The researchers report that 50.9% of learners completed Practice 8 in 2017 with the remote laboratory, compared to 21.3% of learners who completed the same practice in 2016 without the remote laboratory. On the other hand, Yuxiang Zhang and other researchers in [38] propose a remote FPGA experiment for experiments from a Computer Systems curriculum. The laboratory hardware uses an Artix-7 FPGA for practicing and a Zynq-7 SoC from Xilinx as a controller to program the FPGA’s binary file through serial slave configuration. The researchers test the platform with the implementation of a 32-bit MIPS architecture processor capable of running a modified version of the Linux kernel.

Thang Manh Hoang and other researchers in [39] propose a remote laboratory for teaching FPGA and HDL. The laboratory hardware uses an Altera Cyclone II 2C20 FPGA for practical exercises, which is controlled through a PIC16F877A microcontroller. Additionally, Toyoda and other researchers in [40] propose an FPGA-based remote laboratory implemented in a hybrid cloud for semi-automatic FPGA-run experiments. The laboratory consists of development systems from Altera. The user only needs to prepare their HDL code and FPGA configuration parameters, which are then sent to the laboratory. Finally, Aramburu and other researchers in [41] propose a cross-national remote laboratory based on FPGAs, implemented by the universities UPNA in Spain and UNIFESP in Brazil. The laboratory consists of 14 Altera development systems from both universities. They use a Raspberry Pi 3 B+ SoC to install the server and a Logitech webcam for video streaming.

Muhammad Alhammami in [42] outlines the development of a Hardware Development Kit (HDK) for a remote training platform based on FPGA. The HDK is equipped with a Raspberry Pi, a screen, a camera, LEDs, and the EP3C16Q240 FPGA chip from Altera. The raspberry Pi is used to run a service as a loading or programming server for the FPGA. They present the design of a mechanical enclosure. To interact with the HDK, the VNC Viewer is used. Additionally, Rithea Sum and other researchers in [43] propose a remote embedded system design approach utilizing Zynq 7000 FPGA, providing a web-based platform for learners to remotely test and debug their designs, with a focus on efficient signal acquisition and effective debugging and analysis. The methods used in the study include the implementation of a lab module with adaptive run-length-encoding data compression with an average compression ratio of 2.90 across three benchmark signals. Also, Carlos Cruz and other researchers in [44] proposed a remote laboratory using a Nexys 4 FPGA Board. The designed remote setup allowed learners to reserve laboratory time by creating customized environments for a wide range of experiments across different subjects. They used a remote computer, camera, sensors, and motor for the development of experiments. There was one lab exercise reported. The study used a questionnaire with 17 questions to gather learners’ perceptions of the remote lab. The results were derived from the Electronic Design course with over 70% of learners preferring to combine real lab with remote lab. On the other hand, Guerrero-Osuna and other researchers in [45] presented a remote laboratory based on a Basys 3 FPGA Board, a Raspberry Pi 5, Google Firebase services, and a web platform called UAZ Labs. They used a waterfall methodology integrating IoT and Cloud Computing technologies to facilitate close interaction between hardware and software. There were three lab exercises reported focusing on controlling DC, servo, and stepper motors. The testing phase involved 50 robotics and mechatronics engineering learners who participated in hands-on sessions for one month, followed by a structured survey evaluating their experience, interaction, and the educational relevance of the platform. Finally, Ballina and other researchers in [46] describe a remote laboratory with a cluster of an AMD Zynq UltraScale and a multiprocessor System on Chip (MPSoC) based on FPGA technology. The cluster is used for teaching the concepts of data transfer and parallel processing across CPU and FPGA. The laboratory is used in a parallel and heterogeneous computing course or in the development of accelerators for an ad hoc computing course. The authors present five exercises for heterogeneous computing.

There are common elements reported in the literature; however, most studies focus primarily on the technological architecture, consisting of hardware design and software infrastructure, with limited attention to pedagogical integration. This can be observed in the fact that only some studies report a sequence of laboratory exercises, none of the reviewed papers report learning outcomes or explicitly state the learning theory employed, and only a few describe the use of measurement instruments applied to learners.

Specifically, this manuscript highlights three main gaps in the existing literature:

• The lack of studies that conceptualize remote laboratories as integrated Smart Learning Environments (SLEs), combining technological, pedagogical, and organizational dimensions;
• The limited use of established theoretical models, such as the Technology Acceptance Model (TAM), to systematically evaluate student acceptance and behavioral intention in FPGA-based remote laboratories;
• The predominance of descriptive or technical validations, with scarce empirical evidence derived from authentic instructional contexts involving real learners.

Based on these identified gaps, we identified the main elements and characteristics required to create an SLE using a remote laboratory in a DLD course, based on an IoT technological environment and the e-learning approach, as follows:

• Technological architecture: Includes the hardware components used by a personal computer or an embedded system based on SoC technology, a development board based on a programmable logic device (PLD)—either a Complex Programmable Logic Device (CPLD) or an FPGA—and the application software.
• Learning Management System: Provides learning activities and didactic resources for a specific course using different learning strategies.
• Lab exercise sequence: A sequence of laboratory exercises designed for a specific course using a CPLD or FPGA.
• Learning theory: The learning theory applied to support interaction among learners when using the remote laboratory.
• Measuring instrument: An instrument used to evaluate learners’ acceptance of the remote laboratory.
• Learning outcomes: Metrics used to evaluate academic performance of learners in a specific course using the remote laboratory.

The proposed research is not limited to the implementation of a new technological platform. Instead, it introduces a structured methodology for the design and deployment of a remote laboratory framed as a Smart Learning Environment and empirically evaluates student acceptance using an extended TAM model within a real Digital Logic Design course.

In Section 7, a detailed comparison between this paper and the reviewed literature is presented.

3. Research Methodology

In this paper, a quantitative research approach with an exploratory and explanatory scope was used. The research methodology is shown in Figure 1.

Figure 1 shows the research methodology with three different stages: Analysis and Design, Implementation, and Evaluation and Results. The methodological design of this paper was explicitly structured to address the research questions formulated in Section 1. Each methodological stage was selected to generate empirical evidence aligned with a specific research objective:

• The analysis and design, and implementation of a Smart Learning Environment (RQ1).
• The assessment of students’ acceptance of the proposed technological and pedagogical environment using an extended TAM framework (RQ2)
• Learning outcomes and assessments associated with the use of the remote laboratory (RQ3)

The following sections describe how each methodological stage contributes to answering these research questions and to generating new empirical and methodological insights.

4. Analysis and Design Stage of the Research Methodology

4.1. General Architecture

In this stage, the general architecture of the remote laboratory for the DLD area is presented, using reconfigurable technology based on FPGA, a connectivist model based on Connectivism Learning Theory, and an embedded system based on IoT for implementation. Figure 2 shows the general architecture.

The general architecture consists of two important components, which are:

• On-site implementation of lab exercises.
• Use of remote laboratories based on IoT.

These components are described below:

4.2. On-Site Implementation of Lab Exercises

In this first component, the learner performs the analysis, design, implementation, simulation, constraints assignment, and BitStream file generation of the lab exercises to be developed using a CAD-EDA tool (ISE or Vivado by Xilinx) [47]. In this development environment, a project is created by selecting the FPGA of the Nexys 4 development board [48]. The sequence of actions for the on-site implementation of lab exercises is shown in Figure 3 and described below:

• Design procedure of the digital logic lab exercise: The Digital Design methodology is used to obtain the entity, the Algorithmic State Machine (ASM), the functional blocks, the datapath, and the control unit for the lab exercise.
• Project creation with CAD-EDA tool: In the development environment, a project is created by selecting a target device, which can be either a Complex Programmable Logic Device (CPLD) or an FPGA.
• Lab exercise programming with HDL: A program is written using an HDL, such as VHDL [49] or Verilog [50]. All functional blocks, the datapath, and the control unit of the design are programmed.
• Lab exercise simulation with HDL test bench: The HDL program is simulated to verify its correct operation according to the exercise specifications using a set of test vectors with a Test-Bench file. For this, the ISE simulator integrated into the CAD-EDA tool is used.
• Pin assignment in constraints file: Pin assignment in the constraints file (.xdc) is performed using a virtual connector created within the technological architecture, called LAB REMOTE. This connector contains 24 virtual switches for assigning input pins. The output pin assignment is carried out through the peripherals on the development board.
• BitStream file generation: Finally, the syntheses, mapping, place, route, and BitStream file (.bit) generation are performed.

4.3. Use of Remote Laboratories Based on IoT

In this second component, the learner accesses the remote laboratory to interact, program, manipulate, visualize, and verify the results of the lab exercise on the FPGA using the Nexys 4 development board. The remote laboratory is implemented on an embedded system with SoC technology. The sequence of actions for using the remote laboratory is shown in Figure 4 and is described below:

• BitStream and constraints file transfer: To achieve this, an SSH server is used for file transfer from a terminal on any operating system (Windows, Linux, MacOS) executing the scp command. In addition, an SSH client for desktop or mobile devices can be used.
• Access to video server: A video web server allows visualization of the results from each lab exercise performed on the Nexsys 4 development board.
• SSH connection to remote laboratory: Remote access to the remote lab is achieved through the SSH server using the username and password provided by the instructor.
• FPGA programming with BitStream file (.bit): The BitStream file is programmed in the FPGA device using an application developed for the SoC.
• Lab exercise verification with constraints file: The lab exercise is verified through an application developed for the SoC.

5. Implementation Stage of the Research Methodology

In this stage, the following modules are used:

• Technological architecture of the remote laboratory.
• Sequence of lab exercises for a DLD course.
• Connectivist model based on Connectivism Learning Theory.

5.1. Technological Architecture of the Remote Laboratory

To implement the general architecture shown in Figure 2, a technological architecture for the development of the remote laboratory is proposed. Figure 5 shows the main components of the technological architecture.

Three important components shown in Figure 5 are explained below:

• V-Model methodology.
• Embedded system based on IoT.
• SoC–FPGA interface.

5.1.1. V-Model Methodology

For the analysis, design, and implementation of the remote laboratory using an embedded system, an adaptation of the V-model methodology proposed by Coop [51] was used for the development of SoC-based embedded systems. The stages of this methodology are shown in Figure 6.

Figure 6 shows the stages of the V-model methodology, from the specification of requirements to the operational testing of the system. This methodology allows returning to previous stages to make the necessary adjustments and ensure that the established requirements are met. In addition, the methodology supports the use of Unified Modeling Language (UML) in each stage [52], enabling a detailed description and a standardized design.

5.1.2. Embedded System Based on IoT

An embedded application was developed using SoC technology and a Linux-based operating system, specifically, Raspberry Pi OS Lite (64-bit), which has an image size of 423 MB [53]. The SoC consisted of a Raspberry Pi 3 Model B+, which has the following features [54]:

• A 64-bit quad-core Cortex A53 processor, on a Broadcom BCM2837B0 SoC.
• Memory of 1 GB LPDDR2 SDRAM and Gigabit Ethernet over USB 2.0.
• Wireless transmission: 2.4 GHz and 5 GHz IEEE 802.11b/g/n/ac wireless LAN, Bluetooth 4.2, BLE.
• Peripherals: SPI, I2C, UART, I2S, USB, GPIOs.

Although a Raspberry Pi 3 Model B+ SoC was used, it could be replaced by a Raspberry Pi 4 Model B or a Raspberry Pi 5. The SoC uses a Camera Module V2 for Raspberry Pi [55], based on Sony’s IMX219 8-megapixel sensor [56]. This camera communicates with the SoC via the MIPI CSI-2 protocol [57] for live video streaming.

Furthermore, two servers were configured on the embedded system, as described below:

• SSH server: This server uses the Secure Shell protocol for encrypted communication and is managed by the systemd initialization system.
• Video web server: This server is implemented using motion, which is used through a web application, so a browser is used for access. Motion is a configurable program that monitor video signals from many types of cameras and perform actions when movement is detected [58].

Additionally, two Linux shell applications were programmed and implemented on the embedded system to interact with the Nexys 4 FPGA development board, as described below:

• FPGA programming application: An application called progFPGA is used to program the FPGA device and relies on the drivers for the Advanced RISC Machine (ARM) architecture provided by Digilent Inc. (Pullman, WA, USA).
  These drivers are managed through the Join Test Action Group (JTAG) standard.
• Virtual switches application: An application called inputFPGA is used to verify the lab exercise and relies on the GPIOs of the SoC. This application allows the manipulation of up to 24 virtual switches which are labeled with the input port names defined in the user constraints file.

5.1.3. SoC–FPGA Interface

This manipulation interface is an electronic circuit that connects the SoC’s 40-pin connector to the Nexys 4 development board through the PMOD connectors. The block diagram of this interface is shown in Figure 7.

The functions provided by the SoC–FPGA Interface shown in Figure 7 are as follows:

• Create virtual switches: A connector referred to as “LAB REMOTE” is created, which supports the operation of up to 24 virtual switches. These virtual switches are shown in

  Table 1. Virtual switches of the LAB REMOTE connector.

  Virtual Sw	FPGA-Pin	Virtual Sw	FPGA-Pin	Virtual Sw	FPGA-Pin
  SWV0	H14	SWV8	G17	SWV16	B18
  SWV1	H16	SWV9	G18	SWV17	A18
  SWV2	G16	SWV10	E18	SWV18	B16
  SWV3	G13	SWV11	F18	SWV19	B17
  SWV4	F16	SWV12	D18	SWV20	A15
  SWV5	F13	SWV13	E17	SWV21	A16
  SWV6	D14	SWV14	C17	SWV22	A13
  SWV7	E16	SWV15	D17	SWV23	A14

  .
• Configure a Real-Time Clock/Calendar (RTCC): The SoC lacks an integrated Real-Time Clock Calendar (RTCC) for system date and time configuration; instead, it relies on a Network Time Protocol (NTP) server to synchronize the system clock. When an RTCC is required, it must be implemented as an external peripheral to the SoC. The SoC–FPGA interface provides a connector compliant with the IIC bus specification [59], enabling the integration of external devices. Consequently, a custom electronic board was designed to incorporate an external RTCC, model DS1338 from Analog Devices [60], into the SoC.
• Configure a Crypto-Authentication device: These devices feature a cryptographic coprocessor that performs hardware-based encryption algorithms for IoT applications. A custom electronic board was designed for the connector, compliant with the IIC bus specification of the SoC–FPGA interface, to integrate an external Crypto-Authentication device, model ATECC608 from Microchip Inc. (Chandler, AZ, USA) [61].
• Provide a USB-to-serial-UART interface: The SoC–FPGA interface provides a connector compliant with the UART interface. It enables the interconnection of external peripherals such as a USB-to-serial-UART interface (FT232R) [62]. The FT232 device allows console access to the SoC operating system and access to programming, configuration, updating, and maintenance tasks for the embedded system applications.

5.2. Sequence of Lab Exercises for a DLD Course

The remote laboratory has been used in the DLD courses since 2021, with nine lab exercises covering the course content. The lab exercises are shown in

Table 2. Lab exercises of DLD course.

No	Lab Exercise Title	Course Topic
1	Combinational logic	Introduction
2	Flip-Flops	Latches and Flip-Flops circuits
3	Registers	Registers: architectures and applications
4	Sequence detector	Registers applications and Mealy Machine (MyM)
5	Multiplexed message	Moore Machine (MoM)
6	Counters	Counters: architectures and applications
7	Special counters	BCD, ring and Johnson counters
8	Sensors	MyM, special counters applications
9	Algorithmic State Machine (ASM)	Registers, counters and memories applications, and ASM

.

Lab exercise 1 through 8 are explained in general terms, while lab exercise 9 is explained in detail as it encompasses the full thematic content of the course.

Lab exercise 1 involves integrating different combinational logic circuit elements such as a multiplexer, comparator, and code converter into an application that allows the use of various HDL structures, including concurrent, sequential, and conditional ones. In this lab exercise, learners review and/or acquire the foundational knowledge needed for the course.

In lab exercise 2, learners design, implement, and test an SR Flip-Flop (FF), JK-FF, T-FF, and D-FF based on the equations obtained from their extended truth tables. The implementation is carried out using the D-FF and HDL on an FPGA. Through this lab exercise, learners apply and reinforce the theoretical knowledge acquired on latches and FFs.

In lab exercise 3, learners design, implement, and test a circuit that performs the functions of a register, including load, hold, shift-left, and shift-right operations. The implementation is carried out at different levels of abstraction using HDL on an FPGA. Through this lab exercise, learners apply and reinforce the theoretical knowledge acquired on registers, including their architectures and applications.

In lab exercise 4, learners design, implement, and test a 4-bit sequence detector without overlap using HDL on an FPGA. The sequence to detect is “1101” where the methodology for designing sequential circuits is applied. Through this lab exercise, learners apply and reinforce the theoretical knowledge acquired on Deterministic Finite Automaton (DFA) with outputs called Mealy Machines.

In lab exercise 5, learners design, implement, and test a multiplexed message using HDL on an FPGA. The message has four symbols and is displayed on a module of four multiplexed common anode displays. Also, the methodology for designing sequential circuits is applied. The implementation is carried out in two ways: a static message without movement and a moving message in marquee mode. Through this lab exercise, learners apply and reinforce the theoretical knowledge acquired on DFA with outputs called Moore Machines.

In lab exercise 6, learners design, implement, and test counters using HDL on an FPGA. They analyze an up-counter with enable for obtaining a generic equation using a Moore Machine and applying the methodology for designing sequential circuits. Additionally, they implement counters using high-level operators + and −. Through this lab exercise, learners apply and reinforce the knowledge acquired on counters.

In lab exercise 7, learners design, implement, and test BCD, ring, and Johnson counters using HDL on an FPGA. They analyze these counters through their Mealy and Moore Machines and implement them using packages and components. Through this lab exercise, learners apply and reinforce the knowledge acquired on special counters.

In lab exercise 8, learners design, implement, and test an application that determines whether a person enters or exits a room and counts the number of people in the room using two optical sensors and BCD counters. The application is implemented using a Mealy Machine analyzed with high-level HDL. Packages and components are used for the implementation. Through this lab exercise, learners apply and reinforce the knowledge acquired on Mealy Machines and special counters.

Practice 9 is described in detail below.

Algorithmic State Machine Lab Exercise

ASMs are used to model dedicated cores through a flowchart that represents the state transitions and outputs generated by Mealy and Moore machines. The resulting digital logic design enables the execution of a specific algorithm in hardware.

In this lab exercise, a digital logic system is designed, implemented, and tested using HDL on an FPGA to determine the number of bits set to logic ‘1’ in a 22-bit register through an ASM.

The design begins with the analysis of the algorithm to be implemented, which is shown below. From Algorithm 1, the ASM is obtained, which contains the actions to execute the practice’s algorithm. The ASM is shown in Figure 8.

Algorithm 1 Pseudocode algorithm of the ASM lab exercise

countBitsInOne$\left(\mathbf{A}\right)$     $//\mathbf{A}=\mathbf{22}\mathbf{bits}\mathbf{number}$     $\mathbf{B}=\mathbf{0}$     $whileA\ne 0do$          $if{a}_0=1do$               $B=B+1$          $endi f$               $A=Ashift\_right1$     $repeat$     return $\mathbf{B}$

From the ASM in Figure 8, the microarchitecture shown in Figure 9 is obtained. This microarchitecture is known as the datapath.

In this microarchitecture, the datapath of the design is shown and the following functional blocks are presented:

• Register A: This register contains the 22-bit number to be analyzed.
• BCD Counters: They count the number of bits set to logic ‘1’ contained in Register A. The algorithmic diagram of the BCD counters is shown in Figure 10.
• Ring Counter: Performs the multiplexing of the digits from the BCD counters on the four multiplexed common-anode displays.
• ROM: Performs the decoding of the 4 bits from the BCD counters to the 7 segments of the display. For a ROM with an organization of $m\times n$ bits, a data bus called $DATA$ with n bits and an address bus called $BCD\_N$ with $lo{g}_2\left(m\right)$ bits are created using the following equation:

  $$DAT{A}_i=ROM{(BCD\_N_j)}_i$$

  (1)

  where:

  $$\begin{array}{cc}\hfill i& =0,1,\dots ,n-1\hfill \end{array}$$

  (2)

  $$\begin{array}{cc}\hfill BCD\_N_j& =0,1,\dots ,m-1\hfill \end{array}$$

  (3)
• Control Unit: The automaton of the control unit obtained by replacing the actions of the ASM in Figure 8 with the control signals of each element of the datapath shown in Figure 9. This automaton is shown in Figure 11.

• The automaton of the control unit is defined by the 9-tuple:

  $$M=(Q,\Sigma ,\Delta ,\delta ,\alpha ,\beta ,{\lambda }^1,{\lambda }^2,q_0)$$

  (4)
• where:  

  $$\begin{array}{cc}\hfill Q& =\left\{q_0,q_1,q_2\right\}\hfill \end{array}$$

  (5)

  $$\begin{array}{cc}\hfill \Sigma & =\left\{0,1\right\}\hfill \end{array}$$

  (6)

  $$\begin{array}{cc}\hfill \Delta & =\left\{0,1\right\}\hfill \end{array}$$

  (7)

  $$\begin{array}{cc}\hfill \alpha & =\left\{INI,Z,Q{A}_0\right\}\hfill \end{array}$$

  (8)

  $$\begin{array}{cc}\hfill \beta & =\left\{SHE,LA,IB,LB,SEL\right\}\hfill \end{array}$$

  (9)

  $$\begin{array}{cc}\hfill q_0& =Initialstate\hfill \end{array}$$

  (10)
• For each state $\left\{q,p\right\}\in Q$, each input symbol $a\in \Sigma$, and each input signal $s\in \alpha$, the transition function $\delta$ is defined as follows:

  $${\delta }_s(q,a)=p$$

  (11)
• For the automaton of the control unit in Figure 11, the transition function $\delta$ is defined as follows:

  $$\begin{array}{cccc}\hfill {\delta }_{INI}(q_0,0)& \hfill =q_0& \hfill {\delta }_{INI}(q_0,1)& \hfill =q_1\end{array}$$

  (12)

  $$\begin{array}{cccc}\hfill {\delta }_Z(q_1,0)& \hfill =q_1& \hfill {\delta }_Z(q_1,1)& \hfill =q_2\end{array}$$

  (13)

  $$\begin{array}{cccc}\hfill {\delta }_{INI}(q_2,0)& \hfill =q_0& \hfill {\delta }_{INI}(q_2,1)& \hfill =q_2\end{array}$$

  (14)
• The output function ${\lambda }^1$ represents the Mealy-type outputs of the ASM. Additionally, for each state $q\in Q$, each input symbol $a\in \Sigma$, each input signal $s\in \alpha$, each output signal $b\in \beta$, and each output value $d\in \Delta$, the function ${\lambda }^1$ is defined as follows:

  $${\lambda }_{s,b}^1(q,a)=d$$

  (15)
• For the automaton of the control unit in Figure 11, the output function ${\lambda }^1$ is defined as follows:

  $$\begin{array}{cc}\hfill {\lambda }_{INI,LA}^1(q_0,0)& =1\hfill \end{array}$$

  (16)

  $$\begin{array}{cc}\hfill {\lambda }_{Q{A}_0,IB}^1(q_1,1)& =1\hfill \end{array}$$

  (17)
• The output function ${\lambda }^2$ represents the Moore-type outputs of the ASM. Additionally, for each state $q\in Q$, each output signal $b\in \beta$, and each output value $d\in \Delta$, the function ${\lambda }^2$ is defined as follows:

  $${\lambda }_b^2\left(q\right)=d$$

  (18)
• For the automaton of the control unit in Figure 11, the output function ${\lambda }^2$ is defined as follows:

  $$\begin{array}{cc}\hfill {\lambda }_{LB}^2\left(q_0\right)& =1\hfill \end{array}$$

  (19)

  $$\begin{array}{cc}\hfill {\lambda }_{SHE}^2\left(q_1\right)& =1\hfill \end{array}$$

  (20)

  $$\begin{array}{cc}\hfill {\lambda }_{SEL}^2\left(q_2\right)& =1\hfill \end{array}$$

  (21)

With this lab exercise, learners apply and reinforce the knowledge acquired in the theoretical topics of special and applications counters, memories, and ASM. Additionally, the learner applies the digital systems design methodology using ASM symbols for the implementation of the lab exercise.

Each element shown in Figure 9 is implemented using VHDL. Specifically, the learners apply the design using packages and components in VHDL, utilizing component parameterization. Furthermore, the control unit in Figure 11 is implemented using functional description by specifying states through the TYPE directive in VHDL. Functions, procedures, and file reading in VHDL are also implemented.

5.3. Connectivist Model Based on Connectivism Learning Theory

To conduct theoretical topics, learning activities, and the development and assessment of lab exercises for the DLD course, the Connectivism Learning Theory was applied. This theory is one of the most relevant frameworks in smart e-learning environments [25].

The Connectivism Learning Theory is the thesis that knowledge consists of sets of connections between entities, such that a change in one entity can result in a change in the other, and that learning is the growth, development, modification, or strengthening of those connections [63]. Connectivism is the integration of principles explored by chaos, network, complexity, and self-organization theories [64].

Siemens defines the principles of connectivism in [64]. Based on these principles, Siemens and Downes [63] proposed in 2008 a non-formal connectivist learning environment called a Massive Open Online Course (MOOC), also referred to as a connectivist MOOC (cMOOC). In this type of environment, there is no predefined content or fixed thematic sequence. Learners make decisions regarding the selection of thematic content and learning objectives, which provides them with the autonomy to establish a personalized learning path based on informal learning [65]. This approach enables learners to acquire connective knowledge, defined as distributed knowledge that emerges from the connections formed among the various entities involved in the MOOC and their interactions [66].

In contrast, extended MOOCs (xMOOCs) are characterized by a predominantly instructivist approach, influenced by behaviorist and cognitivist learning theories, in which the teaching–learning process focuses on the structured and sequential transmission of content [67,68].

In this paper, a novel connectivist model was developed for the DLD course using remote laboratories, called a Massive Open Online Laboratory (MOOL). The MOOL is described through different models, two of them derived from the Unified Modeling Language (UML). UML is a diagram-based modeling language for the specification, visualization, construction, and documentation of any complex system [69]. It has been used to model software engineering systems as well as other types of systems [70,71,72,73,74]. In this paper, UML is used to model the connectivist environment. The models used are as follows:

• Entity model.
• Use case diagram.
• Activity diagram.

5.3.1. Entity Model

This model shows the functionality, connections, and interactions of each entity. The model is shown in Figure 12.

Figure 12 shows the different entities of the connectivist model; each of them is explained below.

• Learning Management System (LMS) for DLD course: An LMS is designed to enable educators to manage, measure, and enhance learning experiences. Learning activities and didactic resources in LMSs are lecture notes, instructional design documents, class videos, assignment, and exercises. Homepage and course content of the DLD course in the LMS are shown in Figure 13. The explanation of the ASM lab exercise in the LMS is shown in Figure 14.
• Cloud storage: In this entity, a native application is used for storing the content of the DLD course.
• Video conferences: This entity utilizes a platform that allows scheduling and initiating video conference sessions. In these sessions, participants can join to collaborate through voice, video, and screen-sharing functions. This platform is used to deliver synchronous theoretical class sessions, which are recorded for later storage in the cloud, so that the videos can be accessed asynchronously by learners. During these sessions, learners’ questions regarding the covered topics are clarified and addressed.
• Virtual meetings: This entity utilizes a video communication service to conduct video conferences and virtual meetings. This service is used to hold synchronous class sessions for the review of lab exercises via the remote laboratory. During these sessions, learners demonstrate the functionality of each lab exercise to the instructor by implementing their VHDL program, running simulations via test-bench file, and verifying the design on the FPGA through the remote laboratory. Learners’ questions related to the lab exercises are also clarified and addressed in these sessions.
• Platform for video storage: This entity uses a social media platform that allows hosting and sharing videos showcasing the remote laboratory’s operation. These videos can be accessed online asynchronously by the learners.
• Instant messaging application for mobile devices: This entity uses a platform to communicate with all learners in the course for the activities shown in Figure 9. In addition, this node enables academic interaction among learners.
• Remote Laboratory: This entity uses the remote laboratory, where learners test lab exercises by programming the FPGA, interacting with it and manipulating it.

5.3.2. Use Case Diagram

Within the structural view is the use case diagram, which models the functionality of a system as perceived by the actors interacting with it [52]. The use case diagram of the connectivist model is shown in Figure 15.

Figure 15 shows the different use cases of the connectivist model, each of them is explained below.

• Deliver synchronous classes: In this use case, the professor and learner actors interact during synchronous classes. The participating entities are an instant messaging application for mobile devices, video conferences, the LMS, and cloud storage.
• Generate didactic resources: In this use case, the professor actor generates didactic resources by managing and editing course content within the LMS. The participating entities are the LMS, platform for video storage, and cloud storage.
• Review didactic resources: In this use case, the learner actor reviews didactic resources from the LMS. The participating entities are the LMS, platform for video storage, an instant messaging application for mobile devices, and cloud storage.
• Conduct learning activities: In this use case, the learner actor conducts learning activities from the LMS. The participating entities are the LMS, platform for video storage, an instant messaging application for mobile devices, remote laboratory, and cloud storage.
• Lab exercise assessment: In this use case, the professor, learner, and embedded system actors interact during the lab exercise assessment. The participating entities are an instant messaging application for mobile devices, virtual meetings, the LMS, and remote laboratory.

5.3.3. Activity Diagram

The dynamic behavior of the connectivist model can be analyzed through the activity diagram view [52]. These diagrams show the flow control of the activities performed by the learner, professor, and embedded system actors from de use case diagram, and each entity within the connectivist model. In Figure 16 the activity diagram of the “Lab Exercise Assessment” use case is shown.

Figure 16 shows the interactions between the professor and learner actors and the instant messaging application for mobile devices, virtual meetings, the LMS, and remote laboratory entities.

6. Results

The tests performed on the proposed system, as well as the evaluation of the results obtained, are divided into the following sections:

• Testing and results of server’s performance on the SoC.
• Testing and results of the ASM lab exercise conducted in the remote laboratory.
• Testing and results of the Technology Acceptance Model (TAM).
• Learning outcomes and assessment.

These tests were carried out using the remote laboratory, which consisted of twelve development systems used in the DLD courses of the Computer Systems Engineering program at the Higher School of Computing of the National Polytechnic Institute located in Mexico City.

Figure 17 shows the physical implementation of a system used in the remote laboratory, which consists of a System on Chip, SoC–FPGA interface, the FPGA development board, and a power supply.

6.1. Testing and Results of Server’s Performance on the SoC

Figure 5 shows the video server and the SSH server implemented on the SoC used in the remote laboratory. Their testing and evaluations are described below.

6.1.1. Testing and Results of Video Server’s Performance on the SoC

The video server used a Raspberry Pi Camera v2 [55] based on Sony’s IMX219 sensor [56]. That server allows a maximum of 10 users to connect. The server was tested with a program that displayed the message “Lab-rEnnoto-ESCOnn-IPN!” in marquee mode using a four-digit multiplexed common anode display module. The camera resolution was 1024 × 768 pixels at 20 frames per second. The Linux operating system top command was used to obtain the CPU and memory usage percentages, which are shown in

Table 3. CPU performance and memory usage for the video server.

Users	% CPU	% MEM	Mem (MB)
			Total	Free	Used	Cache
0	36.6	5.2	871.7	548.0	68.7	254.4
1	84.8	5.2	871.7	548.2	69.0	254.4
2–10	85.1	5.2	871.7	548.2	69.1	254.4

.

Table 3 shows that the maximum CPU usage percentage was 85.1, corresponding to a single core of the processor. The remaining three cores were used for running other system processes. The percentage of memory used in the SoC was only 5.2% for 10 connected users.

6.1.2. Testing and Results of SSH Server’s Performance on the SoC

To test the SSH server, the JMeter application [78] was used. With this application, load tests were performed with a range of 5 to 50 users in time intervals between 1 s and 60 s. The results obtained are shown in

Table 4. SSH server’s Performance.

User Connections	Connections Made Within Time Intervals
	1 s	3–60 s
5	5	5
10	10	10
15	15	15
20–30	15	19

.

In Table 4, it is shown that the system can handle up to 15 users within 1 s of response time. Additionally, it is observed that a maximum of 19 users can connect starting from 3 s of response time. This allows the connection of up to six groups of three learners each, along with one instructor.

6.2. Testing and Results of the ASM Lab Exercise Conducted in the Remote Laboratory

Each practice shown in Table 2 was analyzed, designed, and implemented using the Vivado v2022.2.2 tool from Xilinx [47] and the Nexys 4 development board [48] with the XC7A100TCSG324 FPGA [79]. The testing and evaluation of ASM lab exercise results are reported below.

Each element of the microarchitecture shown in Figure 9 was implemented using VHDL. Figure 18 shows the implementation of the control unit.

After the implementation of the lab exercise using VHDL, a simulation was performed using a test-bench file with the test vector $DA=\mathtt{0}\mathtt{x}\mathtt{3}\mathtt{AAAAA}$, which is a hexadecimal value containing 12 bits set to one. This vector allowed us to verify the correct operation of the lab exercise. Figure 19 shows the simulation result.

Figure 19 shows the right-shift operation in the QAS register’s output and the increment in the BCD counters from 00 to 12. The result was displayed on the common anode displays.

Next, the input and output terminal assignment was performed using the constraints file and the virtual switches from the remote lab connector. At that moment, the synthesis, place and route, and generation of the BitStream file for the ASM lab exercise were carried out. After this process, the FPGA resources used were obtained, as shown in

Table 5. FPGA resources of the ASM lab exercise.

Resource	Utilization	Available	Utilization (%)
LUT	65	63,400	0.10
FF	72	126,800	0.06
IO	58	210	27.62
BUFG	2	32	6.25

.

Timing information was also obtained, as shown in

Table 6. FPGA timing information of the ASM lab exercise.

Period	Worst Negative Slack	Maximum Frequency	Worst Hold Slack
(T)	(WSN)	(Fmax)	(WHS)
10 ns	7.788 ns	452 MHz	0.262 ns

. The maximum frequency of the design was obtained using Equation (22).

$$Fmax={\displaystyle \frac{1}{T-WSN}}$$

(22)

Finally, the testing and evaluation of the ASM lab exercise were carried out using the remote laboratory and the connectivist model, as shown in Figure 20.

6.3. Testing and Results of the TAM

The TAM is a theoretical framework originally developed by Fred Davis [80] to explain and predict user acceptance and adoption of information technologies. Over the past decades, the TAM has been extensively applied in educational contexts, including e-learning environments, remote laboratories, and virtual laboratories in engineering education [81].

The core TAM constructs considered in this paper were as follows:

• Perceived Usefulness—PU: It measures practical learning gains, innovation in modality, temporal comparison with a physical laboratory, pedagogical value vs. simulators, and spatio-temporal accessibility.
• Perceived Ease of Use—PEU: It measures the ease of use of different technical components.
• Intention to Use—IU: It measures a latent intention.

Additionally, to capture contextual and technological factors specific to engineering education and remote experimentation, the original TAM was extended with three additional constructs, which are described as follows:

• Technology Application—TA: Refers to the extent to which a learner utilizes foundational knowledge from areas related to the technology being used. This allows the learner to both apply previously acquired knowledge and learn new topics.
• Support Digital Resources—SDRs: Refers to the digital resources available to the learner for managing and using the technology. These resources include online user manuals, videos, supporting software, and Learning Management Systems.
• Acquired Digital Skills—ADSs: Refers to the acquired knowledge through learning digital technologies necessary for using the new technology. These digital technologies include CAD-EDA tools for managing and programming the physical device of the remote laboratory and applications for remote interaction.

Derived from the different constructs of the extended TAM framework, a data collection instrument was designed, consisting of a survey with 20 items. These items are shown in

Table 7. Items for each construct of the extended TAM.

Variable	Tag	Item
Learner	SP1	Age.
Profile	SP2	Gender (male/female).
Perceived Usefulness	PU1	The remote lab allows learners to gain practical knowledge of the topics covered in the course.
	PU2	The remote lab allows learners to perform lab exercises remotely in an innovative way.
	PU3	The time allocated for remote lab use is greater than the time allocated for physical lab use.
	PU4	Interaction with remote lab enhances the understanding of each course topic more than using only simulators.
	PU5	Remote lab access is available from anywhere and at any time.
Perceived Easy of use	PEU1	The application for programming the BitStream file onto the FPGA is easy to use.
	PEU2	The application for interacting with the remote lab connector allows for easy input value assignment to test the lab exercises.
	PEU3	The video server allows the results of the lab exercises to be displayed with low latency (in seconds).
	PEU4	The live video stream allows the results of the lab exercises to be viewed clearly and sharply.
	PEU5	Assigning terminals on the REMOTE LAB connector using the constraints file is easy to do.
Technology Application	TA1	The use of the remote lab allows learners to acquire and apply knowledge from the Computer Networks course.
	TA2	The use of the remote lab allows learners to acquire and apply knowledge from the Operating Systems course.
Support Digital Resources	SDR1	The operation video of the remote lab using Putty and WinSCP is useful for learning how to use it on the Windows operating system.
	SDR2	The user manual of the remote lab is useful for learning how to use it.
	SDR3	The support material provided is useful for operating the remote lab.
Acquired Digital Skills	ADS1	The Vivado CAD-EDA tool allows learners to develop and simulate HDL programs of each course lab exercise.
Intention to Use	IU1	Would you like to continue using the remote lab in future courses?
	IU2	Would you like to continue using the remote lab for development and learning of personal and academic projects?

.

In this paper, Perceived Usefulness, Perceived Ease of Use, Technology Application, Support Digital Resources, and Acquired Digital Skills were conceptualized as emergent constructs rather than latent traits. Each indicator represented a distinct and non-interchangeable facet of the construct domain, contributing uniquely to the overall meaning of the construct. Consequently, the removal of any indicator would alter the conceptual interpretation of the construct, which is a defining characteristic of formative measurement models [82,83].

In contrast, Intention to Use (IU) was modeled as a reflective construct, as its indicators were considered interchangeable manifestations of a single underlying behavioral intention, consistent with the original TAM literature [82].

Figure 21 illustrates the measurement model (outer model) and the structural model (inner model) specified for the extended TAM framework used in this paper.

The items shown in Table 7 were delivered in the form of a self-administered survey conducted on 28 learners from group 2CM16 of the DLD course taught during the 2021–2 semester, using a Likert scale. The Likert scale consisted of the following values: totally disagree (td), disagree (d), neutral (n), agree (a), and totally agree (ta). Regarding item SP1, the surveyed learners were between 19 and 24 years old, with 46.4% being 20 years old. Regarding item SP2, 75% of the surveyed learners were male. The results obtained from the remaining items are shown in

Table 8. Survey results.

Variable	Tag	(n)	(a)	(ta)
Perceived Usefulness	PU1		3.6%	96.4%
	PU2		3.6%	96.4%
	PU3	3.6%	3.6%	92.9%
	PU4		3.6%	96.4%
	PU5		7.1%	92.9%
Perceived Easy of Use	PEU1		7.1%	92.9%
	PEU2	3.6%	3.6%	92.9%
	PEU3	3.6%	7.1%	89.3%
	PEU4		10.7%	89.3%
	PEU5		3.6%	96.4%
Technology Application	TA1		10.7%	89.3%
	TA2	3.6%	7.1%	89.3%
Support Digital Resources	SDR1		7.1%	92.9%
	SDR2		3.6%	96.4%
	SDR3		3.6%	96.4%
Acquired Digital Skills	ADS1		14.3%	85.7%
Intention to use	IU1		7.1%	92.9%
	IU2		14.3%	85.7%

.

This research adopted an exploratory approach and involved a relatively small sample size ($ns$ = 28). The research model included formative constructs and multiple mediated relationships. Therefore, Partial Least Squares Structural Equation Modeling (PLS-SEM) was applied, as it is the recommended analytical technique under these conditions [85,86].

6.3.1. Measurement Model Assessment

The measurement model was assessed in accordance with established guidelines for PLS-SEM, taking into account the mixed specification of formative and reflective constructs adopted in this paper [85,86]. Specifically, PU, PEU, TA, SDR, and ADSs were modeled as formative constructs (Mode B), whereas Intention to Use (IU) was specified as a reflective construct (Mode A).

• Assessment of Formative Measurement Models: For formative constructs, traditional internal consistency and convergent validity measures such as Cronbach’s alpha, composite reliability, and average variance extracted (AVE) are not applicable and were therefore not considered. Instead, the evaluation focused on collinearity among indicators using variance inflation factors (VIFs) and the significance and relevance of outer weights and loadings. The results obtained are shown in

  Table 9. Collinearity, outer weights, and outer loadings.

  Item	VIF	Relation	Outer Weights	Outer Loadings
  ADS1	1	ADS1 → ADS	1	1.000
  IU1	1.857	IU1 ← IU	0.483	0.895
  IU2	1.857	IU2 ← IU	0.607	0.935
  PEU1	1.414	PEU1 → PEU	0.738	0.747
  PEU2	1.014	PEU2 → PEU	0.662	0.591
  PEU3	2.269	PEU3 → PEU	0.016	0.454
  PEU4	1.841	PEU4 → PEU	0.147	0.354
  PEU5	1.009	PEU5 → PEU	0.053	−0.031
  PU1	1.008	PU1 → PU	0.582	0.533
  PU2	1.008	PU2 → PU	−0.028	−0.100
  PU3	1.081	PU3 → PU	0.017	0.058
  PU4	1.008	PU4 → PU	0.765	0.722
  PU5	1.083	PU5 → PU	0.4	0.335
  SDR1	1.931	SDR1 → SDR	−0.988	−0.380
  SDR2	1.003	SDR2 → SDR	−0.712	−0.690
  SDR3	1.929	SDR3 → SDR	0.822	0.163
  TA1	1.205	TA1 → TA	0.344	0.677
  TA2	1.205	TA1 → TA	0.808	0.950

  .
• Assessment of the Reflective Measurement Model: The reflective construct Intention to Use (IU) was evaluated using standard reliability and validity criteria. Both indicators exhibited high outer loadings ($IU1$ = 0.895; $IU2$ = 0.935), exceeding the recommended threshold of 0.70, thereby indicating strong indicator reliability. Additionally, IU demonstrated adequate internal consistency reliability, with Cronbach’s alpha [87,88] $(\alpha =0.809)$ and composite reliability ${\rho }_a=0.839$, ${\rho }_c=0.912$; all exceeding the recommended thresholds. Convergent validity was also confirmed, as the average variance extracted (AVE) reached 0.838, indicating that the construct explained a substantial proportion of the variance in its indicators.

6.3.2. Structural Model Assessment

The structural model was evaluated following established PLS-SEM procedures, focusing on the assessment of path coefficients, coefficient of determination ($R2$), and total indirect effects to examine the explanatory power and predictive relevance of the proposed extended TAM framework [85]. The results obtained are shown in

Table 10. Path coefficients, coefficient of determination, and indirect effects.

Relation	Path Coefficients	Construct	${\mathit{R}}^2$	Adjusted ${\mathit{R}}^2$	Relation	Indirect Effects
ADS → PEU	0.152	IU	0.342	0.316	ADS → IU	0.084
PU → IU	0.585	PEU	0.886	0.872	ADS → PU	0.145
PEU → PU	0.951	PU	0.904	0.900	PEU → IU	0.556
SDR → PEU	0.011				SDR → IU	0.006
TA → PEU	0.811				SDR → PU	0.010
					TA → IU	0.451
					TA → PU	0.772

.

6.4. Learning Outcomes and Assessments

To evaluate the remote laboratory, a quasi-experimental field design was employed [89] with the experimental group 2CM16. In this course, the connectivist learning model proposed in Figure 12 was used, and the course followed an e-learning approach. The learners were assessed using the rubric shown in

Table 11. Assessment rubric for the DLD Course.

Specific Indicators	Criteria	Grade
		8.0–10	6.0–7.9	0–5.9
A. Ability to represent a problem using a model based on Mealy Machine, Moore Machine and Algorithmic State Machine.	a. Problem analysis, determination of inputs and outputs	a	a	a
	b. Model selection and design	b	b
	c. Model states’ reduction	c
B. Ability to apply the digital logic design methodology and obtain a digital circuit.	d. Correct code assignment	d	d	d
	e. State table generation	e	e	e
	f. Correct assignment of values to the control signals of the chosen FF	f	f
	g. Correct use of minimization method	g
	h. Correct equations	h
C. Ability to implement the digital circuit using a model based on Mealy Machine, Moore Machine, HDL, and a CAD-EDA tool.	i. Programming using an HDL	i	i	i
	j. Using a simulator with a test-bench file	j	j
	k. Pin assignment, constraints, and BitStream file generation	k
D. Ability to test lab exercises using the remote laboratory.	l. File transfer to the server	l	l	l
	m. Remote access to the server	m	m	m
	n. FPGA programming	n	n
	o. Manipulation of lab exercise inputs	o
	p. Verification of lab exercise results	p
E. Ability to write technical reports using the transmedia narrative strategy.	q. Writing the report using digital media	q	q	q
	r. Explanation of lab exercise testing	r	r
	s. Explanation of results and conclusions	s	s
	t. Inclusion of appropriate references according to the digital media	t

. This rubric specified the evaluated learning indicators, performance criteria, and grading scale, which was based on a numerical scale from 0 to 10.

The assessment results of the experimental group 2CM16 are presented alongside the assessment results of three control groups from the same course in the years 2017, 2018, and 2019, when the courses were taught in person. These results allowed the reported average of the experimental group to be interpreted relative to the grading scale and in comparison with the control groups.

Table 12. Analysis of learner performance in DLD courses.

Specific	2017	2018	2019	2021
Indicator	2CM1	2CM10	2CM7	2CM16
A	7.847	7.057	8.303	9.714
B	7.881	7.006	8.442	9.782
C	7.981	7.134	8.576	9.790
D	7.914	7.127	8.370	9.880
E	8.136	7.053	8.348	9.721
Total average $\left(\overline{x}\right)$	7.951	7.075	8.408	9.777

presents the grades for each specific indicator for all groups, using the assessment rubric shown in Table 11.

As the study was exploratory in nature, the analysis focused on descriptive statistics rather than inferential statistics. Each group consisted of 33 enrolled learners, whose grades were used for the descriptive statistical analysis.

The sample mean $\left(\overline{x}\right)$ was calculated as a measure of central tendency. In addition, the sample variance $\left(s^2\right)$, standard deviation $\left(s\right)$, and coefficient of variation $(CV=s/\overline{x})$ were calculated as measures of dispersion. This was carried out using a program developed with the Pandas library [90] and the Jupyter Notebook 6.4.12 development environment [91]. The results are shown in

Table 13. Descriptive statistic results in DLD courses.

Year	Group	Mean	Standard Deviation	Variance	CV
		($\overline{\mathit{x}}$)	($\mathit{s}$)	(${\mathit{s}}^{\mathbf{2}}$)	(%)
2017	2CM1	7.951	1.1905	1.417	14.97
2018	2CM10	7.075	1.967	3.871	27.8
2019	2CM7	8.408	1.978	3.916	23.53
2021	2CM16	9.777	0.634	0.403	6.49

.

In Table 13, it can be observed that the grades’ sample mean $\left(\overline{x}\right)$ of the experimental group 2CM16 from the year 2021 was higher than the average in the groups from 2017, 2018, and 2019.

7. Discussion

7.1. Discussion of Server’s Performance on the SoC

As for the servers implemented on the embedded system, the video server supported up to 10 connected users, depending on the configured camera resolution, the number of frames transmitted per second, and the available network bandwidth. For 10 users, the video server on the embedded system showed a CPU usage of 85.1% on a single core and 5.2% RAM usage, indicating that the processing and memory resources provided by the embedded system were sufficient for the remote laboratory’s operation. Furthermore, an embedded system with fewer processing and memory resources could also be used, resulting in lower power consumption and reduced costs.

The SSH server could connect up to nineteen users simultaneously, allowing up to six groups of three learners each, along with one instructor per remote laboratory. This was due to the maximum number of connections allowed by the network manager.

These findings directly address the research problem by demonstrating that embedded systems based on SoC technology offer sufficient performance for the implementation of the remote laboratory’s technological architecture.

7.2. Discussion of the ASM Lab Exercise

The ASM lab exercise illustrates the different stages of the DLD methodology, as shown in Figure 3, as well as the stages for using the remote laboratory, shown in Figure 4. The utilization of LUT and FF resources in this lab exercise was less than 1%, demonstrating the high availability of FPGA resources. Furthermore, the maximum frequency achieved was 452 MHz for this lab exercise; however, the other lab exercises used different FPGA resources, with maximum frequencies of at least 400 MHz. Additionally, further lab exercises can be proposed beyond those presented here.

7.3. Discussion of the Extended TAM Framework

• Collinearity Assessment: Collinearity among formative indicators was assessed using variance inflation factors (VIFs). As shown in Table 9, all indicators exhibited VIF values below the conservative threshold of 3.3, indicating that multicollinearity does not pose a threat to the estimation of the formative constructs. These results confirm that each indicator contributes unique information to its respective construct and that redundancy among indicators is limited.
• Significance and Relevance of Outer Weights: The relevance of formative indicators was evaluated through their outer weights. Several indicators demonstrated substantial contributions to their corresponding constructs. For example, within the Perceived Ease of Use construct, PEU1 (0.738) and PEU2 (0.662) exhibited strong positive contributions, while PEU3 (0.016), PEU4 (0.147), and PEU5 (0.053) showed lower relative importance. Similarly, for Perceived Usefulness, PU4 (0.765) and PU1 (0.582) emerged as the most influential indicators, whereas PU2 and PU3 contributed marginally.
  Within the Support Digital Resources construct, SDR1 (−0.988) and SDR2 (−0.712) displayed negative outer weights, while SDR3 (0.822) showed a positive contribution. In formative measurement models, negative outer weights do not indicate measurement problems; rather, they reflect compensatory or suppressor effects among indicators capturing different dimensions of the construct domain. These results suggest that different types of digital support resources may exert contrasting influences on students’ perceived ease of use.
  For Technology Application, TA2 (0.808) contributed more strongly than TA1 (0.344), indicating that operating system-related knowledge played a more prominent role than computer network knowledge in the context of the remote laboratory. Acquired Digital Skills was represented by a single indicator (ADS1), which fully defines the construct in this model.
  Although outer loadings were also examined as a supplementary criterion to assess indicator relevance, they were not used as the primary basis for indicator retention, in accordance with formative measurement guidelines. The observed loadings further support the distinct contribution of indicators without implying internal consistency requirements.
  Overall, the formative measurement assessment confirms that the selected indicators adequately define their respective constructs and that the measurement model is free from critical multicollinearity issues.
• Reflective construct IU: Given the two-item nature of the construct and the high loadings observed, the reflective measurement of IU demonstrates satisfactory reliability and convergent validity. These results confirm that IU is appropriately specified as a reflective construct, with its indicators representing interchangeable manifestations of students’ behavioral intention to continue using the remote laboratory.
• Path Coefficients: Table 10 present the estimated path coefficients of the structural model shown in Figure 21. The results indicate that Technology Application (TA) exerts a strong positive effect on Perceived Ease of Use (PEU) $(\beta =0.811)$, highlighting the importance of learners’ prior technological knowledge in shaping perceptions of ease of interaction with the FPGA-based remote laboratory. In contrast, Acquired Digital Skills (ADSs) show a modest positive influence on PEU $(\beta =0.152)$, while Support Digital Resources (SDRs) exhibit a negligible effect $(\beta =0.011)$.
  Perceived Ease of Use strongly influences Perceived Usefulness (PU) $(\beta =0.951)$, confirming the central TAM assumption that ease of use is a key antecedent of perceived usefulness in technology acceptance processes. Furthermore, PU demonstrates a substantial positive effect on Intention to Use (IU) $(\beta =0.585)$, indicating that learners’ intention to continue using the remote laboratory is primarily driven by its perceived usefulness.
  Overall, the pattern of path coefficients supports the theoretical structure of the extended TAM model and highlights the dominant role of PEU and PU in explaining learners’ acceptance of the remote laboratory.
• Coefficient of determination $R^2$: The explanatory power of the structural model was assessed using the coefficient of determination $\left(R^2\right)$. The results revealed high levels of explained variance for the endogenous constructs. Specifically, PEU achieved an $R^2$ value of 0.886 (adjusted $R^2=0.872$), indicating that ADSs, SDRs, and TA jointly explain a substantial proportion of the variance in perceived ease of use.
  Perceived Usefulness exhibited an $R^2=0.904$ (adjusted $R^2=0.900$), demonstrating that PEU accounts for a very large proportion of its variance. Intention to Use achieved an $R^2=0.342$ (adjusted $R^2=0.316$), which can be considered moderate in behavioral research contexts and is acceptable given the exploratory nature of the study and the relatively small sample size.
  These results indicate that the proposed model exhibits strong explanatory power for the key cognitive constructs of the TAM and a meaningful level of prediction for learners’ behavioral intention.
• Mediation and Indirect Effects: To further examine the mechanisms through which the exogenous constructs influence Intention to Use, the total indirect effects were analyzed. The results indicated that Technology Application exerted a substantial indirect effect on Intention to Use $(\beta =0.451)$, primarily mediated through Perceived Ease of Use and Perceived Usefulness. Similarly, Technology Application showed a strong indirect effect on Perceived Usefulness $(\beta =0.772)$, reinforcing its central role in the acceptance process.
  Perceived Ease of Use exhibited a strong indirect effect on Intention to Use $(\beta =0.556)$, confirming its dual role as both a direct predictor and a mediator within the model. Acquired Digital Skills demonstrated smaller but positive indirect effects on Perceived Usefulness $(\beta =0.145)$ and Intention to Use $(\beta =0.084)$, suggesting a secondary contribution to acceptance through cognitive evaluations.
  In contrast, Support Digital Resources displayed minimal indirect effects on both Perceived Usefulness $(\beta =0.010)$ and Intention to Use $(\beta =0.006)$, indicating that within the studied context, digital support resources played a limited role compared to learners’ technological application capabilities and Perceived Ease of Use.
  Overall, the mediation analysis revealed that acceptance of the FPGA-based remote laboratory was predominantly driven by indirect mechanisms, with Perceived Ease of Use and Perceived Usefulness acting as key mediators between contextual technological factors and students’ behavioral intention.

Additionally, learners provided further comments in the survey, some of which are given below:

• Learner 1: “The remote laboratory was a great support, bringing the lab exercise to our homes in a simple way, without the need to purchase extra materials for each of the lab exercises”.
• Learner 2: “Completely an innovative tool and one of the most helpful while we were taking online semesters”.
• Learner 3: “I think the use of a remote laboratory is excellent, as it extends the time for learners to test their lab exercises, and is not limited to available spaces or restricted usage time”.

7.4. Discussion of Learning Outcomes and Assessments

In Table 12, the grades for each specific indicator of the evaluation rubric can be observed. All grades are higher for the group in which the remote laboratory was used. Specifically, indicator D shows the highest score, with a value of 9.88, indicating that all learners successfully completed the laboratory exercises using the remote laboratory.

In Table 13, it can be observed that the sample mean $\left(\overline{x}\right)$ of the grades for group 2CM16 in 2021 is the highest, with a value of 9.777, in comparison with the control groups in previous years. This suggests that academic performance improves with the proposed system. Furthermore, the coefficient of variation, with a value of 6.49%, indicates the lowest relative variability, suggesting high and consistent performance among the learners in group 2CM16 when the proposed technological architecture and connectivist model were applied through the remote laboratory.

7.5. Discussion of Laboratory Modalities

Although this COVID-19 pandemic period motivated the development of the proposed technological architecture and connectivist model with an e-learning approach to solve the challenge of conducting distance lab exercises, it is not exclusive to this period. In fact, the remote laboratory has multiple advantages compared to the laboratory used in in-person classes, which are shown in

Table 14. Differences between laboratory modalities.

Aspects to Consider	In-Person Modality	Remote Modality
Usage time (Availability)	Very limited, only 1.5 h per week	Continuous time, 24/7 access
Accessibility	Only learners belonging to the academic unit	Any learner with an assigned account
Learner location	The learner must attend the academic unit	Anywhere in the world
Laboratory infrastructure	Personal computer, CAD-EDA tool and development board	Embedded system, internet connection, and development board
Learner infrastructure	None	PC, CAD-EDA tool, and Internet connection
Lab physical space	Lab classroom dimensions determined by educational institution	30 cm × 20 cm × 20 cm dimensions for each remote lab
Educational staff	Staff is required to provide access, materials, and perform reviews	No staff required
Learners who interact during the review	Limited to team-member learners	All the learners in the class

.

7.6. Comparison with Papers in the Literature Review

Finally, the main differences between this paper and the papers reported in the literature review is shown in

Table 15. Comparison with the literature review.

Paper	Technological Architecture	Learning Theory	Software Application	Measuring Instrument	Lab Exercises Sequence	Learning Outcomes
Paper proposed	Server on Raspberry Pi3 SoC, video from the Camera Module V2, Nexys 4 with Xilinx FPGA	Connectivism	Visual shell applications for FPGA programming and interaction with virtual switches	Likert scale survey with extended TAM framework	Nine lab exercises	Evaluation rubric, descriptive statistics
[34]	Server on Raspberry Pi4 SoC, without video, Nexys3 with Xilinx FPGA	None	Web application	Likert scale survey without model	Four projects	None
[36]	Server on PC, video from WebCam, Spartan-3E with Xilinx FPGA	None	Web application	Without survey and model	Two projects without interaction	None
[41]	Server on Raspberry Pi3 SoC, video from WebCam, DE2-115 with Altera FPGA	None	Web application	Likert scale survey without model	Without lab exercises	None
[37]	Cloud Server, host computer, without video, Spartan 6 FPGA	None	Web application	Without survey and model	Nine projects	None
[38]	Server on Zynq-7 SoC, without video, Artix-7 with Xilinx FPGA	None	Web application	Without survey and model	MIPS32 processor	None
[39]	Host Computer, without video, Cyclone II with Altera FPGA	None	Visual interface	Without survey and model	Without lab exercises	None
[35,40,43,44]	Host Computer, with video, FPGA Board	None	Web application	Without survey and model	Without lab exercises	None
[45]	Raspberry Pi5, with video, Basys 3 FPGA	None	Web application	With survey but without model	3 lab exercises	None
[46]	MPSoC-FPGA, without video	None	Jupyter Hub Interface	Without survey and model	5 lab exercises	None

.

The evolution of emerging technologies such as the Internet of Things, mobile and ubiquitous computing, artificial intelligence, and embedded systems has enabled the Industry 4.0 [92] and the development of disruptive technological environments such as remote laboratories that allow remote experimentation, fostering the consolidation of knowledge and the reinforcement of theoretical concepts introduced in the classroom. The proposed architecture makes it possible to advance teaching and learning processes in various courses across different educational levels toward Education 4.0 [93] through the use of highly efficient, low-cost technologies.

8. Conclusions

The research methodology proposed present an alternative for create an SLE based on the technological environment of IoT and the e-learning approach using the Connectivism Learning Theory.

IoT applications implemented through various technologies have enabled the development of remote laboratories in different fields. The technological architecture and the connectivist model of the remote laboratory presented is a solution for the remote management of DLD physical equipment. The technological architecture is implemented using embedded systems based on SoC technology and applying the V-Model Methodology. This allows the development of highly efficient remote laboratories at very low cost. The Systems on Chip (SoCs) used in the implementation of the remote laboratory cost only USD 40.00 [94]. Additionally, with this technological architecture, learners do not need to purchase these development boards, which have a high cost at USD 349.00 [95].

The learning theory based on connectivism has enabled the creation of connectivist learning environments such as MOOCs. However, implementing these environments using a new technological platform, such as remote laboratories, enables the creation of a new connectivist environment, which we refer to as MOOL. This MOOL is designed using UML to describe the system entities, functionality, and control flow of activities. Furthermore, the MOOL allows learners to interact with FPGA-based development boards located in the institution’s laboratory from anywhere (home, office, university, etc.), at any time, and from any device (PC, laptop, mobile device, etc.). Through the remote laboratory approach, the MOOL offers several advantages over the in-person laboratory modality, enabling learners to successfully complete 100% of the lab exercises and reinforce the theoretical knowledge acquired during the semester. In the MOOL, a sequence of nine lab exercises that cover the thematic content of the Digital Logic Design course was proposed. With the implementation of applications for FPGA programming (progFPGA) and input manipulation through virtual switches (inputFPGA), learners can program, manipulate, and interact with each lab exercise to verify its functionality.

The MOOL contains the theoretical elements necessary for learning the course content, similar to a traditional MOOC. In addition, it includes the components for conducting lab exercises with real physical equipment. In the MOOL presented, the learners carried out the actions sequence for the on-site implementation of lab exercises and subsequently, the sequence of actions required to use remote laboratories.

All these advantages of the MOOL provided unrestricted access at any time, enabling learners in the experimental group to interact freely within the connectivist model and fostering active, autonomous, and self-organized learning, which in turn improved academic performance and learning outcomes.

The measurement model evaluation in the extended TAM framework supported the adequacy of the proposed mixed formative–reflective specification. The formative constructs exhibited acceptable levels of indicator collinearity and meaningful outer-weight contributions, while the reflective construct demonstrated strong indicator reliability.

Additionally, the structural model assessment demonstrated that the extended TAM framework provide a coherent and explanatory representation of learners’ acceptance of the FPGA-based remote laboratory. The strong path coefficients, high $R^2$ values for PEU and PU, and meaningful mediation effects collectively support the proposed theoretical relationships and underscore the relevance of technological application and cognitive perceptions in shaping intention to use in e-learning-based engineering education contexts.

The experimental group was active during the COVID-19 pandemic, during which the proposed technological architecture and the connectivist model, using an e-learning approach, were applied. This group achieved a mean evaluation score of 9.777, which was higher than that of the control groups, where a traditional in-person teaching approach was used. These results suggest that academic performance improves when a remote laboratory, connectivist learning theory, and an e-learning approach are applied.