[Alex] recently gave a Marantz audio amplifier the ability to be remotely-controlled via WiFi by interfacing an ESP32 board to a handy port, but the process highlights how interfacing to existing hardware often runs into little, unforeseeable problems that can sink the project unless solved.
At its core, the project uses an ESP32 and the ESPAsyncWebServer project to create a handy web interface that is accessible over WiFi. Then, to actually control the amplifier, [Alex] decoded the IR-based remote signals by watching the unit’s REMOTE ports, which are intended as a pass-through and repeater for IR signals to other Marantz units. This functionality can be exploited; by sending the right signals to the REMOTE IN port, the unit can be controlled by the ESP32. With the ESP32 itself accessible by just about any WiFi device, [Alex] gains the freedom to control his amplifier with much greater flexibility than just the IR remote would offer.
Sounds fairly straightforward, but as usual when interfacing to an existing piece of electronics, there were a few glitches. The first was that high and inconsistent latency (from 10 ms to 100 ms) made controlling the amplifier a sometimes frustrating experience, but that was solved by disabling power saving on the WiFi interface. Another issue was that sending signals by connecting a GPIO pin to the REMOTE IN port of the amplifier worked, but had the side effect of causing the amplifier to no longer listen to the IR remote. Apparently, current flowing from the REMOTE port to the ESP32’s GPIO pin was to blame, because adding a diode in between fixed the problem.
The GitHub repository holds the design files and code. This kind of project can be pretty complex, because the existing hardware doesn’t always play nice, and useful boards like a modern ESP32 aren’t always available. Adding a wireless interface to vintage audio equipment has in the past involved etching circuit boards and considerably more parts.
A nice solution done the wrong way, IMO. Using a web page makes things easier indeed but adds the need of a web browser (probably among the heaviest mobile apps everywhere) and forces the uC to run a web server, hence needing a more powerful one. The simpler old-school solution would be to set up che uC to open a socket (UDP is fine on local networks) then wait for packets. A single non fragmented UDP packet can carry enough payload for hundreds of bytes. On the “remote” (cellphone, smartwatch, etc) the browser would be swapped by a small GUI with buttons and other controls linked to functions sending and receiving the right packet. Network/host data alignment is not a problem at all once one understands how hton/ntoh etc. endianess functions and data padding work. There’s no need for xml, json and other binary to text translations: I’ve exchanged data between Power! and x86 platforms using different languages in the past at huge speeds on very slow machines using this method.
Can you point to an example project on how to do this? I would really be interested in doing something like that. Thanks.
Home Assistant, ESPHome, and a simple IR transmitter is all it takes. All you need is some simple YAML and the firmware literally writes itself. See here: https://esphome.io/components/remote_transmitter.html
All I have is code I wrote at work that I cannot publish, but if you grab any UDP socket tx and rx example, it will become straightforward. All it needs is to define and allocate a structure with the data you want to send/receive, then give it as the buffer to the sendto() and rcvfrom() functions so that the receiving socket will get a copy of the data in its buffer. Of course you must take into account endianess, padding and all machine dependent representations (take a look at the ntoh*() and hton*() functions) otherwise there will be problems when talking between different architectures (that’s the reason everyone uses text, but if speed is needed then going binary helps a lot).
In a home local network it is also possible to transmit in broadcast, so that every endpoint can know data from every other one; one field of the buffer structure can contain source and destination ids so that appliances can know what device sent what (and to whom); this makes very easy to build IoT networks, and the load on both the network and hardware is dramatically lower.
But presumes that the user is able to write a decent mobile app for the various platforms. TBH, something like ESPHome that exposes all of the defined entities in an easily consumed manner via either the HA API or MQTT, as well as offering a web server if desired, seems like a better solution to me. Sure, it may be heavier, but I don’t really know how much lighter you want, and how much time/money you will save by using something lighter weight.
“But presumes that the user is able to write a decent mobile app..”
Not too difficult if you have gone to the trouble of writing the code for both the ESP32 and the web page.
Try B4A (was Basic4Android), quick easy and well supported.
writing a whole app just to avoid having the esp32 host a webpage even a esp8266 can host a webpage as simple as this
I’m working on an Android app using B4A for the first time. It’s come together really fast, coming from a VB6 and Swordfish Basic for PIC18F-series micro controllers. Looking forward to trying it with ESP8266s and ESP32s.
I don’t see this as the wrong way: an ESP32 is almost as powerful as the Pentium 100 that carried me thru college, so I doubt running a small webserver would be a heavy load.
A web browser is something everyone already have. It’s faster to just connect to the amplifier Wifi and access some page than to download the small GUI apk. Imagine going to some party and a guy you never saw says “to control the amp you just download this random apk from somewhere, it needs unrestricted internet access but don’t worry…”
I do not see anything “wrong way” here.
1. Web browser is available on every mobile or ipad i have. And its usually on anyway
2. Web server on esp32 is very fast. Moreover, if you will set expire headers (i dont) device will cache it for you
3. I know what UDP is. But this would require custom client. Lets count my platforms:
– Android (different versions)
– IPAD (some very old ios)
– Few iphones, including heavy locked enterprise one
– OpenWRT (as i am turning of this amplifier just by doing curl from the cron)
4. There is no any need for “huge speed”. Its responsive enough and could be compared to hw ir remote.
5. I will need also to write UI for most of the usecases. Thing about different screens, etc. Right, its exactly what html + css + svg already solves lol
So i think that UDP here + ton of custom clients is actually a very bad way.
I’ve created a similar project, essentially an IR translator that responds to IR codes from spare buttons on my TV remote and sends out codes to control my amplifier, using a Tindie purchased “Remotsy” which uses an ESP8266, IR receiver + transmitter and my own custom firmware.
My firmware hosts a very simple webpage and at first I just had each virtual button send a unique GET request parameter, but later I switched it to use websockets to relay virtual button presses, and that greatly reduced the delay between button pushes.
yes, i was also thinking about websocket, it would also help with “long keypress” emulation, this is cool that you implemented it.
True. OSC + android app exported from Processing IDE could be easy solution
“…and useful boards like a modern ESP32 aren’t always available.” HUH? every distributor and mom and pop shop have them in stock all the time. I think your thinking of RPI boards.
I don’t want to dog on this person’s work but they took a pretty weird approach to the problem. Bit-banging via digitalwrite might be the worst-possible solution to accurate timing and it neatly explains all the problems the creator had.
All of these problems have been solved for AGES, there have been solid IR transmit libraries going back to the PIC days (LiRC etc). Marantz uses RC5 encoding which is pretty common and is supported by the Arduino-IRremote library available right from the IDE.
Did you read the bit about him having problems removing the carrier function ?
And maybe just maybe he doesn’t know any better than using bit banging.
I remember the first coding I did for a simple enough game. The object boundary checking took about 60 seconds to run through all the if loops.Then I discovered what arrays were for and it took less than a second.
If it had only been a second for the If loops I doubt I would have looked for another solution since it was working.
Welcome to teaching yourself to program.
I get just going at things the hard way because sometimes that’s how I learn best.
My post was more to anyone looking to repeat the effort: there is a huge shortcut you can take as this technology is a well-travelled space. You can build on the shoulders of giants! Just grab one of the many libraries out there and you can do this too with very little pain involved.
> Bit-banging via digitalwrite might be the worst-possible solution to accurate timing
Not true. Timing is very accurate. And it is exactly what IRremote is doing, check it sourcecode before posting such.
> Marantz uses RC5 encoding
read my post, its using modified encoding NOT supported by IRremote. Also format on rc socket is a bit different, so to use this library i will need to hack it a lot anyway.
Only accurate timing if it isn’t interupted by something like serving the webpage, it’s fine if it’s a dual core esp32 but if it’s not it could cause problems occasionally. That might not even be an issue depending on the way the code is written though.
true, but in fact its not impacting at all in my tests. And again – this is exactly what IRremote is doing.
I hate wifi, what if you have to change wifi password? Which should be rotated.
Better practice is to leverage RADIUS with named users, something which is also supported by this board. I strongly prefer wires for reliability reasons, but some solutions really work best with WiFi. In the case of the OP, one might also have accomplished a similar solution with a LAN-to-Serial gateway as most Marantz gear also offers a 232 port for system control.
Sure is practical in a home environment.
You must be fun at house parties.
“hey dude, what’s the wifi password?”
“Just a second, let me access Access Directory to create an user for you… it’s quick…
I need your full name, real address, email, SSN, full set of fingerprints, and a face photo, front and side…”
LOL, I totally understand that reaction and I 100% agree. My point was simply that this kind of solution can be implemented reasonably securely if that’s what you like. Rotating passwords is fine but it’s not best practice for WiFi if security is your goal.
My guest wireless password is now my wife’s phone number, because it’s the only thing I could think of that she could not possibly forget, and which her friends probably already had written down in their phone.
you can use esp32 with eth hat if you want. Or implement command to rotate pw on device and store it in eeprom.
Does anyone remember Philips’ ESI Bus in 90’s hifi elements? I’d like to build something similar for the receiver model FR911 but can’t find any documentation about it. My skills on reverse-engineering are very limited.
I also own a Marantz amp which has a RS232 port. To control it i just added a MAX232 to an ESP-01, and hosted a simple web frontend on my NAS which sends commands and receives status messages over a websocket connection. Works pretty well. Was a pain to find the documentation for the serial protocol, though. Biggest advantage of this method is the possibility to receive status changes even if settings are changed directly on the amp. Next step will be implementation of a mqtt connection.
thats cool, yes, you can get a feedback. Mine does not have any serial connector, so it was only way w/o hw hacking
Anyone disappointed to not see a picture of the Marantz amp/receiver?
Here you are :) https://www.sbazar.cz/fsaudio/detail/144009015-marantz-pm-62
Just use OpenHab and global cache itach control devices, the software is all free. You can build itach like hardware of you want a pet project.