[B3OHACK3R]

One very practical example here. BL2000 converted to an AirPlay receiver.

Automatically switches on when the stream starts and also turns off once it stopped.
The buttons / IR receiver are fully functional and control the source application. Next, previous, play, pause.

Would also be pretty easy adding a couple of pre-programmed radio stations that could be selected independent of any incoming AirPlay stream.

I’m surprised how good the BL2000 actually sounds in that combo. Interesting price/performance ratio. They are traded for very little money…

Works with any other ML linkroom product and will also sync the clock on a BL3500.

Video:

[B3OHACK3R]

silou wrote:

I misspoke ! Controlling the ML USB adapter by direct by UART instead of USB !

Ah, okay. On the hardware side that would work. The thing is that ML requires setting some (nowadays) very uncommon parity bits. I’m glad that I found a USB-serial chip that on the receiving side happily ignores any parity errors but let’s you set arbitrary bits when sending.

So if you are not going through the USB interface it gets a bit more complicated and really depends.

 

silou wrote:

Is there any “waiting list” for this device and/or ML to RJ45 adapter ?

Will update this thread once everything is ready. Still have to do the compliance testing and paperwork… You can also send me a PM and I’ll put you on the list. 🙂

[Glitch]

silou wrote:

Controlling the ML USB adapter by direct by UART instead of USB

I had a similar thought. I considered suggesting adding solder jumpers and some pads to attached wires (or a connector) to the UART signal traces. Without more detail of the design, it is hard to know if suggestions like this make sense or not.

B3OHACK3R wrote:

I’m glad that I found a USB-serial chip that on the receiving side happily ignores any parity errors…

What happens when there is an actual (real) parity error?

I’m looking forward to any updates on functionality, availability, and pricing. This device has the potential to be a lot of fun.

Glitch

 

[B3OHACK3R]

Glitch wrote:

I had a similar thought. I considered suggesting adding solder jumpers and some pads to attached wires (or a connector) to the UART signal traces. Without more detail of the design, it is hard to know if suggestions like this make sense or not.

What exactly you’d like to connect there?
Right now the RX/TX pins from the ML transceiver circuit are directly connected to the FTDI USB-serial chip. By soldering / removing a few resistors they can also be routed to the 40-way pinsocket. For Raspberry Pis there is a library for bit-banging such things on the GPIOs. Haven’t tried it but they promise it works up to 19200 baud (exactly the ML speed) with zero errors.

 

Glitch wrote:

What happens when there is an actual (real) parity error?

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.
ML and many other low-power machines from that time are using space and mark parity bits for better performance. The first and the last byte is sent with a mark parity bit while the rest of the message is sent with a space parity. The receiver is always set to space parity and so will wake up / get triggered when a parity error occurs. So no need for polling which greatly frees up resources.

 

Glitch wrote:

I’m looking forward to any updates on functionality, availability, and pricing. This device has the potential to be a lot of fun.

I’m currently preparing a summary for everything. Will also provide the schematic.
It can receive and transmit ML & DL audio + data. Can act as master or slave.

The kit will contain:

• Raspberry Pi compatible “MasterDataTool” with RJ45 ML and DIN DL connectors
• RJ45 <-> ML adapter
• short USB-C <-> USB-A cable
• three 3d printed plastic parts that will form a basic housing when assembled with a Raspberry Pi
• € 150 incl. 19% VAT (likely also including shipping cost but not sure yet)

 

[B3OHACK3R]

[silou]

B3OHACK3R wrote:

Glitch wrote:

I had a similar thought. I considered suggesting adding solder jumpers and some pads to attached wires (or a connector) to the UART signal traces. Without more detail of the design, it is hard to know if suggestions like this make sense or not.

What exactly you’d like to connect there? Right now the RX/TX pins from the ML transceiver circuit are directly connected to the FTDI USB-serial chip. By soldering / removing a few resistors they can also be routed to the 40-way pinsocket. For Raspberry Pis there is a library for bit-banging such things on the GPIOs. Haven’t tried it but they promise it works up to 19200 baud (exactly the ML speed) with zero errors.

 

I would like to inject commands, and extract commands on the ML from an my HA system using rs232.

[B3OHACK3R]

silou wrote:

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).

[silou]

I am also very interested.

is it possible to control it directly by serial Rs232 (with/without a level converter) ?

 

Thank you for your excellent work !

[B3OHACK3R]

Madskp wrote:

A very great use case which has been requested by many

Yes, certainly makes BL2000 and BL3500 a lot more useful again. 🙂

 

silou wrote:

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.

 

silou wrote:

Thank you for your excellent work !

Thanks 🙂

[silou]

B3OHACK3R wrote:

silou wrote:

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.

I misspoke ! Controlling the ML USB adapter by direct by UART instead of USB !

 

Is there any “waiting list” for this device and/or ML to RJ45 adapter ?

Thanks

[B3OHACK3R]

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…

 

[Madskp]

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.

[B3OHACK3R]

Madskp wrote:

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.

[Madskp]

Looking good ?

[Glitch]

B3OHACK3R wrote:

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.

B3OHACK3R wrote:

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

 

[B3OHACK3R]

BeoCenter 2 and MasterDataTool in action

https://www.youtube.com/watch?v=HRpvP_2JzAE

[B3OHACK3R]

Glitch wrote:

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. 😉

[B3OHACK3R]

Glitch wrote:

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…

[bnousr]

Count me in as well as interested in this project and already see request has been made to be able to integrate with Home Assistant and were I’ve opted in for Domtoicz, which there are a few script projects already available to communicate for example with the MLG.

Also recalled that there was a previous attempt on ML bridging with open source software project in a previous thread.

[XavierItzmann]

@Madskp:

from my Linkplayer experience:

• BS3000 displayed, on activation, that the source was either N.RADIO or N.MUSIC. It then displayed the song and the author via horizontally scrolling displayed; or, the radio station and the song.

• BL3500 only displayed N.MUSIC or N.RADIO; no additional data was displayed.

The scrolling abilities of BS3000 avoided the cut-off titles shown on the BeoCenter 2 video included above.

[Author]

Posts