Build an IoT-Based Solar Panel Monitor

Using the Sigfox LPWAN

In this project article, Pedro details how to make an end-to-end IoT device for monitoring electrical energy generated by solar panels, to monitor exactly how much electrical energy is being generated to recharge a battery. For wireless communication to send data to the cloud, the system uses Sigfox LPWAN communication.

The demand for renewable energy to supply a great variety of electronic devices has increased in recent years. This is justified both by the need to generate electrical energy in a sustainable way, and the need to have an environmentally friendly complement to current power sources for electronic devices. Among all methods of producing electrical energy in a renewable way, solar energy—generated through solar panels and auxiliary circuitry—is one of the best ways to reach this goal. Consider that, in most of the places on planet Earth, every day there is some useful sunlight to be converted to electrical energy.

Taking advantage of this huge (and free) amount of renewable energy to produce electrical energy is, therefore, the key to supplying power to recharge batteries in electronic and embedded devices, mainly in remote places where other power sources are not available. But how to know for sure how much electrical energy can be produced in a certain place, to be used to recharge batteries? How can it be remotely monitored using the Internet? These are the questions this article will answer, proposing an end-to-end IoT solution to monitor the useful electrical energy generated by solar panels, using an embedded device, Sigfox LPWAN and TagoIO IoT platform. All software involved in this project is open source, and is hosted on my project GitHub repository at [1].

REDFOX DEVELOPMENT KIT

This project uses the RedFox development kit for housing the Sigfox transceiver (HT32SX) and main programmable module (Arduino Nano V3). This kit was developed by Brazilian engineer Luiz Henrique Corrêa Bernardes [2]. The RedFox development kit is shown in Figure 1.

RedFox uses a HT Micron HT32SX SiP (system-in-package) running an AT Command interpreter plus Sigfox communication firmware as Sigfox transceiver. This kit contains a PCB antenna for Sigfox, highlighted in orange in Figure 1. The HT32SX SiP is highlighted in green. The user programs the main application in Arduino Nano V3 board (plugged-in in the area highlighted in blue), commanding Sigfox communication in HT32SX through AT Commands sent by a software UART. All HT32SX documentation, examples and AT commands can be found in the HT32SX GitHub repository at [3]. The hardware parts list for the project is shown in Table 1.

The following software tools are used in the project:

• Arduino IDE (1.8.13 or later)
• A common browser (for interaction with TagoIO IoT platform and Sigfox backend)
• Adafruit library for INA219 [4]

PROJECT OVERVIEW

This is an end-to-end IoT project, from the embedded device side to the cloud (IoT platform) side. The solution proposed here is capable of performing the following actions:

1. Periodically (every second) measure useful instant voltage (V), useful instant current (mA) and useful electrical energy (kWhour) generated by solar panels; and accumulate the amount of useful electrical energy (kWhour) generated until that point. All this useful electrical energy generated is used to recharge a single-cell (3.7V) Li-ion battery.
2. Periodically (every 30 minutes) send via Sigfox the useful instant voltage (V), useful instant current (mA) and send the total amount of useful electrical energy generated (kWhour).
3. Allow total electrical energy measurement value to be reset (set to 0) using the RedFox board push-button.
4. Manage HT32SX power consumption, by putting it into deep sleep mode when Sigfox transmission isn’t required.
5. Automatically (and securely) redirect all the data received in Sigfox backend to TagoIO IoT platform.
6. Parse all data received via Sigfox into variables in the IoT platform.
7. Show parsed data in a dashboard.

Since Sigfox communication is used to send all the data from the embedded device to the cloud, the distance between the embedded device and the Sigfox gateway can be huge (greater than 10km). The project overview is diagrammed in Figure 2.

EMBEDDED SIDE

The embedded side of this project includes the following topics: Sigfox and why it’s a good choice as wireless communication for this project, schematics (connectivity diagram), an overview of a Texas Instruments (TI) step-down LM2596 module, an overview of an INA219 module and highlights of embedded software (programmed into Arduino Nano V3).

Sigfox is an IoT network operator. The company’s sub-GHz, narrow-band and world-wide LPWAN (low-power wide-area network) is based in France, present in 72 countries and is currently being used by 17.6 million electronic devices around the world. Sigfox is meant to be used in solutions where small data amounts (up to 12 bytes) are required to be sent to the cloud, when the device is distant kilometers away from a Sigfox gateway (in practical terms, greater than 10km), using low electrical energy for this. Once data is received by a Sigfox gateway, the data is stored into the Sigfox backend, where it can be automatically and securely redirected to any cloud service you choose (IoT platforms, Google Sheets spreadsheet, email and so forth). With all that in mind, Sigfox works as an integration piece among embedded devices not capable of establishing direct Internet connection and cloud platforms (Figure 3).

