What state is this project in?

[Joebeazelman]

I was able to build this project and load it in Saleae Logic2. When I ran it with my ADB data nothing appeared on the channel it was assigned to. Perhaps I might be doing something wrong, but I'm unsure. The only thing I can think of is that the data set I am using isn't triggering anything. Unfortunately, I can't get the debugger to attach to Saleae to investigate it further. lldb claims it can't read the file.

[pgreenland]

Hi,

It was fully working when I left it. I wrote it to take a look at the ADB traffic between an ADB device I've been developing for my SE/30 and its usual keyboard and mouse.

I was using the highly advanced technique of sticking a paperclip in the second ADB port.

I've haven't tried it with any other machines though unfortunately.

If you wanted to check the analyser was working properly, display wise. Running Saleae logic without a device connected and selecting demo mode. You should be able to load the analyser and see some decodes from internally synthesised data.

Let me know how you get on......you're quite possibly the first person other than me to try it.

Thanks,

Phil

[Joebeazelman]

Thanks for getting back to me! I'm trying to monitor ADB traffic for a converter that doesn't work on my particular MacBook Pro. I am also interested in the protocol because it's always been a bit of a mystery. It's a very LSD-tripped version of the 1-wire protocol. Most the code I've seen for it doesn't fully implement it. They usually leave out interrogating all the device IDs, which makes sense since only the keyboard and possibly the mouse are relevant.

Originally, I wanted to use Sigrok's PulseView because there's an ADB plugin for it but the project seems abandoned. The site is riddled with broken links and invalid downloads. Do you know what may have happened? Thankfully, I did some more searching and mysteriously found your project. It pays to shop around! Let me test it out get give you a response.

BTW, I am curious as to using the paperclip in the second ADB port. I figure you were monitoring the data pin without opening the device, but it would require another GND pin too.

[pgreenland]

You got me....I may have been using two paperclips.

If you cant get it working, drop me a short Saleae capture and I'll try firing it up when I get a moment, see if it can pull anything out.

The address assignment and round robin / device attention requests were what I was interested in looking at. Mainly to check my device was following the rules and playing nice. Because of that all of those things should be handled. Think a service request is indicated by a little arrow on the edge. Should all appear in the data table too.

[Joebeazelman]

It successfully annotates the data in demo mode, but doesn't display anything when I use my data. I suspect it only works if the data is precisely timed, or follows a specific sequence of rise and falls. There's also a possibility my logic levels are 3.3V instead of 5V, but it doesn't seem likely.

Anyway, I've enclosed my data as a sample for your review.

Capture.sal.zip

[pgreenland]

Thanks for the capture file, yep definitely wasn't working.

It looks like the host you're using (presumably a USB -> ADB adapter?) is not meeting the protocol timing to the letter (as I understood it when writing the decoder).

If you take a nose in ADBAnalyser.h there's a series of timings and allowable percentage errors, depending on which side is transmitting. The host side is expected to be more accurate than the device for example.

From memory I found originally that the SE/30 was pretty close the Apple's specified timings, but the devices wandered a little more than the spec allowed.

I've tweaked the timings slightly and pushed them to https://github.com/pgreenland/adb-analyzer/tree/relaxed_timings

With those it's able to decode your frame, byte 0xFA it would seem.

I was planning on adding the timings and allowable errors to the config GUI....but didn't quite get that far.

See how you go with those settings and a longer capture.

[Joebeazelman]

Sorry you haven't heard back from me. Sigrock's Pulseview is now active again. I'm using it with another user contributed ADB decoder plugin. It is fairly comprehensive, but could benefit from some extra annotations. The Python code base makes it easier to modify and maintain than using C++.

[pgreenland]

No worries,

C++ wasn't my choice of language for an analyser unfortunately, python would have been a lot easier :-P.

The low level Salaea Logic plugins all have to be implemented in C++ as far as I know. I can understand it from a performance point of view.

The higher level analysers can be written in Python but I don't believe they have access to the original digital samples. They're expected to be sat on top of a low level analyser.

If you get a chance to try the relaxed timing branch let me know, would be good to close the ticket.

Thanks,

Phil

[Joebeazelman]

Yes, I will give it a run as soon as I get back to my project. I've been busy meeting deadlines and putting out fires.