link

link

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.

Looking forward to get my hands dirty on some datalink ?

link

Madskp wrote: 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.

I have got one now and it is working with the Saleae application with the excaption of the channel naming on device being 1-8 and ind the applicattion being 0-7, but I think I can mange that. I wan't to be comfortable using it before I am visiting my parents again next weekend and doing measurements on their BS1. Therefor I have done some testing with different data sources, and can see that I might need some verification of what I am doing. I have taken this screenshot from a recording of an A.TAPE command on the tape port on a MCL2AV: Login to view imageWhat I need to know is does this look correct, or do I need to do some settings in the Saleae application? Also if I export the data in binary format what is the best way to compare them to those datalink commands that are available in different online projects? I have found a HEX editor, but unsure what format I must show the data in to be compareable (BInary, HEX, Decimal ??) Thanks in advance  

Nice, that's looking good to me. You captured a DL80 message. They are pretty short and I think there is no public documentation about it so far. The shorter pulse is a logic 0, the longer one a logic 1. That's all you need I guess. The two longer pulses right in the beginning might be some kind of message header or wake up mechanism.
FYI - DL86 also implements a third value "same bit as before". This pulse then is a bit longer than a logic 0 but shorter than a logic 1. I think DL80 doesn't have that.

How I understood it, for a source activation DL80 will send out 2x 4 bits with the same value. For PHONO I have seen 0011 + 0011 and what you are seeing is likely 0001 + 0001 for A.TAPE. I think that does only partly correlate with DL86 / MCL. There e.g. 0x91 is the A.TAPE source which is 1001 0001 in binary. So the last 4 bits are still matching. Same is true for the PHONO source.
So for CD activation on DL80 I would expect seeing 0010 + 0010.

FYI:
A few years ago, a Norwegian by the name of Tore Sinding Bekkedal tried to reverse-engineer the Datalink protocols. Tore wrote the logic analyzer software for Arduino. You can see his efforts on this GitHub page:

What I need to know is does this look correct, or do I need to do some settings in the Saleae application? Also if I export the data in binary format what is the best way to compare them to those datalink commands that are available in different online projects? I have found a HEX editor, but unsure what format I must show the data in to be compareable (BInary, HEX, Decimal ??) Thanks in advance

This look totally correct, here is a scope capture of out of the TAPE2 socket on my Beomaster 5500, from a few years ago. Login to view image I have successfully reverse engineered most of the DL-80 protocol, but my notes really need a good cleanup to be of use (It's mostly a pile of different files, scope captures, logic analyzer traces, etc...) I do believe the 2 pulses are either a compatibility mode for older devices (I think I read somewhere that some pre-datalink devices used double pulses to trigger play / pause), or a way to trigger a collision on the bus and get the end device to stop talking and listen. What you have following that is definitely the "Beocord play" command, so I think you're all set up. B3OHACK3R : Don't reason with the pulse length for the DL-80, it's simply made of 8 bits packets with 3.125ms bit duration.

Hello guys and thanks for all the inputs.

Glad to hear that I am on the right track.

Now I will try with some different commands and see if I fully understand it.

link

B3OHACK3R : Don’t reason with the pulse length for the DL-80, it’s simply made of 8 bits packets with 3.125ms bit duration.

Ah, interesting. You probably have more insight into the DL80 stuff than I currently have. How are you counting those 8 bits? So in your capture from above - are you seeing two bytes each being 01010100? From my experience with DL86 (and IR as well) there a logic 0 is a 3.125 ms pulse. Logic 1 is a 9.375 ms one while same bit" is a 6.250 ms pulse.

link

Exactly ! Although I have the bit values inverted in my notes, since the bus is pulled to 5V through a resistor, and actively pulled low by the end devices, so I use ‘1’ when the bus level is 0V.

Interesting. It totally makes sense by just looking at it. Nevertheless if you are coming from DL86 where data is determined by the pulse length its a bit different and still makes sense somehow. Your capture is an ATAPE activation command. In the MCL world (and ML as well) that is the 0x91 command. 1001 0001 in binary. Similar commands are CD (0x92) and PHONO (0x93). So the first four bits are likely some kind of a category (audio in that case) and the last four are the actual source. So if you just look at the last 4 bits and take the DL86 pulse length decoding it matches the DL80 ones just fine. So going back to your example again. With that pulse length decoding strategy you'll have 3x short pulse and 1x long pulse. Resulting in 0001. For PHONO activation I have seen the one below and interpreted it as 0011 which then would match the last 4 bits of DL86 for that source (0x93 = 1001 0011). My conclusion from this was that DL80 does not send a space" between "1"s like DL86 does. It just ties them together resulting in that long low period for the two sequential "1" bits. Login to view image Of course I was really biased with the DL86 stuff and you weren't. So I could be completely wrong. Yes, building all that must have been "interesting" back in those days.