Monday, October 24, 2016

Project Time!

Team?

For this project, I have decided to team up with Maximilian Sharpe, whose blog can be found here. We have decided to work on his project idea: a toolkit to help bystanders give help to those at the scene of a disaster before first responders can arrive.

Timeline?

Here is another copy of the timeline for completeness' sake.
Project Requirements and Timeline

  • Required features for final project:
    • Can take pulse.
    • Can provide information to user on first aid measures.
    • Can send a location to a computer or to a mobile device.
    • Can take in information from the user on the type of emergency.
  • Required features for proof of concept:
    • Can provide information to user on first aid measures.
    • Can send a location to a computer or a mobile device (IFTTT?).
  • Required Parts:
  • Timeline
    • Friday 21st October:
      • Complete list of parts to be ordered
      • Complete timeline and project planning
    • Monday 24th October:
      • Order all parts
      • Begin researching first aid response to different situations
      • Begin experimenting with pulse sensor
      • Begin experimenting with sending information (a preset location) to a computer
    • Friday 28th October:
      • Receive (hopefully) all parts for the project
      • Determine how best to fit everything together
        • Glove? Wristwatch? Portable device?
      • Begin experimenting with display
    • Friday 4th November → Proof of Concept Presentation:
      • Have something printing to the display
      • Have a location being sent from the photon to anything else
    • Friday 11th November:
      • Start to integrate research on first aid into what is being displayed on the screen
      • Begin experimenting external power supply
      • Add pulse sensor in some capacity
    • Friday 18th November:
      • Market research
        • What is the problem?
        • Why does this solves the problem?
        • Who is the target market?
        • Projected costs?
      • Begin experimenting with user input into the device
        • What is the emergency?
        • How many are hurt?
        • Is it safe yet or are things still dangerous?
    • Friday 25th November:
      • Clean up loose ends
    • Friday 2nd December → Final Presentation of product

What am I doing?

We're not quite sure yet. There's no set specialization for either of us. Which is good! That should foster effective collaboration and communication.

Friday, October 21, 2016

Project Idea Refinement

Candidate:
Idea 2: Audio control system.
What problem are you looking to solve?
Audio volume issues when using a speaker system
What potential solution(s) have you considered for this problem?
Aside from the IoT solution of intelligent control of volume and other factors, there remains little that can really be done to solve this issue. Perhaps a sound engineer would know more about it. Maybe tearing down the entire room and rebuilding it for better acoustics? That’s definitely not practical, no matter how rich you are, and the return on such a project would be minimal at best.
How might you integrate IoT concepts?
The IoT solution is to have a bunch of Photons or other devices scattered around the room. They each have sensor(s) that can detect different aspects about the audio in the room, and they all report those readings to another device that is controlling the audio device of the room.
1 minute pitch draft:
“Everyone’s heard of audio feedback before. The dreaded ‘eeeeEEEEE’ that keeps getting worse until you turn down the volume or shut down the entire system. What I’m proposing is a way to solve that issue, once and for all. Thanks to the handy Particle Photon, an accompanying audio sensor, and some programming knowledge, we can hook up a bunch of these around a room and use them to automatically control the volume of audio systems so that they’re just the right volume. We’ll start small, in college lecture halls. From there, we can expand to presentation rooms, and finally into the home. The future of self-regulated audio is here.”

RIP this idea

Friday, October 14, 2016

Transmission Control Protocol is a Thing of Beauty

Particle Photons are Quite Versatile

You can do so much with a Photon. IoT stuff, yes. Especially with Particle's built-in cloud services. But there's way more than they can do.

The Basis for the Game: Pong

I've spent over a year of time by now working on a Game Engine using Java. So far, the one game implementation that exists is the classic game of Pong. The details are a bit complicated, of course, but every single game runs of a Client-Server basis. By creating a Client implementation using the Photon, it was possible to turn the Photon into a wireless controller for Pong.

Hardware

The hardware consists of a Photon as well as a breadboard, two buttons that act as up and down controls, and a bunch of wires and resistors. The breadboard itself doesn't look very pretty.
Of course, it doesn't have to. It's a prototype, and it works. That's what matters. But what good is this hardware without accompanying software to actually make it work?

Software

The software of the Photon is based on the same software as Arduinos, allowing much compatibility. In addition, Particle has provided many useful libraries in addition to the default Arduino ones that unlock additional functionality that the Photon and other Particle boards have the hardware capable of using. Among the others, there is the class TCPClient, which is what it sounds like. When used in conjunction with a TCP Server, no matter what the source, TCPClient allows for the transmission of data across the internet. Of course, in this case, the client and server are right next to each other. But by the nature of TCP, as long as both devices are connected to the internet (and not firewalled or whatever), it is possible to communicate between the devices. Compared to Bluetooth or other near-range communications, using the internet effectively extends the range to anywhere in the world.

Of course, anywhere in the world is a bit optimistic, as this is Pong after all. There is no way that the Photon is powerful enough to display the real-time playing field of Pong, at least not with the fidelity required to play it well. Thus, the Photon is effectively tied to the computer displaying Pong, a sad reality for the once-limitless Photon.

Communication How?

On the Java side, the server makes use of Java's SocketChannel, ServerSocketChannel and ByteBuffer classes. The server itself runs based on the tick model. Any data that needs to be sent is aggregated until the end of a tick, when it is sent all at once in a manner similar to Nagle's algorithm. A separate thread exists to read packets received by the TCP and UDP channels so that processing is possible as soon as a tick begins.

The Photon uses the Firmware's built-in class TCPClient, akin to SocketChannel. But before it can connect, it has to know what to connect to. That's why functions to set the host address and port are exposed using the Particle Cloud. Via the Particle app, it's possible to tell the Photon what to connect to. From there, the TCPClient instance attempts to connect to the ServerSocketChannel on the server. If all is done properly, including setting up the host, then the Photon will connect to the Computer and the game will begin.

Using the two different backends is no problem, however, as they are unified by TCP (and UDP, but it's not used in this case). On the Photon, all the packets received are discarded, as they wouldn't be useful anyways. However, it does send one packet to the server in the format of an Input Packet. What goes into that packet? Time to find out...

Anatomy of a Packet

So what goes into the packet that's sent? Well, every packet sent has its ID as a 4-byte int added to the buffer first. Then, all the data that the packet contains is added to the buffer. In the case of the Input Packet, its ID is 6. So the integer 6 is written into the buffer as 00 00 00 06. The data of the input packet is a 2-byte short that specifies the player number, and a 1-byte byte that specifies the direction that the player wants to move the paddle. The player number for the Photon should always be 1, so the player number is written to the buffer as 00 01. The direction that the player wants to move is dependent on the buttons pressed. Internally, the directions are known as 1 for up, 0 for stop, and -1 for down. However, these values are known internally as 01, 00, and FF respectively. Finally, the end delimiter is written as a substitute to the next Packet ID, which is the minimum value for a signed 4-byte int. The internal value of that is 80 00 00 00.

Overall, the packet is thus 00 00 00 06 00 01 DIRECTION 80 00 00 00.

Prove It!

The following shows the Wireshark analysis for the data. From here, we can see a few things. The Photon's IP is 141.213.30.71, so we're looking for packets sent to and from that. The highlighted packet shows one sample of input packet. Obviously, this is way more than 11 bytes of data. 88 bytes, in fact. This is due to the fact that the Photon's delay is only 5 milliseconds, which allows it to send many different inputs which are aggregated together. The server only processes the first one, as the end delimiter is encountered right after it.

Looking at just the first 11 bytes, we see that the data are indeed correct. Awesome!

Sunday, October 9, 2016

Project Idea Research

Problems that Exist Today in Education and Healthcare, and Possible IoT Solutions:

  1. Logistical/Supply Chain issues: Keeping track of inventory and stuff ordered
    • IoT Solution: Photon with special attachment mechanism – potentially 2 sets of extendable straps. Power is provided by battery, and is only turned on when both are connected. From there, all the metadata about the package can be entered via a web interface, and all the data can be stored in the cloud if desired, or possibly on local servers. The Photon is kept in a low-power mode and woken up by an inventory request. At that point, it should be delivered to its intended destination. If tracking is desired, it is possible to activate Internal Positioning making use of the onboard WiFi, or other technologies if WiFi is impractical.
  2. LECTURE HALL AUDIO EQUIPMENT being too LOUD AND HURTING EARS
    • IoT Solution: Several Photons positioned around the lecture hall, all with some sort of method to pick up audio. Use software to determine whether audio being received at these points is too soft or too loud, and automatically adjust so that the volume is as close to an ideal level as possible.
  3. Lights and other utilities being on with nobody around
    • IoT Solution: An array of sensor and Photons working to process the presence of people within a room. If no people are detected, then the lights can be dimmed or even turned off.
  4. Impatient Patients
    • IoT Solution: Give each doctor/nurse a Photon (potentially in their pockets) and use existing AP’s and Internal Positioning Systems to triangulate position and make impatient patients somewhat calmer.
  5. Smoke Detectors that GO OFF FOR NO REASON
    • IoT Solution: Photons scattered throughout the buildings whose readings of temperate and other metrics also affects the decision for the sprinklers and alarms, etc. to go off. The photons and smoke detectors should be weighted equally, but fire alarms should override both and immediately call the system into action.
  6. Inaccurate Diagnoses that lead to billions of wasted dollars on treatments for aliments that aren’t even the problem.
  7. Bathrooms. Even in the most hygienic of places, such as hospitals, the bathrooms with inevitably be dirty. That’s quite an issue for both healthcare professionals and patients alike…
  8. Malfunctioning technology that may not seem like much… but over time adds up in lost time teaching and doing hospital things. As we grow more and more dependent on technology, we will also learn its flaws.
  9. Cybersecurity. Though applicable to almost any field, education and healthcare are probably the most in need of good security against breaches, beit hacking or ransomware, as they often contain very sensitive records that the institution needs to function and should keep private.
  10. Speaking of those records… more efficient record keeping. No doubt there are already decent databases in use today. But there are some cases, such as transferring schools or hospitals, which should automatically transfer records, among other possible improvements.

Sunday, October 2, 2016

The System Diagram & Identifying the 5 System Components

Consider the original Edison electric bulb, as well as the Philips Hue bulb. Diagram the 5 system elements in each case. What additional system(s) has to be present for the Philips Hue to work? Can you diagram it?

For the original Edison electric bulb, the system diagram is quite simple for the bulb itself. It requires electricity of some sort, so its source is from a power plant. The distribution system is the electric grid, and the packaged payload is the electricity itself. The tools are the bulbs, and the control system is the light switches that we all know and love.

The Philips Hue, however, requires a few additional components in addition to the simple electricity delivery that the classic light bulb needs to function. It also requires the information as an Internet of Things device to function properly. In that case, the source is the user's phone (typically), the distribution system is the internet, and the packaged payloads are the bytes that comprise the information needed to control the Hue. The tools are the Hues, and the control system is once again they user's phone.

Consider self-driving cars. Identify (& diagram) the 5 system elements needed for self-driving cars to work?

Self-driving cars are a curious case; a long sought-after technology that always seems to be so close, yet so far at the same time. In any case, the thing that allows humans to drive cars is one thing: our ability to take in and process information. The same must be possible for self-driving cars. Instead of organs and a brain, however, self-driving cars have sensors and most likely some controller within the car itself. The packaged payload is once again information, this time in the form of bits and bytes instead of electrical impulses. The tools are again the control system of the car, and the control system is the computer within the car.

If you have a choice between making very smart or somewhat less-dumb roadways, which would you choose & why? How would you improve safety?

Of course, one car is not an island. Self-driving cars will of course be required to work with each other in order to make sure that they coordinate and do not crash into anything. Roads may be one of the keys to providing that information, though there are also other ways to do it. From a certain standpoint, making roads as smart as possible seems like the best thing to do. They could tell cars what condition they are in so as to promote slower driving in harsh conditions, as well as communicate the presence of non-vehicular presences on the roads like deer. They could also provide quite precise location detection of every car on the road. All this technology, however, comes at quite the price, int both upfront and maintenance costs, and most of them can be supplied much more easily with existing infrastructure. GPS can allow for location tracking. Meteorological services can be correlated with road conditions, and unexpected presences in the road are being dealt with even now, with proximity detection and automatic braking. So, instead of making roads wicked smaht, we can make the cars driving on them smarter and tap into existing technologies to get the same information those roads could provide.

As for safety, that is where coordination comes in. Humans are notoriously poor drivers because we are not coordinated at all; the root cause of traffic jams and accidents. If every single car on the road was self-driving and communicating, then those issues would cease to exist. Traffic jams would no longer be an issue, and accidents would be cut to 0: so long as every car is working together.

Now, how would they communicate and work together? Obviously, having one, or even several centralized computers probably won't work. The data from billions of cars, all having to be polled in real-time may be too much to handle, and if a supercomputer capable of doing such a thing did exist, imagine the cost of running it! Also, imagine a scenario where a deer suddenly leaps in front of a car in Russia. If the car has to transmit that data to a server elsewhere, then wait for the server to make a decision, it may be too late. Time is measured in milliseconds; too long a time waiting for such decisions could cost lives.

Instead, localize the communication. Have each car be powerful enough to make decisions on their own, and communicate that decision to other cars within a local radius. This dramatically cuts down on stress on a handful of supercomputers as well as saves precious time in the process. Even if that one car that brakes suddenly to avoid the deer is being trailed close behind by another, the first car can transmit that data to the one behind it, and so on if necessary. The trailing cars can then brake along with the first one.

Of course, that's not to say that there shouldn't be a few centralized sources of communication. They are still useful for sending notifications to every single car necessary, which may become necessary in cases of national emergency,

Identify the Packaged Payload in (B). How do you make money if you’re Ford? How do you make money if you’re Google? Is the packaged payload the same?

If you're Ford, the Packaged Payload is simply energy in the form of petrol, just like it always has been. You make money off of sales of the car itself, along with any accessory sensor that may be deemed necessary to retrofit older cars, perhaps.

If you're Google, the Packaged Payload is slightly different. Instead of the fuel used to propel the car, it is the information that the car needs to decide where to go. Perhaps it is unentrepreneurial to say that such a thing should not come with a cost. Perhaps it could, and with most other healthy competitive industries, a consumer should have the choice of which control module to buy to control their car. The separate modules would communicate via a universal protocol agreed to by all companies. Differentiating features would include security, personalizability, and performance. If one really wanted to make money aside from upfront costs, perhaps charge some sort of subscription fee to use the module. As much money as one might make, however, I do believe that something as revolutionary and critical to safety as a self-driving car control module cannot feasibly charge a monthly fee for use, only a one-time fee. This will of course inevitably lead to the ethics of business and practices, but we'll cross that bridge when we get there.

Hopefully soon, as the potential for such technology is limitless.