DEQ2496 firmware hacking

Hi all,

I'm new to this forum so not sure if this is the sort of thing that interests anyone here.

I've recently repaired a Behringer DEQ2496 due to a failed power supply (bad caps and a failed TOP245 switching controller) and while I had it in pieces I decided to finally write a program to communicate with it over MIDI as I had been meaning to do for many years.

It turned out that Behringer's SysEx document for the DEQ2496 is mostly wrong when it comes to the firmware, so it look a bit of reverse engineering and disassembly but I finally got the unit to accept messages from me:

deq2496.hello_world.jpg


The code is written in NodeJS and is available on GitHub if anyone is interested. It's still incomplete at the moment but I hope to add a few more features to it. Contributions are welcome if anyone wants to add support for other devices!

It's been a bit of an adventure getting this far, figuring out all the undocumented things. The data blocks you send to the device are encrypted with the string "TZ'04" (I'm guessing the initials of one of the developers), and the 7/8 coding and "CRC" algorithms mentioned in the SysEx manual aren't widely used or documented anywhere. But after a few days of trial and error I got it to work!

There are hints in the firmware that there might be a few undocumented SysEx functions (mostly technical) and there seems to be a hidden hardware test mode that I'd like to figure out how to activate, just out of curiosity. Apparently (from the messages I found) it's got something to do with adjusting the VR1 potentiometer on the main board.

My goal is to see if I can get the unit to run my own firmware, just for the fun of it. I could never hope to reproduce the functionality of the official firmware, but it always struck me that the device seems under utilised, with all those extra push knobs and buttons that duplicate functionality. Perhaps if I get all the pieces in place, someone else might end up creating their own firmware for it. Apparently there are ports of Linux that run on the Blackfin processors used by the device, so although it would be completely pointless, part of me wants to get Linux to boot on it just to see if it can be done :D (might be a bit tight though as it only has 2MB of RAM.)

Let me know if anyone is interested in this sort of thing and I'll post updates if I have any successes.
 
  • Like
Reactions: 1 user
Well actually it started because I realised if my DEQ2496 died and I had to get a replacement, I'd lose all my presets which would take forever to recreate, and I'd never thought to back them up. So I wrote the tool to do that originally, and then discovered that the device doesn't send you the full preset, as it cuts off the end of the data, so you can't get a complete backup.

I also implemented the function to grab a screenshot since it looked simple, and I discovered that it too truncates the data and omits about a third of the final row of pixels.

So I contacted Behringer to report the bugs and they said thanks but no promises. I asked if they could pass a message onto the devs about the SysEx stuff as by then I was trying unsuccessfully to get the LCD message to appear, and they politely told me to, well, bugger off as it's proprietary and protected by patents.

Of course as everyone knows, being told you can't do something because of a silly reason is a great way to get it to happen (what's the point of withholding the information if it IS protected by a patent? That's the whole point of a patent!), so here I am now a couple of days later with the issue mostly solved except for one last bit (a final layer of encryption that so far eludes me).

While doing all this stuff I realised that the unit is pretty nice for hacking, and set up to make it difficult to brick (actually impossible to brick if you have an EEPROM programmer) so it got me even more interested than when I started!

Ironically if Behringer support had just given me the info I was after I'd have backed up my presets now and probably would've moved onto the next project...
 
Well I've continued to have some success. I have now fully reverse engineered the firmware flash algorithms, so I can now flash any data I like into any part of the flash chip I want. I found where the boot logo was stored and tried replacing it, which worked well:

deq2496.new_bootlogo.gif

(if it doesn't animate, have a look at the original)

I've also been able to fully decrypt the firmware, so I could run both the bootloader and the application through a Blackfin disassembler, to turn them back into a sort of assembly language. (It was by reading this disassembly that I was able to find out how the decryption algorithms work.)

I have only just started examining the application firmware but I've already found there is an undocumented SysEx function 0x62 which isn't included in the manual. I haven't yet figured out what it does, but it appears to send a SysEx response if you feed it the correct parameters.

Anyway still a little of my own code left to clean up but I will soon publish instructions on the DEQ2496 documentation page in the GitHub repo explaining how to replace the boot logo for anyone else who would like to have a go at customising their DEQ2496.
 
Last edited:
Watching with interest.

I have a DEQ2496 (original 1.x hardware running 1.4B I think) and I have always wanted to remote control it via MIDI, as it would make A/B testing of EQ changes from the listening position possible. (without long analogue/power cables...)

However the MIDI command set is so poorly documented that I gave up writing something like this myself and the only remote control software I've found doesn't seem to work for me. (Maybe it needs 2.0 hardware)

Regarding backup/restore - I vaguely rememeber doing this successfully with a piece of generic MIDI software that supported SysEX capture/restore, but it was a long time ago now and I have no idea what that software was now. From memory it was a full system configuration dump and restore, not just individual presets, but that was good enough for me as a "backup". (However in 16 years I have never lost any of the presets or configuration)

Interesting about the power supply failure - I bought mine around 2004 and after only about 3 years the power supply blew up, it turned out to be the main rectifier diodes, however I also found a loose screw wedged under the power supply board! (So I suspect the screw shorting against the bottom of the PCB was the original cause of the blown diodes)

About a year ago I replaced the input bypass relays as one of them had intermittent high contact resistance which had gradually got worse over a few years which caused the right channel to be slighly down in level (about 0.5dB) vs the left in active mode, but only sometimes. Toggling bypass a couple of times would fix it for a short time, typical of oxidised relay contacts.

Since I replaced the relays that problem is gone and the unit is back to full health. Not too bad really for 16 years from "inexpensive" hardware. At the time I bought it there was nothing even remotely in its price range with the same functionality.
 
Last edited:
Interesting. Let me know if you try the code and if you have any success.

As far as I can tell, the MIDI interface between v1 and v2 hardware should be the same. Reading between the lines, I am wondering whether the CPU in the v1 hardware may have gone end-of-life and they had to pick a different one, which led to the v2 hardware. But there's not much info available so without access to one myself I'm only guessing. The only bit of doco - the Behringer SysEx guide - appears to have been written for the v1 device and not updated with the changes made when v2 came out.

The v1 firmware is encrypted with a slightly different key (TZ'02 instead of TZ'04) and the data offsets are slightly different but I added support for v1 as best I could based on the v1.4 firmware image I found online. This doesn't include the bootloader though, which makes reflashing a bit risky as there's no way to restore the chip with an EEPROM programmer in the event that you accidentally tell it to overwrite the bootloader.

If you happen to have an EEPROM programmer and feel like taking your DEQ2496v1 apart, feel free to send a dump of the ROM my way.

Otherwise as long as you stay away from the flash functions, the rest of the code should work. I think the function that writes a message on the LCD won't work as this is sent as a flash write to a magic memory address, which means it has to be encrypted with the proper key which varies between hardware versions. (Or may not even be encrypted on v1 hardware - one of the things I am unsure of and can't test.)
 
Hi Malvineous, Very interesting thread.
I own a DEQ2496, just updated from 2.4 to v2.5.
My target is to get a remote software, at least to load and save memories, and if i can adjust the PEQ will be perfect.
Not sure if you know Simon´s remote software: http://www.seoman.nl/deq2496/DEQremote.html
Unfortunately, Simon created it years ago under WinXP and DEQ v1.4. My v2.5 unit crashes this software.

Then I discovered Ctrlr, https://ctrlr.org/
It´s very nice software, promising. Unfortunately, there is no "plane" done for the DEQ2496 so someone needs to do it first.

To be honest, I have no idea about midi and music. I am coming from electronics and radio world, although I can code/understand small pieces of software.

And today I discovered this thread.
I can see in Github the software. It looks Java. Not sure if it runs under Win10 ??

I´ll give a try.
Happy to collaborate if needed.

Cheers.
Maximo
 
Last edited:
How easy is it to transfer curves from the likes of REV into a deq.
Unless someone writes some software to convert them and upload them via MIDI then it's going to be a manual process.

It supports both graphic equalisation and parametric equalisation.

The parametric equaliser has 10 bands, each one has an adjustable centre frequency, Q and amplitude. It also supports 6dB/oct and 12dB/oct shelving functions, and also a low cut / high cut 12dB / octave filter. (I use it for a rumble filter)

To be honest I don't really use the graphic equaliser or many of the other features like the dynamic range compressor/expander, stereo width enhancer, etc I use the parametric equaliser.
 
Mal thanks for sharing your work and please keep this thread alive. There is much untapped potential down this road. I’m sure of it. Firmware hacking skills are a rare thing indeed here on Diyaudio. The deq holds much untapped potential.

What improvements could be made to this unit via firmware.
 
Hi all,

Sorry for the late response, didn't get notifications of the replies!

@dennt If the unit is awake enough to ask for a firmware update then you should be able to send that MIDI file as normal. It updates the 'application' part of the EEPROM but leaves the 'bootloader' part alone. The bootloader part is the bit that is asking you to upload the firmware so that part seems to be ok. [EDIT: missed you have already done this, see my next post]. There is no way I know of to download the whole EEPROM (including bootloader) unless you remove the chip and put it in an external reader, so if anyone out there has a DEQ2496 v1 and an EEPROM reader it would be good to get a full firmware dump of it, as I only have a v2 device.

@EA1DDO Yes you can run my code on Windows but I haven't tried it so I'm not sure how the MIDI support works. You'll have to download and install NodeJS first, then I believe you can just run the 'npm' commands listed in the Readme. If they don't work let me know and I'll do my best to help.

I chose to write the code in NodeJS as historically I've written everything in C++ but cross-platform compatibility was a nightmare. Since JS can run inside a web browser it means that potentially the whole thing can be ported to a browser one day (pending WebMIDI compatibility) so you won't even have to install anything, you can just visit a web page and grant it access to your DEQ2496, which would be nice.

Thanks for posting the response from Behringer about the SysEx document. Clearly their engineers and support people aren't talking as there are quite a few differences between the versions!

@sumilux Transferring presets will not be easy at present as all we can do is dump and load the binary data, so backup and restore is all it's good for. Someone will have to reverse engineer the binary format (not hard just time consuming) before we can convert the binary data to some text format that is easier to edit external to the device. Of course most of the values are already available as MIDI controllers so I guess you could program them in that way already.

As to what you can do with custom firmware, there is plenty of space left over in the EEPROM, the question is whether you try to hack in extra functions to the existing code (messy and difficult) or rewrite your own firmware from scratch, ditching what the unit currently does and reimplementing it with your own code. This is the most flexible as you can easily add and remove features, but it requires someone to code all the existing functions from scratch before the unit is usable again. I don't mind rewriting the UI/menus/etc. but I have no experience with DSP programming so I wouldn't be able to reimplement the EQ or any of the other functions. I could probably do a white noise generator but what good is that :)

Some features I would like to see are the ability to mix multiple inputs instead of only being able to select one input at a time, and having multiple signal paths through the device. There are three inputs and four outputs, so it would be nice if you could at least process four channels at once and not be limited to stereo. I also wouldn't mind being able to reassign some of the buttons I don't use, so for example being able to change the 'GEQ' button to instead toggle between two PEQ presets, or something like that.

@marconi118: If the DCX2496 uses the same platform then it's possible but I don't have access to one to test. You can probably try the code as-is, so long as you don't use the functions that flash firmware then there's little risk of breaking anything. But the DEQ2496 v1 and v2 use different encryption keys so I imagine the DCX might too, which may prevent it from responding to any messages the code sends.
 
Last edited: