Збирач потоків

The Arduino core for Zephyr RTOS has reached version 1.0.0. This release marks the completion of the transition away from the old MbedOS-based core. The new core provides a modern and flexible foundation for current and future Arduino boards. It also lets you use Zephyr RTOS features and APIs directly from the Arduino IDE, Arduino CLI and Arduino App Lab tools.

The project is built on a two-component architecture. The core generates a standalone elf file that is loaded dynamically by a precompiled Zephyr firmware called the loader. The loader handles the interaction between sketches and the underlying Zephyr system. After the initial bootloader installation, the loader automates the sketch loading process. Version 0.90.0 made the Zephyr loader installation procedure fully automatic.

The loader and its operating modes

The loader’s behaviour is set through the IDE’s Mode menu. In Standard mode, the loader loads the sketch automatically. In Debug mode, on the other hand, it requires you to type ‘sketch’ in the Zephyr shell. This flexibility makes debugging much easier. The loader design is generic: board-specific changes are made in the DTS overlay or fixup files.

The core is validated with version v0.16.8 of the Zephyr SDK. Development uses the standard tools of the Zephyr ecosystem, such as west and sync-zephyr-artifacts. The core also relies on components such as llext, the dynamic extension mechanism, and zephyr-sketch-tool for compiling sketches. Everything rests on ArduinoCore-API to maintain compatibility with the Arduino ecosystem.

What you need to get started

To try the Zephyr core you need a supported board and an up-to-date development environment. Here are the main steps:

• Install Arduino IDE 2.x.x or Arduino CLI
• Add board support through the Board Manager
• Install the Zephyr core from version 1.0.0
• Configure the loader mode from the IDE’s Mode menu

Version 1.0.0 of the Zephyr core is a milestone release. The move from MbedOS to Zephyr is complete. The new core offers a more solid foundation for the future of Arduino boards. Among the new features, support for the project’s code repository includes all the loader and core sources. In addition, the new Arduino UNO Q board is among the first devices to benefit from this architecture.

The Zephyr core represents a paradigm shift for Arduino. It is not just an update: it is an infrastructure built to last. The separation between loader and sketch makes the system safer and easier to update. What’s more, using Zephyr RTOS opens the door to advanced features such as support for numerous protocols and optimised power management. For anyone developing IoT applications, this is a solid foundation to build on.

The transition from MbedOS to Zephyr was not only technical, but also strategic. Zephyr is an open source RTOS with an active community and a regular release cycle. This guarantees long-term support for Arduino boards. In addition, version 1.0.0 of the core is validated with the Zephyr SDK v0.16.8, ensuring stability and compatibility. The future of Arduino boards goes through here.

Source: https://github.com/arduino/ArduinoCore-zephyr

Related products

• Arduino UNO Q 4GB – Complete kit with accessories

The post Arduino Zephyr core 1.0.0: the move away from MbedOS is complete appeared first on Open Electronics.

Let’s discover and try out the benchtop tools that every good electronics technician should have.

 

Nowadays, experimenters and technicians alike use and appreciate portable and handheld measuring instruments. Over the years, these instruments have multiplied and diversified, reaching even the professional user: this is the case of the Hantek 2000 series handheld instruments, which we have tested and described in this article, whose characteristics and interfaces place them fully in the category of semi-professional instruments. More precisely, we focused on two models (both available on the website www.open-electronics.org).

The basic model (HANTEK2C42, part number 6072-MHO2C42) combines a two-track digital oscilloscope with a maximum frequency of 40 MHz with a digital multimeter with automatic readout, while the oscilloscope of the top model (HANTEK2D72, Open Electronics part number 6072-MHO2D72GEN) reaches a frequency of 70 MHz.

The digital multimeter function of both is identical, but the higher-performance model additionally features a waveform generator with the maximum frequency depending on the type of signal generated: sine 25 MHz, square 10 MHz, other types 5 MHz and 1 MHz, maximum amplitude 2.5 Vmax (corresponding to 5.0 Vpp).

From this initial information, it is easy to see that just by putting one of these instruments and a power supply in a case, you have a good portable laboratory bench for analysis or repair on site.

Of course, as we shall see, our HANTEKs will also play their part in a stable laboratory, as their size allows them to be positioned close to the circuit, within easy reach, avoiding the constant twisting of the neck required to display what we need on the bench-top instruments.

In order to prove the truth of this statement, we decided to test these instruments from the comfort of our home PCs, not in the laboratory, by simulating an off-site operation.

Fig. 1 shows all the tools and accessories that we put in a small hard case, all supplied by Open Electronics to carry out this test.

 

Fig. 1

 

The instruments and accessories used for testing HANTEK handhelds:

• HANTEK2C42 handheld;
• HANTEK2D72 handheld;
• Velleman 8220-EDU06 kit  (Oscilloscope Tutor);
• kit FT1464K (Waveform generator – to be mounted);
• Cables and connectors are required for connections.

 

We specify that all tests have been carried out on both models (except, of course, those relating to the waveform generator) but, for obvious reasons, the measurements will be reported only once, having however verified by comparison the total of the results. Finally, for convenience, we will describe the two instruments as if they were one.

Inside the sturdy cardboard packaging, we find a beautiful rigid transport bag, complete with a handle, as well as a quick guide in Italian, of which we will report in this article the images necessary for understanding the operation of the instrument; for everything else we refer to the complete manual in Italian (in the package you will find instructions for downloading the relative pdf).

When you open the zip, you can see that the bag is well organized, in fact, the base has a space in which the instrument, the 230 Vac – 5 V – 2 A mains power supply and the USB cable type C are housed, so not the cable of common smartphones, but that of some new generation models; on the lid of the bag there is a net that contains all the supplied cables: a BNC probe for an oscilloscope with switchable 10x-1x attenuation, with typical accessories, a pair of test leads for the multimeter, a BNC to R/N cable (two in the case of the 2D72 model). Refer to Fig. 2.

For those who wish to equip themselves with a second probe, in order to use both traces with 10x attenuation, we recommend the model 6072-PROBE100, available at www.open-electronics.org.

 

Fig. 2

 

Some details

The HANTEK handheld has a 2.8″ 64,000 colour LCD screen in TFT technology; its resolution is 320 horizontal pixels x 240 vertical pixels with adjustable contrast.

The apparatus is heavier than a normal digital multimeter, partly because of its metal case, covered by a strong rubber, whose purpose is to isolate the circuitry as much as possible from external disturbances.

The two batteries, 18650 type 3.7 V and 2,600 mAh, are already installed inside, and are correctly charged to about 50% of full charge; remember that this type of battery should never be left fully charged or fully discharged for long periods of time, otherwise they can be irreversibly damaged. The instrument has a removable bracket on the back that allows it to be kept in an upright position, and covers the two screws of the battery door. On the right side, there is a rubber cap that allows access to the USB port type C for charging batteries and for connection to the PC; although the cap shows the symbol of an SD CARD, in reality, the slot does not have any housing and in any case is not declared anywhere. In the upper part, there are 3 BNC: the first two for the oscilloscope channels (CH1 and CH2), the third for the output of the waveform generator (Gen out), which of course is operational only on models equipped with this function (2Dxx series).

 

Front panel

Fig. 3 describes the front panel, which is organized in three sections, from top to bottom: the display, the control buttons, and the digital multimeter input jacks.

 

Fig. 3

 

The control keys are as follows:

–  Scope: Oscilloscope mode;

–  DMM: Multimeter mode;

–  AWG: Waveform generator mode (only active on 2Dxx versions);

–  Menu: utility menu;

–  Trig: Trigger setting menu;

–  Enter: In Scope, saves the oscilloscope user-defined settings; in AWG it is used to confirm the character just entered via the digital keyboard;

–  Auto: automatically adjusts the horizontal and vertical scales of the oscilloscope and automatically sets the attack, type, position, slope, level and trigger mode, etc., to ensure a stable waveform display;

–  Channel: menu for setting the two channels (vertical);

–  Time: Horizontal setting menu;

–  F1/F2/F3/F4: in each menu mode, operate the selection of the corresponding menu items on the screen.

–  Zoom and direction keys: perform different actions depending on the menu selected;

– in the Trigger menu, the Left and Down arrows move the trigger level down, while the Right and Up arrows move it up;

– in the Channel menu, the Up and Down arrows change the zero-level position of the track, while the Left and Right arrows change the Volts/DIV of the channel;

– In the Time menu, the Up and Down arrows change the Time/DIV, while the Left and Right arrows change the position relative to the horizontal trigger;

– In Multimeter mode the arrows change the measurement function;

– In Generator mode, after selecting a parameter, the Left and Down arrows will reduce the parameter value, the Right and Up arrows will increase the parameter value; the four arrows are also used for selecting keys on the digital keyboard;

 

We then have buttons marked with icons:

= Pressed and held down, it allows you to access the shortcut menu and to select the desired function by means of the specific key (F1÷F4); after having selected the function, press the Shortcut key once to confirm or cancel the selection (the functions of this menu are described in the specific paragraph);

= RUN/STOP, in Scope mode, stops or executes waveform acquisition; in DMM mode, retains measured data or updates it; in Generator mode, turns waveform output on or off;

= POWER ON/OFF; is the on/off button.

 

On the front panel, we also have the digital multimeter input sockets (DMM Input Connector), from left to right: A (ammeter input 4 A and 10 A capacity, unprotected), mA (ammeter input 40 mA and 200 mA capacity protected by fuse), COM (common input, black ferrule), V/Ω/C/ (voltmeter input, ohmmeter, capacimeter, diode measurement, and short circuit).

Table 1 shows the general characteristics of this family of instruments, while Table 2 shows the main technical characteristics of the oscilloscope section, the arbitrary waveform generator and the multimeter.

 

Tab 1

 

 

Tab 2

 

 

Preliminary operations

After checking that the instrument’s equipment corresponds, the first step is to recharge the instrument’s internal batteries, using the power supply and the cable provided; the POWER button will light up solid red (if it flashes it means that the batteries are not installed or are defective) and will only switch off when the batteries are fully charged.

Now you can turn on the instrument and perform the preliminary operations: firmware update, auto-calibration and Utility menu setting.

 

Software installation and firmware update

Since the instrument can be interfaced with the PC, the management software must be downloaded from the download section of the Hantek site; once the folder has been unzipped, it will contain both the setup and a subfolder with the updated drivers. Connect the handheld to the USB port of the PC, go to the Windows Device Manager and update the driver with the one just downloaded.

The next step is to install the DFU (Device Firmware Update) software and driver. At this point the instrument’s firmware can be checked for updates. The procedure is automatic, so within a couple of minutes, the instrument will be updated to the latest version of the firmware (ARM) and FPGA.

 

Auto-calibration

The oscilloscope has an auto-calibration feature that helps to optimise the signal path for maximum measurement accuracy. It can be performed at any time, but the manufacturer recommends performing it if the ambient temperature changes by at least 5 °C. For more accurate calibration, wait 20 minutes after the oscilloscope has been switched on for it to reach its steady-state temperature.

In addition, the auto-calibration must be performed without any input signal, otherwise, the instrument may be damaged.

 

Utility menu

After auto-calibration, press the Menu key, access the Utilities and make the necessary settings by pressing the keys indicated (those not listed are not needed at this stage):

-F1         : leave English selected (the only alternative at the moment is Chinese);

-F2         : Activate or deactivate key sounds;

-F3         : Set the intensity of the display backlight;

-F4         : Go to page 2 of the Utility Menu;

-F1         : Set the backlight duration;

-F4         : Go to page 3 of the Utility Menu;

-F2         : enable or disable the panel for measurements of the signals shown on the display (for the initial phases it is definitely preferable to leave this panel enabled);

-F3         : View information about the hardware and software versions of the instrument for possible upgrade;

-F4         : Go to page 4 of the Utility Menu;

-F1         (shutdown): Set the automatic shutdown time;

-F2         (calibration): carry out self-calibration (to be done every 12 months or whenever the ambient temperature changes by more than 5°C);

-F3         (default): reset to factory settings (in case you have any doubts about the manoeuvres carried out);

-F4         : Go to page 4 of the Utility Menu;

-F1         (boot logo): enable or disable the display of the logo when the handheld is switched on.

 

At this point we begin to see how to use the instrument, pressing Scope to start with the most important function: the oscilloscope.

 

Setting up the oscilloscope

To obtain a correct image display of the signal detected by the probe, three sets of parameters must be set:

-Vertical: V/DIV for signal amplitude;

–  Horizontal: Sec/DIV for signal width;

-Trigger: synchronisation for signal stability.

 

We would like to point out that our oscilloscope is equipped with an Auto function (activated by the key of the same name) that searches and finds (where possible) the best combination of Volt/DIV, Sec/DIV and Trigger to display in a stable manner the signals applied to one or both of the CH1/CH2 inputs.

But in some cases, you cannot get the expected result, so it is important to learn how to adjust the oscilloscope manually.

To make the adjustment manually, you must move through the function menu, setting the channel operating parameters first; then press the Channel button to enter the channel menu.

-F1         allows you to select the channel to be adjusted;

-F2         is used to enable/disable the selected channel;

-F3         is used to set the probe coupling:

• DC sets DC coupling, useful for reading DC voltage values or the offset of alternating or variable signals;
• AC sets the coupling to alternating, which shows only alternating signals;
• GND shorts the probe to the ground and shows no signal (typically used to calibrate the vertical position of the track);

-F4         allows you to go to the second page of the menu, where:

– F1        allows you to set the attenuation of the probe used, it must have the same value as the switch position on the probe;

– F2      is used to activate bandwidth limiting, in order to eliminate high-frequency noise that may affect the displayed signal;

– F3     reverses the signal in phase.

 

The next step is to set the time base by pressing the Time button:

-F1         is used to set the mode (for normal measurements set Mode YT);

-F2         is used to set the length of image recording.

 

Once this is done, the trigger settings are made by pressing the Trig key to enter the corresponding menu:

-F1         allows you to select the channel to be synchronised;

-F2         allows you to select the slope to be considered for synchronisation:

• Rising;
• Falling: downhill;
• Double: both uphill and downhill.

-F3         sets the synchronisation mode:

– Auto: triggers the signal even in the absence of normal conditions;

– Normal: triggers the signal in the presence of a valid trigger condition;

– Single: locks the display as soon as it acquires a valid waveform.

-F4         allows you to switch to the second page of the menu, where:

-F1         forces the trigger in difficult conditions, completing the acquisition even in the absence of a valid trigger signal.

These are the general settings; now we will see how to set some parameters according to the type of signal we are going to detect, whether we know the maximum values or they are unknown.

 

Probe compensation

The first time a new probe is used on an oscilloscope, the compensation operation must be performed. The procedure consists in applying a known square wave, typically with a frequency of 1 kHz and an amplitude of 2 Vpp, to the probe connected to CH1, then using a small screwdriver, possibly plastic, turn the compensator screw on the probe itself, until a perfect square wave is seen, without overshoots, bevels or inclined edges (see Fig. 4).

 

Fig. 4

 

For the 2Dxx versions, everything is simplified by the fact that you can use the built-in waveform generator, but the 2Cxx versions don’t have one, so we thought we’d use a low-cost kit instrument that will come in handy for both probe compensation and oscilloscope verification. Now we are ready to view and measure our signals with the oscilloscope.

Once the FT1464K kit has been assembled, we have arrived at the point where we have a valid waveform generator (sine, triangle and square), with adjustable frequency from 50 Hz to 6 kHz (in two ranges: 50 Hz÷600 Hz and 600 Hz÷6 kHz) and amplitude 2 Vpp AC (sine), 11 Vpp AC (sine) and 11 Vpp AC (sine). (sinusoid), 11 Vpp AC. (square), 3.5 Vpp AC. (triangular).

The generator in the kit and the 2Cxx handheld computer will be mutually useful, as the oscilloscope will allow the various trimmers in the generator to be calibrated once the probe is calibrated, but also during the calibration phase.

Let’s proceed in order: we know the amplitude of the generator signal (11 Vpp ac) and we know that we need a 1 kHz frequency, so let’s see how to pre-set the two instruments. We start with the FT1464K generator in which:

-trimmers VR3 and VR4 must be positioned at about half stroke;

-the potentiometer must be turned all the way to the left;

-the flow switch is set to FR-H to set the range >600 Hz.

 

Once this is done, plug the probe BNC into the CH1 socket of the oscilloscope; set the attenuation switch to 10X and connect the probe tip to the square wave output and the alligator clip to the generator ground.

We now go to the oscilloscope, where we set CH1 to AC coupling, then press F4 and F1 in sequence to set the attenuation to 10X.

Since we expect a signal with an amplitude of about 11 Vpp, to see it as wide as possible it is best to set the V/DIV to 2 V~ using the Right and Left arrows.

The period relative to the frequency of 1 kHz is its inverse, i.e., 1/1000 Hz=1 ms, so a single square wave lasts 1 ms; the horizontal grid is composed of 12 divisions, let’s consider 10 for convenience; each of them must be worth 1/10=100 us; we must therefore set the Time/DIV to 100 µs. Then press Time and the Right and Left arrows to set the horizontal cursor T to 0.000 ns; then            Time and the Up and Down arrows to set the Time/DIV to 100.00 us.

At this point, we can power the generator with 12 Vdc using any power supply; if everything has been set up according to our instructions, the display will show a very large square wave and the box in the top right-hand corner (if it is not visible, re-read the section on the Utility Menu and enable it) will show the yellow values close to these:

-MAX   5.5 V;

-MIN     5.5 V;

-FRE      600.0 Hz.

 

These values may vary due to the fact that our generator is not a professional instrument, if they vary a lot there will be a circuit problem in the generator or some wrong setting in the instruments or in the probe.

Start by turning the potentiometer very slowly to the right until you obtain a value as close as possible to 1000 Hz, the multiturn trimmer VR2 will be used to obtain the most precise value possible.

Referring to Fig. 4 above, if necessary, adjust the probe compensation until a perfect signal is obtained.

 

Fig.5

 

Calibration of the waveform generator

Once the probe has been adjusted, we can calibrate the generator, starting with the duty cycle of the square wave; except for future requirements, the value to be set is generally 50%; if necessary, turn the VR3 trimmer until the HIGH period of the signal occupies the same number of divisions (squares) as the LOW period, specifically, each of the two periods must occupy exactly 5 divisions. In fact, each division is worth 100 us, a 1 kHz cycle lasts 1 ms, therefore 10 divisions, the duty cycle at 50% means exactly 5 divisions for each of the two periods LOW and HIGH.

At this point we can move on to the calibration of the sinusoidal signal:

• Volts/DIV must be           set to 500 mV;
• Time/DIV must be           set to 200.0 us;
• Connect the probe to the sine wave signal output.

 

Now turn the VR4 trimmer until a sine wave is obtained in which the two half-waves are as equal as possible to each other.

The last check is made by connecting the probe to the output of the triangular wave, if everything is in order you will see two cycles that will completely fill the display both vertically and horizontally.