Regarding frequencies and signal gain allowed, because Sigfox is a world-wide LPWAN and RF regulations may differ from country to country, Sigfox split the world into seven different zones of communications (from RC1 to RC7) listed in Table 2. Once a zone is correctly configured according to the country where the Sigfox transceiver is located, every Sigfox transceiver can work within all Sigfox-covered areas in that country.

From development and product manufacturing standpoints, Sigfox presents some good features considering its usage in embedded devices.

1. All gateway and backend infrastructures are provided by the Sigfox company and its distributors. That means developers don’t need to worry about this on their solutions. Once Sigfox coverage is present in the area of interest and the Sigfox transceiver is activated in the Sigfox network, it will work out of the box.
2. Sigfox plans are a lot cheaper than available 3G/4G plans, especially in plans where just one message per day is allowed;
3. Every Sigfox message is sent in three different frequencies, so as to reach up to three Sigfox gateways. This significantly increases the chance of messages being received for at least one Sigfox gateway, increasing Sigfox robustness as a wireless communication solution. In Brazil, for example, there are cases of a Sigfox message being received by a gateway 80km (50 miles) away from the transceiver;
4. Usually, Sigfox transceivers use a simple UART interface for communication with an embedded device (usually using AT commands). Since nearly all microcontrollers (MCUs) available today have at least one UART interface available for general purpose communication, Sigfox transceiver integration is straightforward and easy to do in hardware and embedded software.

If you want to check if there is Sigfox coverage in a particular area, Sigfox world-wide coverage is shown at the webpage url www.sigfox.com/en/coverage. The connectivity diagram for this project is shown in Figure 4. Note that Li-ion batteries (as LiPo batteries) present explosion and fire hazards when overheated. Their upper temperature limit is about 140°F (60°C). Therefore, it’s strongly recommended that you protect the battery (in a plastic case with grooves, for example) from potential heat sources and from exposure to direct sunlight.

OVERVIEW: LM2596 AND INA219

LM2596: The LM2596 module (Figure 5) is an adjustable step-down converter. All the required auxiliary circuitry is attached, making it easy to use. This module supports up to 40V input, can output up to 35V, and its minimum voltage dropout (difference between input voltage and output voltage) is 1.5V.

In this project, the nominal solar panel voltage is 12V, and the battery charger module (TP4056) requires 5V input voltage, making this step-down converter a good choice for this application. If you aren’t familiar with step-down converters, you may be wondering: “Why can’t I just use a simple linear voltage regulator (such as the LM7805) to drop 12V down to 5V?” In fact, you can, but you shouldn’t. Step-down converters are much more efficient than linear regulators, and solar panels aren’t known for being particularly efficient. Because any power loss should be prevented, the step-down converter is a good method of converting 12V to 5V.

Because this step-down module is adjustable, a calibration/adjustment must be done to set output voltage at 5V before use in this project. To do this, we must simulate a 12V input (which we expect a solar panel to generate), and adjust the output voltage of 5V in the module’s potentiometer. The output voltage adjustment potentiometer is highlighted in red in Figure 5.

The calibration/adjustment procedure is performed in three steps. First, connect a reliable 12V power source to the module voltage input (+12V at IN+ input and GND in IN- input). Second, put a reliable multimeter in DC voltage measurement mode, and check module output voltage. Be careful with the LM2595 module output voltage polarity. Third, turn the potentiometer right or left until the output voltage (measured in the multimeter) is 5V.

INA219: It’s pretty clear that this project requires voltage and current measurement, right? For such tasks, this project uses an INA219 current sensor module (Figure 6). With this module, voltage and current can easily be measured. The INA219 module communicates with the external world using an I²C interface.

The INA219 measures DC voltages from 0V to 26V and current from -3.2A to +3.2A. Since this project requires useful voltage and useful current measurement, both of which are used to recharge the single-cell Li-ion battery (3.7V, and usually less than 1A of recharge current), the INA219 is a good match for the required electrical measurements.

