My second Covid lockdown has been gracious in allowing me the time to write-up one of my latest projects. How generous of it. It's a revamp of a 1970s radio receiver into a contemporary internet web radio. I’ve documented as much as possible. Hopefully giving some ideas to anyone wanting to undertake a similar venture.
A couple of years ago whilst visiting the Maker Faire here in Paris, I stumbled upon a project of a household vintage receiver which had been revived into an internet wifi radio. Alexandre Svetec had found a faulty 70s Grundig RTV500Pi in his loft and had decided to give it a new lease of life by way of the internet. As we chatted, I was intrigued at how he had aimed to keep the main functions of the radio very close to the original. Paying particular attention to details such as a working S-meter and having the sound of white noise whilst tuning between internet radio stations, made it indistinguishable from a traditional RF radio. This was accomplished with a handful of electronic components coupled to a Raspberry Pi and some smart coding skills. The devil’s in the detail.
I was convinced that something similar could be created using an ESP8266 or the more powerful ESP32. Scouring the internet I found many projects that just converted old radios into glorified bluetooth speakers but not many real WiFi radios. The few real WiFi radio conversions I stumbled across had often cut, gutted and hacked the original radios to shoehorn in new electronics. I equate this to the current fad of converting iconic BMW motorcycles into modern cafe racers. Or modifying vintage Volkswagen Beetles with electric motors. I do understand the new trend of modifying old bikes to become beautiful cafe racers. But, a part of me cringes at the thought that these irreplaceable vintage vehicles are now being butchered beyond recognition. Soon there won’t be an R-Series BMW motorcycle in it’s original version to be found anywhere. Future generations will judge us I fear. For this project I wanted to avoid any major alterations to the original ‘donor’ radio. The WiFi radio modification would need to be as easy to remove as it was to insert. A clean, subtle and reversible install. As well as being able to still receive the traditional radio bands together with the new internet radio ‘band’. With the WiFi radio virtually mimicking the operation of a real radio.
THE PLANI’m using the ESP32 microcontroller to run the code. This can be programmed with the familiar IDE used for Arduinos. Expressif’s ESP32 is many times more powerful. It’s the successor to the popular ESP8266 with even more features, speed and flexibility. In fact I found it much easier to setup than it’s ESP8266 predecessor. It runs all the code and spits out the audio in I2S format to a PCM5120 DAC whose AF output is then routed into the final audio amplifier stage of the vintage radio. The PCM5120 receives the audio in I2S format from the ESP32 and converts it to an analogue signal. The 1970s radio I use is mono so only one audio channel is necessary. Finally, to control wifi radio functions like tuning and selecting the different modes, I have a line of Hall effect chips which are addressable with an MCP23017 port expander. This IC by Microchip gives me a maximum of 16 GPIOs, accessible by I2C with just a 4 wire cable. Daisy chaining them with different addresses and I can have many more GPIOs but one MCP23017 is enough to tune up to sixteen internet radio stations. As a tuning aid and to get some synoptic functional feedback, I use a multicolour LED strip mounted on the rear of the case.
The ESP32’s sketch was coded with the standard java based Arduino IDE using the C/C++ ‘arduino dialect’. For this an add-on needs to be installed onto the IDE to be able to code and program the ESP32. This process is well documented online. After choosing the ESP32 module, the memory partition sizes need to be selected. I've used 2MB for the code and 2MB for my SPIFFS files. 2MB of SPIFFS space is just about enough for my config and mp3 files. I’m sure we could whittle away at the code to get it under 1MB and then have the possibility of 3MB SPIFFS space but having 2MB of coding real estate does allow for more experimental leeway, tolerates disorderly coding and can accommodate any extra features later on.
Libraries used:
- "Audio.h" PCM5102 ESP32 I2S library. https://github.com/schreibfaul1/ESP32-audioI2S
- "SPIFFS.h" Expressif's SPIFFS library. https://github.com/espressif/arduino-esp32/blob/master/libraries/SPIFFS/src/SPIFFS.h
- "Adafruit_MCP23017.h" Adafruit's MCP23017 library. https://github.com/adafruit/Adafruit-MCP23017-Arduino-Library
- “FastLED.h” For programming addressable WS2812 LED strip. https://github.com/FastLED/FastLED
- “ArduinoJson.h” For dealing with our config.json file. https://github.com/bblanchon/ArduinoJson
- "time.h" Expressif's library used for getting time and date. https://github.com/espressif/arduino-esp32/tree/master/libraries/ESP32/examples/Time/SimpleTime
A key part part of this project was finding a suitable radio candidate. I spent months on various auctions sites with filtered searches and daily notifications. Garage sales, second hand and charity shops I would imagine are a good source but there aren’t many around where I am. The french ‘brocantes’ and ‘marche de puces’ will sometimes have old radios but condition and prices seem to vary enormously. In the end I had to rely on online auction sites. More risky? Not necessarily. It just involved a little more investigative work. Like reading the descriptions carefully. Inspecting each photo meticulously. Checking the vendors feedback. And, researching the radio thoroughly. Including downloading a user manual with a circuit diagram which would make the job simpler later on. I stuck to popular radio models. Searching for radio manufacturers like Grundig, Telefunken, Philips, Normende, Roberts and SABA. I do love the 1970s vibe. Scandinavian designed lighting and Danish furniture. Dieter Rams, Vitsoe and Braun. Anyway, after a few months of on and off searching I stumbled across a suitable candidate and took the plunge. Research, patience and a fair bit of luck paid off. I found a SABA Donau radio. Had I hit the mother lode?
THE RADIOIs the SABA Donau the ideal radio candidate? Well, it did fill many prerequisites:
- It was working, so I could still listen to the original broadcasting bands, LW, MW, SW and local FM stations. Actually, there’s not much activity on the lower bands anymore but still lots of strong FM stations in France. Most component faults could be fixed. These older radios suffer less from the modern day capacitor plague it seems. Mechanical breakages are more difficult though. Luckily I only had to dust out the inside and use a little spray on the band switches and raspy potentiometers.
- A user manual with circuit diagram and board layout was freely available on the internet. By sticking to popular makes and models of radios, finding documentation is easier and more user forums are available. Where those golden nuggets of information often lurk. Also replacement components are still obtainable if required.
I feed in the DAC's web radio audio at pins 3 or 5 of the DIN socket rear, shown in orange. Phono switch P3 selects between this and the radio's demodulated audio, shown in pink. Either of these signals will be amplified by the final audio amp, whose TBA810S can still be readily procured as spares. The sense voltage is tapped off from one side of resistor R401, shown in green.
- It had an Auxiliary input/output socket on the back via a 5pin DIN socket. This allowed users to record broadcasts to tape (output) or listen to records by connecting a turntable here for example (input) just using the radio’s AF amplifier stage. That means it’s an ideal place to splice in the PCM5120’s audio output signal. No need to cut tracks or components on the vintage PCB.
- A ‘Phono’ button on the front panel. The phono switch reroutes the audio signals in and out through the rear auxiliary DIN socket. It is located right next to the other band switch buttons on the front panel and would effectively be used to switch in the WiFi radio audio and provide a web radio band.
- Like many radios of that era tuning was displayed with a sliding pointer coupled back to the variable capacitor through a cord system. The SABA had the added convenience of possessing ample space on the rear side of the frequency display to 'hook & loop tape' (like the one made by Velcro Industries BV) the A3144 sensor board. This ample frequency band display would allow for more hall sensors on the rear, meaning more preset wifi stations.
- Speaking of space. This 70s shelf radio was also roomy enough to house the wifi radio’s main ESP32 wifi pilot board and it’s associated 6V power supply.
- The cosmetic condition was fairly good. A lot of these radios have been stored in less than ideal conditions leading to bumps, scratches, rust and moisture damage. It’s worth waiting longer or paying a little extra. Slowly, slowly, catchy monkey.
- Nice sounding audio. Due for the most part to the chunky speaker attached to the front of what is basically a big sound box. These old radios didn't need to use the tiny speakers crammed into our compact modern day electronics. They didn't have the size constraints we have today. They deliver rich and bassy audio. Having said that, their plastic or wooden cases with hardly any shielded circuits, provide little defence against EMI or AC hum. A sign of simpler times, where dwellings weren't chockablock full of gadgets and gizmos perhaps.
There are various possible ways to tune WiFi radios. Often push button or rotary encoders are used. I have a preference in using encoders. With clever coding they can offer much flexibility and in a small form factor. Here however, the aim was to avoid having to mechanically attach an encoder onto the variable capacitor’s axle. Access to these spindles can be difficult and I wanted to avoid butchering the radio’s innards with hacksaws and files. Reading the variable tuning capacitor’s value with a microcontroller to tune different internet stations had been done too. But I wanted to keep the original LW, MW, SW and FM bands operational and I was aware that adding an extraneous circuit across this LC tank could detune its normal operation as well as the risk of more noise being introduced. I needed complete circuit isolation. Was there another solution?
Many old radios have a band spread display with a moveable pointer. The pointer moves across the band by means of a cord system which leads back to and is controlled by the tuning capacitor. Reading where this pointer is on the frequency display could be possible.
I initially tested this with time of flight sensors. Reading how far the pointer was across the band by fixing a small ‘object’ to the dial pointer. I tested this with a VL53L0X sensor and afterwards with the more accurate VL6180X. It did work but I could never achieve a clean and consistent result. The returned distance value would hover around and was less precise the further the distance. The little square object stuck on the dial pointer was too small to be seen by the laser accurately.
In the end I settled for a solution based on hall effect sensors. I used a row of A3144s sitting behind the front frequency dial display at 1.5cm intervals. By sticking a small magnet on the tuning pointer's rear, it would trigger them as it wafted over each one when tuning.
It worked well, gave consistent results and was cheap. A couple of euros for literally dozens of these sensors. The 1.5cm separation did mean that I was limited to the total number of internet radio stations I could tune. The Saba’s frequency pointer travels about 23cm across the frequency band display. At 1.5cm spacing this would give me 15 internet radio stations which I could select from. Now I would just need to run 15 GPIOs back to the ESP32. Did the ESP32 have enough free IO pins? Actually, this wasn’t my main concern. The thought of having an ugly spaghetti fest of 15 wires plus power and ground going from the rear of the frequency display back to the main board was. I wanted a low impact and clean project. Ribbon cable? Maybe I could route the flat cable around the inside of the radio. Or maybe there’s a smarter solution.
THE PORT EXPANDERA control bus provides a tidy solution to access my row of Hall sensors so I2C seemed perfect for the job. If it's good enough for Philips, it's good enough for me. An extra 16 addressable IO pins are possible using Microchip’s MCP23017. Which actually, with the ESP32, I may have not needed. Anyway I didn't stop to count. I can now take up to 16 sensor lines (19 total with power and ground lines) down to only 5 easily routed wires (SDA, SCL, +5.0V, +3.3V, GND) coming from the Hall sensor board and avoid a spaghetti like mess. The only investment being a little research and then coding it into the sketch. This chip also operates on 1.8V to 5.5V, so we can use 3.3V and have logic levels compliant with the ESP32.
The MCP23017 comes in a few package types including an ubiquitous and tiny SSOP version (marked E/SS). I prefer the SSIC body (marked E/SO) since it's still small but easier to juggle with if SMT reflow soldering at home. A big through hole DIP version is also available for the more SMT challenged and if space is not an issue. An alternative solution without resorting to I2C could be with shift registers and modifying the code accordingly.
The ubiquitous A3144 is a non-latching Hall effect sensor IC in a small TO92 package. It will detect the presence of a magnetic field and toggle it's output much like a reed switch would. Unlike a reed switch however, it is much smaller, less fragile and cheaper. I’ve aligned them all in a row on a PCB, which is designed to have the board space for the ones not used just snap off.
Magnet choice and positioning is paramount. This adjustment is easier than dialling in a Mini Cooper's twin SU carbs on a cold damp morning...but not by much. Experimenting with different magnets before final installation is important. I have the row of sensors spaced at 15mm intervals on my PCB. This I gives me 15 web stations to tune across on the SABA's display. The magnet is chosen and positioned so as to provide enough magnetic effect over an A3144 to trigger, but also not to trigger any A3144 when lying between two sensors. Magnet strength, distance from sensor and orientation plays a big part. The A3144s also display some hysteresis effect to trigger on and off. My magnet was scavenged from a magnetic push pin. I 3D printed a small holder for it to sit in which facilitated adjustment. It can shuttle to and fro across the back of the display, skimming just above the Halls and their plastic TO92 heads.
The magnet is quite weak. A stronger one may trigger two adjacent Hall sensors. It's a case of more is less. Magnetic 'al dente' as it were. Your mileage may vary.
I hole punched some markers from black insulating tape and stuck them in a neat line on the front display as a tuning aid. Anal-retentives could even position the sensors to line up precisely behind the broadcasters/countries named on the vintage radio’s frequency band display. With the corresponding internet radio station URLs set up to match in config.json.
THE POWER SUPPLYThe ESP32 DEVKIT V1 board has an AMS1117 low dropout voltage regulator which has the task of supplying 3.3V to Expressif's ESP32. Old school linear regulators usually needed an input voltage a couple of volts higher than their output to function correctly. These days, newfangled LDOs get away with much less. But feeding even 5 Volts to Vin of the DEVKIT development board, gave me somewhat flaky performance. The WiFi function especially seems to draw a bunch of current. Any voltage losses along my power leads during testing didn't help either and ultimately manifested itself as erratic board behaviour. I found that the ESP32 development board seemed happiest being fed with 6 or 7 Volts. This was indeed backed up by the datasheet. However, much over 7V and the little AMS1117 will have to shed the extra voltage it doesn't need as heat. Relatively cheap power supplies capable of 6 to 7 Volts can be sourced on the internet. My 3 Amp Chinese PSU is capable of supplying not only the pilot board but also the string of multicoloured LEDs quite contently. Keeping their brightness value to a modest level will reduce current drawn. In any case, the overall intensity change is more perceptible to the eye in the lower values of brightness. As a safety, there is a maximum power cap function included in the code anyway.
Why do I over-dimension PSUs? A bigger power supply compensates for the over exaggeration of Chinese manufacturing specification claims. It runs cooler when not pushed to the limit. It runs cleaner with less noise generated when not pushed to the limit. It’s often cheaper than some of the valuable components it powers.
The 5V needed for other components was taken by dropping some voltage across a diode. I've used a 1N5392 which is a slightly beefier version of the ubiquitous 1N4001 series of diodes. At 1.5A max current it's not much bigger and gives me a bit more peace of mind whilst driving the ambilight LEDs. The modest amount of power needed for the MCP23017 can be taken from the DEVKIT's 3.3V pin. Although this port expander IC usually whizzes along at 5V, by keeping it at 3.3V means that we can have the I2C bus lines feeding directly to the ESP32 without any extra logic level converters. Although 3.3V ESP32 boards sometimes accept 5V at their GPIOs it's 'hors normes' and could lead to some nasty surprises, sooner or later.
Data pin 34 of the ESP32 is used to sense a voltage high, tapped off from the original radio. Several voltages are available. I selected a handy 9V rail supplying part of the SABA's RF circuits. It was easy to emulate this voltage with a fresh 9V PP3 battery during development. Measured, it's actually 9.5 Volts. I siphon off 1mA into a potential divider network made up of a 6.2K and a 3.3k resistors. These are standard resistor values and conveniently give a 3.3V logic level. These resistor values need to be selected for the particular radio and the particular voltage attempting to be detected. A 3.3V compliant high logic level is needed at pin 34.
The code is constantly pooling D34 and uses the presence of voltage here to see if the radio is turned ON or OFF. When the radio is turned OFF there will be no logic high here. The DevKit's built-in blue debug LED will start to flash, whilst the code waits ten seconds before sending the ESP32 into deep sleep mode. This effectively turns off all current guzzling functions like the WiFi. Perhaps not a necessity with a 3 Amp power supply, but still good practice and it just keeps the ESP32 module cool. In fact most of the current consumption during sleep will be due to the A3144s and a few extra components on the DevKit board.
Waking up from deep sleep happens when the radio is powered on again. The ext0 mode was set in code to wake up the microcontroller on seeing a high on RTC_GPIO4 (GPIO34) pin. At that point it will restart the ESP32 and resume operation.
THE NORMAL MODESWIFI RADIO MODE
This is the normal wifi radio function which performs much like a standard broadcast radio. The name of the web radio is announced each time a new station is tuned into and the corresponding backlight LEDs flicker red. When slowly tuning from one station to another, a shortwave audio squeal is also heard to simulate a real RF radio. A nod to the white noise hiss of Alexandre’s Grundig transformation.
ZEN/CLOCK MODE
Tuning between two web radio stations (no radio streamed), the ambilight will change colour after a couple of seconds. The code will then jump into Zen/Clock Mode after a delay of around 30secs. Firstly it will connect to an NTP time pool server and update its RTC. Consequently, at the top of the hour it will chime and can announce the time. Meanwhile it will randomly play the zen sound clips at irregular intervals (timing defined in config.json file).
THE CONFIGURATION MODESetting the dial halfway between any two web radio stations (no radio streamed) BEFORE powering on and the ESP32 will kickoff in Configuration Mode. Permitting us access to it’s resident SPIFFS memory, for updating the user specific.JSON configuration file and all the customised.MP3 files.
This is possible thanks to David Bird’s (G6EJD) handy file server system by just pointing a browser at 192.168.0.150 or however the ESP32’s http://www.fileserver.local/ has been defined. This address needs to be made available in the internet router's configuration. Or otherwise the lines in network.h need to be changed to accommodate the router.
Although in the past I have always used EEPROM memory to hold program configuration data, for this application the ESP32’s SPIFFS memory provides a better solution. As well as program settings it also stores all the.MP3 files needed. With David Bird’s ESP32 file server system it gives us a user friendly way of remotely configuring the WiFi radio using an internet browser. Initially these files can be uploaded using the IDE of course. Menu Tools - ESP32 Sketch Data Upload. The IDE’s Serial Monitor must be closed before uploading SPIFFS data, otherwise we get an error. Any beefy MP3 files can quickly take up a lot of memory, so best keep them brief. After choosing the ESP32 module I selected a Partition Scheme of 2MB App and 2MB SPIFFS (with no OTA). This allows space for the code (2MB) and the files which will reside in SPIFFS (2MB). If I run out of room I can try shorter MP3 announcements, less zen sounds or whittling away at my code so it occupies less space.
00clock.mp3 to 12oclock.mp3The hourly voice announcements when in Zen/Clock mode. The 00clock.mp3 to 12oclock.mp3 files announce midnight to twelve o’clock respectively.
chime.mp3This sound bite occurs exactly every hour when in Zen/Clock mode and is prepended to the hourly voice message. It’s a heads-up before the hourly announcement. Other MP3 choices like the BBC pips time signal have also been used.
hfsqueal.mp3This mimics a real receiver when tuning slowly between the web radio stations. I’ve used other types of commonly heard band noises like man-made interference, naturally occurring atmospheric noise or FM hiss. It's convenient to have a few seconds of silence at the end of this sound, effectively preventing the radio trampolining too quickly into Zen/Clock Mode.
inconfig.mp3This announcement confirms that Configuration Mode has been entered and invites us to connect to the wifi radio’s file server.
ntptime.mp3The first time switching to Zen/Clock Mode the code will try and update the ESP32 RTC and announces the fact by playing this mp3.
radio_01.mp3 to radio_16.mp3Individual voice announcements for each of the preset web radios, which are played on tuning a new station. Each one must be customised to identify the actual web radio station connected to. The radio_01.mp3 to radio_16.mp3 files announce stations 1 to 16 respectively.
wififail.mp3At switch on the ESP32 will try to connect to our wifi network. If it fails after about 10 seconds, it will play this file and retry.
zen_01.mp3 to zen_10.mp3These are sound files that will play randomly when in Zen/Clock Mode. The zen_01.mp3 to zen_10.mp3 allow up to ten files to be used.
config.jsonThis is the most important configuration file in.JSON format and holds all specific user choices. It abides to the JSON object syntax, which must be preserved when editing the key:value pairs. These pairs include settings like the audio output level, timezone and web radio station URLs. Details below.
THE CONFIG.JSON FILEOne of the first things the code does is read the configuration file. It holds all customisable parameters. The internet radio URLs must match with the MP3 files. For example the line ”radio_06":"http://bbcmedia.ic.llnwd.net/stream/bbcmedia_radio4extra_mf_p", means that the sixth preset station will connect to BBC Radio 4 Extra’s web radio stream. Thus, this announcement should be in radio_06.mp3, and so on. The config file is in the standard.JSON format with each pair of fields separated by a comma, have quotation marks, colons, and overall surrounded by curly brackets. Care in editing this file must be observed.
volume (0 to 21)The audio output level of the PCM5120 DAC. This is the audio level that will be injected into the vintage radio’s AF amplifier. A value here sufficient to get roughly the same amount of sound as a strong FM band station. Starting low and working up.
bright (0-255)This is the maximum brightness of the LED ambilight strip. It is not the maximum capability of the LED strip as the code reduces this value to an acceptable level to avoid overdriving the power supply. Hopefully dodging any unruly behaviour like brownouts, which could reset the ESP32. If the setMaxPower line wasn’t used, at a full whack of 255 the LEDs would illuminate the sun. I have it at 40 which works well. If we don’t want the ambilight effect this parameter can be just set to zero.
zenRandomMin (secs)Used to calculate a random period between each zen audio file played. This wait period is generated in the code between zenRandomMin and zenRandomMax seconds. For example, if zenRandomMin is 30 and zenRandomMax is 60, each audio file will wait anywhere from 30 seconds to 60 seconds before playing the next zen audio file. Basically the smaller the numbers then the shorter the wait period and so the MP3s will play more often. Zen RandomMin should be longer than the length of the longest zen mp3 file, otherwise the files will seemingly play continuously without a wait period.
zenRandomMax (secs)Used to calculate a random period between each zen audio file played. This wait period is generated in the code between zenRandomMin and zenRandomMax seconds. For example, if zenRandomMin is 30 and zenRandomMax is 60, each audio file will wait anywhere from 30 seconds to 60 seconds before playing the next zen audio file. Basically the smaller the numbers then the shorter the wait period and so the mp3s will play more often.
gmtOffset (secs)Used to calculate the time zone retrieved from the NTP server. I live in Paris which is +1 hour ahead of GMT and so I have a value of 3600 seconds. In London, which is on GMT, this would be set to zero.
daylightOffset (secs)Used to define the daylight saving offset which will be applied to the time during those warmer months.
In Paris there is an offset of +1 hour so I need a value of 3600 seconds here. Actually giving, together with gmtOffset, a correct local time +2 hours ahead of GMT.
In London there is also an offset of +1 hour during these months. Thus, a setting of 3600 seconds would also used here to obtain a correct local time. Actually giving, +1 hour ahead of GMT, since gmtOffset for London is zero.
radio_01 to radio_16 (max 16)These are the stream URLs of each web radio station. Various sites on the internet list this information. A good one I’ve found is at FMstream.com. It is also possible to extract the address of a streaming station using a browser to View Page Source or Inspect Element.
THE NTP POOL SERVERThe Network Time Protocol is used for clock synchronization between computer systems. It is used to synchronise computer clock times in a network. A client such as our ESP32 connects to the time server and sends a time request packet. The NTP sever responds with a time stamp packet from which we can parse out our current date and time. The ESP32 uses this to update it's RTC. To minimise repetetive requests to the NTP server the sketch does this only once per switch on.
THE SOUND FILESEach radio identification announcement must pair up with its corresponding internet radio URL. So the file radio_01.mp3 should announce the first web radio and so on. I could have recorded my own announcements but decided to use a text to speech converter for consistency and audio quality. There are several online text to speech converters catering for a multitude of languages and accents. A voice of choice can be selected. I used English Brian and Portuguese Cristiano at ttsmp3.com. As well as punctuation, many also allow us to emphasize words, add pauses, alter speed and vary pitch just by adding tags to the text. Other MP3s like hourly clock, WiFi reconnecting and time server updated messages were generated in a similar fashion.
Sound samples, like the HF tuning squeal and hourly chime MP3s can be found online on sites like freesound.org and such.
Finally, for the zen sounds I used Audacity to edit out ten short birdsong sound bites from a large audio file. Other options could be rolling thunder, wind chimes, ocean waves. Whatever takes one’s new age hippy self’s fancy.
THE AMBILIGHTA WS2812 RGB strip along the back of the radio to give the project some jazzy added value and aids tuning. Using an idea pioneered by the bias lighting used by television manufacturers, this rear ambient light casts a coloured halo behind the SABA. In normal WiFi Radio Mode it projects a green aurora behind the radio, with two red LEDs that follow the dial’s tuning pointer and simulate locking on to a station by flickering. When in Zen/Clock Mode the ambilight will slowly cycle through all the RGB colours and exudes a mood light effect. In Configuration Mode these LEDs will be blue and in conjunction with the voice announcement they are confirmation that SPIFFS management is possible by connecting to the ESP32’s fileserver.
The brightness of the LED strip can be set in the config.json file and is intentionally dialled back in the code to save on power supply current needs. In choosing a suitable power supply, an approximation of the current consumed by the project is required. Just a quick back of a fag packet calculation will suffice. Each RGB led can consume anything up to around 60mA, depending on the colour value it is showing. Driving all 32 LEDs would equate to a worst case scenario of nearly 2 Amps of current drawn. Lower value brightness changes are better seen by the naked eye than higher ones. It's not a linear perception. We observe less change when going from 100 to 255 than 10 to 25. So a lower 'bright' value will keep the power supply happier with no real world visual detriment. The 'bright' value in the config.json file should be chosen judiciously so as not to overload the PSU. I set it at 40, which is more than enough light for my arrangement on a bookshelf and it still gives smooth colour transitions. Too small a value here and jumpy colour transitions may be noticed because of how the HSV colours are set. In any case, I also included the setMaxPowerInVoltsAndMilliamps function in the code to cap this brightness value and avoid any supply power unpleasantness.
THE LED STRIP HACKIt has probably not gone unnoticed that the LED strip is powered with +5V, yet feeding in data at an unconventional +3, 3V logic level. Of the half dozen RGB strips I tested, all tolerated this lower data input level. No additional conversion circuit was necessary. However some people have encountered issues in driving the LEDs like this and suitable solutions are documented online. These include sacrificing the first LED and then coding as +1. It's good practice to put a large decoupling capacitor across the strip supply as well as a current limiting resistor on the WS2812 data line to protect the LEDs of any misfortune. This is handy whilst testing the circuit and should limit the risk of any mishap to the LEDs. However, I did find that a lower resistor value or even none at all, was necessary when driving with a 3.3V data level. The potential dropped across it seems too great. Ultimately pushing the level further outside the LED strip's data input tolerances. Your milage may vary depending on the LED strip used.
WiFi disconnect. Find a way to detect when the radio is tuned to the traditional radio bands. Maybe a signal from the band-switches could deactivate the WiFi radio when not in use. At the moment it’s possible that WiFi radio stations are still being streamed in parallel, after switching to a traditional radio receiver band. This can be seen by observing the rear ambilight colours. Maybe a concern if we are without an unlimited internet data plan. A simple workaround is to switch on in Configuration Mode first, before selecting the FM radio band. The ambilight will show blue.
Magnet sourcing. New magnetic 3D print filament could be the answer to sourcing a suitable sensor magnet. Possibly printing a cone shaped magnet to direct the field more precisely to the sensors. But exactly how magnetic is this material?
Better shielding. Then using an ESP32 with an off-board WiFi antenna. To combat noise generated by the microcontroller when listening to the other bands. Interference on the traditional FM band was barely noticeable. To my chagrin, this wasn’t the case with the decametric bands. Thus, always best to keep the pilot board away from any power supplies to reduce AC hum or switching noise. In fact, exactly how I’ve not done. An audio isolation transformer and separate AGND might be beneficial too. I just used some shielded audio wire to feed in the signal to the phono input from the DAC.
The PCM5102 DAC glitch. This chip does output some decent audio quality for its tiny footprint. However, it seems to introduce some short clicks at start and end of playing each MP3. In normal Radio Mode these clicks are diluted in with the tuning squeal noise and less noticeable. They can actually be an aid to knowing when I’ve positioned the magnetic shuttle right on a sensor. In Zen/Clock Mode it’s more evident. Is it worth changing to another module if I can't find a workaround with code?
Using LittleFS instead of SPIFFS. Expressif is now concentrating all their efforts on LittleFS which allows for separate directories where files can be organised in different folders. SPIFFS is a flat file system where everything is stored under one roof. Apparently LittleFS is also a more robust file system. It safeguards data transfers during a loss of power. But SPIFFS does everything we need it to in conjunction with David Bird’s G6EJD file server system.
Setting WiFi's SSID/Password and fileserver/address. Currently they are hard coded into the sketch as I should not need to change these. Nevertheless, it would be convenient to be able to securely modify these remotely. Instead of having to edit the program, recompile and upload it each time through the USB port.
Using IDC connectors. With flat cable to link the two boards, LED strip and the radio. These would provide a neater solution to Dupont or soldered wires that I used.
Streamlining the sketch. I need to trim away the fat. My rushed smorgasbord of code was pieced together, tested and debugged over just a few weeks. The sketch has a roller-coaster flow to it. It's not pretty. I'm not a programmer. There are most definitely more efficient ways to achieve this.
Earlier this year the BBC stopped some of it's online stream servers. I lost my favourite radio station to listen to by way of their normal stream. This is an issue that Mr. Ralph S. Bacon has addressed on his popular YouTube channel. He gifts us with some workarounds: https://youtu.be/lYyvNDQwm0I
Luckily I found an alternative stream address here: http://www.radiofeeds.co.uk/
Then downloaded the .pls playlist file and extracted the URL directly.
To avoid crackles and pops caused by the PCM5102 DAC 'glitch' mentioned previously, a possible solution might be to mute and unmute just before the start and end of playing each track, using the XSMT pin. I've done this with a MAX98357A DAC chip using it's SD pin and it worked beautifully. You will need to add a second or so of silence to beginning and end of each track.
THE REQUIRED READING- ESP32 Datasheet.
https://www.espressif.com/sites/default/files/documentation/esp32_datasheet_en.pdf - MCP23017 Datasheet.
http://ww1.microchip.com/downloads/en/devicedoc/20001952c.pdf - MCP23017 at 3.3V.
https://www.schematics.com/project/mcp23017-io-expander-for-esp8266-36048/ - Alexandre Svetec.
https://www.hackster.io/user708224/rtv500pi-original-70-old-web-radio-d81bdf - G6EJD David Bird. ESP32/8266 Download, Upload, Delete, Stream, Directory using HTTP and HTML as an interface. Tech Notes 85-87.
https://youtu.be/6XR6BXbc0aI - XTronical for I2S and more.
https://www.xtronical.com/ - DroneBot Workshop.
https://dronebotworkshop.com/ - FMstream.
http://fmstream.org/ - Radio Feeds UK.
http://www.radiofeeds.co.uk/ - NTP Pool Project.
https://www.ntppool.org - Adafruit MCP23017 powering.
https://learn.adafruit.com/mcp230xx-gpio-expander-on-the-raspberry-pi/hooking-it-all-up - Ladyada on IDC connectors.
https://youtu.be/GVCADTTB_jU - Installing the ESP32 Board in Arduino IDE (Windows, Mac OS X, Linux).
https://randomnerdtutorials.com/installing-the-esp32-board-in-arduino-ide-windows-instructions/ - Andreas Spiess. #121 SPIFFS and JSON to save configurations on an ESP8266.
https://youtu.be/jIOTzaeh7fs
#222 More Memory for the ESP32 without Soldering (How-to adapt partition sizes).
https://youtu.be/Qu-1RK4F - Nuno Santos website.
https://techtutorialsx.com/ - LED strip hacks.
https://hackaday.com/2017/01/20/cheating-at-5v-ws2812-control-to-use-a-3-3v-data-line/ - ESP32 I2C pullup resistors.
https://github.com/espressif/arduino-esp32/issues/997 - Insights into powering ESP32.
https://techexplorations.com/guides/esp32/begin/power/ - NodeMCU power requirements.
https://diyi0t.com/esp32-tutorial-what-do-you-have-to-know-about-the-esp32-microcontroller/ - SparkFun Thing.
https://learn.sparkfun.com/tutorials/esp32-thing-hookup-guide/hardware-overview - Online.json assistant.
https://arduinojson.org/v6/assistant/ - Online.json editor.
https://jsoneditoronline.org/ - Collaborative database of audio files.
https://freesound.org/ - Online Text-to-Speech.
https://ttsmp3.com/ - SABA Donau Service Manual.
https://elektrotanya.com/saba_r160_donau-p.pdf/download.html
Comments