ARCHIVED FORUM -- March 2012 to February 2022READ ONLY FORUM
This is the second Archived Forum which was active between 1st March 2012 and 23rd February 2022
Hi all,
just wanted to inform you that I am very busy with a high priority project at the moment.So there are no new updates since I don't have much time for finishing the hardware layout for BeoPi.I hope this will change in a couple of weeks...
BR,BeoMotion.
BeoMotion: The layout is finished but before I send it to production I will try one more thing. All of the original ML circuits seams to be very well protected so I decided to give it a try with a 3V3 RS485 transceiver.I just ordered some and I think they should arrive tomorrow. Let's see what happens...
The layout is finished but before I send it to production I will try one more thing.
All of the original ML circuits seams to be very well protected so I decided to give it a try with a 3V3 RS485 transceiver.I just ordered some and I think they should arrive tomorrow. Let's see what happens...
Hi BeoMotion,
My concern here is that both outputs (D+ and D-) from an RS485 driver are generally at levels of between +1V and +4V relative to GND (D+ being at +4V while D- is at +1V for 'mark', and the opposite for 'space'). This results in a 'difference' of +3V and -3V respectively, but neither line is actually negative compared to GND. Masterlink on the other hand expects the ML_DATA- signal to be negative in relation to GND. Also, RS485 drivers are tri-state, so are passive whilst in receive mode, but actively drive the bus whilst transmitting, whereas the responsibility for driving the masterlink bus remains always with either the video or audio master.
I also think the differential output from an RS485 driver might be inverted compared to what we want, or more to the point, it might fail to recognise the differential input levels unless inverted. The ideal RS485 receiver would toggle between logic high and low at exactly the 0V crossover between positive and negative 'difference', but the hysteresis points for the MAX3280E were <= -200mV for logic low and >= -50mV for logic high. With masterlink our differential values were 0V for mark and +500mV for space/idle which would both produce a logic high output if connected the right way around, but by inverting the connections to between ML_DATA+ / ML_DATA- and inputs D+ and D- we end up instead with differential voltages of 0V and -500mV which fall either side of the hysteresis range above (with a very small margin) and produce the expected output (albeit inverted).
Whilst in in tech speak mode again - yesterday I rediscovered this document:
http://ojs.statsbiblioteket.dk/index.php/daimipb/article/download/7043/6004
I've seen it before, some time ago, but had pretty much forgotten about it. It describes in some detail the lock management protocol which is based on a 'token' and also mentions briefly other things which may be of relevance to us.
I think as soon as we have a working prototype the first priority will be to work on this as well as trying to work out how ML addresses are negotiated, how the bus master is determined, and what timings are involved in trying to avoid collisions.
Since the bus is async, we can read the data back as we transmit to detect (most) collisions, but it is normal with similar protocols to monitor the bus to ensure it is idle for some milliseconds before trying to transmit, and also, so that all devices don't do this and still try and transmit together, for this idle time to either have some randomised element, or to have a fixed time plus some additional amount of time determined by the senders address on the bus for example.
In an ideal world I would have a ML setup with the full 16 (ideally identical) devices and turn them all on at once, then monitor the carnage that ensues on the ML data bus!. I wish now I had not sold most of my beolink passives as at one stage I had 7 of them and these would have been ideal for this testing, but I think I now have only 2.
Kind Regards,
Martin.
Okay, as promised in the "Interested in controlling your ML setup with a Raspberry Pi?" thread, I've attached a gzipped tar of my working directory for the ML protocol reverse engineering side of things in case anyone wants to take a look or use this as a basis for further work - all contributions are very welcome! (you'll need to remove the .txt - the forum has some restrictions on file extensions that can be uploaded).
The code is written in Perl and takes a single argument, a filename - this file should contain masterlink telegrams, one per line, as space separated hex values (comments can exist in this file, preceded with a #) - see the 'ML_telegrams.input' file for example.
The current code is not pretty (in fact it is just a nasty mess right now) but I wasn't intending to make this code public. The aim right now is to build a picture of how the protocol functions and document anything that can be deciphered easily from the telegrams seen so far (along with anything which has already been documented elsewhere). Once this has been achieved it should be possible to start writing something with more structure - both in terms of code and data types.
My thoughts are that we will need to implement the ML code in a layered approach, with the low level comms, namely TX/RX, ML bus address negotiation, collision detection / avoidance, timing etc being handled at one level (and probably written in C), with higher level functionality being dealt with at an application level.
Attached is the current MLdata schematic. Just delete the .txt extension to only have MLdata.pdf
The transmitter part isn't working and needs debugging.Also the pins of the RJ45 plug seams to be wrong assigned.Due to size limitation I replaced the 4 transistors (from the original ML schematic) with two dual ones. Normally this shouldn't be a problem.Power supply and LED's are fine. Maybe somebody can see the root cause of problem?Otherwise I have to spend some debugging hours with a scope on it.
MLdata.pdf.txt
Hi,
just found some errors concerning the RJ45 connector:
Pin 4 and 5 should be swapped.(should be no problem up to now, but if ADC/DAC connected the signal gets inverted ) Pin 7 needs -ML voltage connected. Maybe therefor no proper function possible?
Ralph-Marcus
RaMaBo: Hi, just found some errors concerning the RJ45 connector: Pin 4 and 5 should be swapped.(should be no problem up to now, but if ADC/DAC connected the signal gets inverted ) Pin 7 needs -ML voltage connected. Maybe therefor no proper function possible?
Hi RaMaBo,
thanks a lot for looking at the schematic and comparing.Well, I think we have found a bug in the documentation of the cables.I have used the one attached. It seams that there the pins of the left channel are not correctly labeled.Very strange...
The negative ML supply is never used (at least in link speakers, active, passive) and should be no problem. For testing I have connected it to a working ML system with a master and some slaves. So I think in this scenario the data pull-ups und the ML supply can be left out.
BR,BeoMotion..
BeoMotion:Well, I think we have found a bug in the documentation of the cables.I have used the one attached. It seams that there the pins of the left channel are not correctly labeled.Very strange...
Yeah, there do seem to be a few different pinouts floating around for this. I don't have any pre-made RJ45 to ML leads to check so perhaps it would be worth emailing Steve @ Sounds heavenly just to confirm the correct pinout (or I'll take a continuity tester with me next time I visit my local store!).
BeoMotion:The negative ML supply is never used (at least in link speakers, active, passive) and should be no problem. For testing I have connected it to a working ML system with a master and some slaves. So I think in this scenario the data pull-ups und the ML supply can be left out.
I haven't studied the Ouverture's +/- 15V ML supply and audio interface schematics in sufficient detail to ascertain the full logic behind it yet, but it is certainly not required for data, and given we're not yet trying to act as a ML master , I agree, the pull ups for supplying +/-0.25V to the ML data pins should not be required either.
I've printed your schematics in A3 size today, and taken some A3 photocopies of the relevant Ouverture schematics so I can scribble all over them without ruining my original service manual. I'll work through these comparing them component by component and connection by connection this evening.
I've compared, trace by trace, component by component, the ML_Connector (ignoring RJ45 pin numbers), ML_Protect, and ML_TX sections of your schematics.
The good news is that I have found no discrepancies when compared against the Ouverture schematics. The bad news is that this means you're gonna need to get the scope out...
It's probably worth scoping the Drain of Q4 first, just to confirm the level shifting is functioning adequately.
With the interface connected are the other ML devices still able to communicate with each other? If so I would say this rules out any inverted logic issues on the TX side of the interface as I would expect the ML_DATA lines to be pulled down constantly if this were the case.
Finally, I presume at this stage the 0R resistors in the ML_Pullup section (R39 and R40) are not installed?
Kind regards,
Hi again,
thanks for your efforts, riverstyx!
as written in the other thread I've found the problem.R13 was the wrong value. Should be 0R instead of 10K. This was included by me as a solder bridge / test point.I had overseen this mistake when checking the schematic and unfortunately also populated it with 10K instead of zero ohms.
Next thing is the ultra small bga footprint of the dc/dc inverter. Was really difficult to populate by hand but it worked.I'm going to exchange this part with a more "prototyping friendly" one in the next version.
Then we have the wrong pin numbering on the RJ45 connector and a missing pipe-through connection for the IR signal of a potential IR board...
Will correct all these bugs and send out a new prototype for manufacturing soon.
I'm glad you found the problem. I'd assumed you must be busy at the moment and was thinking only a couple of days ago that I would drop you a line once I was back from my travels this week to see if I could help in any way.
I'm still happy to pay you for a couple of the version 1 prototype PCBs if that would help offset some of the prototyping costs?
I'm not likely to have much time to do further development right now but I'm hoping to finish the bulk of the renovation work on the house over Christmas so hope to have a bit more free time after that (although I think I said much the same to my girlfriend this time last year!)
Hi. I have tried to compile the kpc2 on a debian jessie os. Unfortunately the used KDE Libs (4/5) seems not to be compatible anymore.
Anybody successfully compiled it?
Looks like this thread is long dead.
Anyone succeeded with this interface?
BL8000, BL8002, BL4000, BL3, BL12.2, BS5, BS7000, BS9000, BS9500, BS2000, Ouverture
Hi Phill
could you be so kind and share what you find out. Messages between usp and Beoport.
Thanks Wolfgang
I would like to realize this circuit with the ML I/O .
Has anyone already experience?
Hi there,
so, this is an old thread, but maybe the following will be useful to folks. You can use a MasterLink Gateway to monitor the full ML bus using an undocumented command _MLLOG from the CLI. Here is a python script that will dump the traffic on the bus, and it implements the best I know about the various fields in the protocol.
import getpass import telnetlib import datetime def _hexbyte(byte): resultstr = hex(byte) if byte < 16: resultstr = resultstr[:2] + "0" + resultstr[2] return resultstr def _hexword(byte1, byte2): resultstr = _hexbyte(byte2) resultstr = _hexbyte(byte1) + resultstr[2:] return resultstr ml_command_type_dict = dict([ (0x45, "GOTO_SOURCE"), (0x6c, "DISTRIBUTION_REQUEST"), (0x96, "PC_PRESENT"), (0x10, "STANDBY"), (0x11, "RELEASE"), (0x3c, "TIMER"), (0x0d, "BEO4_KEY"), (0x04, "MASTER_PRESENT"), (0x5c, "REQUEST_KEY"), (0x30, "WHAT_AUDIO_SOURCE"), (0x40, "CLOCK"), (0x44, "TRACK_INFO"), (0x82, "TRACK_INFO_LONG"), (0x87, "STATUS_INFO"), (0x94, "DVD_STATUS_INFO"), (0x20, "MLGW REMOTE BEO4") ]) ml_state_dict = dict ([ (0x00,"UNKNOWN"), (0x01,"STOP"), (0x02,"PLAYING"), (0x03,"FASTFORWARD"), (0x04,"REWIND"), (0x05,"RECORD_LOCK"), (0x06,"STANDBY"), (0x07,"LOAD"), (0x08,"STIL_PICTURE"), (0x14,"SCAN_FORWARD"), (0x15,"SCAN_REVERSE"), (0xff,"BLANK_STATUS") ]) pictureformatdict = dict( [ (0x00, "Not known"), (0x01, "Known by decoder"), (0x02, "4:3"), (0x03, "16:9"), (0x04, "4:3 Letterbox middle"), (0x05, "4:3 Letterbox top"), (0x06, "4:3 Letterbox bottom"), (0xff, "Blank picture") ] ) beo4_destselectordict = dict([ (0x00, "Video Source"), (0x01, "Audio Source"), (0x05, "V.TAPE/V.MEM"), (0x0f, "All Products"), (0x1b, "MLGW") ]) selectedsourcedict = dict( [ (0x00, "CAMERA"), (0x0b, "TV"), (0x15, "V.Mem"), (0x16, "DVD_2"), (0x1f, "DTV"), (0x29, "DVD"), (0x33, "V_AUX"), (0x3e, "V_AUX2"), (0x47, "PC"), (0x6f, "Radio"), (0x79, "A.Mem"), (0x7a, "NMUSIC"), (0x8d, "CD"), (0x97, "A_AUX"), (0xa1, "NRADIO"), # Dummy for 'Listen for all sources' (0xfe, "") ] ) def _dictsanitize( d , s ): result = d.get( s ) if result == None: result = "UNKNOWN (type=" + _hexbyte( s ) + ")" return str(result) beo4commanddict = dict([ # Source selection: (0x0c, "Standby"), (0x47, "Sleep"), (0x80, "TV"), (0x81, "Radio"), (0x82, "DTV2"), (0x83, "Aux_A"), (0x85, "V.Mem"), (0x86, "DVD"), (0x87, "Camera"), (0x88, "Text"), (0x8a, "DTV"), (0x8b, "PC"), (0x0d, "Doorcam"), (0x91, "A.Mem"), (0x92, "CD"), (0x93, "N.Radio"), (0x94, "N.Music"), (0x97, "CD2"), (0x96, "Spotify"), (0xbf, "AV"), # Digits: (0x00, "Digit-0"), (0x01, "Digit-1"), (0x02, "Digit-2"), (0x03, "Digit-3"), (0x04, "Digit-4"), (0x05, "Digit-5"), (0x06, "Digit-6"), (0x07, "Digit-7"), (0x08, "Digit-8"), (0x09, "Digit-9"), # Source control: (0x1e, "STEP_UP"), (0x1f, "STEP_DW"), (0x32, "REWIND"), (0x33, "RETURN"), (0x34, "WIND"), (0x35, "Go / Play"), (0x36, "Stop"), (0xd4, "Yellow"), (0xd5, "Green"), (0xd8, "Blue"), (0xd9, "Red"), # Sound and picture control (0x0d, "Mute"), (0x1c, "P.Mute"), (0x2a, "Format"), (0x44, "Sound / Speaker"), (0x5c, "Menu"), (0x60, "Volume UP"), (0x64, "Volume DOWN"), (0xda, "Cinema_On"), (0xdb, "Cinema_Off"), # Other controls: (0x14, "BACK"), (0x7f, "Exit"), # Continue functionality: (0x70, "Rewind Repeat"), (0x71, "Wind Repeat"), (0x72, "Step_UP Repeat"), (0x73, "Step_DW Repeat"), (0x75, "Go Repeat"), (0x76, "Green Repeat"), (0x77, "Yellow Repeat"), (0x78, "Blue Repeat"), (0x79, "Red Repeat"), (0x7e, "Key Release"), # Functions: (0x40, "Guide"), (0x43, "Info"), # Cursor functions: (0x13, "SELECT"), (0xca, "Cursor_Up"), (0xcb, "Cursor_Down"), (0xcc, "Cursor_Left"), (0xcd, "Cursor_Right"), # (0x9b, "Light"), (0x9c, "Command"), # Light Timeout (0x58, "Light Timeout"), # Dummy for 'Listen for all commands' (0xff, "") ]) def decode_ml(telegram): decoded = decode_device(telegram[1]) + " => " + decode_device(telegram[0]) + " TYPE: " + str(telegram[3]) + " SRC_DEST:" + _hexbyte(telegram[4]) + " ORIG_SRC:" + _hexbyte(telegram[5]) + " PL_Type: " + _dictsanitize(ml_command_type_dict,telegram[7]) + " Len: " + str(telegram) # status info if (telegram[7]==0x87): decoded = decoded + " Source: " + _dictsanitize(selectedsourcedict,telegram[10]) + " Ch/Track: " + str(telegram[19]) + " Activity: " + _dictsanitize(ml_state_dict, telegram[21]) + " Source Medium: " + str(_hexword(telegram[18],telegram[17])) + " Picture Identifier: " + _dictsanitize(pictureformatdict, telegram[23]) # beo4 command if (telegram[7]==0x0d): decoded = decoded + " Source: " + _dictsanitize(selectedsourcedict,telegram[10]) + " Command: " + _dictsanitize(beo4commanddict,telegram[11]) # track info long if (telegram[7]==0x82): decoded = decoded + " Source: " + _dictsanitize(selectedsourcedict,telegram[11]) + " Ch/Track: " + str(telegram[12]) + " Activity: " + _dictsanitize(ml_state_dict, telegram[13]) # track info if (telegram[7]==0x44): if (telegram[9]==0x07): decoded = decoded + " Switch Source. Old: " + _dictsanitize(selectedsourcedict,telegram[11]) + " New: " + _dictsanitize(selectedsourcedict,telegram[22]) elif (telegram[9]==0x05): decoded = decoded + " Current Source: " + _dictsanitize(selectedsourcedict,telegram[11]) else: decoded = decoded + " Undefined" # goto source if (telegram[7]==0x45): decoded = decoded + " Source: " + _dictsanitize(selectedsourcedict,telegram[11]) + " Ch/Track: " + str(telegram[12]) # remote request if (telegram[7]==0x20): decoded = decoded + " Command: " + _dictsanitize(beo4commanddict,telegram[14]) + " Dest Selector: " + _dictsanitize(beo4_destselectordict, telegram[11]) # request_key if (telegram[7]==0x5c): if (telegram[9]==0x01): decoded = decoded + " Request Key" elif (telegram[9]==0x02): decoded = decoded + " Transfter Key" elif (telegram[9]==0x04): decoded = decoded + " Key Transfer Complete" else: decoded = decoded + " Undefined" # what audio source if (telegram[7]==0x30): if (telegram==0x0): decoded = decoded + " Request Audio Source" elif (telegram==0x02): decoded = decoded + " Audio Source: " + _dictsanitize(selectedsourcedict,telegram[11]) else: decoded = decoded + " Undefined" return decoded def decode_device(d): if (d==0xc0): return "VIDEO_MASTER" if (d==0xc1): return "AUDIO_MASTER" if (d==0xc2): return "SLAVE_DEVICE" if (d==0x83): return "ALL_LINK_DEVICES" if (d==0x80): return "ALL" if (d==0xf0): return "MLGW" else: return "MLN: " + hex(d) HOST = "192.168.1.10" # password = getpass.getpass() password = "XXXX" tn = telnetlib.Telnet(HOST) tn.read_until(b"login: ") tn.write(password.encode('ascii') + b"\n") print(tn.read_until(b"MLGW >")) tn.write(b"_MLLOG ONLINE\r\n") try: while True: line = tn.read_until(b"\n").decode('ascii') print("------------------") print(line.strip("\n")) items = line.split() try: date_time_obj = datetime.datetime.strptime(items[0], '%Y%m%d-%H:%M:%S:%f:') telegram = bytearray() checksum = 0 for x in range(1, len(items)): telegram.append(items[x][:-1].decode('hex')) checksum = checksum + telegram[len(telegram)-1] # print ("len:"+ str(len(telegram)) + " checksum:" + str(checksum & 0xff ) + " timestamp:" + str(date_time_obj)) # print (''.join('{:02x}'.format(x) for x in telegram)) print (decode_ml(telegram)) except ValueError: continue except EOFError as error: quit()
hallo zusammen. Ich wäre auch mega an dieser Lösung interessiert.
Könnte man zB auch einfach den I2C einer Ouverture mithören und dann reagieren?
Würde gerne den Tuner Teil trennen und was eigenes einspeisen
Acrusty: Könnte man zB auch einfach den I2C einer Ouverture mithören und dann reagieren? Würde gerne den Tuner Teil trennen und was eigenes einspeisen
I haven't tried this, but yes, it should be possible to emulate the tuner module with a bit of reverse engineering of the communication between the tuner + RDS modules and the main board.
The ouverture is pretty tolerant to working with many / most of its modules missing - I know this because I am using just the transformer, main board, uP, and masterlink modules inside a plastic project box, to connect a datalink capable beogram to an NL/ML converter, so that I can join it from a NL television and control it with the beoremote 1. Obviously this can be done with an intact ouverture, but I wanted something smaller that I could hide away along with the NL/ML converter, and I already had a spare ouverture that was in very bad cosmetic condition, with no doors and no CD mech that I could harvest these parts from.
ich Grunde genommen war die Idee folgendermaßen: Die NF-Zuleitung vom Tuner zum Mainboard trennen, Raspi anschliessen.
Dann den I2C abhören und bei einem bestimmten Signal auf dem I2C Zum Beispiel den Sender zu wechseln.
Kann man den I2C mit dem Raspi einfach Sniffen? Ich möchte die Kommunikation zum Tuner mithören und dann als Trigger für eine Reaktion auf dem Raspi nutzen.
Looking at the schematics within the ouverture service manual, it seems to i2c is not used by the tuner board (it simply loops through the tuner PCB and onwards to the RDS decoder PCB).
Instead, the lines you would be interested in would be those labelled PLL CE (chip enable), CLOCK, DATA, and DATA2 on the tuner schematics.
Given the tuner uses a Sanyo LC7218 frequency synthesizer, these lines will be using Sanyo CCB serial communication protocol. There are some useful links here about Sanyo CCB: https://forum.arduino.cc/t/ccb-data-reading/418509
It's likely all of the inter-IC communication in the ouverture will be at 5V logic levels, so you should not connect the raspberry PI GPIO lines directly as you will likely destroy your RPi. You will need to use some level converters.
Ideally you'd want to connect an oscilloscope to the CLOCK line, at least to see what kind of data rates you are working with.
I would probably be inclined to use an arduino or esp32 (again with the appropriate logic level converters) to handle the low level stuff and then communicate the results with the RPi.
ich versuchs mal. Vielen Dank für Deine Hilfe!!!
@giovanni,
unfortunately the python code is truncated on the side - is it possible to put the code somewhere I can download it directly?
Hi Frog - Giovanni has uploaded it to GitHub as part of his home assistant integration. I’m currently in the process of translating it for indigo. He did an amazing job reverse engineering the protocol.
his project is here:
https://github.com/giachello/mlgw
my efforts (which have required substantial recoding to python 2.7 as indigo doesn’t support python 3) can be found here. I share it in case your system requires an earlier python version.
https://github.com/LukeSpad/BeoGateway
BTW here is the code for that post above. But do check my github instead, it has much newer code with lots more information.
G.