Search the Community
Showing results for tags 'POTM'.
Found 3 results
This project is a submission for the 2015 Project of the Month Halloween contest. It came about as a request from my four year old grandson after he had seen the Blue Angels fly over during Seafair in Seattle. The basic air frame was constructed from two cardboard boxes as shown in the photograph below. . The boxes are attached to each other with brads and hot glue. Edges are reinforced where I felt necessary by folding extra cardboard over or gluing in reinforcement cardboard. Also shown in the photograph above are the following: wings, tail, and fins constructed from a corrugated plastic storage box and hot glued in place reflector on the nose constructed from a coffee can bottom which will eventually become the "search light". There is a similar reflector on the tail which will become the jet exhaust. control panel with various switches and a potentiometer I had in my junk box installed on a wooden paint stirring stick The visible surfaces were then covered with wrapping paper using Outdoor Mod Podge - a waterbased sealer, glue and finish available in craft stores in the United States. A second coat was then put on to make it a bit more waterproof. This is the schematic for the avionics. A little custom MSP430G2553 board with two AA batteries beside it in the tail controls an Adafruit neopixel ring "jet exhaust" with a toggle switch on the panel to turn it on and off. Everything else runs off of three AA batteries with the wiring in the front of the aircraft between a cardboard firewall and the nose. Two latching buttons turn colored LEDs on the panel on and off while a third turns a 3W LED (searchlight) on and off. There is a potentiometer to control the brightness of the searchlight. Finally I repurposed the sound board and speaker from an old greeting card that was originally powered by a coin cell. The WS2812 Adafruit Neopixel ring is controlled by the MSP430G2553. I used the library posted by ILAMtitan at 43oh - so full credit to those who had a hand in developing it. The library example worked well as is for my purposes and about the only thing I changed was the output pin and the number of pixels being controlled in the code. Here is a picture of my grandson trying it out. We glued plastic cups over the headlight and jet exhaust and stuck Energia stickers on it. I may touch it up a bit more if I have time and post a final picture. Improvement Ideas: I also made a "candy counter" out of an old scale for his entertainment (and mine). His immediate reaction was that we should somehow attach the candy counter to the airplane. Clever, but not practical due to the need for the scale to be level and not banged around by a four year old. Using a counter where candy is funneled past a beam, like Chicken did with his counter might work though. My idea is that we add GPS along with thumbs up/down buttons. Then he could rate offerings and either store the data as a reminder for next year or send it out over the IOT with location so that his buddies know where the good candy is.
Overview dAISy (do AIS yourself) is a very simple AIS receiver that I developed from scratch. It is built around the Silicon Labs EZRadioPRO Si4362 receiver, using a Texas Instruments MSP430G2553 MCU for processing and the MSP-EXP430G2 v1.5 LaunchPad as development platform. The complete project source code and schematics are available on GitHub: https://github.com/astuder/dAISy Update 5/18/2015: A finished, self-contained AIS receiver based on this project is now available for purchase on Tindie. AIS, short for Automatic Identification System, is a standard for tracking ships. Ships advertise their position, course and other information with short transmissions on specific frequencies (161.975 MHz and 162.025 MHz). More on Wikipedia. An AIS receiver, like dAISy, receives and decodes AIS transmissions. It then re-packages the raw data into NMEA sentences (specifically formatted ASCII strings). Finally, using a serial connection, these strings are forwarded to more capable equipment for further processing. If you're the lucky owner of a tricked out boat, you could connect dAISy to your navigation computer. For land lobbers like me, a more common use case is to run naval mapping software that supports AIS data input on a PC. In the screenshot below I've connected dAISy to OpenCPN (link), an open source chart plotter and navigation software. On the top right you can see my setup war-driving at the Seattle waterfront as my lab is too far from the coast to receive anything. The LaunchPad sits on the dashboard with a white USB cable connecting to the notebook computer in the foreground. dAISy's data is fed into OpenCPN, bottom right shows a log of the serial data received. OpenCPN maintains a database of all the collected data (lower left) and visualizes nearby ships on a map (top center), including past and projected course. Hovering the mouse over a ship will display its name (text on yellow ground) and clicking it will reveal more detail (top left). Hardware I wanted to build my own, non-SDR, AIS receiver for a long time. There are a few projects floating around the internet (e.g. here) which refer back to an article by Peter Baston, published 2008 in Circuit Cellar magazine (copy available here gone.. google for Peter Baston Circuit Cellar to find other copies). Unfortunately, the CMX family of modem ICs by CMS Microcircuits (link) used in these projects are relatively expensive ($15+) and hard to find for hobbyists. In addition you'd need a radio to do tune into and down-convert from the ~162 MHz carrier frequency. So I was quite excited when earlier this year a parametric search on Mouser brought up a new IC that covered the required range (162 MHz) and modulation (GMSK). And best of all, available in single quantities for $3.56 $2.27 $2.22! (link) The Silicon Labs EzRadioPRO Si4362 (link) is a single chip receiver that covers frequencies from 142 to 1050 MHz and supports various modulations, including GMSK. It comes in a tiny 20-pin QFN package and the only external parts required are a 30 MHz crystal, an antenna with a few capacitors and inductors for impedance matching, and finally some decoupling caps and pull-down resistors. Time to whip up a breakout board. I used the opportunity to give KiCad a try and quite like it. Here's the schematic: And the layout: I used OSHPark to make the PCBs. At a smidgen over one square inch it cost $5.15 for 3 copies: http://oshpark.com/shared_projects/QUWi71r4 Note that the layout still has three issues that I already fixed in the schematic: GPIO0 and GPIO1 were flipped SDO required a pull-down resistor as the radio leaves it floating when not actively sending, which confused the hell out of me while trying to figure out the communication protocol. Lastly, the holes for the headers turned out to be slightly too small to comfortably fit the cheap breakout headers I had at hand. Edit: Here's Rev B where I fixed these issues: http://oshpark.com/shared_projects/WI6u3Qmk Which brings us to the BOM: Silicon Labs Si4362 (U1) 30 MHz crystal (X1)Si4362 datasheet specifies <11 pF load capacitance, but a crystal specified for 12pF load capacitance seems to work fine too Antenna/LNA matching network, calculated based on SiLabs AN643 (link, approx. values, +/- 5% shouldn't matter too much):75 ohm (dipole): 10 pF (CR1), 5 pF (CR2), 280 nH (LR1), 200 nH (LR2) 50 ohm: 12 pF (CR1), 6 pF (CR2), 240 nH (LR1), 160 nH (LR2) Decoupling caps:100 pF, 100 nF, 1uF (C1, C2, C3) Pull-down resistors100 k (R1, R2) First thing I noticed when I received the parts: The 20-pin QFN at 4x4 millimeters is tiny! I mounted it by first tinning the pads with a small quantity of solder. I then added flux and placed the chip on the pad. I then used a hot air station to carefully reflow the solder. Worked the first time around. After using jumper wires to figure out how to talk to the chip, I mounted the breakout board on a makeshift BoosterPack using perfboard, double-sided tape and wire (see picture at the top of the post). Here's how I ended up connecting the breakout board to the LaunchPad / MSP430G2553: SEL -> P1.4 (SPI chip select) SCLK -> P1.5 (SPI CLK) SDO -> P1.6 (SPI MISO) SDI -> P1.7 (SPI MOSI) GPIO0 -> P2.0 (I/O unused) GPIO1 -> P2.1 (I/O clear-to-send) GPIO2 -> P2.2 (I/O RX clock) GPIO3 -> P2.3 (I/O RX data) SDN -> P2.4 (shutdown / reset) IRQ -> P2.5 (I/O channel-clear) Software The software of dAISy consists of three major blocks: Radio configuration and control over SPI Packet handler, including a basic FIFO for received messages NMEA encoding and transmission to the PC over UART For UART (TX only) and SPI (TX/RX) I use the MSP430G2553's USCI A0 and B0 respectively. In both cases I don't use interrupts which simplifies things considerably. Upon reset the following steps happen: Initialize MSP430 peripherals Initialize packet handler, which will also reset FIFO Initialize and configure of radio, which will also setup SPI Start packet handler, which will also put the radio into receive mode And in the main loop: If debug messages are enabled, poll packet handler for status and errors and report them over UART Check FIFO for new packets If there is a new packet, invoke NMEA processing (which sends the message over serial to the PC) and remove packet from FIFO Below follows a more detailed discussion of the radio integration and the implementation of the packet handler. Radio The communication with the radio is vanilla SPI using 4 wires: MOSI (SDI), MISO (SDO), CLK (SCLK) and CS (SEL). I used the MSP430's USCI B0 to implement SPI and a separate pin to control CS. The only tricky thing to figure out was, that the Si4362 keeps the MISO line floating unless it actively transmits data. This is unfortunate as the master is supposed to poll for a specific response (FF) to detect when the radio is ready to receive more commands. This is easily fixed by adding a weak pull down resistor to SDO. I did this on the board, but it probably also works with using MSP430's internal pull-down. Additional lines I used to control the radio are: SDN to reset the radio CTS, which by default is mapped to the radio's GPIO1, indicating that the radio is ready for the next command While taking up an extra pin, CTS turned out to be much more convenient than the SPI response code to properly time communication flow with the radio. In dAISy, I wait for CTS to go high after each command to ensure the radio completed its task. The communication protocol is quite extensive but well documented: EZRadioPRO API Documentation describes the complete API and all registers AN633 Programming Guide for EZRadioPro Si4x6x Devices describes how to use the API in common scenarios Both are available on the Si4362 product page (link), under Documentation > Application Notes and are still updated quite frequently. The radio is set up by dumping a large configuration sequence into it. This includes configuration of radio frequency, modulation, GPIO pins and more. This information is stored in radio_config.h, which has to be generated with a tool called WDS (Wireless Development Suite). WDS is available in the Tools section on the Si4362 product site. Above are the settings I used for dAISy. WDS will use this information to configure various amplifiers, filters, clocks and decoding algorithms inside the chip. As Si4362 supports GMSK encoding only indirectly (see this thread), I'm certain there's more optimization potential by tweaking registers, but that's currently way beyond my knowledge of RF theory. While the Si4362 comes with its own packet handler, it unfortunately does not support NRZI encoding (Wikipedia). So I set up the radio to expose the 9600 baud clock and received data on separate pins and implemented my own packet handler. Packet Handler The packet handler (inspired by Peter Baston's implementation) is implemented as a state machine that is invoked on each rising edge of pin P2.2 which receives the data clock. There are 5 main states: Off, no processing of incoming data Reset, start from anew, either on start up or after successful/failed processing of a packet Wait for Sync, waiting for a training sequence to arrive (010101..) and start flag (01111110), implemented with its own state machine Reset, start new preamble 0, last bit was a zero 1, last bit was a one flag, training sequence complete, now process start flag Prefetch, ingest the next 8 message bits to ease further processing Receive Packet, process bits until the end flag (01111110) is found or an error situation occurs Independent of state, the interrupt routine continually decodes NRZI into actual bit sequence. In the "Receive Packet" state there's continuous calculation of the packet CRC and some bit-de-stuffing. When the end flag is found and the CRC is correct, the received message is committed into the FIFO. If an error is encountered, the bytes already written to the FIFO are discarded. In both cases, the state machine starts anew by transitioning into RESET. This reads like a lot of code for an interrupt handler. However with the MCU running at 16MHz even the most complex state only uses a fraction (<10%) of the available time. Future Improvements Lastly a list of things I'd like to improve with the next version of dAISy. Software: Receiving on both AIS channels through channel-hopping done 1/5/2014 Tweak radio settings for better sensitivity and lower error rate LED(s) for indicating reception of valid/corrupt packets Hardware: Proper antenna connector Layout PCB as BoosterPack and/or USB dongle Receiving on both AIS channels at once with two radio ICs -- edit 12/25: replaced original post with high-level project description, more detailed documentation of implementation to come -- edit 12/28: added documentation for hardware (here and on Github), fixed some typos -- edit 12/31: added documentation for software and list of future improvements -- edit 01/05: implemented channel hopping (change to state machine) -- edit 01/15: changed state machine to reflect recent changes (see post further down for details), added link to shared project on OSHPark -- edit 01/25: major rework of sync detection state machine
This project is an update to the binary clock that I used on my desk. The new version has a lot of new features including RGB leds(WS2812), a bigger microcontroller(The Olimexino-5510 board), capacitive touch and light sensor. My first idea was to have something based on the MSP430G2553, a couple of WS2812 leds and capacitive touch. But after comparing the work i would have to do, and very few rewards to the Olimexino-5510 functionality I quickly reconsidered. The Olimexino-5510 provides quite a few things I wanted: MSP430F5510 Battery Charger USB capabilities Arduino Form Factor So all I had to do was make a nice board that went on top with the stuff I wanted for the clock functionality. WS2812 RGB LEDs The main feature of the Clock is the 6x3 WS2812 RGB led matrix. These leds contain a little controller that accept a serial protocol for the color data and they handle the PWM. They're also chainable meaning that only one pin(D11, LED-DATA) is required to quite all of them. In my using @@oPossum's library Power Supply The Olimexino-5510 has a connector for a battery. But it just connects the battery to the 5V rail, the battery could go as low as 3V. The WS2812 aren't meant to run that low, specifically the Blue led get a lot dimmer. In order to fix this I incorporated a SMPSU that can get 5V from the battery voltage. It could in theory handle as much as 2A. The design was done with TI Webench, all parts are the same as the suggested ones. I had to modify the Olimexino a little to actually give me the raw battery voltage on the shield connector, on battery there's no voltage on the 5V pin, i assumed there was. It all works quite well now except it's kinda whiny. The WS2812 leds are very bright, so in the darkness this might be a problem. One could dim them by sending them a darker color but this reduces resolution. Q2's purpose is to PWM is the 5V that the LEDs in order to dim them externally. This essentially gives another scaling factor for the brightness. It's a similar principle to how dynamic contrast works in TVs. Unfortunatelly this did not work as I wanted, the mosfet was too slow to PWM the leds fast enough without aliasing. My next design will probably contain a mosfet driver. Capacitive Touch Pads I have 4 pads acting as buttons. I originally connected them directly to some pins assuming I had PinOsc hardware like on the value line. Unfortunately I discovered this was not the case too late. I fixed it by adding 2 resistors between each of the pairs. This allows me to do a pretty crappy RC measure. It still works quite good though, i can get about 200 discrete values of the reading. As suggested by TI I had a non solid ground plane of the backside to reduce the intrinsic capacitance. Light Sensor The shield also has a light sensor, meant to measure ambient brightness. One can use this to make the display's brightness match the room. The sensor is connected via I2C, since neither the Arduino nor the Olimexino-5510 have I2C exposed on the pins I will have to do a software solution for this. The TCS34725FN sensor is also capable of measuring RGB color; I'm sure something fun can be accomplished using that. Of course I managed to do the footprint wrong for this, so it required some cutting traces to swap some pins; after that it worked just fine. Eagle Files I also have the schematics in PDF format. Code The current code is mostly made to prove the hardware. It could use a lot more work for the UI. Features Clock Functionality with fading SMPSU Off demo Capacitive Touch Demo Light Sensor Demo USB CDC ported from Energia that i used for debugging so far Everything was compiled with msp430-gcc. I uploaded the firmware using the new f5529 launchpad board due to the fact that mspdebug does not support the olimexino usb bootloader. Parts Most parts I got from digikey, except the Olimexino-5510, the beefy 6600mAh battery and the WS2812 leds. I got a pretty good price for the LEDs from Alibaba at only 13 cents each. I ordered the board through Elecrow, I really needed it to be black. Meta My old clock was this boring thing with an attiny44, using a matrix of green leds. I originally started this version(v2.0) as a school project, but I wanted to share it. Due to the many issues I had I'll probably make a version 2.1(if i fix the shield) or a v3 if I make a standalone board. I'm open to ideas. I still have quite a few board leftover(about 7), i'm open to sending them to people if postage is cheap/free/easy. Imgur album for non-users.