This R function allows sampling of a dataframe. This is helpful when writing a script which will be used against a large dataframe, however, writing the script is iterative. Sampling allows the overall reduction in time of testing iterations, without losing the validity of realistic results.
This project is meant as stepping stone to implement Lumi2. The Lumi projects I’ve been working on are over-the-air uploaders of Arduino / AVR programs to Atmega and Atiny chips which are programmed with the TinySafeBoot bootloader. The goal is to allow the user to select either WiFi or Bluetooth, create a connection to either an ESP8266 or HM-1X device, and upload whatever program to an AVR connected to the wireless receiving device.
The last iteration of Lumi was written in Windows Universal Apps SDK. Unfortunately, the code-base turned into spaghetti. I’ve diagnosed the issues to be due to God-modules, poor understand of object-oriented design, and rushed coding. Passion got ahead of my ability. Here’s my history on the project so far:
Vorpal Hoff – an attempt at wireless uploading with a HM-11 and LPC1114 combination. Written in C / C++.
HM-1X Aid – this project was meant to be a GUI on top of the HM-1X modules, allowing “easy” editing of the module’s behavior. It was my first venture into C#. (It’s sooo bad;although, the serial communication was asynchoronous.)
Lumi1 – this the first succesful TinySafeBoot uploader. It was written in C# using the .NET WinForms. Unfortunately, it was synchoronou. And I was finished with the USB-to-UART uploader before I realized there was no easy BLE support in WinForm’s .NET.
Lumi2 – this is where things start getting better. It is the current version of the TSB wireless bootloader. It works, is asynchronous, and has BLE support. Unfortunately, the code turned into spaghetti. This is largely due to my poor understanding of object-oriented design. It has god-modules, a horrifically implemented SerialEvent response protocol, poor encapsulation, no polymorphism. It’s just a mess.
Now, I’m going for the third attempt. I’ll attempt to correct for the above errors and implement the WiFi uploading, with the receiving device being the ESP8266.
ESPER is a mini project to troubleshoot how the Lumi3 program will interact with a remote device.
There are two sets of code below, the first is the C# side of the interaction. It sets up an HttpClient with POST and GET calls. The one real variant which makes C# ESPER code a little bit different is the asynchronous polling POST request for data. This is meant to imitate a serial communication RX line across a WiFi signal.
The other code is Arduino C and sets up the ESP8266 device as an HTTP WebServer. It can then take data received from the UART and print it to the server. This allows the C# polling POST call to pick up the data. Of course, in the same manner, there is a the Arduino code is setup to receive data from the HTTP Client and transmit it across the UART. Voila! Serial communication across WiFi. Now all we need is the annoying autobauding sounds and we will be firmly back in the 1990s.
I’ve added a search method to the ESPER class. Basically, this iterates over a range POSTing a name request for the ESPER. When the C# code discovers an ESPER, then it adds it to an array. I’m pretty happy with it.
I did run into an issue trying to use Windows.HttpClient, as there doesn’t seem to be a way to adjust the timeout. The default was like 3 seconds, which is way too long. Therefore, the System.Net.HttpClient was used, since it has a Timeout property which takes a Timespan.