Jukebox - part 2

Following the first part, here more information about the design choices.

Cards

Depending on the frequency and the capabilities of the tag, several (physical) formats are available. For the 125kHz frequency, the non-rewritable sort seems to exist in 3 main forms:

Labels

Wondering how to personalise the cards, in the end I went for a simple printed sticky label which can be replaced if necessary. With the A4 paper size, it is possible to find some sheets with 15 labels (70 x 50.8mm). These are slightly smaller that the cards themselves (85.6 × 53.98 mm) but near enough.

Creation

As mention before, there are several type of cards depending on the content. So far, this is mainly related to either the colour of the icon or the design of the label.

Examples

The first and main type has the following definition:

- title1: Village Fair
  title2: Dee Yan-Key
  image: village.jpg
  category: music2
  duration: "0'45"
  print: yes

where category can be (for now): music1 (relaxing), music2 (entertaining), story.

The second type, print vertical labels:

- name: The guitar
  nom: La guitare
  image: guitar.jpg
  category: instrument
  print: yes

and is used for "sounds" like musical instruments or animals sounds for example.

Order of printing

The label positions are counted from the bottom-left-hand side of the page. If it seems a bit counter intuitive at first, there are 2 good reasons for this:

ID

Card ID

There are two IDs at the back of each cards. But in reality, the numbers are related. I have no idea why it is organised like this but the best guess is that is related to system with 16-bit storage/computation.

The first number represents the decimal value of the complete number (24 bits). For the second group, before the comma, it's the first 8-bit decimal number and after, the 16-bit decimal remainder.

For example:

13691859 = 208 x 65536 + 60371

Note that in the YAML database, only the first number is used without the leading zeros because YAML seems to have an issue with big numbers (or might consider the value as octal rather than decimal).