Besides the INA219 chip, itself, this module contains a 0.1Ω shunt resistor and a KRE connector/screw connector to wire the module to the load. This connector is shown in green in Figure 6. The load must be series wired to the module shunt resistor through VIN+ and VIN- pins. Figure 4 shows how to wire the load to this module.

• Figure 5
• Figure 6

EMBEDDED-SIDE SOURCE CODE

As noted previously, the source code for this project refers to what will be programmed into the Arduino Nano V3 board. The HT32SX SiP can support an application to be programmed in it. However, the RedFox kit uses it as a Sigfox transceiver controlled by AT commands, thus allowing Sigfox message transmitting and receiving using AT Commands through UART communication.

Once the Arduino Nano V3 board is the target for embedded-side software, this piece of software is developed using Arduino IDE software. In fact, this brings an upside to this project. Because there are versions of Arduino IDE for several operational systems (Windows, Mac OS and Linux distros for PCs and Arm boards) Arduino IDE is a truly multi-platform development environment. This means project embedded software can be developed, modified/edited and flashed, using almost any computer and operating system you can imagine.

Since Arduino IDE is the development environment used for this project, it also defines the programming languages—a mix of C and C++. The project’s firmware uses C programming language, whereas the INA219 library by Adafruit uses C++. The embedded software can be found in its entirely in the project’s GitHub repository [1]. Certain features of this project’s embedded software are detailed next.

Because the Arduino Nano V3 board uses a Microchip Technology ATmega328P MCU, it has only one hardware UART interface. This UART is used for programming the MCU and to show textual messages in the Serial Monitor tool (or any other serial terminal you prefer). This forces the usage of the SoftwareSerial library from Arduino to communicate between the Arduino Nano V3 board and the HT32SX SiP, as shown in Listing 1. Although this is not the ideal solution for a UART communication (SoftwareSerial is slower than a hardware UART and consumes much more CPU processing and RAM), it works fine for the sporadic communication of AT commands at 9600/N/8/1 configuration.

The code in Listing 2 is used to ensure that the whole TX buffer has been sent to the HT32SX SiP through the software UART before proceeding with software. In this code snippet, the flush() method in software serial eliminates any chance of sending an incomplete or overridden TX buffer to HT32SX.

The Arduino Nano V3 MCU (ATmega328P) cannot properly support an RTOS (such as FreeRTOS) due to its limitations in SRAM. To ensure good embedded software performance and avoid blocking delays in the code, every action is triggered based on total ticks (which equals the MCU “timestamp” since it has been powered-up) and actions temporization. This works like a very simple task scheduler, but is fine for its purpose. The code in Listing 3 (extracted from breathing light routine) shows how this simple task scheduler works.

As previously mentioned, the Sigfox payload size in uplink messages—messages sent from device to Sigfox gateway—is only 12 bytes long. This means that some compression or some extra work at the bits and bytes level should be done to ensure that all data will fit the payload maximum size.

The 12-byte payload is enough for the data to be sent in this project. But some extra byte work was done and the total data size was reduced to only 7 bytes long. The only thing that remained untouchable is the total electrical energy generated (4 bytes, float type), in order to ensure good value precision. The code in Listing 4 shows how that byte work was done in this project.

Listing 1
SoftwareSerial library is used to communicate between the Arduino Nano V3 board and the HT32SX SiP.

#define TX     2   /* Serial TX (Nano -> HT32SX) */
#define RX     3   /* Serial RX (Nano <- HT32SX) */

…

SoftwareSerial serial_HT32SX(RX, TX);
…
#define BAUDRATE_SERIAL_DEBUG   115200 /* Hardware UART */
#define BAUDRATE_SERIAL_HT32SX  9600  /* Software UART */

Listing 2
This code ensures that the whole TX buffer has been sent to the HT32SX SiP through the software UART before proceeding with software.

void  send_AT_command_HT32SX(char * pt_command)
{
      char cmd_buffer[50] = {0};
      memcpy(cmd_buffer, pt_command, strlen(pt_command));
      serial_HT32SX.write(cmd_buffer, strlen(cmd_buffer));
      serial_HT32SX.flush();
}

Listing 3
This code shows how this simple task scheduler works.

/* Turn breathing light on and off */
    if (time_difference_ms(timestamp_breathing_light) >= TIME_BREATHING_LIGHT_ON_OFF)
{
        if (is_nano_board_led_on == false)
        {
              digitalWrite(LED, HIGH);
              is_nano_board_led_on = true;
        }
        else
        {
              digitalWrite(LED, LOW);
              is_nano_board_led_on = false;
        }
        
        timestamp_breathing_light = millis();
}

