Close
0%
0%

glayer

An mp3 player for kids

Similar projects worth following
Audio tapes are surely old fashioned, but I've always found some magic in browsing my bag full of those plastic rolls.

I wanted to recreate that feeling with some more modern flair, using RFID badges as canvases for custom playlists and with an interface a kid could use as well.

Glayer has been conceived as a Christmas present for a baby girl, who was always in the need for asking mommy to loop her favorite songs on mommy's ipod.

Primary objective: it had to be dead easy to use.

The interface is composed of a slot, where an ISO RFID card can be inserted and two arcade-style buttons.

The slot uses the card's identification number to select a folder in the SD storage. Each individual card corresponds to a folder, which ultimately is a collection of songs that are played in order. As soon as a card is inserted into the slot, the player starts playing back the first song of the collection.
The buttons allow to skip to the next song or to go to the previous one. A long button press allows to change the volume.

Once the card is removed, the player stops the playback and goes to standby.

In order to keep the overall power consumption to the minimum, the presence of the card is detected by an infrared light barrier, which requires a fraction of the power of the NFC inventory.

The assembly plans are available in fusion 360: https://a360.co/2CC5uf0

The firmware is hosted in github: https://github.com/oxullo/glayer

FBD.pdf

Functional block diagram

Adobe Portable Document Format - 67.47 kB - 12/28/2018 at 21:57

Preview
Download

Glayer assembly Drawing v4.pdf

Main assembly drawings

Adobe Portable Document Format - 321.75 kB - 12/28/2018 at 21:57

Preview
Download

PCB Drawing v1.pdf

Soldered components drawings

Adobe Portable Document Format - 167.85 kB - 12/28/2018 at 21:57

Preview
Download

RFID slot Drawing v2.pdf

RFID slot subassembly drawings

Adobe Portable Document Format - 122.67 kB - 12/28/2018 at 21:57

Preview
Download

  • 1 × Adafruit Feather M0 (Atmel SAMD21G) basic proto CPU, battery management, debug port
  • 1 × Adafruit Music maker featherwing (VLSI VS1053) Multiformat audio decoder and SD card holder
  • 1 × Stereo Enclosed Speaker Set - 3W 4 Ohm
  • 1 × Adafruit TPA2016 amplifier breakout Analog 2.8W stereo amplifier with AGC
  • 1 × Seeed studio NFC grove (NXP PN532) RFID reader w/ antenna

View all 11 components

  • Limited electrons availability

    OXullo Intersecans01/01/2019 at 00:39 0 comments

    What fascinates me about battery-based devices, it's the creative process of limiting power consumption at its minimum. It's certainly a non-trivial task that requires experience, proper tools and dedication.

    While developing Glayer I certainly underestimated the task, but at the end I found the results satisfactory.

    By design, the player has no power switch and it's always ready to start, unless the battery is empty. This obviously required care in minimizing power consumption at least when idling.

    RFID detection

    I considered the option of adding a companion detection mechanism for the card, even before having selected the RFID module itself.

    The idea was to use a light barrier: after testing a couple of options, I ended up with a Vishay TCST2103, a 950nm paired LED/phototransistor. With a pulse of just 50µs I had a very reliable readout. Going down to numbers, with a 1-second detection period, the calculated average consumption was about 3.5µA (the LED current is set to about 7mA).

    I failed to compare this figure with the power consumption of an RFID inventory operation, mostly for the lack of proper instrumentation. But looking at the electrical specs of the PN532 and the indicated 60mA @5V when energizing a properly tuned antenna, in addition to the 25mA of the typical operating current consumption of its core module, the light barrier seemed to me an evident advantage.

    The RFID module is kept in low power mode while the light barrier is constantly polling. When a card is inserted the RFID module is awaken and an inventory scan is performed. Once the card is recognized, the RFID module is put again in low power mode. The light barrier keeps checking the card's presence at regular intervals.

    One note regarding the Seeed NFC grove module I used: it seems that due to a design mistake, the breakout can constantly draw 40mA.

    Amplifier

    During the first iteration, the amplifier was integrated in the music maker featherwing. The unit I received was unfortunately faulty (same situation described in this thread). In addition, it was fairly impossible to mod the board to expose the shutdown pins to the microcontroller. The TPA2016 with the convenient TPA2016 amp breakout seemed to be a valuable alternative, with a shutdown current of 0.2µA.

    VS1053

    The decoder can be put into powerdown by tying down the XRESET line, with an average consumption of about 19µA. Such line is controlled by the microcontroller (with a minor mod required to the featherwing), but the current software implementation doesn't use it, since it requires some modification to the library (Adafruit VS1053).

    Ideally, the chip should be kept in reset when idling and awaken and reconfigured as soon a card is inserted.

    Microcontroller

    The main controller could sleep a lot during idle. The only thing required to be operational is the periodic poll of the card detector. The µC, a SAMD21G, has several power down modes and an appealing option might be implementing Adafruit's SleepyDog library. This is still among the todos.

  • Interfaces and ownership

    OXullo Intersecans12/29/2018 at 23:27 0 comments

    Finding "the" way to user interfaces is always a daunting challenge to me.

    Even more challenging, when the user is a kid.

    After observing how glayer has been used in the last days, I'd spend some words about choices and outcomes.

    I can't deny that a great deal of inspiration to the interface came by Tonies and Hörbert, two awesome music players for kids.

    Tonies offer an intriguing interface based on an accelerometer (slap the sides to skip next / previous track or tilt sideways to fast forward / rewind) and two mechanical buttons for volume control behind their iconic ears (more info in this teardown). What renders tonies even more intriguing is the music selection process, that takes place with a token (a figurine with a builtin NFC tag), that is to be placed on a landing surface.

    Choosing songs using physical tokens reminded me of what I was used to do, several years ago, when browsing for dusty tapes or vinyls. The covers were powerful emotional cues and any marking or imperfection couldn't but help to boost a feeling of ownership. Such perspective is long lost due to the now widely adopted subscription models of modern music providers.

    "Tokenizing" a collection has two functions, IMO: first of all it restricts the search context, making easier to follow a mood path. We're human beings, challenged by the unbound amount of information we have constant access to. Sometimes less is more, availability doesn't necessarily imply happiness. Secondly, a token can be an open canvas that allows and might encourage customization, helping out in creating that lost sense of ownership mentioned before.

    In respect to Tonies, I wanted the token to be cheap and blank. Obviously Tonies capitalize on the token themselves, while I didn't have to. The initial idea was to allow kid and mommy to personalize the token by painting them. In practice it didn't happen because the kid bound pretty quickly to the temporary icons I sketched over a shard of masking tape glued to the badges, but I still think it's a nice opportunity.


    Regarding the buttons, I've always liked arcade builds and the ones ended up in Glayer are really pleasant to be pushed. They were also pretty functional to the shape of the player itself, being the blinking eyes of the greedy cat. I'm not sure if it's an issue of being old-fashioned, but there's nothing as simple and effective as the haptic feedback of a clicky button to me.

    I wondered if a single button would had sufficed, relinquishing to the "back" control while complicating the volume selection a bit more than necessary. I personally like minimalism and a "one button ops" has always been a sort of motto of mine, but I've noticed the "back" button being used several times, or enough to justify its presence.

View all 2 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

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