If you’re looking for a simple way to make an RF transmitter, check out [Tomasz]’s Morse code transmitter. His design uses nothing more than a microcontroller and a 16MHz crystal to transmit CW Morse code on 96MHz. We’ve seen some similar designs that work at lower frequencies, but transmitting up at 96MHz is pretty impressive.
[Tomasz] used an STM32L microcontroller for this project, which isn’t specced to run up at the high frequencies he wanted to transmit at. To get around this, [Tomasz] wired a 16Mhz oscillator up to microcontroller’s clock input. The clock input is run into the micro’s PLL which is capable of generating high frequencies. He mentions that you can use the internal oscillator instead of a crystal, but it has a ton of phase noise and splatters all over the spectrum.
[Tomasz] chose to start transmitting at 96MHz, which can be picked up by a standard FM radio. To generate this frequency, he set the PLL to multiply the 16MHz crystal up to 192MHz followed by a clock divide of 2 which brings it down to 96MHz. The microcontroller’s CPU runs on the 16MHz crystal input before it goes into the PLL. Next [Tomasz] enabled the MCO clock output pin which routes the 96MHz signal to the outside world.
Transmitting CW is pretty simple; it just involves turning a fixed-frequency transmitter on and off. [Tomasz] wrote a function that enables and disables the MCO output pin. This has the effect of keying any Morse code string you throw at it. Check out the video after the break to see the transmitter in action.
Continue reading “Morse Code RF Transmitter from a Micro’s Clock Output”
With Samsung’s new Gear VR announced, developers and VR enthusiasts are awaiting the release of the smartphone connected VR headset. A few people couldn’t wait to get their hands on the platform, so they created, OpenGear, a Gear VR compatible headset.
The OpenGear starts off with a Samsung Galaxy Note 4, which is the target platform for the Gear VR headset. A cardboard enclosure, similar to the Google Cardboard headset, holds the lenses and straps the phone to your face.
The only missing part is the motion tracking electronics. Fortunately, ST’s STM32F3 Discovery development board has everything needed: a microcontroller with USB device support, a L3GD20 3 axis gyro, and a LSM303DLHC accelerometer/magnetometer. These components together provide a USB inertial measurement unit for tracking your head.
With the Discovery board strapped to the cardboard headset, an open-source firmware is flashed. This emulates the messages sent by a legitimate Oculus Rift motion tracker. The Galaxy Note 4 sees the device as a VR headset, and lets you run VR apps.
If you’re interested, the OpenGear team is offering a development kit. This is a great way for developers to get a head start on their apps before the Gear VR is actually released. The main downside is how you’ll look with this thing affixed to your face. There’s a head-to-head against the real Gear VR after the break.
[via Road To VR]
Continue reading “Build Your Own Gear VR”
A few years ago, [Frans-Willem] bought a few RGB LED panels. Ten 32×16 panels is a lot of LEDs, and to drive all of these panels requires some sufficiently powerful hardware. He tried working with an FPGA development board, but that didn’t have enough memory for 24-bit color. The microcontroller du jour – a TI Stellaris – couldn’t get more than 16 bits of color without flickering. With a bunch of LEDs but no way to drive them, [Frans-Willem] put the panels in a box somewhere, waiting for the day they could be used to their fullest capacity.
This day came when [Frans-Willem] was introduced to the STM32 series of chips with the F1 Discovery board. While looking for some electronic playthings to use with this board, he stumbled upon the LED panels and gave them one more try. The results are spectacular, with 33 bits of color, with animations streamed over a router over WiFi.
The panels in question are HUB75 LED panels. In the 32×8 panels, there are six data pins – two each for each color – four row select pins, and three control pins. The row select pins select which row of pixels is active at any one time. Cycle through them fast enough, and it will seem like they’re all on at once. The control pins work pretty much like the control pins of a shift register, with the data pins filling in the obvious role.
The code that actually drives the LEDs all happens on an STM32F4 with the help of DMA and FSMC, or the Flexible Static Memory Controller found on the chip. This peripheral takes care of the control lines found in memory, so when you toggle the write strobe the chip will dump whatever is on the data lines to a specific address in memory. It’s a great way to take care of generating a clock signal.
For sending pixels to this display driver, [Frans-Willem] is using the ever-popular TP-Link WR703N. He had originally planned to send all the pixel data over the USB port, but there was too much overhead, a USB 1.1 isn’t fast enough. That was fixed by using the UART on the router with a new driver and a recompiled version of OpenWRT.
All the software to replicate this project is available on Github, and there’s a great video showing what the completed project can do. You can check that out below.
Continue reading “RGB LED Matrices With The STM32 and DMA”
Generating VGA is a perennial favorite on the Hackaday tips line, and it’s not hard to see why. Low-res video games, of course, but sending all those pixels out to a screen is actually a pretty challenging feat of coding. The best most project have attained is the original VGA standard, 640×480. Now that we have fast ARMs sitting around, we can bump that up to 800×600, like [Karl] did with an STM32F4 Discovery board.
The problem with generating VGA on a microcontroller is the pixel frequency – the speed at which pixels are shoved out of the microcontroller and onto the screen. For an 800×600 display, that’s 36 MHz; faster than what the 8-bit micros can do, but a piece of cake for the STM32F4 [Karl] is using.
[Karl] started his build by looking at the VGA project Artekit put together. It too uses an STM32, but a 36-pin F103 part. Still, it was fast enough to generate a line-doubled 800×600 display. [Karl] took this code and ported it over to the F4 part on the Discovery board that has enough space for a full 800×600 frame buffer.
With all that RAM on board the F4 part, [Karl] was able to expand the frame buffer and create a relatively high-resolution display with DMA and about a dozen lines of code. It looks great, and now we just need a proper application for high-resolution VGA displays. Retrocomputing? A high-resolution terminal emulator? Who knows, but it’s a great use for the STM32.
If circles and some text aren’t your thing, Artekit also has Space Invaders running on the 36-pin STM32.
Just a few years ago, palm sized radio controlled toys were nothing more than a dream. Today, you can find them at every mall, toy store, and hobby shop. [Alvaro] couldn’t resist the tiny Estes Proto X quadcopter. While he enjoyed flying the Proto X, he found that the tiny controller left quite a bit to be desired. Not a problem for [Alvaro], as he embarked on a project to reverse engineer the little quad.
Inside the quadcopter and its lilliputian radio, [Alvaro] found a STM8 based processor and an Amiccom A7105 2.4G FSK/GFSK Transceiver radio. The A7105 is well documented, with datasheets easily obtained on the internet. The interface between the processor and the radio chip was the perfect place to start a reverse engineering effort.
With the help of his Saleae logic analyzer, [Alvaro] was able to capture SPI data from both the quadcopter and the transmitter as the two negotiated a connection. The resulting hex files weren’t very useful, so [Alvaro] wrote a couple of Python scripts to decode the data. By operating each control during his captures, [Alvaro] was able to reverse engineer the Proto X’s control protocol. He tested this by removing the microcontroller from the remote control unit and wiring the A7105 to a STM32F4 dev board. Connecting the STM32 to his computer via USB, [Alvaro] was able to command the quad to take off. It wasn’t a very graceful flight, but it did prove that his grafted control system worked. With basic controls covered, [Alvaro] knocked up a quick user interface on his computer. He’s now able to fly the quadcopter around using keyboard and mouse. Not only did this prove the control system worked, it also showed how hard it is to fly a real aircraft (even a tiny model) with FPS controls.
The Estes Proto X is actually manufactured by Hubsan, a China based manufacturer best known for the x4 series of mini quadcopters. Since the Proto X and the x4 share the same communication protocol, [Alvaro’s] work can be applied to both. With fully computer controlled quads available for under $30 USD, we’re only a few cameras (and a heck of a lot of coding) away from cooperative drone swarms akin to those found in the University of Pennsylvania GRASP Lab.
Continue reading “Reverse Engineering the Proto X Quadcopter Radio”
The world of hobby electronics have only started putting USB in projects for the last few years, and right now, pushing 1.5 Mbps down a USB port is good enough for most cases. This isn’t true for all cases; that’s a terrible data rate, really, and to get the most out of a USB connection, you can at least move up to USB Full Speed and 12 Mbps.
[Linas] is using the STM32F4 microcontroller for this example, an extremely large and very capable chip. [Linas] is using FTDI’s FT2232D USB UART to send data from an SPI port over USB. This chip does support 12 Mbps, but only after a few additions; an external EEPROM must be connected to the FTDI chip to provide a USB 2.0 device descriptor, otherwise the connection between the microcontroller and a computer is limited to 1.5 Mbps. Even using the USB on the STM32 would be a bottleneck in this case; [Linas] is moving data out of the processor using only the DMA controller – using the USB on the STM32 would eat up processor cycles in the microcontroller.
Thanks to the DMA controller inside the STM32, the microcontroller is capable of sending and receiving data through SPI at the same time. The STM32 is capable of reading and writing to the Tx and Rx buffer at the same time, but the computer is only capable of half-duplex operation – it can only read or write at any one time. [Linas] is setting up the DMA controller on the STM32 as a circular mode, putting everything in the buffer into the FTDI chip, and reading everything sent from the computer back into the STM32’s memory. After counting off the correct number of packets. the controller resets everything, moves the circular buffer back to the beginning, and starts the whole process over again.
The circuit was prototyped with an STM Discovery board. With Labview, [Linas] can see the bits coming out of the microcontroller, and send some bits back to the micro over USB. [Linas] has an extraordinarily detailed video tutorial on this project. You can check that out below.
Continue reading “12 Mbps Communication Between A PC and MCU”
Once you venture beyond the tame, comfortable walls of the 8-bit microcontroller world it can feel like you’re stuck in the jungle with a lot of unknown and oft scary hazards jut waiting to pounce. But the truth is that your horizons have expanded exponentially with the acceptable trade-off of increased complexity. That’s a pretty nice problem to have; the limitation becomes how much can you learn.
Here’s a great chance to expand your knowledge of the STM32 by learning more about the system clock options available. We’ve been working with STM32 chips for a few years now and still managed to find some interesting tidbits — like the fact that the High Speed External clock source accepts not just square waves but sine and triangle waves as well, and an interesting ‘gotcha’ about avoiding accidental overclocking. [Shawon M. Shahryiar] even covers one of our favorite subjects: watchdog timers (of which there are two different varieties on this chip). Even if this is not your go-to 32-bit chip family, most chips have similar clock source features so this reading will help give you a foothold when reading other datasheets.
There is a clock diagram at the top of that post which is small enough to be unreadable. You can get a better look at the diagram on page 12 of this datasheet. Oh, and just to save you the hassle of commenting on it, the chip shown above is not an f103… but it just happened to be sitting on our desk when we started writing.