Lots to cover!
I think the addressing is tripping you up, when in reality (Once the documentation makes sense, as it is written quite poorly! It is quite simple) The chip itself handles all receiving of the addresses, there are multiple ways to address a device
- Logical address, this is the most common, and this is the value that is stored within the chip itself, in the case of the pimost this is the address that you set within the settings page in most-explorer. These start with 0x0140 to 0x02FF, .
- node position, this is just 0x400 + the node position after the master. This makes it easy to message the master, since you know it is always going to be 0x0400.
- the dynamic mode, I haven’t really seen this used, and you are correct in that the default address of the pimost is 0x110, in hindsight this should really be something in the 0x140 - 0x2ff range, however I don’t believe it affects anything it being within the 0x100 - 0x013f range. However perhaps Saab are an outlier and use the dynamic addressing rather than logical which is what all other systems so far seem to use.
- group address, this can be sent to all slaves within a group.
- broadcast, two types, blocking an unblocking. These are sent to every slave on the network, typically shutdown and start up messages etc.
Now when it comes to how this works in practice, think of most-explorer as a sub service to the chip itself. Most-explorer or socketmost for that matter doesn’t care about the address. The chip itself is what handles whether a message should be received. If the message deviceId (which can be any of the above messaging types) matches inside the chip, then the message is passed to the host (most-explorer).
For the next part you are talking about instanceID. This where things now get different. The addressing mentioned above is all to do with the chip itself, so that is at the lowest level. However Fblock and instanceID are more at the software level. The host itself implements these, they are not stored in the chip in anyway. So out of the box the pimost has no fblocks and in turn no instanceIDs. This is why you usually get spammed with messages from the master of “getFblocks” type. This is the master querying what fblocks are present. The idea is the software then handles these messages and responds appropriately with any fblocks present, along with their instanceIDs.
For group addresses, the first thing to mention is you can send a message to a slave requesting what the currrent set groupID of that device is. It is handy to to be able match the pimost to them. Group address is set as just a byte, the chip automatically appends 0x3 as the upper byte. I have found no use so far as to group addresses, and they don’t seem to be used in my experience.
The default address is only used out of the box, so if you have changed it, then it will no longer be used. The address is stored in persistent memory so does not get wiped etc.
For the power, yes apologies that is probably not clear, if using in auto shutdown mode it needs to be on permanent power. It does give the benefit of booting the pi when you unlock the doors too! I have also broken the ring multiple times, infact on my test bench I do it constantly, it has never caused and issue and seems to be very fault tolerant!
I realized, that in my current setup after ignition OFF and ON there actually is a short interruption in the music, but if the PiMOST is removed from the ring there is no interruption. The interruption is visible in the above log “most-dump first 10 sec”:
This is interesting! If the audio is just a blip, then I am guessing something else is overwriting the pimosts “forced switch” I call this a forced switch because it is really doing that. It is bypassing any kind of connection master and connecting an amplifier direct to the pimost. I suspect in your case the connection master is picking up on that and switching it back to where it wants to be.
If you can do a get functions to the connection master, we can look to create a proper connection master way of doing the auto switch. I would just need to see what fblocks are present in your connection master. I also suspect that where there are multiple amplifiers in your set up, perhaps one of the shadow devices are actually the ones the need the classic “forced switch”
Thanks again for your help Rhys!
funny bug indeed!
). I need to talk to my brother, but I think it might be worth to build the raw framework and get it to work, before I actually start with the “final” mechanical integration as described above.