Back in the days, I updated most of my DCX to 1.17 and had no issues - and also no obvious feature addition... I remember some minor changes in the revisions of the hardware back then (aside from the obvious relaunches a few years back).... But I never encountered any reliable complete documentation on what exactly changed with which firmware exactly changed what (there is no official doc whatsoever - at least I never found one)..
Bottom line: If it works, don´t change it.
If its completely broken and you only have a more recent version to re-flash: Should work.
Remember: Reflashing the whole eeprom is a different story than using the software. If software RS232 fails - only a eeprom burner can help.
Important in any case: Do a reset after with the first power on of the device to force the unit to re-init everything and load defaults. Missing that step can lead to weird issues..
I had some complete dumps of 1.16 and 1.17 somewhere. Sent these out to douzens of peoples over the years and never got any problems reported back, seems to work....
Bottom line: If it works, don´t change it.
If its completely broken and you only have a more recent version to re-flash: Should work.
Remember: Reflashing the whole eeprom is a different story than using the software. If software RS232 fails - only a eeprom burner can help.
Important in any case: Do a reset after with the first power on of the device to force the unit to re-init everything and load defaults. Missing that step can lead to weird issues..
I had some complete dumps of 1.16 and 1.17 somewhere. Sent these out to douzens of peoples over the years and never got any problems reported back, seems to work....
That is rather what I'd concluded! thanks for the confirmation. 🙂 I have found that this new (older) model seems to run out of memory more readily and warn me to pull out settings compared with my recent ultradrive (in fact ive never had that message before)...I'm not doing anything very complicated with it..if anything less EQs and less channels. I had read somewhere on a jbl forum that the newer firmware addressed memory usage a bit but that's far from proven I suspect.
Since most units "just work", I suspect no one has taken up the effort to do a deep investigation of any changes and faults. Hardware showrtcomings like the ribbon cable issues or some timiming glitches (for PA usage more or less not important, but some hifi.guys did some modding to de.jitter the unit) have been adessed and are easier to pinpoint.
I do wonder if they did some better memory management in the later firmware. It's frustrating to get pinged for full memory without really stacking that many settings. I'm pretty sure my later dcx is better in this regard. I think I do have an OG computer with a serial port but maybe it's just too risky. 🙂
Maybe they changes something, It would be nice to have a changelog, but I have never encountered a reliable information about that..
Flashing via serial works - until you brick the device - then only reprogramming the Eeprom will help..
Remember to do a reset after flashing first time you power on (I THINK it was holding the page left/right buttons simulationiosly while powering on - but you better check here in the thread for confirmation..).
I rarely ran into memory shortages, over the years I put less and less processing on my speakers 🙂 But of course, if its needed and it doesn´t work... thats not how it should be..
good luck !
Flashing via serial works - until you brick the device - then only reprogramming the Eeprom will help..
Remember to do a reset after flashing first time you power on (I THINK it was holding the page left/right buttons simulationiosly while powering on - but you better check here in the thread for confirmation..).
I rarely ran into memory shortages, over the years I put less and less processing on my speakers 🙂 But of course, if its needed and it doesn´t work... thats not how it should be..
good luck !
Hi everyone,
I recognize that this topic is quite old, having been around for 20 years, yet every search I make brings me back here. Some insights from my side, could be of some help to someone:
TL;DR:
Let's begin the lengthy tale now. Fifteen Wireshark instances (don't ask) consumed all available RAM, causing the Linux OOM killer to terminate those windows, while DCX also stopped working at the same time. I have no idea what exactly happened; nevertheless, DCX has been bricked. The standard method of updating the firmware using a bootloader and RS232 was unsuccessful. I tried recovering it on both Linux (PL2303 USB-Serial) and Win10 (proper 16550 UART) and don't have anything like Win7 or XP or compatible at hand. Then I finally pulled out the T48 EEPROM programmer and made a backup dump of the A29040B EEPROM content. I did notice a relatively large segment of zeroes after the offset of around 0x10000. I did download all the available firmware updates from the product page and took a peek at them with HxD. Every single firmware update contains "heg_se" (0x 68 65 67 5F 73 65) in block 0x 2A-2F, except for version 1.18a.
Regarding the latest v1.18a firmware, it starts with something that resembles the bootloader from the dumped version 1.17, but it is definitely not the same code. Furthermore, the block "heg_se" starts at the offset 0x1002A.
So, it looks like the offset for the firmware update begins at 0x10000. I simply overran everything in a dump from that point on with the code from the 1.17 firmware update. Flashed the chip. Put it back in the DCX. Pulled it out again and turned it 180° since I put it in backwards 👍. I powered it on, and it booted properly. Settings also survived. Now that everything is ready for another bricking, I tried flashing it via RS232. Not working, bricked again. Then I went on with the directly flashing v1.18a update, file as-is on EEPROM. It worked. Boots. Buttons, knobs, LCD, LEDs reacting.
Left it on v1.18a. Still need to check if everything is operational as it should be. at least the stuff that I need (xover, delay, peq).
I recognize that this topic is quite old, having been around for 20 years, yet every search I make brings me back here. Some insights from my side, could be of some help to someone:
TL;DR:
- The DCX2496 (v1.17 with PCMCIA slot) was accidentally bricked - after flashing it to v1.18a via an EEPROM programmer, I lost the menu for storing settings on a CF card; however, since I don't have any CF cards, I couldn't test this feature anyway.
- Behringer's product page has fw v1.18 - it's full dump - just flash it as is onto the chip and it'll boot, at least mine did - still need to try it "acoustically", will update on this some time later
- bad fw v1.17 dumped from the eeprom and successfully recovered - just slap the content of a fw v1.17 bin file in the dump, but from the offset 0x10000
- tried reflashing recovered v1.17 via rs232 - still didn't work; reflashed it directly with 1.18 bin file and it's booting now
Let's begin the lengthy tale now. Fifteen Wireshark instances (don't ask) consumed all available RAM, causing the Linux OOM killer to terminate those windows, while DCX also stopped working at the same time. I have no idea what exactly happened; nevertheless, DCX has been bricked. The standard method of updating the firmware using a bootloader and RS232 was unsuccessful. I tried recovering it on both Linux (PL2303 USB-Serial) and Win10 (proper 16550 UART) and don't have anything like Win7 or XP or compatible at hand. Then I finally pulled out the T48 EEPROM programmer and made a backup dump of the A29040B EEPROM content. I did notice a relatively large segment of zeroes after the offset of around 0x10000. I did download all the available firmware updates from the product page and took a peek at them with HxD. Every single firmware update contains "heg_se" (0x 68 65 67 5F 73 65) in block 0x 2A-2F, except for version 1.18a.
Regarding the latest v1.18a firmware, it starts with something that resembles the bootloader from the dumped version 1.17, but it is definitely not the same code. Furthermore, the block "heg_se" starts at the offset 0x1002A.
So, it looks like the offset for the firmware update begins at 0x10000. I simply overran everything in a dump from that point on with the code from the 1.17 firmware update. Flashed the chip. Put it back in the DCX. Pulled it out again and turned it 180° since I put it in backwards 👍. I powered it on, and it booted properly. Settings also survived. Now that everything is ready for another bricking, I tried flashing it via RS232. Not working, bricked again. Then I went on with the directly flashing v1.18a update, file as-is on EEPROM. It worked. Boots. Buttons, knobs, LCD, LEDs reacting.
Left it on v1.18a. Still need to check if everything is operational as it should be. at least the stuff that I need (xover, delay, peq).
Since I said I would later update on the "acoustic" part of the DCX, updated to version 1.18a, it works. The sound is still rocking the same vibe, and the DSP's free resources are just the same. CX3400 is going back in the box until DCX has its next little hiccup 🙂
Just a quick note I missed in my last post: the officially released firmware v1.18a is a neat 524288 bytes in size, which happens to match the exact size of the space on the A29040B EEPROM. That’s why I decided to dig a little deeper before diving in and flashing it directly to the EEPROM! Naturally, this method did not preserve the settings from version 1.17.
The speakers used in nearfield for the PC are nothing special. A pair of Behringer 1C-BK modified so that the tweeter and midbass each have their own TPA3116D channel (at 20 dB gain) without their passive crossover in the way. For the subwoofer, there is an Edifier T5.
Just a quick note I missed in my last post: the officially released firmware v1.18a is a neat 524288 bytes in size, which happens to match the exact size of the space on the A29040B EEPROM. That’s why I decided to dig a little deeper before diving in and flashing it directly to the EEPROM! Naturally, this method did not preserve the settings from version 1.17.
The speakers used in nearfield for the PC are nothing special. A pair of Behringer 1C-BK modified so that the tweeter and midbass each have their own TPA3116D channel (at 20 dB gain) without their passive crossover in the way. For the subwoofer, there is an Edifier T5.
Last edited:
Nice to see that the ancient original models work with the latest firmware... AFAIR, 1.16 was the latest that was exactly for the older GEN1 Models - but having flasehd douzens to 1.17 and having no probs, it seems that 1.17 is safe on these dinosaurs.
Did you have a specific problem with 1.17? What was the reason to switch to 1.18?
Since the new models don't have the PCMCIA Slot anymore, it only seems reasonable that the function now is gone.
The only real issue I had was the FW update via a serial port. Unfortunately, I don't have anything remotely old enough to boot XP or even Win 7.
The assembly code difference in the bootloaders of 1.17 and 1.18 could be just another compiler/optimization. But when I find some time to fiddle around with the DCX, I will brick it via a serial port to see if I can recover it without T48. Or even try to downgrade it to 1.17 via serial. It is possible that the 1.18 bootloader includes some form of correction, but this is merely speculation. The issue very much reminds me of timing issues with codeplugs for old Motorola VHF/UHF radios, where I needed at most a 286SX AT-PC to get things going due to the software loop timings.
Serial connection needs only 5 wires (GND, RX, TX, RTS, CTS), the rest are not wired on the board. USB adapters that I have are either PL2303 or CH340 based. The FTDI version is on its way, as it has been a long time since I gave one to someone, and I'm not sure to whom. 🙂
The other reason for flashing 1.18 was that the official image inside appeared to be a complete EEPROM content, so I gave it a try.
The assembly code difference in the bootloaders of 1.17 and 1.18 could be just another compiler/optimization. But when I find some time to fiddle around with the DCX, I will brick it via a serial port to see if I can recover it without T48. Or even try to downgrade it to 1.17 via serial. It is possible that the 1.18 bootloader includes some form of correction, but this is merely speculation. The issue very much reminds me of timing issues with codeplugs for old Motorola VHF/UHF radios, where I needed at most a 286SX AT-PC to get things going due to the software loop timings.
Serial connection needs only 5 wires (GND, RX, TX, RTS, CTS), the rest are not wired on the board. USB adapters that I have are either PL2303 or CH340 based. The FTDI version is on its way, as it has been a long time since I gave one to someone, and I'm not sure to whom. 🙂
The other reason for flashing 1.18 was that the official image inside appeared to be a complete EEPROM content, so I gave it a try.
As I recall, most of the information for enhancing the sonic performance of the DCX is derived from research similar to that on the DEQ2496 discussed in this post:
In essence, replacing the X5R/X7R and possibly electrolyte capacitors in the audio path with NP0 or poly eliminates the majority of the distortion. I don't remember coming across a specific inexpensive mod topic just for the DCX, only ones where whole analog boards have been replaced.
Yes, it's noisy, but that noise can be mitigated. If there is no ground loop noise or improper unbalanced connections, the problem is in the gain distribution in the chain, aka gain staging. I don't know what equipment you're using with the DCX, but you might have too much gain at the power amplifier. You can check that:
Nominal levels are intended for full-blast signals without clipping/saturation, not for quieted signals. The goal is to maintain a signal level of +4 dBu, or +10 dBu in this case, throughout the entire chain leading up to the amplifier. Then set the amp to the targeted maximum listening level. You need to at least light up that first LED for -40 dB on the DCX input when listening at normal levels.
My chain, for example: Behringer UMC404HD (main out volume at max) - balanced connection - FBQ2496 - balanced connection - DCX2496 - 4 balanced connections to modified bare TPA3116 boards from AliExpress (BTL, 20 dB gain) for tweeters and midbass-mid (Behringer 1C-BK), and one unbalanced connection to the Edifier T5. I've set the DCX input gains to 0 dB and adjusted the output levels from -11 dB to -13 dB. I'm planning to level that out with some 10 dB attenuators. The tweeter emits a slight noise, but it becomes inaudible from a distance of a few centimeters away.
- Volume down and power off the power amp. Disconnect it from the DCX. For unbalanced input, short the hot side to ground. For balanced input, short + and - (XLR pin 2 and 3, TR on TRS jack).
- Power it on, and the noise that you hear from the loudspeaker is the amplifier's internal noise. It should be faint.
- Play around with the amplifier's volume control. There shouldn't be much difference in the noise level between the min and max positions, but it depends much on the amplifier's quality. Power off the amp.
- Mute all DCX's inputs and outputs. Don't play anything to its inputs yet. Connect the amp, power it on, and check if there is a noticeable difference in noise at some medium volume settings. If the amp produces a lot of noise, it likely belongs to the consumer equipment category. You need to reduce the amp's gain/sensitivity to drop the noise down. If you have crackling, that could mean opening the DCX and reseating the connector for the ribbon cable between the main and analog boards.
- Unmute outputs, noise level shouldn't change.
- Unmute inputs, if nothing is playing noise level could increase, but not by much. Now you're listening full chain with no signal, just a noise floor.
- If it's still noisy so much that bothers you, you'll need to change something in the chain.
Nominal levels are intended for full-blast signals without clipping/saturation, not for quieted signals. The goal is to maintain a signal level of +4 dBu, or +10 dBu in this case, throughout the entire chain leading up to the amplifier. Then set the amp to the targeted maximum listening level. You need to at least light up that first LED for -40 dB on the DCX input when listening at normal levels.
My chain, for example: Behringer UMC404HD (main out volume at max) - balanced connection - FBQ2496 - balanced connection - DCX2496 - 4 balanced connections to modified bare TPA3116 boards from AliExpress (BTL, 20 dB gain) for tweeters and midbass-mid (Behringer 1C-BK), and one unbalanced connection to the Edifier T5. I've set the DCX input gains to 0 dB and adjusted the output levels from -11 dB to -13 dB. I'm planning to level that out with some 10 dB attenuators. The tweeter emits a slight noise, but it becomes inaudible from a distance of a few centimeters away.
