Interface and Application Programming
22 November 2017 | By Casey Evans
“I choose a lazy person to do a hard job, because a lazy person will find an easy way to do it.” -Bill Gates
Akshata, Hong Hao, Song Sata, Elizabeth Carre. Shoot no one is here. My odds are bad. I’m not afraid, I will show what I have but I don’t like talking about myself or my work. Also it’s not as good as it could be and I know that. But I also think that that is always true no matter how much I work. Burhan, Max Allen. "So this algorithm is a fail." "This is just for fun it doesn’t count since part of this is to meet everybody." Scalefulness. Kyle B. Something about the BJT doesn’t make sense. Nothing’s wrong with not having many passes except that it’s hard to solder. Writing code to devices. I should figure out setting up a terminal. Serial communication requires about 1% timing accuracy. You can measure the time of a bit on an oscilloscope. Slow down rate of computation to save power. Watch crystals are for super low power operation. Oh wait. Is Jake in our class? It seems he is. I thought he was a TA. It’s good to make lots of little module boards for development and debugging. I guess that makes my little sensor board a good thing. Byobu attack room divider. Now it inches along. It may also be responsive. Neil notes that moving is good for the project. Responsiveness is extra credit. Do successively bigger spirals around project steps. It’s a project management tool that sounds like a great idea. CBA shop had a fabric printer. At the milk street office. Thermal injet printing. Honghao made it in. He has a cool website. This week he made an LED array. He has a full video of him doing vinyl cutting of copper. Setting correct weeding is easy, settings wrong weeding is miserable. Register the next layer with the layer before it. You can use a frame. Rub between top and bottom should work since glue is electrically conductive but it’s not reliable.
Solder. 5 min epoxy or glue gun is a great afterthought for vinyl cut circuits. Regulator good to use with a diode so you don’t fry it. Regulator is also connected to ground and a capacitor in parallel. Power supply war. Non trivial circuits to combine power supplies. You can power the processor completely parasitically. (Capacitive coupling and internal leaking – zombie processor). Never use ISP as input. Milling limited by time more so than vinyl cutter which follows a linear path. Fat traces though. Also you’ll need to extend pads for better adhesion. Also cast them in a glue or something. Honghao added an extra via layer just for support in lieu instead of epoxy. If you draw a box around each layer you can use a frame for registering. Check connections before placing another layer. Solder paste is a bit more expensive, has a lifetime and must be refridgerated but on the plus side you just dispense little bits. Or if you’re classy and have a ton to do and you have a via mask/stencil you just squeegee the solder on. ATTiny13. Neopixels are not a religious artifact. I don’t know what a neopixel is but it sounds interesting. SOT 23-6 ATTiny10. Same package as the regulator. TA Will has been using them. 3m epoxy film no 1 is flame retardant but he managed to catch it on fire in the reflow process. I think that still makes sense. 256F steady state. Reflow briefly overshoots it. Phenolic Garolite 8525K411 sheets of PCB stock without the laminate. $4 for a 1ft square. It can reach higher temperatures than the epoxy. Neopixels have different colors built in I think. They look like diffuse LEDs. Memory for state of pixels. Remembering color. Be careful with data types and memory usage. ATTiny84 doubles memory and flash. Cubes for modular robots. Too few cubes, too expensive and don’t do much. More useful simpler cubes that don’t do too much to make it a more approachable project. Final project isn’t your life’s work. Maybe do a 1ft NeoPixel. Big structural pixels is interesting. Rui Qing – didn’t do anything this week. Final project, car. Morphing spoilers for a car actually. Digital Morphing Wing paper describes torque tubes on NASA project by Jenett et al. Don’t need fundamental research here. Rapid prototyping and replicating something is okay. Tomas made a dream machine. Something to notice the onset of sleep. He’s working with some friends from Fluid, which I guess is his company. Cool and creepy. Easy to measure and depends on absolutely anything apparently. RFD22301. Antenna is happier if it sticks off the edge of the board. Richard Liu. Loads of ways to measure heartbeat. Sometimes the sensors will have signal conditioning built in. SparkFun pulse sensor. Vik Parth. Holograms. Jake tried to make a magnetic encoder. Everything in the class needs to be in the class repo because links break. “This is a really happy thing to do capacitively” -Neil on magnetic encoding. Max Matthews radio drum. He basically invented computer music. I’d be interested in learning how to play a theramin and why it works. Questions to answer. Don’t need to prove novelty. Interface microcontrollers. You are guaranteed to run out of time. Final week should be debugging and finishing, not building.
You can write data into spreadsheets. You don’t need databases for GB of data, you need them for TB of data. Significantly more data than space on your computer is when you need a database.
Graphics. Xline lowest level – pushes pixels to the screen. Canvas is pixels on the web. Screen becomes a raster. No memory of what you did but it’s efficient. SVG standard for 2D graphics on the web. Once you draw a line it persists as an object that you move. SVG is resolution independent. Photoshop v illustrator, basically. Webgl is messier looking because its setting up a whole 3D pipeline-can be faster since it runs through GPU. WebVR is an emerging extension. You can use it with VR controllers. VTK is an environment for visualizing data (CT or hydrodynamics perhaps). The game engines—Unity and unreal. Both have matured into complete coding languages. Also has hardware interfaces. You could make a world and go into that world to see that data.
Julia is a bit of everything we’ve covered.
None. Be free. Don't drown.
For some reason this project is blowing my mind. I don't know where to start. Gavin suggested I look at the online lectures here. I also found this interesting take on learning how to program, which I will investigate when I have time. So never. I'm going to go ask Natalie Lao for help since I just don't know where to start. She gave me an overview of MIT's app inventor, which is actually a great program. Using the AI2 Companion app (which is only for Andriod btw--though they're working on getting an Apple version) you can debug in real time which is pretty cool. The simple program Natalie had be start with looks at a screen with two check box options: dog and cat. There is also a play sound button which when pressed shows a picture of the animal in question as well as playing the sound that animal makes. The code is implemented in just a few blocks of app inventor as shown below:
This is what it looked like on an Android:
Natalie also showed me the Bluetooth modules for MIT's app inventor. The BLE module is an external download but it is quickly found with a Google search to import into the browser interface. I also talked with my roommates and one of them has an extra Android I can use (since I use an iPhone). What luck! But for this week I will return to looking at the sensors I made last week and see how to work with them in a GUI like Neil's. I will be satisfied with getting that to work for the magnetic sensor. I will then try to work with the temperature sensor. Then I will start working on the app for my final project in App Inventor. Natalie found this post which might be helpful. But first I'll need to go back to the lab and resolder my patchwork from the regrounding since I apparently wasn't very robust the first time. Before I walk all the way over there though I will try to get data from the magnetic sensor. To do that I'm using Neil's code as a guideline to reapply to the ATTiny44A. So I also am referencing the datasheet. So far it's still building so that's nice. I learned that IDE means integrated development environment. Meep. So I have the C code set up like Neil's but I'm not getting an output. This is probably a lot to do with the fact that I don't know where the ATTiny is sending this data. PA1 goes to the Tx on the FTDI cable. Okay. There's a mods version. I will try that and see what happens. I made the mods tree in line with this video but I'm not sure about running the command line stuff. I need a mods server command thing. I'm not sure if that means I need to install mods or what. This is what the serial connection should look like for a bar graph output.
Just sent off a question about installing mods to the TAs but I think I will need to go to TA office hours in order to really get a handle on what I'm supposed to do. So for now I will sign off, knowing that this section is an integral part of my final project so I will figure it out by the end of the semester one way or another.
Before I give up though I heard back from Ben, who suggested I download PuTTY. After checking device manager to see which com port my FTDI is connected to:
But when I ran PuTTY I got nonsense.
Ben then suggested that I was on the wrong part of the FTDI - Tx instead of Rx. I was about to change that when I realized I subconciously changed it. Actually, I just followed the example. And it's fine. False alarm. Ben said it shouldn't be readable anyways. Great. He suggested I just use the Python file and "From a command prompt in the same working directory, try to run: python [script-file] [arguments...] This should work if python.exe is in your system PATH." But it turns out Python 2 and Python 3 are different and Neil's code is for Python 2.
Ben then suggested that I was on the wrong part of the FTDI - Tx instead of Rx. I was about to change that when I realized I subconciously changed it. Actually, I just followed the example. And it's fine. False alarm. Ben said it shouldn't be readable anyways. Great. He suggested I just use the Python file and "From a command prompt in the same working directory, try to run: python [script-file] [arguments...] This should work if python.exe is in your system PATH." But it turns out Python 2 and Python 3 are different and Neil's code is for Python 2. I also needed PySerial. And sleep. I also need sleep. At this point I can open a window but it's not responsive and forever stuck displaying 0.33. The program crashes if I click on it. Not sure what's up but I really need to go to sleep now. I will figure this out eventually. Below is the window I'm getting.
Okay--idea. Instead of running with Python right now (or rather, as I wait for the opportunity to talk to a TA) I can try doing the serial from a button press to type a character so I can see it on PuTTY. Or try running a basic Python program. Honestly, I just need office hours. Now that I think about it I have no idea how this would all correlate to Macs or another operating system. I don't even really know what an operating system is. Am I supposed to know all of this? I don't know where to start to know this? Operating system theory or just trying things. Or coding theory? Computer theory? It's all so complex.
Debugging at office hours. This was actually quite painful. First, I found that somewhere along the line I was writing to the Tx line instead of the Rx line with my ATTiny. We probed the sensors (a multimeter across the thermistor, for example, showed a change in voltage as I placed my finger on it) and saw that the ADC was producing bits by looking in PuTTY. But those bits were unreadable. To debug I went all the way back to Neil's code and when that still didn't work, I started looking through an oscope. At first I was getting a weird capacitive signal but then I realized that I hadn't grounded the thing. Then I got nothing. But to further complicate the issue I was looking at the sensor output pin for some reason, which of course wouldn't be sending bits but I wasn't thinking. Later when I set it to trigger on the Rx pin I saw beautiful results. But the last thing I did at office hours was decide that everything was working just about to the transmission and that something was probably off in the timing since I had converted the 45 code to 44a and needed to double check everything.
But instead of starting with that next time I went to the lab, I tried running hello.echo on it since hello.echo was designed for it. But although I was able to see output in term.py I was getting loads of characters per tap on the keyboard and none of them were very intelligible. I remembered the bit rate problem from class so I decided to check out the Rx and Tx pins on the oscilloscope. The first image is the Rx pin running Neil's default code with 8.5us bit time. I used single mode to get a capture on the trigger. It took some fidgeting to get the oscope to register. It liked the "either rising or falling edge trigger" setting best.
As you can see I was getting 2us instead of 8.5us (or the 1/115200=8.6us I should have been getting). At first I adjusted the port speed the computer was expecting in term.py and I started getting closer:
If you look at the bir breakdown I was only missing the first (and sometimes second) bit of each character.
But then I decided it would be better to change the code instead of the input to term.py, which by standard should be at 115200 baud. After some trial and error and some math estimations, I finally got it to work with a "60us" bit time in the code. I guess my clock is a bit bonkers or something. I'm not too worried about debugging yet since I have it working and the bigger problem is getting it to talk about sensors to the computer. It was pretty nice though to see it working. I summarized a quote from week 14's blog since I was also working on that at the time.
The proof is also in the oscilloscope polt at 8.66us. Perfect!
Next step is to translate this interface to talk about sensor input/ADC conversions instead of echoing the computer. Once I get that working I can write a note in the input devices section and maybe some more here on the interface, as long as I can think of a good way to modify Neil's code, or write my own interface program. But my interface weekly assignment will probably just be the app design for my final project.
And here we are! Wow. Cool. So I can't get the light to actually light up by Bluetooth but I can send it write requests from the app. And here's how. Maybe over J-term I'll get the BLE working. My roommates seemed a bit disappointed that I didn't get full functionality there. Anywho I started with a lot of approaches documented in week 13 and made the start of an app that had a picture of a lightbulb that turned on and off when you pushed the on and off buttons. It also checked to see if your Bluetooth was enabled and gave you a notification if it wasn't on. I go t the idea for that from this site. Here's that error message:
Then I found a great YouTube video to walk through the process but they were doing Arduino. I had to do a bit of researching to understand how UUIDs would apply to my device (and what they were). But following their walkthrough and incorporating my understanding of Bluetooth (explored in week 13 I set up a basic interface in App Inventor. Here's the code:
And here's what the interface looked like:
As you'll hear about in week 13 this code was good at connecting to my final project board and sending it write requests. I then combined this interface with the interface I was setting up earlier when I didn't know what I was doing (the one with the lightbulb) and here's what that code looked like:
The app had two pictures so I'll show them here. I didn't get the buttons to disappear like I thought my code was supposed to make them do by setting visible false but I think I misunderstood what visible means to App Inventor. Anyways, here is the 'unlit' screen:
And here is the lit screen:
Note that the lit screen gave me an error saying it wasn't connected (because I wasn't, I was testing the app without the Bluetooth just to get the photos). But the app was pretty good at scanning and getting a list of devices to connect to. The list picking screen looked like this:
Once you selected a device the app would connect to it which you could see in the terminal emulator. You could also see the write requests pop up. You can see more on that in week 13. Note that the BLE is kind of an output device because it has pins that can flip. It's also an input device because it can send and recieve data. Cool beans.