audioThing - ephemeralEventRecorder

Not your typical "voice recorder" -- an audio event recorder on steroids

Similar projects worth following
UPDATE: The code-site changed! See Links!

audioThing' is an audio-recorder (and text-logger) with a potentially days-long pre-buffer (depending on available memory). When an event occurs that's worthy of recording; one needn't even think about pressing a record-button until it's convenient; quite possibly several hours later. And, unlike a constantly-running voice-recorder, one needn't sift through hours of recordings to play-back the memorable events; the events are saved, and uneventful moments are recorded-over when necessary.

Use it to create music from samples of sporadic and unpredictable environmental sounds (singers in the streets, weird taxi-whistles, animal noises, whathaveyou). Or catch your sleep-talking friends in the act from start-to-finish...

*This device is only to be used by the morally-competent. I don't
know of the legalities of such a device, but I do know that I would hate to
be "had" by someone's morally-que

DISCLAIMER: This device is only to be used by the morally-competent. I don't know of the legalities of such a device, but I do know that I would hate to be "had" by someone's morally-questionable use of such. Do unto others...

This is used purely for the purposes described below, and its "security by obscurity" is intentionally considered against the potential for misuse by others of data logged by this device.

What it does/How it works Video:

Why I started this:

If you've visited my website, you may have read the bit about, roughly-quoted, having to cope with a, "for lack of a better word, 'mental disorder' which affects nearly every aspect of my life"...

I'd rather not go into it, but let's just say that this particular device has aided in my discovering some of the truths behind, and coping with, this "disorder." And doing-so with the skillsets I use to troubleshoot any problem; be it technical, mathematical, or even (now, apparently) mental.

As an unrelated and beneficial aside, it's been found useful for other purposes that may appeal to the broader-public...

  • Need motivation to quit smoking? audioThing can help.
  • Got a friend who randomly talks in their sleep? Torment them with audioThing!
  • Want to create music from random sounds in your environment? Enter audioThing.

See below for more about: (please click "Read More")

  • Example Usages in detail (sleep-talker, environmental music samples)
  • Implementation overview
  • Side-developments including: connecting a matrix-keypad via resistors to a single digital I/O pin
  • Current Status
  • Potential Improvements

---------- more ----------

Example-Usage for the general-user (catching a sleep-talker):

E.G. I've a buddy who falls asleep on my couch from time-to-time. This dude sits up randomly, as though he's awake, and talks to me as though I was in whatever dream he's apparently still in... I have no friggin' clue what he's talking about 98% of the time, but he seems *dang convinced* we're holding a regular conversation. All I can tell is he's having a conversation with an entirely different *me* in an entirely different realm.

I've tried, for years now, to piece together what he's talking-about... where it comes from, what he's dreaming my responses to be vs. what I actually say... I've asked questions and received answers to entirely different questions (...questions that I don't know. For some reason "42" comes to mind).

Wouldn't it be nice to have those moments recorded, to torment him (when he's *actually* awake) with the details of the conversation he had with another me?

With this device running in my shirt-pocket, or on the table, wherever's convenient, I can capture these trans-worldly moments from the very start; the mumbling lead-up, the actual "conversation", the moment when I begin to think he's *actually* aware of the conversation *I* am having with this world's physical manifestation of him...

And, can do-so without any interruption to the natural flow of the conversation. ...That is, *if* you can call it *natural*, or *flow*, or even *conversation*.

Whatever you call it, you can capture *this world's* reality of *that event* from start-to-finish, without necessitating any interruption to even think to press a "record" button, and then, later, torment the inter-world-traveller with deep questions about "the other side."

Another Example-Usage (sampling environmental sounds):There are some pretty interesting sounds outside a city-apartment, but thereally interesting ones are often brief and out-of-the-blue. The

quirky-taxi-whistles, late-night drunken singers, loud phone conversations, the booming trunk-woofers of passing cars, midnight serenades, the sound of a bus sloshing through slush, sudden downpours and the yelps they cause... the list goes on.

To someone a little more musically-inclined, these moments could be sampled and turned into pretty interesting music. Or just compiled for a comedy routine.

These things happen too quickly to press "record" on a voice-recorder, and leaving a recording-device...

Read more »

  • 1 × AVR Electronic Components / Misc. Electronic ComponentsCurr
  • 1 × Microphone This one happens to be line-level output, so no Op-Amps are required
  • 1 × SD Card Originally used 512MB, now supports SD-HC
  • 1 × Nokia LCD This is the hacker-friendly SPI-based B/W display
  • 1 × Nokia Keypad Wired via resistors to a single (digital!) input pin

