Some changes and issues for a system chaining several D220 PRO

[pisabell2]

After successfully starting the Devimote program in an attempt to control a D220 PRO master which drives two D220 PRO slaves, I noticed that the Devimote interface was not being updated correctly. Using Wireshark for monitoring the status packets sent by the Devialet, I managed to trace the problem to a minor difference in the structure of the those packets wrt to those expected by my current Devimote. Basically, the Devialet packets turned out to be somewhat larger, because they were making allowance for a larger number of different sources (15 instead of 8), perhaps because my setup involves chaining several amps.

After I modified my Devimote code to account for that particular change, the status updates turned out to perfectly understood and correctly displayed in my Devimote interface. I will be happy to document that change or to provide my modified version if anyone is interested.

However, at this point in time, I am still struggling with two other problems. The first one is reported below, while I will open a separate issue for the 2nd one.

My first problem is that there also appears to be a small change in the command packets that the Devialet is expecting. Basically all the commands sent by Devimote to the Devialet are working OK, except those for selecting the first four of my seven different sources. In the Devialet command packets, the source selection is encoded by a specific pair of consecutive bytes, but at this time I do not understand by what logic particular pairs of bytes are supposed to relate to particular sources. In the Devimote program the mapping between the pair of bytes and the sources is determined using a calculus that I do not understand:

        out_val = 0x4000 | (output << 5)
        data = bytearray(142)
        data[6] = 0x00
        data[7] = 0x05
        data[8] = (out_val & 0xff00) >> 8
        if output > 7:
            data[9] = (out_val & 0x00ff) >> 1
        else:
            data[9] = (out_val & 0x00ff)

It is the value of bytes 8 and 9 that is expected to select a particular source. However, as it happens, the above calculus does not provide the correct values for my first four sources, as can be seen by comparing the (correct) bytes sent by my Devialet Android app with those sent by Devimote:

# Change source CMD packets, first 10 bytes, as numbered from 0

44 72 00 2c 00 16 00 05 00 00  (source 0-Cinema, Android app)
44 72 00 04 00 02 00 05 40 00  (source 0-Cinema, devimote)

44 72 00 30 00 18 00 05 3f 80  (source 1-lp12, Android app)
44 72 00 9c 00 4e 00 05 40 20  (source 1-lp12, devimote)

44 72 00 34 00 1a 00 05 40 00  (source 2-upnp, Android app)
44 72 00 a0 00 50 00 05 40 40  (source 2-upnp, devimote)

44 72 00 39 00 1c 00 05 40 40  (source 3-Roon, Android app)
44 72 00 a4 00 52 00 05 40 60  (source 3-roon, devimote)

44 72 00 3c 00 1e 00 05 40 80  (source 4-Airplay, Android app)
44 72 00 a8 00 54 00 05 40 80  (source 4-airplay, devimote)

44 72 00 40 00 20 00 05 40 a0  (source 5-Spotify, Android app)
44 72 00 ad 00 56 00 05 40 a0  (source 5-Spotify, devimote)