Both tools are now ready to be used for their respective functionalities.

 

Using the handheld computer software

We have already mentioned the installation of the software in the preliminary operations. The software obviously requires the use of a PC, which obviously affects the question of portability, but on the other hand, greatly simplifies operations, as well as provides the instrument with additional features, such as a series of additional measurements, not available on the handheld, and the possibility of automatic firmware updates; in addition, the PC can easily be a small tablet (or a netbook), which would not affect the overall size and weight of the instrument.

For our purposes, we will only use it to easily take pictures of the various sizes, while for its in-depth use we always refer you to the excellent and comprehensive user manual in Italian.

 

Using the oscilloscope

To test our oscilloscope, we use the other small accessory tool supplied by Open Electronics, the Velleman Oscilloscope Tutor. This is a PCB without a case, already assembled and tested, which, by simply using a normal mains power supply, with a 9-12 Vac output, makes it very easy to carry out eight experiments with any oscilloscope. Let’s take a look at two of them as examples, which we think are suitable for a good evaluation of our instrument.

–  Measure an AC voltage: connect the probe (10x attenuator – CH1) to the test point (tp1) and the alligator clip to tp2. Set the Vertical stage (Channel) to AC and 10 V/DIV, the Horizontal stage to 10 ms/DIV, and the Trigger to Rising and Auto.

The display grid is set at 10 Vpp/DIV and therefore the signal, in this case, is about 34.8 Vpp, which represents the sum of the VMAX and VMIN visible on the instrument; if you want to know the actual (or effective) value of the signal, you must activate the RMS measurement in the software.

Then in the software we use the Measure – Edit options menu option and activate the Peak to Peak, Frequency, and RMS boxes. The result is in Fig. 6. The frequency, as expected, is 50 Hz, the VRMS is 12.3 V, while the Vpp is 34.8 V.

–  Comparison of two out-of-phase waveforms: connect the probe (attenuator 1x – CH1) to tp9, the alligator clip to tp4 and the red clip of the BNC-alligator cable (CH2) to tp10 (the black one can remain free). Set the Vertical stage (Channel) to AC and 5 V/DIV for both CH1 and CH2 (must be enabled), the Horizontal stage to 20 ms/DIV, the Trigger to Rising and Auto. Also in the software, if the green signal does not appear, enable CH2 (Vertical section on the right). With Measure – Edit options activate the VRMS and Frequency measurements for both channels. Finally, using the side arrows 1 and 2 on the left, adjust the height position of the two tracks, so that they are both clearly visible on the screen. The result is visible in Fig. 7.

 

Fig. 6

Fig. 7

 

Using the built-in waveform generator (2Dxx series)

The connection between the two instruments is made by connecting the probe (in 10X mode) to CH1 and the BNC crocodile probe to the BNC Gen Out, with the two black crocodile clips connected together and the probe hooked up to the red crocodile clip (Fig. 8). We will see, again, three different signals.

 

Fig. 8

 

–  Generation of a 5 MHz 2 V square wave signal: click on the AWG key, set type = Square, Freq = 5 MHz and Amp = 2 V; for the latter two settings, you can press the relevant function key (F2 or F3) twice to enter keyboard mode, and enter the desired values with ease.

Press the RUN/STOP button so that the OUTPUT symbol on the display turns green. Click on Scope to switch to oscilloscope mode and set CH1 to 2 V/DIV, AC coupling, Time/DIV to 100.0 ns. Via software, we can activate the VRMS, Vpp, and Frequency measurements to confirm the correctness of the settings made on the Generator (Fig. 9).

 

Fig. 9

The signal we see in the image, being at very high resolution, shows a typical characteristic of square wave generation, the irregularities of the LOW and HIGH zones of the signal, it should be considered that the effect is found, at high frequencies, even in instruments of much higher cost.

However, those who are familiar with digital logic know that this is not a problem at all, since the range of reading of the logical states provides that a signal is considered HIGH when its level is greater than or equal to 2/3 of the value of the power supply, it is instead considered LOW when its level is less than or equal to 1/3 of the value of the power supply; it is easy to understand how small variations in amplitude, both on the HIGH and LOW levels, do not create any problem for the operation of a digital circuit. At low frequencies this effect is practically invisible.

–  Generating a 25 MHz 2.5 V sinusoidal signal: click on the AWG button, set type = Sine, Freq = 25 MHz and Amp = 2.5 V. Press the RUN/STOP button so that the OUTPUT symbol on the display turns green.

Click on Scope to switch to oscilloscope mode and set CH1 to 2 V/DIV, DC coupling, Time/DIV to 20.0 ns. We activate via software the VRMS, Vpp and Frequency measurements (Fig. 10). You can see with this test that the oscilloscope has no difficulty in showing a high-frequency signal on the display, and as we all know, depending on the model, these instruments read signals up to 40 or even 70 MHz without any problems!

 

Fig. 10

 

–  Generation of a
1 MHz 1 V triangular signal
: click on the AWG button, set type = Ramp, Freq = 1 MHz and Amp = 1 V.

Press the RUN/STOP button so that the OUTPUT symbol on the display turns green. Click on Scope to switch to oscilloscope mode and set CH1 to 500 mV/DIV, AC coupling, Time/DIV to 500.0 ns. Again, activate VRMS, Vpp and Frequency measurements (Fig. 11).

 

Fig. 11

 

Using the digital multimeter

The digital multimeter is a universally known instrument, if only because it is always the first tool purchased to equip a laboratory. In our case, in addition to the usual voltage, current and resistance measurements, this instrument offers the possibility of checking the integrity of the junctions of semiconductor components (diodes, transistors, jFETs, etc.), measuring the capacitance of capacitors and searching for short circuits, signaled by the sound of a buzzer.

To activate it, press the DMM button, then set the type of reading to be taken and connect the two test leads accordingly, remembering that the black lead always goes into the COM (common, GND, ground) socket, while the red lead goes into one of the three red sockets.

A special feature, not found in the vast majority of multimeters in circulation, is that depending on the measurement set, the display clearly shows where the two test leads should be inserted, which is useful not only for beginners but also for experts who, in a moment of distraction and haste could make a mistake and certainly obtain undesirable results.

Another useful feature is the lack of measurement scales. Once the measurement has been taken, our multimeter displays it at the highest possible resolution, automatically choosing the scale from those indicated in the technical characteristics table.