View all 7 components

  • audioThing captures spontaneous street-celebrations

    esot.eric01/18/2015 at 23:53 0 comments

    I gotta admit, I'm not much of a sports-fan... But it's hard not to get caught-up in moments like these.

    Yahknow, I'm glad I decided to watch the second-half of our winning the right to go to the Super Bowl.

    And, I got to capture some pretty groovy street-celebrations on audioThing.


    I hear yelling, so go outside to look... no one out there except a little old lady carrying a bag slowly... And just as I start to turn to head back, this calm little old lady turns around and screams "Wooo!".

    And of course, the typical "Sea-HAWKS. Sea-HAWKS!" and honks.

  • Another commonCode over-explanation

    esot.eric01/12/2015 at 15:36 0 comments

    I've been sliding on audioThing, and the commonCode revisions. I guess, technically, it's only been a week, so that's really not a big deal. But obligations are taking-hold, or at least they're supposed to be. So I convinced myself I'd call it quits on those projects after the contest was over, and get to those obligations. Instead I've been doing other projects and dang-near forgot about the commonCode thing. It's fine, no one's been contacting me about it, so there's no pressure. And that, my friends, is why my projects are *never* "completed". Besides always being room for improvement, I usually get to some stopping-point that's functional and forget about it for a while, then get some inspiration/motivation and revisit.

    This mentality, I suppose, lends itself perfectly to the commonCode stuff, though... I've got dozen(s?) of projects (like audioThing, but that's one of the bigger ones) which are always being revisited. Sometimes in the process of revisiting one of those, I come up with new ideas for commonCode (as happened with audioThing); revisions, and bug-fixes... And *this* is why I have *one* directory on my system with all that commonCode. One bug-fix, and it trickles-down to all my projects the next time I run 'make'. (Also quite handy when working on two projects side-by-side).

    I also, generally, do my best to make sure that such revisions that'll trickle-down don't *increase* in size, so if I've a project that's running *just* at the program-space limit, then (hopefully) it won't be killed by a trickled-down bugfix.

    And, yes, there are significant version-changes from time-to-time, but I keep 'em all for when I revisit a *really old* project, or when I need to revert to an older-version of a project. E.G. no need to worry about updating audioThing for that newest version of heartbeat unless I get that bee in my bonnet.

    So, again, it's similar to having a shared-library-directory on your PC, except that the commonCode gets recompiled for each project (different processor-architectures, different options, etc.)

    I'm no computer-scientist, but I can't think of any other such setups. At one point I thought Arduino had something like that, but last I checked, it seems the so-called "libraries" are just folders of code that you copy to your project-directory... and it seems they even have to be hand-modified for individual projects, pinouts, etc., making minor library-version-upgrades difficult.

    OTOH, the *method* for including commonCode is a bit... bulky. Much of it can be ignored, like the "reallyCommon" makefile, and whatnot, but needs to be there.

    I've been thinking about whether it's worthwhile to search harder for a versioning-system (like git) that could work with a setup like this... So far, it seems, most are best-suited to individual projects. E.G. If you want to compile avr-gcc, you need to get avr-libc separately... But, for the most-part, few people (if any?) are going to use avr-gcc without avr-libc... so, then, wouldn't it make sense if they came together? And... they do... via package-managers; yet every package-management system seems different; apt-get, macports, etc. Different people have to maintain these different (yet functionally-similar) databases, despite the fact that e.g. avr-gcc 4.8 requires avr-libc (whatever version)... seems like they could combine that info in the avr-gcc package, somehow standardly, and then run something like 'make get-depencies' or 'make update' and it'd download all the dependencies before you run 'make' on them all.

    That's basically what my commonCode setup does, except of course that it only works on a local-system. So far, to make this public means creating individual git repositories for each piece of commonCode, and there are literally dozens. And even that doesn't lend-itself to different *versions*... I feel like I need to set up a dedicated webserver just to make this stuff available to the public.

    The alternative is to build your own project-independent commonCode directory,...

    Read more »

  • GitHubbing CommonCode revisited

    esot.eric01/05/2015 at 06:38 0 comments

    Been working on a completely new structure for my commonCode tests...

    Read more »

  • gitHubbing commonCode

    esot.eric12/31/2014 at 10:03 0 comments

    As part of making audioThing available to the public, porting to a new chip, etc., I've revisited several pieces of my commonCode, much of which I've been developing/optimizing for several years and use regularly... The vast-majority is my own work.

    One nice factor is that most of these have test-programs, ala "hello-world" or "blinky," except, yahknow, better-suited to test whatever particular functionality that commonThing is responsible for.

    I've been working on a relatively step-by-step procedure for developing a new project and/or testing pieces of an existing one. Thus, a new project can start with just a blinking LED, then wire-up various peripherals and test them one-by-one.

    In the past couple days I've started to make that available at GitHub.

    You can also see a list of most of my commonCode, and how it works. (I'll be putting a better description of the step-by-step process there, soon).

    Yes, I realize this sorta thing has already been done... Yes, I realize that e.g. arduino probably does it a lot better. Reinventing the wheel seems to be what I do. Hopefully something in here is useful to someone, preferably to a lot of people.

    If you browse the _commonCode_localized directory, you'll see what audioThing uses, here are a few:

    • adcFreeRunning
    • anaButtons -- matrix keypad->GPIO via resistors and capacitor
    • bithandling -- bit/port manipulation
    • cirBuff -- circular buffer
    • heartbeat -- fading LED and a pushbutton on a GPIO, blinks error-codes
    • hfModulation -- similar to PWM but bit-banged... used to fade heartbeat
    • _make <-- Really Useful Makefile Stuff
    • nlcd -- Nokia LCD (Original author in the code, it's been revised a lot)
    • polled_uar -- bitbanged/polled Serial Reception (UART minus T)
    • polled_uat -- bitbanged/polled Serial Transmission (UART minus R)
    • __std_wrappers -- normal C/stdio things I use regularly in certain ways
    • tcnter -- poll a timer, used by heartbeat and polled_uar/t for timing
    • timerCommon -- an attempt at standardizing various AVRs' timers
    • usart_spi -- new for ATmega328p: use the USART's SPI interface
    • (spi_sd needs to be made available in commonCode, TODO)

    For porting audioThing to the ATmega328p, for instance, I started with heartbeat (which includes *several* others, including hfModulation, tcnter, and timerCommon).

    After heartbeat, I moved on to polled_uat, then to usart_spi which has a loopback test, then to nlcd, then anaButtons which has a test-program that also allows for calibration, and so on. Leave the old peripheral-tests wired-up, solder up the next... When you're done, steal a couple lines of code from each test-program and throw them in the main-init and main-loop sections of your project, and you've got a functional program that can do quite a bit.

    A couple pieces of audioThing should be thrown into commonCode (e.g. the SD card), but the vast-majority of the remainder of audioThing is project-specific code, completely independent of the hardware. and even some of that could eventually be turned into commonCode.

    Anyways, all that to say, I've started putting that stuff up on GitHub, so take a look!

  • Instructions Loaded.

    esot.eric12/28/2014 at 13:23 0 comments

    The instructions are now up to build a fully-functional system!

  • Video + Standard-Capacity SD-Cards

    esot.eric12/27/2014 at 16:10 0 comments

    Got a video up, now... Pretty funny, the whole thing is about how audioThing's convinced me to quit smoking, because listening to audioThing recordings has made me aware of just how much I cough... And right as I'm about to stop recording, my cat's down on the floor coughing.

    And spent the day trying to figure out why my 2GB SD card was acting so flakey... turns out I mistyped: "bit 30" corresponds to bit *6* in the fourth-byte, not bit *7*. But, now, again I'm confused, because that should've only been a problem with CSDv2 cards, not CSDv1, so what else did I fix in that hours-upon-hours-long-ordeal? Regardless, both an 8GB CSDv2 HighCapacity card and a 2GB CSDv1 StandardCapacity card now work great.

    On the plus-side, always improving my documentation... now the SPI initialization flow-charts (Figures 7-1 and 7-2 from the SD Physical Spec) are in my file in ASCII-Art alongside various notes. Those two figures are quite confusing, they almost seem to contradict themselves, yet they're also almost darn-near identical. I've tried to piece that together a bit in my code-notes.

  • NOW SUPPORTS TrinketPro3.3V @ 12MHz

    esot.eric12/24/2014 at 20:56 0 comments

    Lots of work went into this... when did I last sleep?

    Now audioThing and audioThing-desktop can support your TrinketPro3.3V!

    Read more »

  • beginning instructions

    esot.eric12/23/2014 at 18:25 0 comments

    It's now functional! And I'm beginning to add instructions.

    Read more »

  • boy was I mistaken

    esot.eric12/20/2014 at 14:43 0 comments

    Hah, I thought it was as-functional as the old model... boy was I mistaken.

    Read more »

  • SoftwareSnags

    esot.eric12/19/2014 at 05:55 0 comments

    Got it all wired-up and the software cleaned up a bit.

    Used a 2GB MicroSD card I found (literally), and had all sorts of weirdness. Tried to debug for a while, but finally decided to throw in my 8GB MicroSD from my phone just to see what'd happen. Yep, works.

    There's a few oddities needing some debugging, and I wouldn't mind getting it working with that 2GB card, but in general it's basically in the same state as the original (shown in the picture), that was in-use for quite some time.

    Still gotta work out some documentation-stuff to meet the req's for the contest; photos I've got, but I'm drawing a blank on how to make a video of something that's distinctly audio-related.

    Read more »

View all 13 project logs

  • 1
    Step 1

    [Re-]Download the source code

    audioThing has been added to a code-site!

    First: Download and/or browse the *latest* code.

    (NOTE! a/o 1/5/15: WHOOPS! REDOWNLOAD THAT SOURCE CODE! BOTH audioThing AND audioThingDesktop! I should've run it on a test-user-account. 'make clean' is broken in the old versions. It's a simple fix, see the changelog for audioThingDesktop if you want to do it by hand. Don't look at the changelog for audioThing as I messed up the git process.)

    (NOTE: a/o 12-23-14: The source-code is being updated *DAILY*, please download the newest version, especially as the build-instructions progress).

    (It's kinda hard to find, but there's a ".zip" and a ".tar.gz" option near the top, under the "Source" tab)

  • 2
    Step 2


    View the file "pinoutTrinketPro.h"

    This file contains the pinouts, as well as schematics in ASCII-Art form.

    Some portions are Optional. Some others may already be implemented on a TrinketPro. These instructions should get you started with the bare-necessities including (roughly in order):

    • Heartbeat LED/'memo' pushbutton
    • SD-Card
      • PUAT (polled UART, Transmitter-only, for initial testing, especially of the SD-Card)
    • Line-Level Audio Input
    • Audio Output (for initial testing)
    • audioThingDesktop - To extract and play-back your recordings on a desktop-PC

    OPTIONAL (Documentation to come later):

    These instructions have been revised

    There should be no necessity for hacking the TrinketPro any longer.

    ---------- more ----------

    NOTE: This would most-easily be implemented on a TrinketPro3.3V, as the SD-Card and other devices rely on communicating with the microcontroller at this voltage. Instructions here will assume you're using a 3.3V system.

    NOTE2: As I don't yet own a TrinketPro, I can't vouch for the reliability of my notes/code regarding it. I did my best to make this pin-compatible, but ran into a few snags which are noted in the various pinout files. Mainly: The FTDI header is repurposed for the SD-Card.

    I used an *external* USBTinyISP, which admittedly may have introduced many of these potential problems.

    (If using an *external* SPI programmer like the USBTinyISP with the TrinketPro, it may be necessary to remove the LED on the SCK pin, as some SPI programmers may not be able to source enough current)

    NOTE4: This was originally designed for an ATtiny861, so its code remains, but is disabled as necessary.

  • 3
    Step 3

    Get the heartbeat LED going

    NOTE: Before choosing to relocate any pin, consult 'pinoutTrinketPro.h'.

    Also, see 'pinoutPonderings.h'

    This file lists the necessary pins, where to find their definitions, and also whether they can be moved. Make sure you don't choose pins that are already in use!

    Here I will assume you're working with the default pinout found in pinoutTrinketPro.h.

    1. To get started, make sure the Power Supply circuitry is correct. As this uses 3.3V components, you must use 3.3V!
      1. (Schematics and notes for the power-supply, and everything else, are listed in pinoutTrinketPro.h)
    2. Next, make sure the device is attached to a Crystal (this is at the top of the file).
      1. Update the 'FCPU=' line in 'makefile' to match your crystal frequency.
    3. Attach the heartbeat LED and pushbutton as shown in the pinout file.
    4. Attach the "anaButtons" pin to the capacitor as shown in the schematic
      1. The remainder of the anaButtons circuit can/should be disregarded, for now.
      2. This capacitor needs to be attached, as the pin switches from output--charging the capacitor--to input, and expects to measure "high" for some duration. If this capacitor is not connected, it will float and assume that a button is being pressed, which may cause problems.
    5. Run: 'make'
    6. Power up the circuit
    7. If you're using an external USBtinyISP (or the TrinketPro's USB port?) for programming, you can then type: 'make run'.
    8. After programming completes, the heartbeat LED should begin to blink. (Give it several seconds to start, as it looks for the not-yet-attached SD-Card).

    If the LED blinks seven times, pauses, then seven times again, you're off to a good start. This indicates that it couldn't find the SD-Card, but also indicates that the code is running and your chip is functioning and wired-up correctly.

    Heart Blink Patterns:

    If, at any time, it blinks another pattern, search the code for "heart_blink(" until you find one that matches. Note that it blinks in nibbles: e.g. if it blinks 3 times then 4, then the corresponding line should be 'heart_blink(0x34)' (or is it (0x43?). If it blinks 15 times, then it's 0x0f, etc.

View all 9 instructions

Enjoy this project?



AVR wrote 11/28/2015 at 06:32 point

can't believe I hadn't skulled this before, reusing the phone like you did is impressive especially the soldering job.

  Are you sure? yes | no

esot.eric wrote 11/28/2015 at 14:51 point

Oh, hey! Thanks for that :)

Admittedly, though, one of the middle wires popped off the BGA pad a while back, and I haven't yet soldered it back on, rendering a whole row of keys unusable. 

It was kinda a weird thing, actually, it was BGA, but the solder-balls seemed to be surrounded by a plastic "tray" that stayed on the board even after removing the chip. Kinda a mixed-blessing, on the one hand it kinda created nice little "holes" to insert the wires in, on the other hand it made heating the solder in those holes a little bit difficult. Was never sure whether it was actually a solder-joint or whether I melted the wire to the plastic. I think we found out in one case, anyhow ;)

  Are you sure? yes | no

davedarko wrote 09/06/2015 at 11:35 point

I could have sworn I gave a skull for this o.O anyway, great project!

  Are you sure? yes | no

esot.eric wrote 09/06/2015 at 12:24 point

Woot! Thanks :)

  Are you sure? yes | no

frankstripod wrote 03/31/2015 at 09:26 point

What is the total audiothing recording time? (Sorry I wasn't here for the whole Trinket contest.)

  Are you sure? yes | no

esot.eric wrote 03/31/2015 at 11:52 point

Depends on the SD-Card used... Currently it records at 19200S/s, each sample is 16bits.... I can't math right now. 8GB = A Lot. 2GB = Plenty. 512MB = Good 'Nough.

  Are you sure? yes | no

esot.eric wrote 04/01/2015 at 01:29 point

still in a math-fog, but as I recall, at 8GB each "memo" is a little over 13min... and 256 memos can be recorded, so an empty card can record something like 3500minutes, which is > two days? Yeah, it's really not meant as a long-term recorder, it's more meant for capturing those moments that just passed.

  Are you sure? yes | no

Jacob Christ wrote 12/15/2014 at 14:26 point
It would be nice to add ethernet capabilities so that it data could be downloaded before the SD card fill up.

  Are you sure? yes | no

esot.eric wrote 12/16/2014 at 12:03 point
Indeed, There needs to be a way to extract the data *while it's running*... this is yet to be figured-out. Part of the dilemma is running at nearly 100% processing-power, as-is. Another bit being that reads and writes would have to occur at the SD-Card at (roughly) the same time. This, too, is a consideration as far as "how can I rewind that moment and listen to it *right now* without having to plug into a computer?" Murphey's Law says that the moment you stop the device's recording to do playback, something *amazing* will happen, worthy of recording, and it'll be missed.
But, now that you mention it, this should be one of the higher-priority "TODOs". One option would be to slow the sample-rate during playback... ToPonder. Thanks, and thanks for the skull.

  Are you sure? yes | no

Adam Fabio wrote 12/15/2014 at 02:37 point
Hey Eric! Just to reiterate what I said on the main project page (and to answer the question in your project log) You're within the requirements of the contest - ATmega328, small form factor, etc. Good luck in the Trinket Everyday Carry contest (I can't wait to see where the recorder ends up!)

  Are you sure? yes | no

esot.eric wrote 12/15/2014 at 03:53 point
D'oh! I was kinda hoping to have an excuse to slow down on it for a bit... Now I've no excuse but to pick up the pace! Fading-LED has advanced to countless bugs and lack of documentation found in many places in my early-test-code... I finally have serial communication running (step 2 of what feels like 100).
Seriously, though. Thanks for taking time to look into this project and reply!

  Are you sure? yes | no

PointyOintment wrote 12/13/2014 at 04:40 point
Interesting project, and very intriguing button system description. I look forward to more details on both.

  Are you sure? yes | no

esot.eric wrote 12/14/2014 at 02:58 point
Muchas Gracias, and thanks for the follow and skull.

  Are you sure? yes | no

esot.eric wrote 12/23/2014 at 18:36 point

Thank you, and the "anaButtons" page/code is now up:

  Are you sure? yes | no

esot.eric wrote 12/11/2014 at 12:56 point
Browsed the other contest entries a little more thoroughly, and am a bit uncertain whether submitting an already-long-functional project is a fair move... Gonna sleep on it.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates