Thank you to our Sponsors
Location: Denmark
Would metadata also be possible on the BL3500? It was mentioned as a feature for the Linkplayer software for Beoport back in the old forums.Good question. Haven't tried it yet as I thought the BL3500 firmware would not support that. Easy to add that data on the ML communication. Will give it a try but I have never seen a BL3500 that displays metadata. What I can also see was implemented in ML but never used (at least on the BL3500) is custom source names. The audio master would send the source name string right in the beginning with an extra command. So N.RADIO" in ascii for example. My BC2 and the BL3500 happily ignore that when changed to something else. The BC2 later switches then over to display the metadata but the source name shown after powering on always stays the same.
Location: Denmark
What exactly you’d like to connect there?I'm not exactly sure. It just seems" like something that might be useful. ;-) Being able to bit-bang from a Raspberry Pi would likely cover anything that I would want to play with.
Each telegram contains a checksum. If a bit got flipped somehow (messages colliding etc) the checksum won’t match and the telegram is ignored or resent.My question was related to how the retry strategy works. For example, which device (sender or receiver) initiates a retry? I'm not really looking for an answer here, but your statement of a USB-serial chip that on the receiving side happily ignores any parity errors" got me thinking a bit. My experience is that 90% of code from most projects is (or should be) dedicated to faults and edge cases. This code is usually under-represented since 90% of the coders only want to work on the 10% of code that is NOT faults and edge cases. ;-) Glitch
My question was related to how the retry strategy works. For example, which device (sender or receiver) initiates a retry? I’m not really looking for an answer here, but your statement of a “USB-serial chip that on the receiving side happily ignores any parity errors” got me thinking a bit. My experience is that 90% of code from most projects is (or should be) dedicated to faults and edge cases. This code is usually under-represented since 90% of the coders only want to work on the 10% of code that is NOT faults and edge cases. ?I'm actually happy that is ignores those parity errors" when receiving. After all they are not used for error checking in the ML protocol at all. It's just for signalling start and end of a message. As several parameters of a message are known and consistent we can just estimate when a message starts and ends software wise. That works really well although of course not the cleanest solution. Other alternatives would have been altering the kernel driver of the built-in uart interface for a special 9-bit mode or using a dedicated ML MCU in-between. If a client receives a message with its address but something is wrong (checksum, unknown command, etc) it will send back an error. I've developed a simple message broker that handles the uart interface and takes care of receiving and sending. You can easily connect to it using redis and don't have to think about bit banging or parity bits. Just send the message in hex on the one channel and wait for the answer on the other. ;-)
Location: Malmo, Sweden
You must be logged in as a BeoWorld member to post replies to forum threads.
Register to access the forums, reference material, and exclusive member benefits — including our monthly prize draw.
Become a Member