This guide shows how to read temperature from multiple DS18B20 temperature sensors with the ESP32 using Arduino IDE. We’ll show you how to wire the sensors on the same data bus to the ESP32, install the needed libraries, and a sketch example you can use in your own projects. This tutorial is also compatible with the ESP8266 and the Arduino boards.
The Arduino Core for ESP8266 and ESP32 uses one SPI flash memory sector to emulate an EEPROM. When you initialize the EEPROM object (calling begin) it reads the contents of the sector into a memory buffer. Reading a writing is done over that in-memory buffer. Whenever you call commit it write the contents back to the flash sector.
Due to the nature of this flash memory (NOR) a full sector erase must be done prior to write any new data. If a power failure (intended or not) happens during this process the sector data is lost.
Also, writing data to a NOR memory can be done byte by byte but only to change a 1 to a 0. The only way to turn 0s to 1s is to perform a sector erase which turns all memory positions in that sector to 1. But sector erasing must be done in full sectors, thus wearing out the flash memory faster.
The power supply of my Amiga 500 is a bit unreliable. I’ve had some issues with the machine where the PSU could be the culprit, so I thought that it would be better to get a new power supply. There are used Amiga 500 power supplies occasionally available on online auctions, and there are also unused (but probably quite old) power supplies available on some online retailers. The issue with these 20-30 year old power supplies is that the capacitors are starting to dry. This can be a fire hazard, as old capacitors may even explode (this has happened to the PSU of my old IBM XT, it was not a pleasant experience). So in order to get safe and reliable operation from an old PSU, the capacitors should be replaced.
A visiting researcher dropped by our humble basement workshop with questions about the physical skill level students would need if they added one of our DIY data loggers to their environmental curriculum. I figured the easiest way to cover that was to simply build one, while they recorded the process.
The result of that 3 hour session is now available on YouTube
This tutorial is inspired by dg0opk’s videos and blog post on monitoring QRP with single board computers. We’ll show you how to set up a super cheap QRP monitoring station using an RTL-SDR V3 and a Raspberry Pi 3. The total cost should be about US $56 ($21 for the RTL-SDR V3, and $35 for the Pi 3).
With this setup you’ll be able to continuously monitor multiple modes within the same band simultaneously (e.g. monitor 20 meter FT8, JT65+JT9 and WSPR all on one dongle at the same time). The method for creating multiple channels in Linux may also be useful for other applications. If you happen to have an upconverter or a better SDR to dedicate to monitoring such as an SDRplay or an Airspy HF+, then this can substitute for the RTL-SDR V3 as well.
James Lewis over at Bald Engineer writes, “For an AddOhms series, I created a DIY Arduino I am calling the “Pyramiduino.” It is an ATmega328p based board in the shape of a triangle. Other than being cute, the shape does not offer any other benefit. The design features a 3.3 volt LDO Regulator, which is also the subject of this post.”
A how-to on building a time attendance system with MFRC522 RFID Reader and Arduino from Random Nerd Tutorials:
Before getting started it’s important to layout the project main features:
*It contains an RFID reader that reads RFID tags;
*Our setup has a real time clock module to keep track of time;
*When the RFID reader reads an RFID tag, it saves the current time and the UID of the tag in an SD card;
*The Arduino communicates with the SD card using an SD card module;
*You can set a check in time to compare if you are in time or late;
*If you are on time, a green LED lights up, if you are late, a red LED lights up;
*The system also has a buzzer that beeps when a tag is read.
Felix writes, “I posted a short illustrated guide for making your own Moteino from SMD components. It also includes details how to burn the bootloader and fuses. Check it out here. Thanks and credit goes to forum user LukaQ for his contribution of the images and test sketches in this guide!
Dejan Nedelkovski over at HowToMechatronics shared detailed tutorial on how servo motors work and how to control servos using Arduino and PCA9685 PWM driver:
There are many types of servo motors and their main feature is the ability to precisely control the position of their shaft. A servo motor is a closed-loop system that uses position feedback to control its motion and final position.
In industrial type servo motors the position feedback sensor is usually a high precision encoder, while in the smaller RC or hobby servos the position sensor is usually a simple potentiometer. The actual position captured by these devices is fed back to the error detector where it is compared to the target position. Then according to the error the controller corrects the actual position of the motor to match with the target position.
In this tutorial we will take a detailed look at the hobby servo motors. We will explain how these servos work and how to control them using Arduino.
In the previous posts I explained how to receive and send advertising packets based on the Bluetooth LE standard.
The payload (that is the amount of “useful” data) of those packets is at most 31 bytes. It isn’t much: if – for example – you want to include the device name, little place remains for other data.
The BLE standard allows peripherals to send additional data using the scan request – scan response process.
When a device receives an advertising packet, it can contact the transmitter by sending a scan request packet to request further information. When receiving a scan request package, the peripheral can respond with a scan response packet:
Advertising and scan request packets have the same format; it’s therefore possible to transfer, using scan response, additional 31 bytes of data.
The esp framework offers two modes for configuring the content of a scan response packet: using the esp_ble_adv_data_t struct or creating a byte array (raw mode). These modes are similar to the ones used to configure advertising packets you learned in previous articles (struct and raw mode).
In the first case, you have to declare a second struct, in addition to the one related to the advertising packet, to define the content of the scan response packet:
Very important is set to true the set_scan_rsp parameter. It’s indeed this parameter what tells the driver that this struct is related to the scan response packet.
You can then pass the new struct to the driver, with the same function used previously:
The driver will call the callback function twice: one to indicate the successful configuration of the advertising packet and one for the configuration of the scan response one. The two events are different:
case ESP_GAP_BLE_ADV_DATA_SET_COMPLETE_EVT:[...]case ESP_GAP_BLE_SCAN_RSP_DATA_SET_COMPLETE_EVT:[...]
You have to wait until both the events have triggered before starting the advertising process. In my example program (you can download the source code from my Github repository) I use two booleanvariables:
If you want to use the raw mode instead, you have to declare a byte array and fill it with the content of the payload of the packet. Then you can use a specific function of the framework to pass the array to the driver: