Platform index / Amplifier control network
d&b audiotechnik Remote network — dbCAN, the R70 and R60 interfaces, and OCA
d&b's amplifiers have two remote-control worlds, and R1 drives both. The older one is dbCAN, an 11-bit CAN bus at a fixed 100 kbit/s, reached from a computer through the R70 Ethernet gateway or the R60 USB one. The newer one is AES70 / OCA over TCP. The CAN world turns out to be mostly somebody else's published protocol in a d&b case. What is not published anywhere is the amplifier layer on top of it, and the OCA object map beyond gain and mute.
The load-bearing finding. The R70 is an RM Michaelides (now Proemion) CAN gateway in a d&b case: R1 lists interfaces by MAC address, and the R70's MAC sits in RM Michaelides' IEEE address block. So its network side is RM's published RM Byte Command Protocol on TCP 30000, and it interprets nothing it carries. The one undocumented exchange is R1's discovery on UDP 33333, a 68-byte packet. Above the gateway, R1 writes amplifier parameters as four bytes (02, a channel, a parameter and a value), and one bench session with two D20s has named four of them.
Verdict. Two protocols wearing one badge. The CAN side is far more open than it looks from outside: the gateway is somebody else's published protocol, the bus is in d&b's own technical information, and the one undocumented exchange, discovery, is a 68-byte packet that R1 takes from any device that answers in the right shape. An open gateway built from those documents now drives real amplifiers. The amplifier layer above the gateway is the unpublished part, and one bench session has named only four of its parameters. The OCA side has the mirror-image problem: a public standard for the transport, a public handful of object numbers, and nothing tested here on hardware.
Method
Four bases, kept apart. First, d&b's own published documents (the R70 manual 1.4 and software reference 1.3, and TI 312 d&b Remote network 1.4), the source of every public row on ports, the dbCAN identifier layout and the physical layer. Second, RM Michaelides' published RM Byte Command Protocol, identified as the R70's transport from the R70's MAC address block and from a control-for-control match between the R70's web interface and the command set. Third, captures of R1 V3.46 talking to a software emulator of the gateway (July 2026), which gave the discovery packet and R1's initialisation before any hardware existed. Fourth, a bench session on 2026-10-28 that put R1 3.46.1 on a real dbCAN bus with two D20 amplifiers, through our own open gateway, CANary, which implements the R70's published side and nothing else. The amplifiers were not ours, so nothing on this page is labelled measured: the bench rows are verified, read from that session's retained capture and its timestamped log of what was pressed when, and checked against the amplifiers' front panels. The OCA rows come from the AES70 standard and from public controller code, and none of them has been tried against an amplifier. No R70 or R60 was ever in our hands, and no d&b or RM Michaelides firmware was opened.
Artifacts examined
- R70 Ethernet to CAN interface: Manual 1.4 EN and Software reference manual 1.3 EN, and TI 312 d&b Remote network 1.4 EN, d&b audiotechnik; published on dbaudio.com and not redistributed here
- RM Byte Command Protocol: API description, RM Michaelides Software & Elektronik GmbH
- The IEEE IAB registry entry
00-50-C2 / 5DC000-5DCFFF, registered to RM Michaelides - Captures of R1 V3.46 ↔ a software gateway emulator (2026-07-22), and of R1 3.46.1 ↔ CANary board #1 ↔ two D20s (2026-10-28, an hour, 87 MB), with the bench's timestamped mark log; retained as
.pcap - CANary:
github.com/stoatworks-labs/canary, our own open gateway, whosedocs/PROTOCOL.mdtags every claim by source
No manufacturer firmware, binaries or documentation are redistributed here. Artifacts are referenced by name and version only. See the method and legal statement for the basis on which this analysis was performed and the boundaries it observes.
Hardware architecture
| Item | Finding | Confidence |
|---|---|---|
| The R70 is not a d&b design | R1 lists CAN interfaces by MAC address, and the example in the R70's own manual, 0050C25DC0BE, falls in IEEE Individual Address Block 00-50-C2 / 5DC000-5DCFFF, registered to RM Michaelides Software & Elektronik GmbH of Fulda, now Proemion. The R70's web-interface controls (Block Time in 10 ms units, Online Timestamp, four TCP-or-UDP sockets, mask and arbitration filters) each match a command in RM's published protocol | Verified |
| R70 hardware | 16-bit microcontroller, 10/100 Ethernet, powered by 802.3af PoE or 10–30 V DC at 330 mA, galvanically isolated CAN on two RJ45s wired in parallel, −40 to +50 °C | Public |
| The R60 | d&b's USB-to-CAN interface. Most likely RM Michaelides' CANview USB class of gateway in a d&b case, as the R70 is their Ethernet one: an R60 owner reported on CANary's issue tracker that its serial framing is RM's (43 | length | payload | XOR | 0D, checked on 249 captured frames). No R60 has been seen, captured or opened here | Inferred |
| Bus wiring | On d&b's RJ45: pin 4 CAN_H, pin 5 CAN_L, and CAN ground on the cable shield, so shielded connectors are mandatory. CiA D-SUB9 equivalents are pins 7, 2 and 3. Two RJ45s per device, in parallel, for daisy-chaining | Public |
| Bus limits | 120 Ω at both ends (d&b's Z6116 RJ45 terminator). 600 m at 100 kbit/s, stubs up to 30 m each and 150 m in total, up to 100 nodes a segment and 504 amplifiers in all through repeaters. Cable: shielded twisted pair, 100–120 Ω — Cat5 F/STP, AES/EBU or DMX 110 Ω, DeviceNet | Public |
| The E-PAC grounding exception | E-PAC amplifiers with serial numbers up to 3170 do not link CAN ground through their RJ45s. Mixed with D6 or D12, the first device on the bus has to be a D6, a D12 or a later E-PAC | Public |
| One amplifier, both planes | The D20 answers on dbCAN (two units, firmware V2.30.00, on both of CANary's CAN jacks with zero bus errors) and carries Ethernet for OCA. That makes it a useful test amplifier and the wrong proof for a CAN gateway: the amplifiers that need one are those with no other way in | Verified |
Software architecture
| Item | Finding | Confidence |
|---|---|---|
| Two control planes | dbCAN is CAN 2.0A, layer 2, 11-bit identifiers, 100 kbit/s fixed. The current range is controlled over AES70 / OCA (OCP.1 over TCP). R1 V3 speaks both, and reaches dbCAN only through an R70 or R60 | Public |
| dbCAN identifiers | Bits 10–9 object class (0 primary master, 1 secondary master, 2 process data from a device, 3 stream objects), bits 8–6 subnet 0–7, bits 5–0 device 1–63 with 0 broadcasting into the subnet. Written subnet.device, e.g. 1.02. Object class outranks device in arbitration. Up to two masters | Public |
| The gateway interprets nothing | "No direct protocol interpretation is implemented" in the R70: it is a transparent bridge, and it does not know what an amplifier parameter is. Everything d&b-specific travels inside the CAN frames, between R1 and the amplifiers | Public |
| Gateway framing | RM Byte Command Protocol: 43 | length | command | data | checksum | 0D, where length counts the command and data bytes and the checksum is the XOR of everything from 43 to the last data byte. Command 00 is an 11-bit CAN frame (2-byte ID, MSB first, then up to 8 bytes; DLC is implied by the length), 01 adds a 32-bit timestamp, 02/03 are 29-bit. 40 device ID, 41 versions, 47 bus load, A3 the block time. The spec's two worked examples reproduce exactly | Public |
| Gateway ports | TCP 30000 for data (adjustable), UDP 33333 for discovery (fixed). Default 192.168.1.70 with DHCP on, host name db-70, web configuration on port 80. Four sockets, each TCP or UDP, server or auto-connecting client. R1 handles up to five R70s at once | Public |
| Discovery | R1 broadcasts one probe per local interface to UDP 33333: a 4-byte header (byte 0 the interface index, byte 2 the opcode, 80 for a request and 00 for an answer, byte 3 a record count) and 64-byte records. A record carries the IPv4 address and port big-endian, a service and a protocol byte, the MAC, the ASCII tag R70 at offset 14 and a NUL-terminated host name at 36. The probe is one template record with only the tag filled in, and the answer has the same shape. R1 then lists the interface by host name, protocol, service and port joined with hyphens, e.g. CANary-UDP-CLIENT-30000 | Verified |
| Discovery accepts anyone | R1 listed, connected to and drove amplifiers through a gateway answering from its own MAC address, outside RM Michaelides' block, and the July emulator was accepted the same way. Nothing in the exchange identifies a genuine R70. Where broadcasts cannot reach, R1 V3 has a Dedicated R70 addresses list that skips discovery altogether | Verified |
| R1 opening the gateway | On the bench R1 sent 44 (interfaces version), 41 (versions), A4 03 E8 (bus-load interval, 1000 ms) and 57 FE (CAN at 100 kbit/s, matching the RMBCP baud table), with no reset. After the gateway restarted it sent 44 41 A4, waited 6 s, then C0 (reset) and 44 41 A4 again, and expected a 40 device ID after the reset. In an hour it sent no 42 (error status), no 47 (bus load) and no 58 (CAN reset). 57 and the bus scan only start once R1 is Online | Verified |
| The bus scan | Online, R1 acts as secondary master and sends the device-ident request 00 01 to every subnet's broadcast address, 0x200, 0x240 … 0x3C0, roughly every 35 s. Each amplifier answers from object class 2, so device 1.02 answers on 0x442 | Verified |
| The ident answer | 00 db 00 10 09 00 bc xx from 1.02 and … bb xx from 1.03. The penultimate byte told the two amplifiers apart. The last byte changed from one scan to the next and was the same in both amplifiers' answers to the same scan (c6, 73, ff, ec, cd …). Recorded, not interpreted | Verified |
| The write form | R1 writes to 0x240 + device (secondary master, subnet 1) as 02 cc pp vv…, channel, parameter and value, and the amplifier's replies to R1's polling carry 01 in the first byte. Channel bytes 22, 42, 62, 82 are A to D; device-wide parameters use group 01. R1 polled each channel about every 0.57 s, about 180 frames a second for two amplifiers, which R1 reported as 31 % bus load | Verified |
| Parameters named so far | 05 mute, one byte (01 muted). 06 gain, 16-bit signed in 0.1 dB (00 05 is +0.5 dB; R1's own step is 0.5 dB). 14 loudspeaker setup (00 30 on channels set to T10 PS, 00 03 on Q-SUB). Device group 01, parameter 11: output mode (05 Mix TOP/SUB, 00 Dual Channel). Each was named from the action it followed in the bench log and agreed with the front panel; one session, one amplifier model, one firmware | Inferred |
| Adding an amplifier writes to it | Leaving R1's Edit mode after adding the amplifiers to a project, R1 asked whether to apply the changes and then wrote each channel's setup, the output mode and device parameters 0f, 1b, 24 and 01 to both units. Every value that had been read beforehand went back unchanged except device parameter 01, written 01 where both amplifiers had reported 00. Nothing visible changed | Verified |
| OCA transport | AES70 OCP.1 over TCP: sync byte 3B, a 16-bit protocol version of 1, a 32-bit PDU size counting everything after the sync byte, a PDU type (0 command, 1 command expecting a response, 2 notification, 3 response, 4 keepalive) and a message count. Big-endian throughout; strings, blobs and lists carry 16-bit length prefixes. Subscriptions go through the subscription manager at object number 4 | Public |
| OCA port | TCP 50014 is the documented default for d&b's DS100 signal engine. That the amplifiers listen there too is the assumption our own client and public controllers work on, and it is untested here | Inferred |
| OCA object numbers | d&b packs a tuple into each 32-bit object number: type (4 bits), record (8), channel (5, A = 1) and box-and-object (15), so channel A's gain is 0x10008206 (mute 0x205, gain 0x206). Gain runs −57.5 to +6.0 dB in 0.1 dB steps, the same resolution the CAN write uses. Read from d&b's own integration modules and public controller code; EQ, filter and CPL object numbers are not published anywhere | Inferred |
Update path & security model
| Item | Finding | Confidence |
|---|---|---|
| Neither plane authenticates | RM's protocol has no login, challenge or credential: anything that reaches TCP 30000 can put any CAN frame it likes on the amplifier bus, and an R70 by its own documentation will carry it. CAN 2.0A has no notion of a sender. R1 accepts a gateway on the strength of a discovery answer alone. Control-network isolation is the only protection the CAN plane has | Public |
| Two masters, by convention | dbCAN allows a primary and a secondary master, and R1 takes the secondary role by default (its own preferences call secondary "recommended"). The roles are object-class bits in the identifier: arbitration priority, not access control | Public |
| OCA access control | Not examined. Whether d&b's amplifiers offer AES70's secure transport or any credential on the OCA port is unknown here, and is not assumed either way | Unknown |
| Firmware updates | R1's own help says a firmware update resets the device to factory defaults. No d&b or RM Michaelides firmware image has been opened, so nothing is established about packaging, checksums or signing | Public |
These rows describe how a platform validates a firmware image, because that is a structural fact about its architecture. They are not a vulnerability disclosure and no exploit, bypass or circumvention technique is published here. Licensing and entitlement mechanisms are out of scope throughout — seescope boundaries.
What is programmable
- 1The gateway — and all of it is published
RM's protocol, d&b's identifier layout and the physical layer are documented, and the only undocumented step, discovery, is a 68-byte UDP exchange that R1 accepts from any well-formed answer. An open gateway built from those documents and from captures, CANary, has had R1 drive two real amplifiers through it. None of that needed the amplifier layer, because the gateway never touches it.
- 2The dbCAN amplifier layer — R1 is the oracle
Press one thing in R1, note the time, read the frame. One session has named mute, gain, loudspeaker setup and output mode on a D20. The cheap next step is the same method across EQ, delay, input routing and the CAN-only amplifiers, and the expensive one is anything R1 never writes.
- 3The OCA object map beyond gain and mute
AES70 objects describe themselves (class identification and role are standard methods), so a device can be asked to enumerate its own map rather than having it guessed. Our own sweep tool for that exists and has never been pointed at an amplifier.
- 4The R60
The framing is reported and the commands are RM's, but how R1 recognises an R60 and what one answers have not been captured here. An owner has offered captures.
Third-party open projects
Independent open-source work on this platform, recorded because it is prior art and because in places it confirms or corrects findings above. These are other people's projects: the descriptions are ours, the work is theirs, and nothing from them is reproduced here.
NanoOcp
A small C++17 AES70 / OCP.1 client and server library with no dependencies, carrying object definitions for d&b's amplifiers (Dx, Dy, 5D) and the DS100. The best public reference for which object numbers d&b uses, and for the OCP.1 wire offsets.
- OCP.1 only, by its own description: no object database, no root-block enumeration and no claim to full standards compliance.
- Covers the gain, mute, power, status and metering objects. Like every other public source, it has nothing for EQ, filters or CPL.
- Licensed LGPL-3.0 according to GitHub's licence detection; some of our own notes have it as GPL-3.0. Read it for facts either way.
Licence note: this project is LGPL-3.0. Facts about them — part numbers, what boots, what does not — are not copyrightable and are recorded freely. Their source is not a source for our own differently-licensed work, and no code from them is used in it.
Traps
Mistakes this analysis actually made, or came close to making. They are recorded because each one produces a plausible-looking wrong answer rather than an obvious failure.
- Reading R1's interface label as a bug. R1 lists the gateway as
…-UDP-CLIENT-30000while it only accepts TCP, and a second emulated gateway with different service and protocol bytes made R1 printTCP-SERVERinstead — which looked like proof the first was wrong. It went on the list to fix. Then R1 connected to the "wrong" one over TCP and drove two amplifiers through it. The label is R1's business; the bytes stay as they are. Verify a discovery change by connecting, not by reading the label. - R1 must be Offline to activate an interface. The checkbox that enables a discovered gateway cannot be ticked while R1 is Online, and the bus scan only starts once it is Online again. A gateway that is found and never used reads exactly like a broken discovery answer, and cost a long detour through the wrong layer.
- Answering an ident request with anything plausible. A virtual amplifier that echoed
00 01back was accepted off the wire and then rejected: after two scans R1 sends a reset and starts the gateway's initialisation again, which looks like a gateway fault and is the device's payload. - Resynchronising on
43or0D. Both are ordinary CAN payload bytes and RM's framing has no escaping, so a decoder that hunts for start or end bytes corrupts the stream. Only length, checksum and end byte agreeing together mark a frame, and several frames share one TCP segment whenever block time is in use. - Assuming R1 will reset a stuck gateway. RM's protocol has a CAN-controller reset (
58), and a gateway that waits for it after its controller goes bus-off waits forever: R1 sent none in an hour, including after the CAN cable was pulled and refitted. Ours stayed deaf for nine minutes until it was restarted. A gateway has to recover its own controller. - Trusting the Mac's routing on a link-local bench. macOS sent
255.255.255.255and169.254.255.255out of Wi-Fi rather than the USB adapter the gateway was on, and a VRRP router on the Wi-Fi answered ARP for link-local hosts, so even unicast TCP to the gateway went to the wrong interface. A healthy gateway looked dead to R1 and to our own tools until every socket was pinned to the right interface and R1 was given a dedicated address. - Reading R1's Remote view in the wrong mode. Controls are live only in Tuning mode. In Configuration and Show mode the view is the design layout and every mute button is red, because red is the mute control's default colour, so a screenshot reads as every channel muted. And leaving Edit mode writes the project to the amplifiers.
Open questions
- What the ident answer's bytes mean:
00 db 00 10 09 00and then a byte that differs per amplifier and a byte that changes every scan but agrees across amplifiers. - What device parameter
01is. R1 wrote it from00to01on both amplifiers when they were added to a project, and never read it back. - Everything else on the CAN plane: EQ, delay, CPL, input routing and metering have not been seen on the wire.
- Whether the CAN-only amplifiers (D6, D12, E-PAC) use the D20's write form and parameter numbers. An owner's D12 answered at the addresses the identifier layout predicts (
0x201/0x401), which settles the addressing and nothing else. - One reply from 1.03 reported channel A muted, among forty saying channel B was. Nobody touched A. A single frame, and unexplained.
- Stream objects (object class 3), and anything that uses the primary-master role: neither appeared in an hour of R1.
- Whether d&b's amplifiers serve OCA on TCP 50014, and whether the published gain and mute object numbers hold on current firmware. Nothing on the OCA plane has been tried against an amplifier here.
- How R1 recognises an R60, what a real R60 answers to R1, and which way round its 32-bit timestamp is sent. RM's specification does not say, and R1 ignores the value.
Status of this entry. Substantial findings recorded, but whole subsystems remain unexamined. Nothing on this page has been verified against physical hardware — no unit of this platform has been opened, connected to or modified.