My buddy Harold recently landed a new job at a great technology company. It came at a perfect time for him, having just been laid off from the corporate behemoth where he’d toiled away as an anonymous cog for 19 years. But the day before he was to start, the new company’s HR folks sent him some last-minute documents to sign. One was a broad and vaguely worded non-compete agreement which essentially said he was barred from working in any related industry for a year after leaving the company.
Harold was tempted not to sign, but eventually relented because one needs to put food on the table. Thankfully he’s now thriving at the new company, but his experience got me thinking about all the complications hackers face with the day jobs that so many of us need to maintain. Non-competes and non-disclosures are bad enough, but there’s one agreement that can really foul things up for a hacker: the Intellectual Property Agreement.
Continue reading “Ask Hackaday: How Should Hackers Handle IP Agreements?”
An engineering student at the University of Western Macedonia has just added another appliance to the ever-growing list of Internet enabled things. [Panagiotis] decided to modify an off-the-shelf bread maker to enable remote control via the Internet.
[Panagiotis] had to remove pretty much all of the original control circuitry for this device. The original controller was replaced with an Arduino Uno R3 and an Ethernet shield. The temperature sensor also needed to be replaced, since [Panagiotis] could not find any official documentation describing the specifications of the original. Luckily, the heating element and mixer motor were able to be re-used.
A few holes were drilled into the case to make room for the Ethernet connector as well as a USB connector. Two relays were used to allow the Arduino to switch the heating element and mixer motor on and off. The front panel of the bread maker came with a simple LCD screen and a few control buttons. Rather than let those go to waste, they were also wired into the Arduino.
The Arduino bread maker can be controlled via a web site that runs on a separate server. The website is coded with PHP and runs on Apache. It has a simple interface that allows the user to specify several settings including how much bread is being cooked as well as the desired darkness of the bread. The user can then schedule the bread maker to start. Bread Online also comes with an “offline” mode so that it can be used locally without the need for a computer or web browser. Be sure to check out the video demonstration below. Continue reading “Bread Online is a Bread Maker for the Internet of Things”
[Bayres’] dad setup a webcam as a surveillance camera for a remote property. The only problem was that the only stable Internet connection they could get at this property was DSL. This meant that the external IP address of the webcam would change somewhat often; the needed a way to keep track of the external IP address whenever it changed. That’s when [Bayres] built a solution using Arduino and an Ethernet shield.
The main function of this device is to monitor the public IP address and report any changes. This is accomplished by first making a request to checkip.dyndns.org. This website simply reports your current public IP address. [Bayres] uses an Arduino library called Textfinder in order to search through the returned string and identify the IP address.
From there, the program compares this current value to the previous one. If there is any change, the program uses the Sendmail() function to reach out to an SMTP server and send an e-mail alert to [Beyres’] dad. The system also includes a small LCD. The Arduino outputs the current IP address to this display, making it easy to check up on the connection. The LCD is driven by 74HC595 shift register in order to conserve pins on the Arduino.
The system is also designed with a pretty slick setup interface. When it is booted, the user can enter a configuration menu via a Serial terminal. This setup menu allows the user to configure options such as SMTP server, email address, etc. These variables are then edited and can be committed to EEPROM as a more permanent storage solution. Whenever the system is booted, these values are read back out of the EEPROM and returned to their appropriate variables. This means you can reconfigure the device on the fly without having to edit the source code and re-upload.
When [William’s] thermostat died, he wanted an upgrade. He found a few off-the-shelf Internet enabled thermostats, but they were all very expensive. He knew he could build his own for a fraction of the cost.
The primary unit synchronizes it’s time using NTP. This automatically keeps things up to date and in sync with daylight savings time. There is also a backup real-time clock chip in case the Internet connection is lost. The unit can be controlled via the physical control panel, or via a web interface. The system includes a nifty “vacation mode” that will set the temperature to a cool 60 degrees Fahrenheit while you are away. It will then automatically adjust the temperature to something more comfortable before you return home.
[William’s] home is split into three heat zones. Each zone has its own control panel including an LCD display and simple controls. The zones can be individually configured from either their own control panel or from the central panel. The panels include a DHT22 temperature and humidity sensor, an LCD display, a keypad, and support electronics. This project was clearly well thought out, and includes a host of other small features to make it easy to use.
[Filipe] has been playing around with custom firmware for inexpensive IP cameras. Specifically, he has been using cameras based on a common HI3815 chip. When you are playing around with firmware like this, a major concern is that you may end up bricking the device and rendering it useless. [Filipe] has documented a relatively simple way to backup and restore the firmware on these cameras so you can hack to your heart’s content.
The first part of this hack is hardware oriented. [Filipe] cracked open the camera to reveal the PCB. The board has labeled serial TX and RX pads. After soldering a couple of wires to these pads, [Filipe] used a USB to serial dongle to hook his computer up to the camera’s serial port.
Any terminal program should now be able to connect to the camera at 115200 baud while the camera is booting up. The trick is to press “enter” during the boot phase. This allows you to log in as root with no password. Next you can reset the root password and reboot the camera. From now on you can simply connect to the phone via telnet and log in as root.
From here, [Filipe] copies all of the camera’s partitions over to an NFS share using the dd command. He mentions that you can also use FTP for this if you prefer. At this point, the firmware backup is completed.
Knowing how to restore the backup is just as important as knowing how to create it. [Filipe] built a simple TFTP server and copied the firmware image to it in two chunks, each less than 5MB. The final step is to tell the camera how to find the image. First you need to use the serial port to get the camera back to the U-Boot prompt. Then you configure the camera’s IP address and the TFTP server’s IP address. Finally, you copy each partition into RAM via TFTP and then copy that into flash memory. Once all five partitions are copied, your backup is safely restored and your camera can live to be hacked another day.
There’s a number of devices out there that extend HDMI over IP. You connect a video source to the transmitter, a display to the receiver, and link the two with a CAT5/5e/6 cable. These cables are much cheaper than HDMI cables, and can run longer distances.
[Daniel] didn’t care about extending HDMI, instead he wanted a low cost HDMI input for his PC. Capture cards are a bit expensive, so he decided to reverse engineer an IP HDMI extender.
After connecting a DVD player and TV, he fired up Wireshark and started sniffing the packets. The device was using IP multicast on two ports. One of these ports had a high bitrate, and contained JPEG headers. It looked like the video stream was raw MJPEG data.
The next step was to write a listener that could sniff the packets and spit the data into a JPEG file. After dealing with some quirks, JPEG images could be saved from the remote device. Some more code was needed to have the computer initiate the streaming, and to extract audio from the second port.
In the end, video capture with the low cost device was possible. [Daniel] also provided a bonus teardown of the device in his writeup.
As many of us do, [Steaky] serves as a kind of on-call help desk for his family. His father in law recently contacted him because his pan and tilt webcam died, and he wanted to see if it could be fixed. Never turning down a challenge, [Steaky] decided to give it a shot.
He ended up having to disassemble it since the camera was completely unresponsive, and what he found inside piqued his interest. The no-name camera sported an ARM microprocessor at its core, and it seems that some of its pins were damaged due to a poorly designed case. He figured resoldering the pins would do the trick, but that wasn’t the end of his adventures.
As he dug deeper into the device, he found that the camera essentially killed itself, reading and writing data to the wrong places due to the damaged pins on the processor. After plenty of searching around, he was able to find a somewhat compatible firmware image, though not everything worked properly.
His father in law was so impressed with his work that he asked for the camera back, even though [Steaky] hadn’t fully repaired it yet. While he bid the camera goodbye, we’re pretty sure he’d be more than happy to reclaim it for a few days if any of our readers had some additional insight or resources that might help him finish the job.