Listing 4
This code shows the modifications done to keep the payload size small.

/* Instant voltage and instant current are truncated to 1 byte and 2 bytes values
   (in order to save space among bytes to be send via Sigfox) */
instant_voltage_byte = (unsigned char)(instant_voltage_generated_V*10.0);
instant_current_bytes = (short)(instant_current_generated_mA*10.0);      
/* Formats AT command string and sends it via UART to HT32SX SiP */

sprintf(at_command_string, "%s%08lx%02x%04x;", CMD_AT_HT32SX_SEND_BYTES, 
total_electrical_energy_generated_kwh,
instant_voltage_byte,
instant_current_bytes);

CLOUD SIDE

The cloud side of this project includes the following topics: Sigfox backend quick explanation; Sigfox callbacks quick explanation; TagoIO IoT platform quick explanation; creating a TagoIO account; Sigfox backend and TagoIO integration; TagoIO data parser and creating a dashboard for this project.

The following discussion assumes your Sigfox transceiver is already activated in the Sigfox network. The activation procedure may vary from transceiver to transceiver, and should be done according to the manufacturer’s instructions. For the RedFox development kit, this procedure is described (in Portuguese, with screenshots in English) at [5].

Sigfox backend: Once your Sigfox transceiver is activated in the Sigfox network, you have access to Sigfox backend. In short terms, Sigfox backend is a cloud service provided by the Sigfox company. It allows devices, device groups, messages and message redirection management. The Sigfox backend web address available at https://backend.sigfox.com.

Useful information regarding communication can be achieved in Sigfox backend (as shown in Figure 7), such as link quality indicator and estimated radius (distance), obtained from the last message received from the Sigfox transceiver. In addition, Sigfox backend offers a transceiver geolocation estimator, which is useful for replacing a GPS in situations where geolocation doesn’t need to be exact—for example, identifying the city where the transceiver is located.

Other interesting information that can be obtained includes the raw messages sent and their details. These details indicate how many Sigfox gateways have received the message, all frequencies that the message has been received in each gateway, SNR, RSSI and message timestamp (Figure 8).

Sigfox callbacks—quick explanation: Another useful tool offered by Sigfox backend is the message callback. A message callback is a resource automatically triggered when a message sent from the transceiver comes in the backend, allowing automatic redirection of the data received to another cloud platform, email, Google Sheet spreadsheets and so on. These message callbacks use secure data transmission, using HTTPS, auth-tokens and other particular security measures required by some cloud platforms. Figure 9 shows some examples of allowed callbacks in the Sigfox backend.

• Figure 7
• Figure 8
• Figure 9

TagoIO IoT platform—quick explanation: TagoIO is an American IoT platform, located in Raleigh, NC. Briefly, TagoIO is a robust, scalable and easy-to-learn IoT platform. It doesn’t require any special coding or cloud skills from developers to configure and operate it. Therefore, TagoIO is a good choice if you want a short time-to-market for your IoT project, and don’t want to need “rocket science skills” to configure and operate it. TagoIO doesn’t have lots of fancy or heavy-processing resources like AWS or Microsoft Azure have, but it offers the resources that any scalable and robust IoT project requires.

Also, TagoIO offers a good free plan, allowing you to explore a lot of what TagoIO can do, so you can assess whether this IoT platform is a good fit for your solution. It includes dashboards, full analytics/data post-processing, scheduled actions, alert/alarm creation (sending emails, SMS, HTTP requests to external services), easy integration with LPWANs (such as Sigfox) and so on. For more details, see www.tago.io.

Creating a TagoIO account: To create an account in TagoIO IoT platform, you first register your account at https://admin.tago.io/signup, filling the fields in the form. Use a valid email account address. It will be needed to activate your TagoIO account. Next, after account registration, you’ll receive an email from TagoIO to activate your account. Follow the steps provided in the email. Last, log in to your account. You’ll be redirected to a page asking if you’re a new or experienced TagoIO user. Select the option I already know TagoIO if you want to skip the beginner’s tutorial about TagoIO, or select I’m new at TagoIO if you want to learn the basics about the TagoIO platform. Your TagoIO account is now ready for use.

Sigfox backend and TagoIO integration: It’s possible to integrate Sigfox backend and TagoIO IoT platform, to automatically redirect data received from devices to IoT platform. This is done using Sigfox messages callbacks, in a secure way, using auth-tokens and HTTPS. This integration is well explained in [6].

TAGOIO DATA PARSER

Once Sigfox backend and TagoIO have been integrated using messages callbacks, all data received from Sigfox backend must be parsed into variables to be used in TagoIO IoT platform. Basically, parsing data here means inputting the incoming data into a routine programmed (in JavaScript) inside the IoT platform. This splits the data into proper variables and writes them into a device-variables database (called Bucket) for further usage.

In this project, the data size is 7 bytes long, with segmentation as follows:

• From byte 0 to byte 3: Total useful electrical energy generated by the solar panels (float value, big endian), in kWh.
• Byte 4: Instant useful voltage generated by the solar panels, multiplied by 10 (char or int8 value), in V.
• From byte 5 to byte 6: Instant useful current generated by the solar panels multiplied by 10 (short or int16 value, big endian), in mA.

In this case, both useful instant voltage and useful instant current have been sent via Sigfox multiplied by 10. Therefore, one of the most important things this parser must do is to divide both values by 10 before attributing them to variables and storing them in the device bucket.

The parser code (written in JavaScript) is shown in Listing 5. To insert this parser code in the TagoIO platform, follow this procedure:

1. Click on the Devices button, located on the left side of the screen.
2. In the device management screen, click on your Sigfox device name.
3. In the device information screen, click on the Payload Parser tab.
4. Enable the Run your own parser option.
5. Once Run your own parser option is enabled, a text field will show right below. Paste the parse source-code into this text field.
6. Click on the Save button.

Listing 5
The parser code (written in JavaScript) is shown here.

const payload_raw = payload.find(x => x.variable === ‘data’);
 
if (payload_raw) {
 try {
   const buffer = Buffer.from(payload_raw.value, ‘hex’);
 
   /* Parse all data received. This includes consider its endianness
      and value conditioning (in this case, divide both instant voltage
      and instant current values by 10) */
   const total_useful_electrical_energy = buffer.readFloatBE(0);
   const instant_useful_voltage = buffer.readUInt8(4)/10.0;
   const instant_useful_current = buffer.readInt16BE(5)/10.0;
 
   /* Save parsed data into variables to device bucket */ 
   const data = [
     { variable: ‘total_useful_electrical_energy’, value: total_useful_electrical_energy, unit: ‘kWh’ },
     { variable: ‘instant_useful_voltage’,  value: instant_useful_voltage, unit: ‘V’ },
     { variable: ‘instant_useful_current’,  value: instant_useful_current, unit: ‘mA’ }
   ];
 
   payload = payload.concat(data.map(x => ({ ...x, serie: payload_raw.serie, time: payload_raw.time })));
 } catch (e) {
   console.error(e);
   payload = [{ variable: ‘parse_error’, value: e.message }];
 }
}

Now, all device data received in TagoIO from the Sigfox backend will be automatically parsed into variables in the device bucket.

CREATING THE DASHBOARD

Now it’s time to show all the variables parsed in a fancy way. To do this, a dashboard showing total useful electrical energy generated (kWhour), useful instant voltage (V) and useful instant current (mA) must be created into the TagoIO account. To create a dashboard for this project, follow the steps below:

1) On the left side of the screen, click on the + button (located next to “Dashboards”).

2) A pop-up window will be shown, asking for the dashboard name and dashboard type. Fill-in the dashboard name with Electrical energy – solar panels, and for dashboard type select Normal type. Click on the Create my Dashboard button.

3) An empty dashboard will be created. Now, it’s time to add widgets for this dashboard. A widget is a component of the dashboard that is able to show a variable in a specific format. Click on the Add widget button (or on + on top-right side of the screen).

4) A pop-up window will be shown, asking for the type of widget you would like to add. Select Display type.

5) A pop-up window will be shown, asking what device and variable must be displayed in this Display widget. Fill the form fields as follows:

Title: Instant voltage
Device: Select your Sigfox device (if you’re using TagoIO for the first time, it will be the only device available in the list).
Variable: Type instant_useful_voltage (it’s the same as the name of the variable generated/parsed in device parser).

On the right side of this screen, click on the Data Range & Format tab, and change Decimals field value to 1. It will make useful instant voltage be shown with 1 decimal only. Click on the Save button.

At this point, the widget to show instant useful voltage value is ready to work.

You may observe a “No data available” text inside this widget. It means no data has been received by the Sigfox device and parsed into variables yet.

