đŸ Archived View for benjaminja.info âș log âș 2018 âș feed.xml captured on 2024-05-10 at 10:51:05.
âĄïž Next capture (2024-07-08)
-=-=-=-=-=-=-
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en-us">
<title>Benjamin Jacobs | Log - 2018</title>
<link rel="self" type="application/atom+xml" hreflang="" href="gemini://benjaminja.com/log/2018/feed.xml" />
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2018/" /><id>/</id>
<updated>2018-01-01T07:00:00Z</updated>
<generator>Hugo 0.125.4</generator>
<entry>
<title><![CDATA[The Moon Project]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2018/06/12-the_moon_project/" />
<id>gemini://benjaminja.com/log/2018/06/12-the_moon_project/</id>
<updated>2018-06-12T20:59:59Z</updated>
<summary type="gemini"><![CDATA[While I was browsing thingiverse, and I found a cool model for the moon. It has both a bump map for the surfaceâgiving the texture of the moon with all of its cratersâand a bump map for the darkness on the moon, which is on the inside of the model.
]]></summary><content type="gemini"><![CDATA[While I was browsing [thingiverse], and I found a cool [model for the moon]. It has both a bump map for the surfaceâgiving the texture of the moon with all of its cratersâand a bump map for the darkness on the moon, which is on the inside of the model. The inner bump map is used for lights: A light on the inside will show darker on the thicker spots of the moon, making it look more like the moon. You can read more about how it works, and how you can make your own model [here].
=> https://www.thingiverse.com/ thingiverse
=> https://www.thingiverse.com/thing:2771919 model for the moon
=> http://www.instructables.com/id/Print-Your-Own-Moon/ here
## Printing The Moon
Since my dadâs birthday is coming up, I decided to print one for him. In the first print, I ran out of filament but had some old extra stuff that was not on a roll. It ended up tangling up but able to finish. The two colors were not able to stay together, so I had to reprint it. The second print was done completely with the old filament. However, it got tangled in the night and ultimately failed. I was now out of white filament, so I reprinted with silver. It turned out great except for the fact that it was silver. No light could pass through the moon, and so I had to reprint again. I was able to order some white filament in time and print it in white. It finished but the printer was having temperature problems, and so parts were under-extruded. I will have to print again, but I havenât yet. Also, did I mention that each moon took 25 hours to print?
=> https://youtu.be/CYXU0qKKzmQ Youtube - Printing Moons
## Lighting System
After I printed the moons, I had to figure some way to light it up. My first lighting system was to use a light from a Christmas house. It worked, but I did not like it. There were rings of light at the top, and the lighting was uneven.
=> img_0004.jpg đŒ img_0004
I have a few [NeoPixels] laying around, as well as a [light up button] and a [Pro Trinket]. So I will create my own lighting system. I started out making an Interpolation library. This way the lights can turn on smoothly. After completing the library, I found that someone had already created one: [Ramp]. I will use it in future projects, but for this one, Iâll continue using my [home-made library].
=> https://www.adafruit.com/product/1312 NeoPixels
=> https://www.adafruit.com/product/1476 light up button
=> https://www.adafruit.com/product/2000 Pro Trinket
=> https://github.com/siteswapjuggler/RAMP Ramp
=> https://github.com/ttocsneb/Arduino-Interpolate home-made library
The program has two modes: Power, and Brightness. Power turns on and off the light when the button is pressed/released. Brightness dims and err, undims the light until the button is pressed switching to power mode and saving the current brightness in EEPROM. I uploaded my code to a [Gist], but I recommend you write your own version while using mine as a guide.
=> https://gist.github.com/ttocsneb/54ecf4dc0792c8465a4d0e178fb67792 Gist
Probably the most tricky part was designing a model for the electronics. The cone I designed is small, so I have to fit the Pro Trinket with a USB plug in there without it making holes on the outside. Since it is very specific to my parts, you might want to design your own, but I uploaded both [STL and STEP] files if you are interested.
=> https://www.thingiverse.com/thing:2958491 STL and STEP
=> img_0005.jpg đŒ IMG_0005
=> img_0006.jpg đŒ IMG_0006
=> img_0007.jpg đŒ IMG_0007
=> img_0003.jpg đŒ IMG_0003
=> https://gist.github.com/ttocsneb/54ecf4dc0792c8465a4d0e178fb67792 See my code on my gist
]]></content>
<category term="wordpress" label="Wordpress" scheme="gemini://benjaminja.com/tags/wordpress/" />
<category term="3d-printing" label="3d-Printing" scheme="gemini://benjaminja.com/tags/3d-printing/" />
<published>2018-06-12T20:59:59Z</published></entry>
<entry>
<title><![CDATA[Weatherstation: Charging Circuit]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2018/05/24-weatherstation-charging-circuit/" />
<id>gemini://benjaminja.com/log/2018/05/24-weatherstation-charging-circuit/</id>
<updated>2018-05-24T23:19:17Z</updated>
<summary type="gemini"><![CDATA[One of the big things on the to-do list is a charging circuit. I need a charging circuit to allow the solar panel to charge the battery. Lucky for me, the Arduino Feather 32u4 has a built-in charging circuit, but then why would I need a charging circuit?
]]></summary><content type="gemini"><![CDATA[One of the big things on the to-do list is a charging circuit. I need a charging circuit to allow the solar panel to charge the battery. Lucky for me, the Arduino Feather 32u4 has a built-in charging circuit, but then why would I need a charging circuit?
I bought a little voltage regulator for the solar panel which makes sure that the voltage stays at 5V. If the voltage goes below 5V and has enough current, then the output voltage will be 5V with a little less current. Iâve done this because the charging circuit does not work with lower than 5V. After some testing, I found that the built-in charging circuit stops charging the battery if the solar panel goes through the process of losing sunlight, then regaining the sunlight. In order to fix the issue, I can disconnect the power line from the solar panel to the device when there is no sun. So the charging circuit isnât actually a charging circuit, but rather a charging enable circuit.
## Version 1
My original design used an N-MOSFET. I used an N-MOSFET because everyone uses NPN BJT transistors, so why not use an N-MOSFET. After learning about MOSFETs, I created my V1 charging circuit. It had a voltage divider to probe if the solar panel was getting any sun or not. The circuit with the N-MOSFET had to be connected to the solar panelâs ground: The drain pin should be connected to the load, and N-MOSFETs drain should be more positive than the source (See below image for more detail).
The only problem as you might have guessed is that I could not check the voltage of the solar panel without the N-MOSFET enabled, because the ground was being disconnected, and so the measured voltage had no reference.
I couldnât find the schematic, or picture of the original circuit.
## Version 2
After a few months of ignoring the enable circuit, I decided to work on it again. After learning a bit more about P-MOSFETs, I found that the only difference between them is the voltage of the source and drain. The P-MOSFETs drain should be more negative than the source, so the MOSFET should be placed between V+ and your load.
=> mosfet-diagram.png đŒ mosfet diagram
=> https://electronics.stackexchange.com/questions/3599/basic-p-type-mosfet-question StackExchange - Basic p type MOSFET question
After some experimenting with the new circuit on a breadboard, I found that I donât need the voltage regulator. In fact, the voltage regulator was causing all the problems that made me design the charge enable circuit. I donât need the voltage regulator, because the solar panel is a 5V panel, and wonât be able to produce enough current to step the voltage up if it isnât even at 5V.
Just because the solar panel now charges the Feather doesnât mean that creating a new charge enable circuit isnât useful. If the temperature is too cold or too hot, I shouldnât allow the Li-ion battery to be chargedâThe temperature range for Li-ion batteries are [32F to 113F]. I donât know how I will insulate the battery to help prevent reaching those temperature ranges, but that is a problem for another day.
=> http://batteryuniversity.com/learn/article/charging_at_high_and_low_temperatures 32F to 113F
=> chargin-circuit.png đŒ chargin-circuit
=> ws-charging-circuit.jpg đŒ ws-charging-circuit
]]></content>
<category term="wordpress" label="Wordpress" scheme="gemini://benjaminja.com/tags/wordpress/" />
<category term="weather-station" label="Weather-Station" scheme="gemini://benjaminja.com/tags/weather-station/" />
<published>2018-05-24T23:19:17Z</published></entry>
<entry>
<title><![CDATA[Weatherstation: Lots Happening]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2018/05/18-weatherstation_lots_happening/" />
<id>gemini://benjaminja.com/log/2018/05/18-weatherstation_lots_happening/</id>
<updated>2018-05-18T18:21:09Z</updated>
<summary type="gemini"><![CDATA[Starting in April, I have started working on the weather station project again, and I have failed to make any updates since. So Iâm going to try to write everything I have done in this past month and a half.
]]></summary><content type="gemini"><![CDATA[Starting in April, I have started working on the weather station project again, and I have failed to make any updates since. So Iâm going to try to write everything I have done in this past month and a half.
## Weather Station
First, I created a new repository for the project on [Github]. In this, I have migrated my weather station from an Arduino project to a [PlatformIO] project. This is significant since the Arduino editor works only as a text editor and compiler, while PlatformIO on VSCode acts as a full IDE with code completion along with support for the old Arduino libraries.
=> https://github.com/ttocsneb/Weather-Station Github
=> https://platformio.org/ PlatformIO
Rather than waiting for commands, the weather station waits for 30 seconds then turns on the radio, and sends the weather packet. This is done for power saving. Before, the weather station had the radio turned on and listening 100% of the time. This wasted a relatively large amount of power.
The weather station now accepts commands after sending the weather update: Set Value, Get Value, Set EEPROM, Load EEPROM, Get Status, and Reset. These commands can be bunched together in packets. Some commands send replies which are sent in order after all the commands are sent.
## Base Station
The base station is the raspberry pi device that receives the raw weather data from the weather station through the rf24 chip. It receives the weather, processes the data into human-readable units, then uploads the data to Weather Underground. Most of the work done this past month is for the base station.
I have done a little bit of work in the past on the base station, but very limited. Then I planned to have the program run primarily in python, running a c++ script to get the weather from the radio chip. Now, most of the work done is in a C++ program, running a python script that uploads the weather to [wunderground.com].
=> http://wunderground.com wunderground.com
Program Loop
It runs in a 30-second loop that is synchronized with the weather station. To get synchronized, it will leave the radio on and wait until a transmission is received before beginning the loop again.  One problem I found with this system is that the Arduino and raspberry pi clocks arenât the same. Even though they both wait 30 seconds, one seems to be slightly faster than the other. The problem is solvedâtoo complicated to explainâby the following code snippet.
//wait for an available packet
time_point t = Clock::now();
while(!successfull && timeDiff(t, Clock::now()) < eeprom::listenTime) {
sleep_for(500ms);
successfull = checkForPacket();
count++;
}
//If we are desyncing, compensate.
count -= (eeprom::listenTime /500) /2;
if(count !=0) {
reloadTime += (count *500);
cout <<"Desynced by "<< count *500<<"ms, adjusting"<< endl;
}
Every time the weather station successfully sends a packet: the program will process the data. Upload the weather. And send any commands. Since I have a website to check the current weather/station status; I need to have some way of getting that data to the website. So I decided to use MySQL for data storage and transfer.
MySQL
I am not very skilled in MySQL; after all, Iâve only just learned it. My plan for the database is to hold the weather for 24 hours to display on the website and to move information from one program to another without the hassle of parsing individual files. Here are the tables I have made, displayed in a table.
Website
The website Iâm making is designed to be for me only: to get information about the station without SSHing into the baseStation. If I wanted to get the weather, I would use Weather Underground. Also, I donât think a Raspberry Pi Zero is equipped to handle more traffic than my immediate family.
The website is fairly straightforward, Iâm using the [SB Admin] Bootstrap template. A few pages: One displaying the status, and other useful information. Another with the current weather with a 24-hour graph of previous temperatures, pressure, humidity, rain, and wind. Iâm using PHP to connect to the MySQL database to get the weather/status information.
=> https://startbootstrap.com/template-overviews/sb-admin/ SB Admin
In the future, I want to have a page for configuring the weather station from the website. Such as setting EEPROM variables on the weatherStation, or resetting the system remotely. One worry I have is permissions. I want the website unable to process these commands unless I am logged in. However I have never done anything like that before, so could be more difficult than I think. Of course, it could also be much easier than I think as well.
## Conclusion
As I continue to work on this project, I want to post once a week, or whenever I work on the weatherStation. That way I could give more detail, and include more code snippets to help anyone who might find this website who is also building their own weather station. I hope to get this project done in the next month; I also was planning to get it done a year ago so donât expect too much.
]]></content>
<category term="wordpress" label="Wordpress" scheme="gemini://benjaminja.com/tags/wordpress/" />
<category term="weather-station" label="Weather-Station" scheme="gemini://benjaminja.com/tags/weather-station/" />
<published>2018-05-18T18:21:09Z</published></entry>
<entry>
<title><![CDATA[WeatherStation]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2018/04/09-weatherstation/" />
<id>gemini://benjaminja.com/log/2018/04/09-weatherstation/</id>
<updated>2018-04-09T18:12:09Z</updated>
<summary type="gemini"><![CDATA[đ GitHub Repository đ WeatherStation Posts This is an ongoing project, see the above links for more information on the project A number of years ago, my father got a home weather station for his birthday.
]]></summary><content type="gemini"><![CDATA[=> https://github.com/ttocsneb/Weather-Station đ GitHub Repository
=> /tag/weather-station/ đ WeatherStation Posts
> This is an ongoing project, see the above links for more information on the project
A number of years ago, my father got a home weather station for his birthday. It is a simple station that reads wind, rain, temperature, and humidity. It was a good for seeing how much rain we got, or how hot it is at our house. Somewhat recently, it broke, we arenât sure what happened, but I decided to recycle the parts and create a new, better weather station.
My plan is to make a weather station that uploads its data to [wunderground.com] using their [PWS Upload Protocol]. The problem is that I need to send the weather data through a GET request, which I need a device with wifi. I could use an Arduino with wifi, but I donât think that our wifi has a good enough range to use from the roof. So I am using an [RF24L01+] module from the station to a raspberry pi 0 base station, which will upload the data.
=> https://www.wunderground.com/ wunderground.com
=> http://wiki.wunderground.com/index.php/PWS_-_Upload_Protocol PWS Upload Protocol
=> https://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo RF24L01+
The idea is simple but has a number of problems that need to be addressed, such as power. I plan to use a Li-ion battery with a solar panel to charge.
### RF24 Protocol
Every 30 seconds, the station will activate the radio, and send the weather data down to the base station, then listen for any commands for the next 2 seconds. This will allow me to make changes to some constants in the station without having to reflash. I should also be able to ask the station to do things, such as reset.
The commands are single chars followed by whatever else is needed. ie âSâ is for setting the value of a constant, followed by a char of the code for the constant to be changed, followed by the value. If the command is a request, the station will send a packet back to the base.
### Solar Power
I am using an Adafruit Feather chip which has a Li-ion charging circuit built-in, so all I need to do is connect a solar panel to the charger. However, I ran into an issue, where when the power drops too low to charge, then rises back, the charging circuit will stop charging as expected, but will not start charging again until the solar panel is disconnected and reconnected. I plan to create a circuit with a mosfet and voltage reader so that the station can deactivate the solar panel when it canât supply enough current.
]]></content>
<category term="wordpress" label="Wordpress" scheme="gemini://benjaminja.com/tags/wordpress/" />
<category term="weather-station" label="Weather-Station" scheme="gemini://benjaminja.com/tags/weather-station/" />
<published>2018-04-09T18:12:09Z</published></entry>
<entry>
<title><![CDATA[rcProtocol update]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2018/02/23-rcprotocol_update/" />
<id>gemini://benjaminja.com/log/2018/02/23-rcprotocol_update/</id>
<updated>2018-02-23T01:37:32Z</updated>
<summary type="gemini"><![CDATA[It has been far too long since the last update, near the end of October. Since then I have been able to make a bunch of improvements. When I last posted, the remote could only pair and connect, now constant communication works, telemetry works, the remote even reconnects after resets.
]]></summary><content type="gemini"><![CDATA[It has been far too long since the last update, near the end of October. Since then I have been able to make a bunch of improvements. When I last posted, the remote could only pair and connect, now constant communication works, telemetry works, the remote even reconnects after resets.
I have also been able to fly my quad with the remote.
### Constant Communication
As the name implies, Constant communication allows for communications to be sent constantly. In order for CC to work, both the receiver and transmitter call an update function during its program loop. The transmitter is restricted to run update() at a certain interval designated by the receiverâs settings. While the receiver can run update() as often as it is called.
There are several transmission types, dictated by the first byte in the packet. For example, 0xA0-0xAF are reserved for channel packets, and 0xC0 is for disconnecting. The receiver processes all of the packets in its update(), while the transmitter will send certain packets from different functions, such as the disconnect packet.
### Telemetry
Telemetry is sent by the receiver through ack-payloads. At the moment, Telemetry is sent every time a packet is received. I plan to make the frequency of telemetry packets set by the receiver settings.
I havenât yet merged this to master yet, but telemetry has its own container class now. It manages all of the bytes in the telemetry object into the proper data. There are a bunch of things that can be sent through telemetry, and each needs its own implementation so the remote can enable/disable specific telemetry channels it uses. This allows for more efficient telemetry packets.
The telemetry class so far as only implemented, Battery Voltage, Current, Temperature, rpm, GPS, and alarms.
### Reconnects
For a normal receiver, if the receiver were to reset for whatever reason, there wouldnât be much of a problem, since the transmitter will not care if it disconnected for a bit, but with this system, if that were to happen, it would have to go into connect mode, and do its handshake to make sure they can connect. This is not good, so if the remote, or receiver is to reset while connected, it will immediately consider itself to be connected with that device, and check if the other device is listening.
## Things Still To Do
I think that the library is very close to being finished, but there are still things yet to do. One of the things I want to do is create a container class for the channels similar to the telemetry class.
I want to have the channels be more standard so that the receiver can request certain channels, and the transmitter will know what to do. I think this can be done by recreating the Telemetry class. The remote would tell the Channels class which channels it can provide, and the receiver settings will contain information about which channels it needs. When the two pair, it will check if the transmitter has the channels the receiver asked for. If it works, then they will pair as normal, if they donât match, a warning will be sent to the transmitterâs firmware, and it can decide whether they can pair and if they do, which channels to send instead.
I think this is one of the big things that need to be done before the library can be considered finished, but there are still a few small things that I would like to implement, like signal strength, and other things that I canât think of right now.
]]></content>
<category term="wordpress" label="Wordpress" scheme="gemini://benjaminja.com/tags/wordpress/" />
<category term="drone" label="Drone" scheme="gemini://benjaminja.com/tags/drone/" />
<published>2018-02-23T01:37:32Z</published></entry>
<entry>
<title><![CDATA[rcProtocol update]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2018/02/22-rcprotocol_update/" />
<id>gemini://benjaminja.com/log/2018/02/22-rcprotocol_update/</id>
<updated>2018-02-23T01:37:32Z</updated>
<summary type="gemini"><![CDATA[It has been far too long since the last update, near the end of October. Since then I have been able to make a bunch of improvements. When I last posted, the remote could only pair and connect, now constant communication works, telemetry works, the remote even reconnects after resets.
]]></summary><content type="gemini"><![CDATA[It has been far too long since the last update, near the end of October. Since then I have been able to make a bunch of improvements. When I last posted, the remote could only pair and connect, now constant communication works, telemetry works, the remote even reconnects after resets.
I have also been able to fly my quad with the remote.
There are several transmission types, dictated by the first byte in the packet. For example, 0xA0-0xAF are reserved for channel packets, and 0xC0 is for disconnecting. The receiver processes all of the packets in its update(), while the transmitter will send certain packets from different functions, such as the disconnect packet.
I havenât yet merged this to master yet, but telemetry has its own container class now. It manages all of the bytes in the telemetry object into the proper data. There are a bunch of things that can be sent through telemetry, and each needs its own implementation so the remote can enable/disable specific telemetry channels it uses. This allows for more efficient telemetry packets.
The telemetry class so far as only implemented, Battery Voltage, Current, Temperature, rpm, GPS, and alarms.
I want to have the channels be more standard so that the receiver can request certain channels, and the transmitter will know what to do. I think this can be done by recreating the Telemetry class. The remote would tell the Channels class which channels it can provide, and the receiver settings will contain information about which channels it needs. When the two pair, it will check if the transmitter has the channels the receiver asked for. If it works, then they will pair as normal, if they donât match, a warning will be sent to the transmitterâs firmware, and it can decide whether they can pair and if they do, which channels to send instead.
I think this is one of the big things that need to be done before the library can be considered finished, but there are still a few small things that I would like to implement, like signal strength, and other things that I canât think of right now.
]]></content>
<category term="wordpress" label="Wordpress" scheme="gemini://benjaminja.com/tags/wordpress/" />
<category term="drone" label="Drone" scheme="gemini://benjaminja.com/tags/drone/" />
<published>2018-02-23T01:37:32Z</published></entry>
<entry>
<title><![CDATA[rcProtocol]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2018/02/03-rcprotocol/" />
<id>gemini://benjaminja.com/log/2018/02/03-rcprotocol/</id>
<updated>2018-02-04T04:29:25Z</updated>
<summary type="gemini"><![CDATA[đĄ Github Repository đ Library Documentation rcProtocol (working title) is a protocol for communications between transmitters and receivers. It is not for receivers communicating with flight controllers. I donât intend this to become a standard, though that would be fun; I intend this to be a niche system for hobbyists who want to make their own remote system without going through the effort of creating their own communications protocol.
]]></summary><content type="gemini"><![CDATA[=> https://github.com/ttocsneb/rcProtocol đĄ Github Repository
=> http://ttocsneb.github.io/projects/rcprotocol/docs/html/annotated.html đ Library Documentation
rcProtocol (working title) is a protocol for communications between transmitters and receivers. It is not for receivers communicating with flight controllers. I donât intend this to become a standard, though that would be fun; I intend this to be a niche system for hobbyists who want to make their own remote system without going through the effort of creating their own communications protocol.
## Dependencies
There is only one dependency for the library, which is an [RF24L01(+)] chip with the [TMRh20 RF24] library.
=> https://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo RF24L01(+)
=> https://github.com/nRF24/RF24 TMRh20 RF24
I have tried to keep my code system agnostic, so you could theoretically run rcProtocol anywhere RF24 can, but I canât make any promises.
## Capabilities
rcProtocol allows remotes to be paired with more than one receiver. Each receiver has its own settings that are sent to the remote when paired. There are only simple radio specific settings at the moment, but I plan to give the receiver control of which channels are sent. You can read all of the settings in the documentation [here].
=> http://www.ttocsneb.com/projects/rcprotocol/docs/html/classRCSettings.html here
There is a max of 15 channels that can be sent, this is with full 32-byte packets. I might add the ability to send up to 16 unique channel packets, upping the theoretical channel maximum to 240 channels, though I would not recommend that.
Telemetry is also possible, by populating ACK packets. At the time of writing (V0.3.0), You have to manually parse telemetry. I plan to have standard stuff: Battery, Current, Temperature, RPM, Location, Alarms, etc.
An emergency reconnect system is enabled, making it so that if a board gets reset, it will automatically reconnect to the last device it was connected to before it reset. This is useful because of the way the transmitter/receiver connect, doing its special handshake would not work in a power failure as it would take too much time.
## Usage
The protocol has two main classes: DeviceProtocol (rcDeviceProtocol.h), and RemoteProtocol (rcRemoteProtocol.h). The two classes mirror each other in functionality as they are for the receiver, and transmitter respectively. They both have the same functions but are implemented slightly differently.
To pair with each other, both need to call pair(). The remote broadcasts its ID onto a pairing channel. The receiver will collect this, then start broadcasting its ID, as well as settings.
To connect, they both have to have paired with each other and call connect(). The receiver will broadcast its ID on the remoteâs channel. The remote will then check if the ID is correct, then send a confirmation/denial response. They will both load the settings, and test if communication is still possible.
Once they are connected, the remote is free to send data to the receiver. Though currently, update() and disconnect() are the only communications the remote can send.
There are two other classes: RCGlobal; an internal class used by DeviceProtocol and RemoteProtocol, and RCSettings; a class that holds the settings for communications
]]></content>
<category term="wordpress" label="Wordpress" scheme="gemini://benjaminja.com/tags/wordpress/" />
<category term="drone" label="Drone" scheme="gemini://benjaminja.com/tags/drone/" />
<published>2018-02-04T04:29:25Z</published></entry>
</feed>