–  Measurement of a direct voltage: once again we use our bench power supply, we set a voltage of 20.8 V and read it on the display; to set the multimeter, simply press F1 (DC V) and insert the black test lead into the COM socket and the red one into the V/Ω/C socket, then connect the ends of the test leads to the two crocodile clips on the power supply cable, respecting the colors. Instantly, the display of the multimeter will show the measured value (in our case 20.72 Vdc); the slight difference between the two values is partly due to the tolerance of the two instruments and partly to the fact that the multimeter has two decimals to show the actual value, while the display of the power supply used for the test has only one decimal (Fig. 12).

 

Fig. 12

 

–  Measurement of a direct current: in this case, we will supply a low-voltage LED and measure its absorption.

Let’s set up the instruments: the power supply has to be set to 3 V, while on the multimeter you have to press F4 – F2 (DC mA) and then move the red tip to the mA socket (indicated by the display). Connect the black alligator clip to the black test lead, the red test lead to the anode of the LED (the longest pin) and the red test lead to the cathode of the LED (the shortest pin).

Again, the measurement will be instantaneous, the LED will light up and the display will show the power consumption: in our case 2.33 mA, which is too low to be shown on the power supply’s display, which has a resolution of 10 mA (Fig. 13).

 

Fig. 13

 

Conclusions

Well, we will stop here with the description of the Hantek multifunction oscilloscopes and our impressions of their use on the bench. We believe that what we have outlined in these pages is sufficient to allow you to evaluate the potential of HANTEK handheld instruments in the main measurements that a technician might have to make, both on the bench and in the field.

 

From openstore

Oscilloscope 2CH – 70 MHz+Multimeter

Oscilloscope 2CH – 70 MHz+Waveform Generator+Multimeter

Tutor Oscilloscope

Waveform generator

 

 

 

 

The post HANTEK 2000 series: The all-in-one handheld instruments appeared first on Open Electronics.

submitted by /u/Rhine_Labs [link] [comments]

This is an LED blinkenlights type of thing, driven by 74HC14 Schmitt-trigger inverters driving the LEDs directly; and 74HC157 multiplexers to select different sequences. It's my first time using such tiny components - the matrix area of the board needs to be clear of components but I needed to keep the rest of the board as small as possible while cramming in lots of capacitors and resistors. I know some of you solder this stuff but I can't begin to imagine doing so so I left it to JLCPCB - OTOH I'm still an electronics novice so I'm impressed/amazed/astounded it worked! submitted by /u/GuzziGuy [link] [comments]

submitted by /u/AutoModerator
[link] [comments]

With European Microwave Week 2026 approaching, here is an overview of Qorvo’s plans for the show and its participation in the technical program.

Qorvo, a leading global supplier of connectivity and power solutions, will present RF technologies and system-level expertise for radar, satellite communications, defense and space applications at European Microwave Week (EuMW) 2026, which will be held at ExceL London from 4 to 9 October.

At stand B30A, where Qorvo exhibits together with authorized distributor RFMW, Qorvo experts will bring a system-level perspective on current RF programs and design challenges. Visitors to the stand will be able to explore RF architecture and signal chain trade-offs, power and thermal considerations and the integration issues that affect system performance, as well as approaches for increasing bandwidth and output power while maintaining RF performance.

During the week, Qorvo will also contribute to a series of technical sessions and forums, including:

• Sunday 4 October – SS-01, EuMC: Ryan Jennings, Director of Si, SATCOM and Systems Engineering at Qorvo, and Dean White, Senior Director of Aerospace and Defense at Qorvo, will co-chair the workshop “Challenges and Payoffs in Next-Generation SATCOM: Multi-Band, Multi-Orbit, Multi-Constellation Ground Terminals”. The workshop will explore the technical and architectural challenges of delivering affordable, energy-efficient ground terminals for multi-band and multi-orbit satellite networks.
• Monday 5 October – IEEE MTT-S Inter-Society Technical Panel: Greg Clark, Senior Director of Defense and Aerospace Products, will take part in the panel “Building a Sustainable and Resilient RF Semiconductor Industry”, which examines the challenges of building sustainability across materials, devices and applications, including RFIC and MMIC design, for telecommunications, sensors and emerging applications.
• Wednesday 7 October – Defense Forum: Dean White will present “Future European Defense Systems – RF Technology for Smaller, More Capable Platforms”. The forum will examine microwave technologies for radar, electronic warfare, secure communications and drone detection.
• Thursday 8 October – Space Forum: Ryan Jennings will present “Advances in RF Architecture for Next-Generation Ground Terminals: Multi-band, Multi-orbit, Multi-constellation”. This forum will examine RF, microwave, millimeter-wave and terahertz technologies for future space systems and ground terminals.

Visitors can meet Qorvo throughout the exhibition at stand B30A or arrange a meeting with a Qorvo expert through the Qorvo EuMW 2026 event page.

The post Qorvo Brings RF Expertise to European Microwave Week 2026 appeared first on Open Electronics.

We manufacture a machine able to obtain any kind of shape starting from expanded materials, by cutting with hot wire.

Since hobbyist versions of these machines have been made, machines for shaping solid objects have spread widely, trespassing industrial terrain and landing in schools and the homes of ordinary people: we speak mainly of 3D printers that work by additive printing, but also of other printers for solid objects that in a sense are 3D, while operating with the subtractive technique (CNC mills) or cutting; an example is the Foam Cutter proposed in these pages, which is basically a two-axis printer but able to cut, from slabs of foam and foams of various kinds (sponges, slabs of polystyrene foam and expanded or compact polystyrene, as well as EPP), even 12 cm thick, any kind of figure, even very complex.

In fact, while operating in only two dimensions, this machine allows you to create three-dimensional objects. Cutting is done by hot wire, that is, through a thin metal filament of NiCr alloy (nickel-chromium) that is crossed by a current regulated in order to stabilize the temperature reached and obtain an extremely precise cut and thin passages from the external to the eventual internal. The wire is moved vertically by a mechanism that slides on the uprights of the horizontal carriage, moved by a motor located at the base.

But let’s get to the heart of the project, analyzing first the electrical and electronic part, which basically follows that of a 3D printer but with a few less parts and a revised hardware.

THE CONTROL UNIT

The electronics of the printer is composed of an Arduino Mega board with applied a RAMPS shield, which is the basis of many 3D printers with Arduino architecture and contains all the drivers for stepper motors (in our case it supports 5, but having two stepper-motors we mount only two, namely those of the X and Y axes) and for the heaters of two extruders, as well as manage the limit switches needed to stop the motors when their relative drives arrive at the end of the stroke (Fig. 1).

Fig. 1

The Arduino Mega governs the printing machine through the RAMPS shield and through the USB Device port it is equipped with, it interfaces with the Personal Computer from which it receives the files to be printed and all the settings requested from time to time.

On the electromechanical level, we have two NEMA17 stepper motors, one to slide the carriage horizontally and the other to raise the guide that supports the hot wire on the carriage; in both cases the coupling is a toothed belt.

Then there are the limit switches for these two movements.

The filament is powered through the D10 output of the RAMPS shield, which is connected to a power MOSFET normally used (in the 3D printers the shield is intended for) to power the resistance of extruder no. 1 in PWM; for this reason, as will be clear later, to raise or lower the temperature of the filament we will act on the control of the print client (for example Repetier Host) which acts on the fan speed.

The RAMPS shield is now a standard on which different documentation exists on many websites; we limit ourselves to saying that it contains a certain number of Pololu stepper-motor drivers configurable by jumper in order to set and select multiple microstepping modes and MOSFETs for controlling the extruders.

It also has inputs for reading the NTC thermistors which can be used to read the temperatures of the extruders (not used here) and of the limit switches; everything is interfaced through the headers to the analog and digital I / O of the Arduino Mega.

As you can see in the photo of the shield, between the sockets of each driver module there are three jumpers that are used to define the division factor for the microstepping mode; in our machine the caps must be mounted on all three, in order to set the division factor to 16 (Fig. 2).

For the power supply of the machine (12Vdc) is used the 5 A input of the RAMPS shield.

Fig. 2

To this electronics, if desired, you can add a control panel that allows the use in stand-alone mode; it is basically a unit similar to that provided for the stand-alone use of the 3Drag printer, but programmed with a specific firmware that allows you to display on the LCD screen only the parameters and menu items relevant to the Foam Cutter.

Let’s go back to the D10 output and the fact that the filament power is regulated by the client as if it were the speed of the extruder fan: this, for those who know 3D printers may seem strange; the trick is that the firmware of our machine cutter-polystyrene has been modified with respect to that from which it derives (that of 3D printers) especially in the part that concerns the extruders and the hot plate.

In particular, the extruder 2 is not managed and for the 1 the relative output D10 does not consider the feedback operated with the thermistor (here absent) but behaves like the one of the fan; therefore, the firmware interfaces with the printing client and associates the command to set the extruder fan speed to the PWM signal produced by D10.

That’s why with the fan command we actually vary the current, the power and therefore the filament temperature.

CUTTER MECHANICS

As for the mechanics, it is composed of a base resting on two plexiglass shoulders and formed by two aluminum profiles, two uprights always in aluminum profile, a horizontal carriage (X axis, Fig. 3) formed by a sheet of plexiglass with a stepper-motor applied (for the horizontal axis) and two uprights composed of aluminum profiles that support the mechanism of elevation of the hot wire, composed of two mini-carriages (Y axis) and driven by a toothed belt from a second stepper-motor located in the plexiglass base of the carriage. This belt runs in the hollows of the profiles that act as uprights of the trolley, so as not to be accessible from the outside (Fig. 4).

Fig. 3

Fig. 4

The hot wire fastening system is the same as that used for vertical movement, i.e. up or down, and consists of two small trolleys that slide, by means of wheels, in the slots of the uprights of the horizontal axis trolley. Each of these half trolleys supports and stretches the nickel-chromium filament by means of a helical spring with terminal eyelets that works under traction and has one of the eyelets fixed on the trolley by means of a screw and the other fixed to one end of the hot wire (Fig. 5).

Fig. 5

To stop the foam slab during processing, a series of “pins” have been fitted to the uprights of the machine so that they can slide up and down when the slab is positioned; in practice, to assemble the slab, after making sure that it is as wide as the inside of the machine shoulders minus the thickness of the moulded support points, the latter are applied to the edges of the slab itself by sticking them in and then sliding them down into the slots of the uprights until the lower part of the slab touches the profiles of the base.

INSTALLATION AND USE

Now let’s see how to use the cutter: first of all we need to create the pattern of the object to cut and to do that we need to download from https://inkscape.org the latest version (at the moment 0.92.4) of Inkscape software. Then you have to install the FoamCutterPlugin plugin (downloadable from https://github.com/open-electronics/foamcutter) by copying the files contained in the .zipper file in the InkScape extensions folder (typically C:Program Files (x86)Inkscapeshareextensions).

Then open Inkscape and define the size of the document (Fig. 6), then draw or write in the area of the document what you want to get from the machine; in the example we propose we’ll print the Elettronica In logo, then write the text and place it in the lower left corner (Fig. 7).

Fig. 6

Fig. 7

Whether they are writings or drawings, in order to print them, in Inkscape they must be converted into paths using the appropriate command From object to path (for texts) or Vectorize bitmap (for images) accessible from the Path menu (Fig. 8).

Fig. 8

Subsequently, from the Extensions menu, the command FoamCutter is given (available because you have already installed the relative plugin for Inkscape) and this opens the procedure that allows you to obtain the G-code to be opened, when operating the machine, in the print client, starting from the created path. In the dialog box accessed (Fig. 9) it is possible to select where the G-code is to be created, the dimensions of the foam plate, the execution speed (a value of 300 mm / min is good for a polystyrene of approx. 1 cm), the power to be applied to the wire in percentage (25 is fine for a polystyrene of about 1 cm) and if the curves need to be rounded. In general, temperature and speed must be configured according to the thickness of the material to be cut. In any case, set the document properties according to the size of the polystyrene plate, foam or other material to be processed, in millimeters and apply the appropriate settings. For the example proposed, you must set the parameters as shown in Fig. 9, at least as regards the Setup tab.

Fig. 9

Leave the default settings in Usage for the moment and then click Apply; so confirm the plugin settings and exit the Inkscape extension, saving the created file and going to the print client for the next step. Inkscape will create the G-code related to the writing that we will print.

At this point, open Repetier Host and import the G-code you are interested in. First you need to configure the machine: from the Settings menu, select the virtual COM port to which the FoamCutter is connected and a communication speed of 115,200 baud (Fig. 10). Then:

• select the maximum cutting dimensions of the machine (480x500mm);

Fig. 10