6) Do the same thing for useful instant current. In this case, use the following to fill the widget’s required information:

Title: Instant current
Device: Select your Sigfox device
Variable: Type instant_useful_current

7) Also, do the same thing for Total useful electrical energy. In this case, use the following to fill the widget’s required information:

Title: Total electrical energy
Device: Select your Sigfox device
Variable: Type total_useful_electrical_energy

8) Depending on the solar panels and the output current they can supply, total electrical energy generated in kWhour may take longer to reach 0.1kWhour (and consequently multiples of 0.1kWhour). Therefore, go to the Data Range & Format tab and change Decimals field value to 5.

9) The project dashboard is now complete! Click on the Eye icon on the top-right side of the dashboard. It will finish dashboard edit mode and start dashboard view mode. At this point, the dashboard will show the last total useful energy generated (kWh), useful instant voltage (V) and useful instant current (mA) values as soon as they have been received and parsed by TagoIO.

This project dashboard will look like the one shown in Figure 10. Using this dashboard, you can determine how much electrical energy is being generated, and you’ll get valuable information to correctly size and build real solar-powered battery chargers for a real solution.

EXPLORING THE IoT PLATFORM

TagoIO can do much more than just display values. You can go way beyond what has been shown here, adding features to your IoT solution that surely will make it much more robust and versatile. To open your mind to what else can be done, here are some suggestions for what you can do next with TagoIO resources and the project for monitoring electrical energy generated by solar panels.

You can explore new types of widgets, such as: VU Meter, Line charts, Angular, Dial and Solid. You aren’t limited to working only with the received data. TagoIO IoT platform allows you to write scripts (in JavaScript programming language) to handle all your data and calculate new things, such as mean useful instant voltage, mean useful instant current, maximum useful instant current in the last day, and so on. This resource is called Analysis.

Also, you can create alerts/alarms to detect when something unexpected happens (for example, useful instant voltage value is too high, and useful instant current value is too low). When certain conditions are satisfied, an email, SMS message or push notification can be sent, so you’ll know immediately if something wrong happens, and can quickly mitigate what’s wrong. This resource is Action.

CONCLUSION

I’ve explained how to monitor the total amount of electrical energy generated by solar panels. I used Sigfox LPWAN as wireless comms to ensure low energy demanding and long-range wireless communication when sending data to the Cloud. This is an end-to-end project, from the embedded side (hardware and software) to the cloud side, using TagoIO as the IoT platform. You can use this project to determine how much electrical energy can be generated (to recharge one single-cell 3.7V Li-ion battery) in given conditions—size of solar panels, location, weather conditions and so on. Then you’ll obtain valuable information for correctly sizing and building real solar-powered battery charges for a real solution.

Using this project as a starting point, you can then expand on it to monitor other variables—such as ambient temperature and relative air humidity—or modify it to monitor anything you’d like. The Sigfox LPWAN is appropriate mainly when battery-powered devices are used. Sigfox communications has low electrical energy demands for transmitting data and can communicate with devices 10km (or more) away from a Sigfox gateway. 

RESOURCES

References:
[1] GitHub repository https://github.com/phfbertoleti/electrical_energy_monitoring_sigfox
[2] Luiz Henrique Corrêa Bernardes, “IoT Sigfox Com Edukit RedFox”, Instituto NCB, 2021.
[3] iHub repository: https://github.com/htmicron/ht32sx
[HT32SX SiP datasheet:
https://github.com/htmicron/ht32sx/blob/documents/HTSXMO32L%20Datasheet/DS001%20Rev.05%20-%20Datasheet%20HT32SX%20V2.2_24032021.pdf
HT32SX SiP AT Commands sheet
https://github.com/htmicron/ht32sx/blob/documents/Application%20Notes/AN0006%20-%20AT%20Commands.pdf
[4] Adafruit library for INA219  https://github.com/adafruit/Adafruit_INA219
[5] For the RedFox development kit, this procedure is described (in Portuguese, with screenshots in English idiom) at this link: https://www.newtoncbraga.com.br/arquivos/edukit_redfox_ativacao.pdf
[6]. https://docs.tago.io/en/articles/33-sigfox

Arduino | www.arduino.cc
HT Micron | www.htmicron.com.br
Microchip Technology | www.microchip.com
Sigfox | www.sigfox.com
TagoIO | www.tago.io
Texas Instruments | www.ti.com

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • NOVEMBER 2021 #376 – Get a PDF of the issue