Project Logs

Collapse

• Limited electrons availability

  OXullo Intersecans • 01/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 Intersecans • 12/29/2018 at 23:27 • 3 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