On paper, bicycling is an excellent form of transportation. Not only are there some obvious health benefits, the impact on the environment is much less than anything not directly powered by a human. But let’s face it: riding a bike can be quite scary in practice, especially along the same roads as cars and trucks. It’s hard to analyze the possible threats looming behind you without a pair of eyes in the back of your head.
[Claire Chen] and [Mark Zhao] have come up with the next best thing—bike sonar. It’s a two-part system that takes information from an ultrasonic rangefinder and uses it to create sound-localized pings in a rider’s ears. The rangefinder is attached to a servo mounted on the seat post. It sweeps back and forth to detect objects within 4 meters, and this information is displayed radar-sweep-style graphic on a TFT screen via a PIC32.
Though the graphic display looks awesome, it’s slow feedback and a bit dangerous to have to look down all the time — the audio feedback is by far the most useful. The bike-side circuits sends angle and distance data over 2.4GHz to another PIC mounted on a helmet. This PIC uses sound localization to create a ping noise that matches the distance and location of whatever is on your tail. The ping volume is relative to the distance of the object, and you just plug headphones into the audio jack to hear them. Bunny-hop your way past the break to check it out.
Continue reading “This Bike Sonar is Off the Chain”
We’ve heard reports that internet connectivity in Australia can be an iffy proposition, and [deandob] seems to back that up. At the limit of a decent DSL connection and on the fringe of LTE, [deandob] decided to optimize the wireless connection with this homebrew Yagi antenna.
Officially known as the Yagi-Uda after its two Japanese inventors from the 1920s, but generally shortened to the name of its less involved but quicker to patent inventor, the Yagi is an antenna that provides high gain in one direction. That a homebrew antenna was even necessary at all is due to [deandob]’s ISP using the 2300MHz band rather than the more popular 2400MHz – plenty of cheap 2.4GHz antennas out there, but not so much with 2.3GHz. With multiple parallel and precisely sized and spaced parasitic elements, a Yagi can be a complicated design, but luckily for [deandob] the ham radio community has a good selection of Yagi design tools available. His final design uses an aluminum rod for a boom, 2mm steel wire for reflectors and directors, and a length of coax as the driven element. The result? Better connectivity that pushes his ISP throttling limit, and no more need to mount the modem high enough in his house to use the internal antenna.
People on the fringes of internet coverage go to great lengths to get connections, like this off-grid network bridge. Or if you’d rather use a homebrew Yagi to listen to meteors, that’s possible too.
Wanting to extend the capabilities of the radio frequency devices in his home [Kalle Löfgren] turned a Raspberry Pi into an RF control hub. We’ve seen some of his home automation work in the past. In his media room he built a universal remote base station which used the same RF board as in this project. The main difference is that before he went with an AVR microcontroller and this time he’s upgrade to a Raspberry Pi board.
The RPi brings a lot more to the table. Notably, the scripting (whose output is shown above) and networking features. His radio board is an nRF24L01 which he talks to via the SPI protocol. The Raspberry Pi has no problem talking to SPI devices through its GPIO header. [Kalle] just needed to do a bit of setup to configure the pin modes.
A Python script lets him sent commands using his keyboard, but this can also be automated. Combine that with the TCP server script he wrote and it opens up the a wide range of configurations to switch or talk to any device operating on the 2.4 GHz band.
For a final design project, [Frank] and his group took on an augmented reality project. The goal was to make objects interactively controllable by pointing a smartphone at them. Their solution was Augmented Reality Universal Controller and Identifier (ARUCI).
The system locates controllable objects by sensing IR beacons that contain identifiers for each object. The IR is received by a Wiimote sensor, which has been integrated into a custom PCB. This board sits in a 3D printed enclosure, and mounts to the back of a smartphone. The electronics are powered by tapping off of the phone’s battery.
Commands are sent to devices using a custom 2.4 GHz protocol which was implemented using the ATmega128RFA1. Each device has another ATmega to receive the signal and control the real world object. In their demo, the group shows the system controlling devices including a TV, a radio, and an RC car.
The system provides an interesting way to interact with objects, and the hardware integration is quite impressive. After the break, watch [Frank] give a demo.
Continue reading “IR Based Augmented Reality”
The good [Doctor Iguana] has been working on a pair of robots which communicate with each other using mRF24J40MA wireless transceivers. This presents a challenge in debugging, as he really didn’t have an easy way of monitoring those communications. His solution was to build his own base station which lets him use a computer to monitor what each robot is saying.
He spun his own board for the project. USB connectivity is provided by an FTDI chip, the FT232RL. This converts the USB communications in to serial for the dsPIC33 microcontroller. The FTDI chip comes with a fairly fine-pitch, but the footprint can still be fabricated using toner transfer if you’re fairly familiar with the process. [Dr. Iguana] took some close-up images of the unpopulated board which might make you a little nervous with the soldering iron. The other end of the board hosts the same Microchip wireless module as he used in his robots.
After a bit of rework (noted on the photo labels) he got this up and running. Now he can capture all of the wireless communications and see if problems are due to the sender or the receiver.
[Danilo Larizza] is sharing a network connection between a couple of apartments. They are not far apart, but they are also not right next to each other so a set of external antennas is necessary. He built this 2.4 GHz biquad antenna on the cheap (translated) just to test if it improved the signal before he tried to buy a proper antenna. It turns out to work well enough that this is all that he needs.
The antenna itself is about one meter of thick wire bent into two squares which are 31mm on each side. The coaxial cable going to the router connects to the center portion of this antenna. For a bit better directional reception he added some tin foil as a reflector. Since this is outdoors he used a food storage container for protection (the antenna is mounted to the lid, the body has been removed for this picture). The whole things is perched on a stake in a flower pot with proper line of sight to the other antenna.
We’ve seen a very similar design used for an NRF 24L01+ radio. If you need more details that [Danilo] posted that would be a good project to study.
[Texane] picked up a 2.4 GHz transmitter/receiver pair for transmitting sensor data wirelessly. After using them in a project he wanted to try pushing them a bit to see what the limits are when it comes to higher bandwidths. He ended up building a wireless speaker that transmits audio at about 90 KB/s. That link leads to a subfolder of his git repository. The code for this project is in the RX and TX folders, with images and video in the DOC folder.
The radio hardware that he’s using is a Nordic nRF24L01P chip which is available on a breakout board from Sparkfun. [Texane] mentioned to us that the chip includes error checking, packet ACK, and automatic retransmission. But these add overhead that can slow things down. The chip does offer the option to disable these features to get lower level access to the hardware. That’s exactly what he did and he mentions that the example code he wrote for the transmitter and receiver make every cycle count. This makes us wonder if it’s the speed of the ATmega328 chip that is the bottleneck, or the transceivers themselves?