44 72 00 44 00 22 00 05 41 60  (source 14-Air, Android app)
44 72 00 b0 00 58 00 05 41 60  (source 14-Air, devimote )`

The last two bytes must be as in the Android app for the source to be selected correctly. For the time being, I am circumventing this issue by hard coding the relevant pair of bytes in my modified version of Devimote. However, I hope that I will eventually be able understand the correct logic and get rid of any such hard coding.

[gnulabis]

Yes, that was a hack on my side, because I could also not fully understand the logic behind the output encoding in my setup. I noticed in wireshark that it was different if the output was above 7, so I coded that without being able to explain why such a thing was necessary.

In recent times I bought a subwoofer and reconfigured my D200 to switch an input to a pre-out to drive the subwoofer, which made me think that perhaps the different encoding is needed for configurable inputs/outputs or other similar stuff. But I never got to test this theory.

[gnulabis]

As for the different packet size because of more channels, when I look at the code I see that the loop takes into account 15 channels, not 8:

devimote/src/devimote.py

Line 183 in 2c33a0c

for i in range(0,15):

Where did you have to change the code to account for more channels?

[pisabell2]

You are right: your program already provided for 15 different sources. My mistake.

I first noticed that the data strings were longer in my version and, accordingly, I made the following change:

# Original code

 def update(self):
        '''Try to get UDP status packet and decode it'''
        sock = socket.socket(socket.AF_INET,    # Internet
                             socket.SOCK_DGRAM) # UDP
        sock.bind(('', self.UDP_PORT_STATUS))
        sock.settimeout(2)
        try:
            data, addr = sock.recvfrom(512) 

# My modified code

   def update(self):
        '''Try to get UDP status packet and decode it'''
        sock = socket.socket(socket.AF_INET,    # Internet
                             socket.SOCK_DGRAM) # UDP
        sock.bind(('', self.UDP_PORT_STATUS))
        sock.settimeout(2)
        try:
            data, addr = sock.recvfrom(598) # buffer size changed from 512 to 598 bytes 

I had then noticed that in my status packets, the critical status bytes for power, mute, etc. appeared quite a bit further down in the string. I thus made the following changes:

# Original code
 for i in range(0,15):
            enabled = int(chr(data[52+i*17]))
            if enabled:
                self.status['ch_list'][i] = data[53+i*17:52+(i+1)*17].decode('UTF-8')
        self.status['power']   = (data[307] & 0x80) != 0
        self.status['muted']   = (data[308] & 0x2) != 0
        self.status['channel'] = (data[308] & 0x3c) >> 2
        self.status['volume']  =  data[310]
        self.status['crc_ok']  = (_crc16(data[:-2]) == struct.unpack('>H',data[-2:])[0])

# My modified code:
 for i in range(0,15):
            enabled = int(chr(data[52+i*17]))
            if enabled:
                self.status['ch_list'][i] = data[53+i*17:52+(i+1)*17].decode('UTF-8')
        self.status['power']   = (data[562] & 0x80) != 0
        self.status['muted']   = (data[563] & 0x2) != 0
        self.status['channel'] = (data[563] & 0x3c) >> 2
        self.status['volume']  =  data[565]
        self.status['crc_ok']  = (_crc16(data[:-2]) == struct.unpack('>H',data[-2:])[0])

My speculation that those changes were the result of allowing for more source was obviously wrong. There must be some other reason for them.

[ocococococ]

Excellent work.

As owner of a model Expert 140 Pro (Core Infinity), I can confirm all modifications made by pisabell2 are correct.

Moreover, I also have a 'source-5' which can be selected by sending 44 72 00 ?? 00 ?? 00 05 40 C0 (with these last 2 important bytes 40 C0).

I cannot figure out the right formula to generate the correct values for these 2 bytes in function of selected output index.
Hence, I also hard-coded them in my modified version of devimote.

In my case, the loop for i in range(0,15): can be extended to for i in range(0,30): to potentially retrieve the whole list of available outputs. I presume, the right number of outputs is hidden somewhere in one of the unknown fields mentioned in des.lua.

But once again, this stays a mistery so far, how to implement fully and correctly the set_output method without hard-coded values ?

So I wrote this:

def set_output(self, output):
    out_vals = {
        0: 0x0000,
        1: 0x3F80,
        2: 0x4000,
        3: 0x4040,
        4: 0x4080,
        5: 0x40A0,
        6: 0x40C0,
        14: 0x4160
    }
    if output in out_vals:
        out_val = out_vals[output]
    else:
        out_val = 0x4000 | (output << 5)

    data = bytearray(142)
    data[6] = 0x00
    data[7] = 0x05
    data[8] = (out_val & 0xff00) >> 8
    if output > 7:
        data[9] = (out_val & 0x00ff) >> 1
    else:
        data[9] = (out_val & 0x00ff)
    self._send_command(data)

I also added .rstrip('\0') after both .decode('UTF-8') calls to remove all trailing 0 bytes.

And I also can't manage to modify the code so that self.status['crc_ok'] is computed to True.