TBC...

    Jukebox - part 1

    Genesis

    The seed of the idea was a project made by someone who inserted RFID tags in CD plastic cases in order to help an elderly member of his family. I couldn't remember the reference any more but, at the time, I found the idea fantastic.

    The idea here is towards a young member of the family but general logic is the same: It has to be very easy to use.

    Similar projects

    Similar projects which can be found on the Internet, though. For example,

    ⮕ These 2 jukeboxes are beautiful but I was aiming at something easier to use (10 months +) and simpler/cheaper to build!

    ⮕ A bit expensive, limited in number of "tokens", ...

    ⮕ Limited in number of songs

    Design choices

    Frequency

    There are 2 main frequencies in the world of (short range) RFID : 125kHz and 13.56Mhz, the latter being used for NFC and smartcards as well. These days, availability and price of cards/tokens/readers doesn't seem to be an issue for either type.

    I ended-up going to the 125kHz route a little bit by chance:

    • Readers are very cheap and I had one collecting dust on my desk.
    • The range is slightly shorter than with higher frequencies which could be beneficial to avoid interferences between the cards.
    • Lower frequency might be less of a health hazard for a young child.

    On the other hand, library books here and mobile phones are using the 13.56Mhz frequency. I might miss some opportunities of evolution. Who knows?

    Arduino or Raspberry Pi?

    After considering using an Arduino and a MP3 module, it turned out that there would be far more possibilities of evolution with a Raspberry Pi.

    The main issue with Raspberry Pi/Linux is that both the card and filesystem are at risk if there are to many write IOs or the power is cut abruptly. These were mitigated using a Read-Only setup.

    In term of price, a Raspberry Pi is slightly more expensive but (at the time of conception) I found some Raspberry Pi 3 for $25 delivered (from China (but UK made?)). Boot time (specially when using Python 3) is several time faster than with a Raspberry Pi B+ or zero even if these should be performing well enough.

    Technical practicalities

    SD Card & USB Flash

    Although it is perfectly possible to store both the system and the data (music) on the same SD Card, the re-imaging of the system is a bit more complicated in this case. For the time being, I decided to keep them separate and store all the music aside on a USB Flash drive.

    Boot time

    A number of recipes exist to boot the system faster. It's particularly long on a old Raspberry but on a Raspberry 3, this doesn't seem to be too much of an issue (just a few seconds). So in the end, I didn't investigate much.

    Read-Only

    As mention earlier, the weak point on the Raspberry Pi platform is certainly the storage, specially with SD Card: They either wear quickly or end-up with a corrupted filesystem if the power is cut violently. This is a downside compare to a solution based on a Arduino for example.

    In our case, it is essential to protect the card against this kind of bad treatment as one can't guarantee anything in the end of a child!

    Two techniques seem to co-exist: The first one consist in using an overlay and any change will be written in RAM and lost during reboot. It as its advantages but wasn't that practical in the long run.

    The second one, created, improved and popularised par K3A, Charles Hallard and Adafruit, ... has the big advantage of providing a way to switch RO to RW (and back) live, making updates very easy.

    Storage of media

    To keep things simple and to allow the use of the jukebox for multi-part music albums & stories, media are stored using the following structure:

    1 card = 1 id = 1 album = 1 folder = 1 info file + 1 or more media files

    The name of the album doesn't matter (usually something Composer-Title). A scan is ran at the start-up and the association id <-> path kept in memory.

    In theory, it should be possible to read the content of a folder sorted by name, at random, etc... but so far this hasn't been implemented.

    Type of cards & IDs

    The info file in each folder can contain grouping tags (genre, ...) and a system of generic/group cards can be implemented (for example: "Dancing music at random" or "Lullabies" or "Bed time stories", ... This hasn't been fully implemented yet.

    On the printing side of label, 2 types of cards (music / sounds) and several icons have been designed. There is currently no link with the tags cited above. More on these later.

    Version 0 - Prototype

    The first version created was to validated the concept. In order to keep things "easy", I decided to buy a ready made speaker solution (Adafruit I2S 3W Stereo Speaker Bonnet). The price of the bonnet + speakers + shipping (from a local reseller) ended-up in the same order of the Raspberry Pi 3 itself but it was supposed to be easier.

    It turned out that VLC + Pulse Audio + "cheap" I2S is barely compatible and even after the tweaks, each song had variable level (from medium to loud) and was starting with a big plop. Usually after 2-3 songs, the whole system would crash and in need of a complete restart.

    The jukebox was unstable and the packaging was ugly...

    Version 0

    ... but it was a great prototype and it was a instant hit with my little one!

    TBC...

    Gazpar's socket

    As mentioned 9 months ago, the new French smart gas meter is called Gazpar and has a socket. So far I couldn't find any info about it but slowly, details are starting to emerge:

    In this thread (in French), there is a link to a adaptation cable reference EER31130 sold by Schneider Electric for their own product but it looks like it could by used for any solution.

    It also gives an indication of the type of socket (made by JAE but unfortunately I can't find the exact reference).

    JAE connector

    Schneider Electric's "pulse emitter" has the following characteristics which give other info about what the Gazpar might be (open collector (most likely) or reed switch):

    • Compatibility with meters with pulse output of types: Open collector (electronic) / dry contact (mechanical contact), REED switch (magnetic) with the following characteristics:
    • Voltage on the contact: 2.7 V (delivered by the Pulse Emitter)
    • Closed contact impedance: <1 kΩ
    • Open contact impedance: > 1 MΩ
    • Pulse duration: > 66ms
    • Delay between pulses: > 33ms

    A suivre...

    Teleinfo with Wifi on the Linky

    Following the upgrade of my electricity meter (from rotating disk to latest generation of smart meter), I am now able to use the Teleinformation output (hurrah!)

    Linky

    The Linky smart meter has a slot for a "LRT" module and a 3-pin header for teleinfo (the traditionals "I1" & "I2" as well as a power source named "A").

    There are also two communication modes available: Historical (the only one available so far) & Standard (i.e. the new one starting with Linky).

    LRT

    The "Linky Radio Transmitter" (Emetteur Radio Linky) is a module developed to transmit the value to a household display. Specifications show they can be using either Zigbee or KNX. It was supposed to be totally open but I am yet to see a schematics of it.

    ERL/LRT

    At least the Interface Specification is available. I reused the name of Zigbee attributes for the MQTT publication.

    Teleinfo

    Official docs are available (in french) on Enedis's website, in particular NOI-CPT_02E for Teleinfo in general and NOI-CPT_54E for Linky in particular.

    The electronics part is mainly based on work done a long time ago by others, specially Charles Hallard (Démystifier le décodage Téléinformation et l’optocoupleur SFH620 and PiTInfo V1.2, en finir avec la téléinfo capricieuse).

    Board

    My board is vague cousin of Charles Hallard's Wifinfo but where most of the components are already embedded on the nodemcu module.

    CH340G (USB to UART)

    Something worth noting is that CH340G seems to be struggling with 7N1 (7 bits instead of the usual 8). Although it doesn't matter for day to day usage of the ESP8266, it makes tests (emulation of the Teleinfo frames) more difficult.

    It could be the driver though I am using Linux. Using boards (Amica) based on CP2102 or FT232 didn't show any problem.

    Power

    From the meter

    In theory, the pins "A" and "I1" are maint to be used as the power source. That said, the characteristics are 6 Vrms (50 kHz) and 130mW. This is far from the ESP8266 requirements (~ 150mA) and if it would be easy to rectify and smooth the current, a storage system (super cap or battery) would be needed to deliver peaks of currents every time the data is published (re-charging being one while module is in deepsleep).

    External 5V source

    To keep things simple and since I already had a 5V source at my disposal, I used the embeded regulator on the nodemcu board (through the Vcc pin but it could have been through the micro-USB socket).

    OTA

    Having the circuit permanently plugged to the meter means that the option of remote updates is a big bonus. The module is off/asleep most of the time so the best method was the HTTP Server one. But in order to make things easier and more secure, there is a physical jumper to allow OTA or not. When jumper is on open position, no OTA is possible. In the other position (closed), every time the program starts (i.e. every minute), it checks if an upgrade is available.

    This is were the additional python script comes handy. By running a webserver and comparing the MD5 checksum of the firmware on the module to the one on the server, it is possible to launch the upgrade sequence only when necessary.

    MQTT

    Selected data is transferred using the MQTT protocol. As mentioned above, the names/topics used are based of the ones in the ERL/LRT documentation.

    ADCO  --> Serial Number used in topics (ssssssssssss)
    
    BASE  ---->  cm/teleinfo-ssssssssssss/data/index {"value": "000073370"}
    PAPP  ---->  cm/teleinfo-ssssssssssss/data/apparent_power {"value": "00320"}
    IINST ---->  cm/teleinfo-ssssssssssss/data/rms_current {"value": "001"}
    

    Since the tariff is a constant one and not a differential one, there is only one reading to report and there is no need to advertise which tariff is active. People dealing with Heures Pleines / Heures Creuses would have to change the code.

    Deep sleep

    In order to reduce the amount of power drained, reduce the heat production and because there was no need to keep the module on for nothing, I decided to turn the wifi off. But it turned out that it isn't as straightforward as it initially sounded. Just calling the corresponding fonctions doesn't really make any difference in term of power consumption and forums are full of examples looking really like black art.

    On second thought, I decided to go to the deep sleep route which turned out to be easier to implement and perfectly adapted to this kind of usage. The teleinfo is continuous with values coming all the time but having a refresh every second or so has very limited interest. Even everything minute is kind of luxury.

    The only downsides of deep sleep are the need of a physical wiring for reset purpose and that the programme really resets every time. In this case where the bridging is stateless (state/info is held by the smart meter and given every single time) it doesn't matter the least.

    Next version

    This version has been running for a while without any issue. Once the meter is properly registered by the supplier (they seem to have technical issues actually), they should be able to change the mode to "Standard".

    This new mode is only in Linkys, uses a different serial speed (9600N7 instead of 1200N7) and provides more information. The "codes" are slightly different too.

    There is no physical modification needed and everything is documented so making the software changes should not be too complicated.

    Will see....

    Module in its box

    Code

    As usual the code and schematics are available (AS IS) on github.

    Page 1 / 9 »