• enable the visualization of the route (for this purpose click on the eye-shaped icon (Fig. 11);

Fig. 11

• after connecting and powering up the FoamCutter, from the Manual Control menu you can move the axes and bring them to Home (Fig. 12); Home for this machine corresponds to the X carriage towards the min endstop and the Y carriage at the top towards the min endstop); this configuration allows you to avoid breaking the wire and work the slab from above;

Fig. 12

• with the Load button you can import the G-code created (Fig. 13); the writing will be positioned near the home, then the object will be cut starting from the top, then reversed vertically.

Fig. 13

Now position the plate and bring the wire near the upper corner of this, then start the cut, waiting for the writing to be cut and at the end of the work remove the plate, taking care not to damage the nickel-chromium filament.

Here, your first realization will then be finished. Of course, this was a useful example to explain the procedure by which the graphic idea is passed to the creation of the G-code file, which will then be printed using the popular Repetier Host print client. Recall that the temperature of the hot wire can be varied with the client’s Fan slider, raising it if you want a higher cutting speed or if the filament is straining, or lowering it if not and if you see that the cut trace gets too wide.

FROM OPEN STORE

3D Printer Full Graphic Smart Controller with 3Drag adapter

The post Foamcutter appeared first on Open Electronics.

This project turns the ESP32-C6-Zero board into an IoT gateway. The device collects data from wireless sensors and forwards it onto the local network. In practice, it acts as a bridge between Bluetooth LE devices and the home Wi-Fi. All of this with low power consumption and a minimal footprint.

The board at the centre of the project is the heart of the system. The ESP32-C6-Zero development kit integrates an ESP32-C6 microcontroller with Wi-Fi 6 and Bluetooth LE radios. Having both radios is the key strength: the gateway can listen to BLE sensors and, at the same time, talk to the Wi-Fi router. Connectivity is therefore dual, and no additional hardware is needed.

The MicroPython firmware

The gateway software is written in MicroPython. The language simplifies managing network connections and reading radio packets. The code handles three main operations: initialising the two radios, listening for incoming messages from the sensors, and forwarding the data to the local server. All of it in a continuous, readable loop.

The source code is available in a public repository. The code repository contains the example sketches and the instructions for the first boot. Anyone who wants to replicate the project will also find the network configuration and the parameters to change in order to adapt the gateway to their own home network. What is more, the modular structure of the firmware lets you add new types of sensors without rewriting the whole program.

Handling the received packets is another carefully thought-out point. The gateway filters valid messages and discards corrupted or duplicate ones. For every valid data item, it creates a JSON payload and sends it over Wi-Fi. This approach makes the system robust even in environments with many active radio devices.

Power supply and consumption

The gateway’s power supply is flexible. The ESP32-C6-Zero board can be powered through the USB Type-C connector, which is useful during development and testing. For bench use, on the other hand, you can connect a LiPo battery to the power pins. This dual option makes the project suitable both for a fixed setup and for a portable device.

Consumption is kept low thanks to the power-saving features of the ESP32-C6 chip. The firmware can put the radio into sleep mode when there is no data to transmit. This way, the gateway can stay active for a long time even with a small-capacity battery. The project does not state precise battery-life figures, but the choice of components clearly aims at efficiency.

For anyone who wants to get started, the path is simple: all you need is an ESP32-C6-Zero development board and a USB cable. The kit includes integrated sensors and peripherals that help with the first tests. What is more, the presence of a USB Type-C connector makes programming convenient and fast.

The project lends itself to many practical uses. For example, it can become a network thermometer that collects data from several wireless probes. Or a door opener controlled from a smartphone via Bluetooth. The interesting thing is that the same hardware and software base adapts to different scenarios with just a few changes.

• Gateway for Bluetooth LE sensors
• Bridge between BLE network and Wi-Fi 6
• MicroPython firmware
• Powered via USB Type-C or LiPo battery
• Source code in the repository

The code repository is the starting point for anyone who wants to dig deeper. There you will find the firmware files and the configuration notes. The project demonstrates how a single board can handle two different radio protocols and become a useful node in a home automation network.

Source: https://github.com/RaemondBW/esp32-ant

The post ESP32-C6-Zero: a low-power IoT gateway appeared first on Open Electronics.

Quaddle is a mini desk-sized quadruped robot designed for physical AI experimentation. The project, by Dr. Rongzhong Li and funded on Kickstarter, uses the open-source OpenCat framework. It is available in three models: Builder, Buddy, and Scout. Its distinctive feature is the use of only 4 servos instead of the usual 8–12, which reduces cost and complexity without sacrificing movement.

The heart of the robot is an ESP32-S3FN8 motion core that manages the servos, LED PWM, buzzer, and gyroscope for balance and touch response. The servos with position feedback enable Puppet Mode: you guide the legs by hand and record movements without writing code. The Scout model includes an optional ESP32-S3R8 AI core for voice recognition and Smart Home control.

Performance and battery life

Quaddle reaches a top speed of 1.8 BodyLength/s at a trot and 3 BodyLength/s in a glide. Rotation in place reaches 90°/s. Dimensions vary: 11×7×7 cm for Builder and Buddy, 11×7×11 cm for Scout. Weight ranges from 170 grams for the Builder to 198 grams for the Scout.

Power comes from a replaceable BL10C 1800 mAh battery. Battery life ranges from 1.5 hours on the Builder model to 1 hour on the Scout, which has more sensors and an optional AI core. The project has already shipped over 30,000 robots to more than 60 countries, and two previous campaigns raised over 1 million dollars.

Sensors, extensions, and programming

An extension hat adds a touchpad, RGB LEDs, microphones, Grove connectors, a PIR sensor, and a UART port for Raspberry Pi. The Scout model features a sense core with infrared sensors, light sensors, gesture recognition, and optional AI vision. Everything is managed by the open-source OpenCat firmware, which you can explore in the code repository of Dr. Rongzhong Li.

Programming is versatile: OpenCat is based on Arduino, but the robot also supports Python, MicroPython, C++, ROS, ESPHome, and Xiaozhi AI. This makes it suitable for schools, hobbyists, and researchers. In addition, more than 20 academic papers cite the platform.

• ESP32-S3FN8 motion core for servos, LED, buzzer, and gyroscope
• Optional ESP32-S3R8 AI core on Scout for voice recognition
• Hat with touchpad, RGB LEDs, microphones, Grove, PIR, and UART for Raspberry Pi
• Sense core on Scout with infrared, light, gestures, and AI vision
• Puppet Mode to record movements without code

The Kickstarter campaign has a funding goal of $50,000. The Builder model is priced at $99 (list price $149), the Buddy at $139, and the Scout at $199. Shipping costs $15 to most of the world and $18 to the European Union. Rewards are scheduled for delivery in December 2026.

For those who want to get started, the Builder model is the most affordable and lightweight. If you are looking for AI features and advanced sensors, the Scout offers the complete package. All models share the same motion core and OpenCat firmware, so the programming foundation remains identical.

Source: https://github.com/PetoiCamp/OpenCat-Quadruped-Robot

The post Quaddle: A Mini Quadruped Robot for Physical AI appeared first on Open Electronics.

GreenPaks have always been in a unique market niche. Not exactly programmable as one would expect from full-blown FPGA or CPLD (except their ForgeFPGA brethren), but insanely small and often with many cool extra features, like dual-voltage I/O, wide voltage span (usually from 1.7V to 5.5V) built-in ADCs, DACs, I2C, SPI etc even power MOSFET switches or half-bridges and 12V capability etc etc. Newest one doesn't do much of that, but it's even more insanely tiny- just 1.6x1.5mm in 12-pin STQFN or LESS THAN 1.2x1.2mm in 9-ball WLCSP! Thing has I2C, couple oscillators, works at 1.7-5.5V, up to two high(er) voltage I/O pins, some 3-input LUTs with D flip-flops, counters, analog comparators etc etc. Renesas SLG-46801 submitted by /u/Camper_Sly [link] [comments]

submitted by /u/Linker3000
[link] [comments]

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

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

From choosing the animal to the first print

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

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

An exhibition you can touch and open

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

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

Mistakes on display: the educational value of failure

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

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

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

Related products

• Servo shield

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

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

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

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

Factory parameters

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

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

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

Let’s look in detail:

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

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

Configuring the GSM library parameters

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

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

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

Supported command strings

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

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

The system password

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

PWDxxxxx;pwd

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

PWD3325;12345

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

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

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

Saving and deleting phonebook numbers

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

NUMx+39nnnnnnnnnnn;text;pwd

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

NUM2+393474131177;”Rossi”;33225

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

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

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

NUMx;pwd

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

NUM2;33225

Reading the phonebook

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

NUM?;pwd

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

NUM?;33225

You get the following response:

# Command received by user -> NUM?;33225

# Command “NUM?” processed successfully

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

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

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

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

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

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

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

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

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

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

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

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

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

ANUM?;pwd

Running the command produces the following response:

# Command received by user -> ANUM?;33225

# Command “ANUM?” processed successfully

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

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

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

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

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

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

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

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

…….

…….

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

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

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

FNUM?;text;pwd

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

FNUM?;Rossi;33225

The following response is obtained:

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

# Command “FNUM?” processed successfully

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

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

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

# Command “FNUM?” processed successfully

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

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

Deleting SMS messages from memory

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

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

DSMSx;pwd

DASMS;pwd

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

SMS notifications and voice calls for inputs

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

SMSxxxxxxxx:ON;pwd

SMSxxxxxxxx:OFF;pwd

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

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

SMS1357:ON;33225

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

SMS2468:OFF;33225

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

VOCxxxxxxxx:ON;pwd

VOCxxxxxxxx:OFF;pwd

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

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

# Command “SMS” processed successfully

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

# Command “SMS” processed successfully

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

# Command “VOC” processed successfully

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

# Command “VOC” processed successfully

Input activation level

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

LIVx:A;pwd

LIVx:B;pwd

LIVx:V;pwd

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

LIV1:A;33225

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

LIV?

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

# Command received by user -> LIV?

# Alarm activation level for input 1: HIGH

# Alarm activation level for input 2: HIGH

# Command “LIV?” processed successfully

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

Inhibition and observation time

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

INIx:mm;pwd

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

INI?

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

# Command received by user -> INI?

# Alarm inhibition time for input 1: 10

# Alarm inhibition time for input 2: 5

# Command “INI?” processed successfully

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

TIZ1x;pwd

TIZ2x;pwd

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

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

OSSx:ss;pwd

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

OSS?

which returns:

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

Alarm message text

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

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

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

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

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

TIN1A:Bilge flood alarm!!;33225

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

ALNy:xx;pwd

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

ALN1:5;33225

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

ALN?

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

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

Digital output management

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

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

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

OUT1:ON;33225

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

OUT1:30;33225

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

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

STA?

Executing the command returns the following:

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

Periodic report SMS

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

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

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

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

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

AUTOC?

Which, when executed, returns the following:

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

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

FORS:x;pwd

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

Output state recovery and startup SMS

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

RIPx;pwd

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

RIP?

Which, when executed, returns the following:

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

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

AVVx;pwd

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

TSU:xxxxxxxxxxxx;pwd

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

TSU:Telecontrol StartUp! Have a nice day;pwd

Gate opener function and ECHO

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

TAC:ss;pwd

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

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

ECHO:x;pwd

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

System information commands

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

QUAL?

which returns:

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

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

OPER?

which returns:

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

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

REV?

which returns:

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

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

Power failure and power restoration SMS

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

PWRFx;pwd

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

PWRRx;pwd

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

TPWPF:xxxxxxxxxxxx;pwd

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

TPWPB:xxxxxxxxxxxx;pwd

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

Restoring factory parameters

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

RES;pwd

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

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

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

Multiple commands and silent response

Let’s make a few more small considerations:

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

qual?,oper?,rev?

The response is:

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

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

Managing the GSM shield LEDs

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

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

Conclusions

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

Related products

• GSM/GPRS SIM900 Shield for Arduino

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

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

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

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

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

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

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

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

Software and programming with Arduino IDE

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

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

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

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

Numbers and limits of a 21-gram satellite

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

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

Here are the key components of the project:

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

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

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

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

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

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

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

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

Why cuffless BP monitoring matters

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

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

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

The engineering challenge behind the vision

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

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

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

A practical engineering path to cuffless BP device innovation

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

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

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

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

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

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

Why custom hardware becomes necessary

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

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

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

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

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

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

The role of AI and data in cuffless BP monitoring

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

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

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

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

The road ahead

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

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

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

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

Frequently Asked Questions (FAQs)

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

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

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

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

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

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

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

Related Content

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

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

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

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

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

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

DFEs ease design

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

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

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

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

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

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

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

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

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

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

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

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

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

GaN is still the PA of choice

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

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

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

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

RedCap 5G reaches maturity

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

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

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

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

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

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

AI-enabled RF modems

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

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

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

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

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

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

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