I acquired an Onkyo AV receiver, and it worked well enough for several years. And then one day, it did not work anymore. It would power up and light the display, but no longer pass audio or video. I put it aside. Sometime later I checked online for a service manual and found a scan of a service manual. The service manual included instructions for how to get into the service menu from the front panel, and this led to the result that the DSP had died, and the main CPU was unhappy because it could no longer talk to the DSP. 

Normally this would be an unfixable problem, but I am not normal. I decided to see if I could replace the CPU with my own. I don't need the DSP functions. I don't care if it passes video. But it would be nice if it was usable as a audio receiver.  I considered removing all but the power amp stuff, and just putting some relays in there to switch inputs, but that seemed unnecessarily crude.

Problem Summary

There were four problems I had to solve, ranked in increasing difficulty:

1. Figure out how to talk to the built-in tuner.
2. Figure out how to read the keyboard.
3. Figure out how to drive the front panel display.
4. Figure out how to control the audio processing IC, which is in charge of switching audio inputs, tone control, and volume control.

The tuner, which is a tiny module of perhaps a cubic inch in volume, uses an Si4730 tuner chip. This turns out to be well documented and have an Arduino library to talk to it. So the tuner problem was solved.  More on this anon.

The keyboard, which has 32 keys, uses resistor dividers to reduce the 32 possible key presses to four analog voltages. The processor has to read the four voltages, and then interpret the voltages as a key press. More about this below.

The display is a 15 character vacuum fluorescent display (VFD) with 30-something icons. The VFD uses an M66005 driver IC, which is documented, although some of the documentation is only available in Japanese. More on the VFD below.

Last problem is the audio processor, which is also not documented, but there is a sister part that is similar enough that one can figure out how to talk to the part in my unit. There was an attempt at a driver by somebody else, and it might have worked, but they had obviously started learning C the day before. So I rewrote their driver and created a GitHub repository for it as well.  More on this audio processor below.

If I solved those four problems, then I could hook my processor in place of the factory processor and actually pass audio through the receiver again.

Processor Selection

I started using the ESP32, because:

• I'm familiar with it.
• It has a lot of I/O.
• I have them in stock.
• I could always change my mind if I ran into a show stopper. I was also considering the Arduino Due, which has an 80MHz ARM processor.

The ESP32 turned out to be a good choice, because it has enough I/O to get the basic functions working, and with the use of an MCP23017 I/O expander, I can control everything, including unimportant stuff like the front panel LED. In the beginning of the work, I was using an "Espduino", which is an ESP32 in the form factor of an Arduino UNO. This was convenient because I had a "shield" that fits that that presents all the pins as screw terminals, so the i/o wires are securely connected.

Side note about "Dupont" jumpers

"Dupont" (.025" square pins and matching sockets) jumper wires are convenient for lashing something up quickly, but they don't have the best retention force, and fall out at the least provocation. With a project like this, with 30 I/O wires connected up and going all over the place, I found that it's best to use screw terminal blocks for the MPU end of the wire. At the other end, I "gang" up connectors that are going to the same device and change out the single plastic housing for a multi-pin housing that holds all the pins at once. The retention force for a multi-pin connector is way better than for a single connector pin.

Controlling the Tuner

I was surprised at how small the tuner is. That's the F connector for FM antenna and the black terminals are for an AM antenna.

Carefully prying off the lid (thankfully not soldered on) is a tiny 12 pin chip (about 3mm on a side) with even tinier writing on it, which some internet searching revealed to be an Si4730. This chip is one of a family, with AM, FM, and even short wave tuning in some models. There is an Arduino library, so relatively easy to talk to (using I2C).

Tuner UI improvements

Since I had to write a whole new UI (user interface), I could make it do everything I wanted. I feel that a tuner should be tunable both by turning a knob and by directly entering a frequency. There are so many buttons on the front panel that I was able to identify 10 that would work as numbers 0 to 9, and then rig up a UI so the user can enter AM or FM frequencies directly. Or, the user can use the knob to change frequency. Or, the user can use the existing "tune up" and "tune down" buttons on the front panel to change frequency.

The user can also store stations as a preset, including entering the stations call letters so the preset will have a useful name. This uses the knob to scroll through the alphabet (first character of call letters constrained to be either "W", "K", or "C", to accomodate stations that are west of Mississippi, east of same, or Canada).

Interfacing with the keyboard and volume knob

Interfacing to the volume knob was trivial: it's a standard digital quadrature control, for which Arduino libraries already exist.

The keyboard was more challenging. Onkyo engineers decided to use resistor dividers to cause different analog voltages to appear on any of four different lines when keys are pressed. Some lines have up to 10 buttons on one line, but one line has only four buttons. The ESP32 A/D converter is 12 bits, but it's not very good, having bad linearity at the top and bottom of it's range.

But that wasn't the problem, it was the iffy contact made by the push buttons themselves, which meant that the analog voltages are not consistent. One has to push the button with "determination", because a light tap will give an erroneous voltage and be mis-interpreted by the cpu. To reduce errors a bit, I read the same analog pin 16 times in a row, and then take the average of the readings. I still get some false keys, but it's usable, and I really don't want to rewire the entire front panel to turn it into a 6x6 matrix. 

There are Arduino libraries for analog keyboards, but none quite like this one, so it was reasonable to just write my own keyboard scanner for this.

Controlling the Display

First problem with the display was finding a datasheet for the M66005. After a lot of internet searching, I found the Japanese language datasheet for the M66005, and also the English datasheet for it's sister part, the M66004, which is mostly compatible. Google can translate the Japanese, though I had to make several passes, once by feeding the PDF to Google, and again by converting parts of it to JPEG, and then feeding those to Google, and then merging the results using Gimp (photo editor). Also, shout out to Image-Magick, used to convert PDF to JPEG and back.

There was theoretically a driver written for the M66005, but honestly it was a dog's breakfast and I don't know if it would actually work. So I rewrote the driver and put it up in a GitHub repository.

I had some initial trouble getting my ESP32 talking to the M66005, which turned out to be swapped wires in my connection between the two.

One peculiarity of this display (on this model Onkyo) is that the display chip can control up to 16 characters, but the Onkyo engineers made a 15 character display and then used the 16th character to control the 32 icons (the display is 5x7 dot matrix vacuum fluorescent, so has 35 outputs per character).

Since the display controller chip has ASCII characters and Kanji characters in its character rom, I wrote a "UTF-8" filter that converts many of the accented characters into their nearest ASCII equivalent (like é -> e) so the display won't just show garbage when the currently played song has "funny" characters in it. This also solved the problem that caused the Android app to crash, since the UTF-8 characters aren't supported by my routine to take the MQTT payload and print it on the phone screen.

The Audio Processor

The most challenging part of this has been working out how to control the audio processor. The part is a Renaisys R2A15218FP, which has next to no documentation. Fortunately, somebody on a forum somewhere figured out that its sibling, the R2A15220FP, is similar enough that you can use its datasheet to figure out how to talk to the 15218 part. I would buy that "somebody" a beer if I could find him, but sadly all I have is a "handle" of "geo98".

The part is weird. It has 6 24 bit registers, which are write only. These control all the functions: 11 stereo inputs, volume control, bass and treble filters, and many different signal routing options.

Because of the 24 bit "frames", I don't think it's possible to use SPI or I2C to talk to it, so the driver that somebody wrote does bit banging. I re-wrote the driver I found, because the one I found was obviously coded by a beginner (no subroutines, for example). I've made a GitHub repository for it.

As part of the process of getting this to work, I hooked my logic analyzer up to look at the traffic between the stock CPU and the Audio Processor. The Sony-Tek analyzer had trouble capturing useful data, so I used an ESP32 as a simple logic analyzer, since, for one thing, it's got much more memory than the Sony Tek logic analyzer. Then, a Perl script on my laptop converts the raw data from the ESP32 capture into a readable output.

Adding new features

As long as I'm going to go to all this work, I figured I might as well add features and make the device more useful. The four features I've added are:

• Internet Radio with presets
• Bluetooth streaming (e.g. from your phone)
• Phono preamp
• Android app control

Internet Radio with presets

I already have a great internet radio "sketch" that runs on an ESP32, and it was simple to add the code for that to the receiver code. Mostly, I just renamed the setup() and loop() routines in the internet radio sketch to "iradio_setup()" and "iradio_loop()", and then called them from the "real" setup() and loop() routines.

Yes, there was housekeeping, like only running the iradio routines when the user has selected the internet radio input, and integrating the front panel buttons with the controls for the internet radio, but the end result works well.

The internet radio uses the I2S system on the ESP32. The I2S system sends PCM (digital) audio out the I2S pins on the ESP32, and then one needs an I2S D to A converter to make actual audio from that. I mounted the I2S DAC module on the back panel of the receiver.

The internet radio presets, which consist of call letters and a URL for each station, are stored in flash in the ESP32. The ESP32 initially downloads this list from a "master list" that I keep on my webserver. (This is the pretty HTML version. The ESP32 downloads a text file that is the source for the pretty version.)

There is a command that can be run from the front panel of the receiver that will erase the internet radio presets file. On the next cold boot, the ESP32 will notice it's missing and download a fresh copy. That way I can keep my internet radio(s) up to date when stations change their streaming service (as they do somewhat frequently).

Bluetooth Streaming

I thought I could add this function to the same ESP32 code as well, but I couldn't figure out how to get both the internet radio and the bluetooth code to share the I2S interface.

So bluetooth is handled by a (cheap) bluetooth streaming board. I control that board using the digital I/O of the ESP32 to "push the buttons" of the bluetooth module, by shorting across the buttons with open-collector transistors.

Phono Input with Preamp

I might as well add a phono input, since this receiver has about 8 different inputs on the back panel. I still have phonograph records and turntables, so it's not out of the question that I might want to hook a turntable to this thing.

I had a Philmore Phono preamp kit laying around (long story) and so I built that. The PCB is only about 35mm on a side, and uses a dual op-amp. The kit came with a LM1458, but yuck, so I subbed an NE5532, which is pin compatible but a much more modern (and better) part. I tried it out on the bench, and it seems to work (signal generator to the input and scope on the output looked OK.)

As a listening test, I wired up a "reverse RIAA" filter, so I could feed program material into the phono preamp from another source (like a CD player). The reverse RIAA filter does what it's name suggests: it attenuates the signal down to the expected level from a phono cartridge, whilst also cutting the bass and boosting the treble, to match the RIAA recording curve that all modern phonograph records are made with. This was a fun diversion (researching and then making the filter) and listening tests confirmed that the phono preamp was working properly.

The phone preamp is mounted on the back panel of the receiver (but not in the photo below).

Final Integration

The plan is to remove the "CPU" board, which hosts not only the stock CPU, but also the broken DSP and the HDMI switching, and some voltage regulators to generate 5.6v and 3.3v. I will replace this board with my ESP32 board, with the MCP23017 port expander, as well as voltage regulators and pullups for the analog keyboard.

I also plan to use a "standard" ESP32 Dev Kit board instead of the ESPduino, because (a) it's smaller, and (b) I found a screw terminal board into which the Dev Kit plugs. I've also got some "FFC" (flat flexible cable) adapter boards, that allow me to use the stock FFCables to connect my CPU to the I/O on the other boards.

Early March Progress

I finally built a "production" cpu board, by attaching modules (including the ESP32 in a carrier board) to some pieces of perf board. Most of the connections are now attached with screw terminals or soldered (and using telephone wire), rather than using the "Dupont" jumpers in the experimental version.

I've replaced the Bluetooth board with a different one, that also will play music from either a USB flash drive or an SD card. I've extended the wire that leads from the front panel USB socket to reach this new board, so that now the "Bluetooth" function will also play music from a USB flash drive. To allow the user to control the "Play/Pause" and "Next" and "Prev" buttons, I wired up some computer I/O to some transistors so that the open collectors can act like the push buttons on the module.

The front panel labels had two problems. One, many of them were wrong, as I don't have any of the DSP functions, and I've changed the input functions (like adding a Phono input). Two, they're a typical modern front panel that has 8 point grey type on a black background, so unreadable by me without a strong light and a magnifier.

Fortunately, there's a good solution. The Brother P-Touch label maker has available black tape with white letters, so it's easy to knock out readable labels that don't look hideous. (I had made labels with an old Casio label maker, but its labels, with their black type on white tape, and a hideous font, looked awful.)

Late March Progress

I finally did what I should have done long ago, and tried poking "randomly" at the undefined bits in the six registers in the R2A15218FP. By doing this, I found another signal routing switch, which allowed me to feed the front sound (after the volume control) to the 'B' speakers amplifier channels. (The amp doesn't just switch the 'B' speakers in parallel with the 'A' speakers -- they use two amp channels to amplify a "copy" of the 'A' signal. This may be because the amp channels are specified to work with speakers of 6 Ω and over, and two 8 Ω speakers would, if put in parallel, result in a 4 Ω load. I have added a new method to the R2A15218FP driver so that this switch can be controlled.

In addition, I figured out how to drive the Center channel and the Subwoofer channels. I used the existing op-amps that were used to amplify/buffer the (now, non-existent) DAC outputs, by modifying them to add the left and right ADC outputs (from the R2A15218FP) together to give a mono signal. So now, all the outputs can be used: Front(2), Surround(2), B(2), Center(1), and Subwoofer(1). Subwoofer is preamp out only -- no amp channel for it. The Surround outputs use the same amplifiers as the 'B' outputs; you can have either/or.

I also did a bunch of clean-up of wiring etc so that all the hardware now fits in the box, and I could theoretically put the cover on.

One hardware problem was that the Mute circuit stopped working correctly; I realized I had lost (in removing the stock CPU board) a digital buffer stage that's between the CPU mute output pin and the muting transistors that short the audio signals to ground. Rather than build this buffer (two transistors and a handful of resistors and capacitors), I cut the circuit I needed out of the original CPU board (with a Dremel), and connected to that. It's all surface mount and the whole thing is about 15mm on a side, so much smaller then I could make using TO-92 transistors and 1/4 Watt resistors.

Remote Control

The Onkyo originally had an infra-red remote control. Since I don't know the codes it uses, I can't easily use the remote. With lots of work, I could figure out the remote codes, and then add all the code to recognize and act on them. I've done this job before (on this project) and it's not fun.

I had an epiphany: I can control any internet connected thing using MQTT, and this receiver, since it's always connected to the WiFi (so it can get Internet Radio) can easily send and receive MQTT messages. I tried this out using MQTT Dashboard, and it works great.

Time to fire up MIT App Inventor (2), which allows "anyone" to build an Android app. By "anyone" I mean people who aren't professional computer programmers, including children. I had to find and install an MQTT "extension", and then I was able to build a phone app that controls my receiver.

The great thing about making my own app is that I can control all the new features I added to the receiver (like internet radio, and bluetooth reception), and I don't need to point a remote at the receiver to get it to work. I can control the receiver from the next room, or from the next county, for that matter.

Source code here.

Note that the app sends messages to topic "cmnd/Oinkyo/#", and listens to messages in topic "stat/Oinkyo/#". The Oinkyo (née Onkyo) sends its status messages to "stat/Oinkyo/#" so that the app knows the state of the receiver, for example, what is the input source, or what radio station we are tuned to. (The '#' character means "wildcard" in MQTT. An actual message would look like: "cmnd/Oinkyo/INPUT FM".)

April Progress

As I finish this web page in mid-April, I am listening to the receiver. All the functions work, and I haven't fixed a bug since yesterday, and the one before that was 5 days ago, so most of the (easy to find) bugs are stomped out.

Problems Yet to Solve, Things to Do

Create a QR code to download the app from my own server.

FAQ

Q. Why not use bluetooth for the app?

A. Because there's only one radio in the ESP32, and it's being used for WiFi.

Q. Will you fix mine?

A. No, I'm retired and so not interested in a job.

Hardware details

Here are the hardware/wiring details, in the unlikely event you want to do this to your Onkyo.

User Manual

The manual is here.

Source Code

The source in a gzipped tar file is here. The source in a zip file is here.

Link(s) to this article

Hackaday.com

Disclaimer/Warning

This is just my documentation for my repair. I don't claim that doing this is safe or recommended.

Soldering irons are dangerous, be careful. Oh, and don't eat the solder.

There are live mains voltages in this unit. Be careful when poking around in the power supply area.

William Dudley
April 20, 2025