Forum Replies Created
- AuthorPosts
-
But unfortunately the commands only startup the BM in muted state and I can´t get it to unmute
Hi!
Maybe I can jump in here. Was busy with ML lately and haven’t had a deep dive in the DL’86 protocol yet.
What I would try first is just sending it a virtual volume or mute key stroke.So similar to this
https://github.com/toresbe/datalink/blob/main/datalink86-captures-new.txt#L26But instead of the 0x09 at the end (digit-9) give it a try with 0x60 (volume up) or 0x0d (mute toggle). Maybe it will then leave the muted state it started up with.
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.
That’s the reason OTA updates should be used straight from the beginning in the development process of every project. 😉 As long as in-field updates are proven and solid you can take care of the edge cases as they are coming in. Not a friend of that either but…
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. 😉
BeoCenter 2 and MasterDataTool in action
Thanks for advice @B3OHACK3R! I will leave that thought alone and start saving for an oscilloscope!
There are some pretty inexpensive logic analysers available. Search on Amazon for 8CH logic analyser. Should be more than enough for anything that might get send on the Data Out pin.
Maybe not a good idea as the Masterlink data is something like 0.25V and I measured 5V in one of the pins on my parents BS1. But maybe @B3OHACK3R can elaborate on that
Perhaps we should try connecting the BS1’s Data + and Data – to a Masterlink device Data in/out (pins 1 and 2) and see what happens? If I am feeling brave I could try it with my BV10-32, but I wouldn’t know what to connect to the ‘ML sense’ pin 3.
No, please don’t do that. As Madskp wrote ML requires a special receiver and transmitter circuit operating at low voltages +/- 0.25 V. It’s definitely not available in the BS1 according to the service manual.
My best guess is that it’s an exposed serial port of the microcontroller. Either use an oscilloscope or a logic analyser to see if something is coming out there. If it’s valid serial data then you could talk to it with something like the FTDI TTL-234X-5V.
My best guess as also noted in the Beolink Active thread is for use with the ML/MCL converter where powerlink to MCL is also possible as shown in the ML/MCL user manual. For this sceneario commands from the link rooms has to be recieved through the Power Link connection.
Ah, true. You mentioned it there already. It makes certainly sense. Probably they had plans to implement it everywhere but then stopped. On several products you can see that they had something in mind with PL-Rx but then didn’t implement it properly.
My other guess was that speakers with buttons or volume dials were planned but then never developed. I guess we will never find out.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.Found one on Ebay and ordered it. Should be nice to have for things like this
Nice! I think most of these cheap ones still work with the Saleae application. It’s a straight forward to use tool.
A quick video with a BL3500. Pretty much the same as the previous one with the BL2000.
Still have to take the video with the BeoCenter 2. That works really nice as well. Showing even the AirPlay metadata on the display…
BTW I got the schematic from the old BeoLink Active service manual. The IR eye is using the same circuit and it’s included in there.
Only had matching ceramic caps on hand but that’s working well. Used slightly higher voltage ratings due to the dc bias characteristic.
I have my doubts you will be able making it work on a M1/2 Mac.
You have to use a x86 windows host. I guess there is no Beo6 driver for Windows on arm (the one that you install with parallels). So either give it a try with a x86 emulator and a x86 client install (painfully slow) or a dedicated windows machine.
BS3000 also has no datalink but shows ‘DL’ connections to pins 6 and 7 in the circuit diagram:
If you follow the signal it goes to P23 (internal 3 pin connector). The other two signals on that connector are Powerlink data Tx and Rx.
P23 connects to P33 on the MCU board. Only pin 3 is connected to the MCU (PL-Tx). The other two are N.C. (not connected). So neither Datalink nor Powerlink Rx for BS3000. I think no audio master ever implemented Powerlink data Rx. I’m still wondering what they had in mind for it.I am wondering if it was developed as a way to connect a set of headphones with a special DIN connector as the first generation of the century did not have a headphone jack, but did not end up beeing official in the product.
Had another look again. I think there is a mistake in the schematic. If you follow the signal it goes to the tape board. When you look closely those are not outputs but inputs. Also if you look at the audio chip with in integrated multiplexer you see that tape-in connects there while those signals certainly need to be outputs.
So probably those pins are a hidden microphone input for recording something on tape.
That would make sense in that is undocumented, but on the other hand shouldn’t it be mentioned in the service manual of all places.
Could also be for development purpose which would then not be worth mentioning in the service manual. IN/OUT could hint towards a normal serial data transmission. Who knows. Now I’m curious if there is any communication possible on those pins…
Just remembered that the Beosound Century that also does not have datalink.
Interesting. Could be that it triggers an internal test mode. I remember from the BL7000 that there is also such a test mode pin as well. When you apply a 10 Hz signal it enters test mode.
Also interesting regarding pin 6. If you connect it to ground it will unmute the analoge output on that connector. Haven’t seen that before on other devices.
It’s not entirely clear to me. Is the BS9000 data pin functional or not?
No, it’s not functional. In the service manual it’s looking like they wanted to implement it but then didn’t proceed with it.
You can see something similar in the BS9000 service manual. On the connector board those pins are labeled with “data” but if you follow the path they are then marked with N.C. (not connected).
Interesting that they actually routed it to the MCU on BS1. What confuses me a bit is that they are marked with “IN” and “OUT”. Datalink is bi-directional / half-duplex. So there are no separate signals for in/out. Could also be that it’s an undocumented service port.
I have no BS1 unfortunately but you could hook up an oscilloscope to see if there is being some data transmitted.A very great use case which has been requested by many
Yes, certainly makes BL2000 and BL3500 a lot more useful again. 🙂
is it possible to control it directly by serial Rs232 (with/without a level converter) ?
No, that won’t work unfortunately. It’s a half-duplex symmetrical bus working at very low voltages (+/- 0.25V). It is a bit similar to RS422 but won’t work with such transceiver chips due to the low voltages. Also you have to provide power to the data pins as well as to the ML detect pin. So quite a circuit required and anything else than straight forward.
Thank you for your excellent work !
Thanks 🙂
I would like to inject commands, and extract commands on the ML from an my HA system using rs232.
Yes, that is certainly possible. I would just leave the Raspberry in the signal chain as it will take care of handling the ML protocol. Your HA system will not be able to deal with the ML protocol anyway.
You could connect a simple USB-RS232 converter to the Raspberry and then have a small application running on there that translates the serial commands from your HA to ML commands (or the other way around). - AuthorPosts
