Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by EuphonistiHack

  1. This is great! TI had something similar in their demos a few years back... powered by a chronos watch.


    Yes they did!  I actually stole the maze from that demo (with the blessing of the marketing folks who owned it, of course).  I thought it was a really cool idea, but since the 9b96 is now NRND'd and the SimpliciTI stack (what it used for wireless comms with the Chronos) isn't supported anymore, our marketing folks had pretty much stopped using this demo entirely, which made me sad.


    Since this iteration uses hardware and software that is more heavily supported by TI, the marketing folks have agreed to start using it again for trade shows and the like :)  They even said they'd foot the BOM for me to build a few more of these :-D

  2. Hey everybody, I made a new thing!




    This project uses two Stellaris Launchpads equipped with Sensorhub Booster Packs, which in turn have CC2533EM Zigbee 2.4 GHz daughter cards attached.


    The notion is that one launchpad is hand held, and continually computes its roll, pitch, and yaw via the sensors on the booster pack.  It then transmits these values down to the receiver via the Zigbee daughter card.  The receiver takes these values and uses them to rotate servos that are attached to the x and y axes of a marble maze.


    An explanation video can be found at http://www.youtube.com/watch?feature=player_embedded&v=NUIewWkACPk  Sorry for the noise, but I was debuting the demo at NI Week, and the exhibition hall was pretty noisy.

    A full writeup can be found on my blog, at http://euphonistihack.blogspot.com/2013/08/amazing-sensors.html

    The source code and bill of materials can be found on my github, at https://github.com/EuphonistiHack/marble-maze

    ...well, the bill of materials will eventually be there.  Still working on it.  Source code's up, though :)


    Hope you all enjoy it, and if you have any questions, feel free to ask!



  3. Well, with 5.3, the CCS guys changed around a bunch of tool names, including the tms470 compiler that is used for the Stellaris line (they now call it the ARMv5 compiler).  That's why you're seeing the "Please install the ARMv5.0 Compiler" message... if it were just that my project was using a newer version of the tms470, CCS would still let you import, but give you a warning.  Since my project is using a compiler with both a different version and a different name from the one you have, it's outright not letting you import the project.  I'll push an update sometime today or tomorrow with the compiler set to the tms470... in the meantime, you can try poking around the .project files in the ccs directory to see if you can find out where the compiler is declared and switch that to whatever you're using.

  4. bwar... I recently had to update to CCS 5.3 to for an unrelated project.  I'm assuming this will be a common issue, as 5.3 was released pretty recently.  If you want to get up and running right now, updating CCS should fix it.  I think I still have version 4.9 or 4.7 of the compiler somewhere on my build system... I'll see if I can revert the compiler version in my project settings and push that to github.

  5. That is correct.  Honestly, though, the only reason I cap it at 80K is because there's no reason to go higher than that in my project.  The hardware is capable of handling higher frequencies, but the larger the maximum value, the more difficult it is to set the value using the touchscreen slider.  You can change the maximum sampling frequency pretty easy in my code by editing a single macro.

  6. Hey CorB,

    I'm going to venture a guess and say you'd be able to modify my code pretty easily to suit your needs.  I don't have a datasheet handy, but if memory serves me right, the ADC peripherals on an lm4f120 have a max sampling rate of 1 MHz,.  To get an upper bound of 100 KHz, you'd want to sample around 200 KHz.  I'm fairly certain that the processor and DSP algorithms I use are good enough to give you a good data rate if you're sampling at that frequency.  Your frequency bins are going to be a bit large though... The maximum FFT size that the CMSIS library allows is 2048, which means your bins are going to be 200,000/2048 wide, or ~100 Hz per bin.  


    You're probably going to need to do something fancy for your analog input though.  For one thing, standard microphones aren't normally designed for handling frequencies above ~25 Khz (since we can't hear much audio above that).  You'll also want to be careful in your opamp selection.  It shouldn't be hard to find one that can handle up 100 KHz, but I know the one I used for my project isn't spec'd for it.


    The final point to consider is what you're going to be doing with the data.  If you want to take immediate action based on what's happening in a frequency range, you're good.  If you want to keep a record of things happening though, you're probably going to hit memory restrictions real quick.  I have a new version of my code that I'm going to be releasing this week, and the final compiled binary takes up 32,743 bytes of ram.  Note that the chip has 32,768 bytes of ram total.  When doing DSP on a microcontroller, memory gets scarce :/


    Hope this helps, and happy hacking :)

  7. You are so lucky to get your hands on one. Was there any reason not to use the mic on the board olimex itself?


    I meant to include this in the writeup, but yes. For one, I searched high and low for a datasheet on the thing and wasn't able to find anything useful, which made me a bit leery. I tried playing around a bit with the output, and what I observed was that the mic was not very sensitive. If I placed it right next to a set of speakers blaring death metal, I could get a decently clean signal off of it, but it didn't look like it would be a good solution for ambient noise. I'm considering using the speaker for input and passing it through an opamp that's wired up to be 4x gain to see if that helps.


    Nevermind.. probably for the signal conditioning circuit.

    That's pretty much the reason. I have a schematic for an interposer board that would go between the launchpad and the olimex board to obviate the need for all the blue wires. I'm hoping to have the layout for that board done by the end of the month, and will release the EAGLE compatible files for it at that time.

  8. I think the booster pack is from Olimex. Check https://www.olimex.com/dev/index.html - they've got a frame based site so can't link directly, but it's in the MSP430 section under booster packs.


    Yep! It was originally an MSP430 booster pack, and can be found at https://www.olimex.c...msp-led8x8.html


    If I remember right, I was able to find one at either Digikey or Mouser for about $15.


    Glad to hear you all enjoy my project! If you have any questions, feel free to ask away. You can also find more information about my project on my blog, http://www.euphonistihack.blogspot.com

  • Create New...