On Sun, Apr 8, 2018 at 5:48 PM, Glen Slick <glen.sl...@gmail.com> wrote: > On Sun, Apr 8, 2018 at 2:01 PM, Ethan Dicks via cctalk > <cctalk@classiccmp.org> wrote: >> On Sun, Mar 25, 2018 at 3:48 PM, Ethan Dicks <ethan.di...@gmail.com> wrote: >>> SN-921 >>> >>> https://upload.wikimedia.org/wikipedia/commons/7/74/Sgi_dialbox_sn-921_front.jpg >>> >>> DANAHER CONTROLS Dials DLS80-1022 >>> >>> https://upload.wikimedia.org/wikipedia/commons/c/cd/SGI_dialbox_DLS80-1022_front.jpg >>
> What version of the dial box do you have? I have an HP A4362A dial box > which looks identical to the pictures of the DLS80-1022 dial box. I have one DLS80-1022 and one SN-921, both badged for SGI. Because I did not get the serial/power Y-cable with the DLS80-1022, I started working on the SN-921 because it just takes +5V on either the serial cable or a 2.1mm jack and was shipped with a +5V PSU for it and I just had to pass RxD, TxD and GND back from it. I have not put together a triple-voltage supply and custom cable for the DLS80-1022 yet, but that may be in my near future. I do have the necessary tools to trace out and monitor the comm circuit on each dial box. > I just hooked up the HP A4362A dial box to a PC serial port with the > Y-cable and the +5,+12,-12 AC adapter and I get 9600,N,8,1 dial > rotation data from the dial box as soon as it is powered on without > needing to send any commands to the dial box first. OK then! My SN-921 is definitely *not* talking. I will crack it open and check the upstream of the RS-232 chip and see if the MCU is generating traffic. I'm entirely willing to believe the weak link is either the onboard boost converter for +/-9VDC for comms or the converter chip itself (not a 1488/1489 pair). It's also possible I have a dead unit, but there's more investigation to do. > It appears that the data format is three bytes per dial rotation > report. The first byte is the dial number, 0x80 through 0x87. The next > two bytes are the twos-complement rotation count, MSB first, > counter-clockwise negative, clockwise positive. Very handy to know. I was looking over the Python code and it seems that there are a number of modes where the host sends some bytes to modify the behavior of the dialbox before setting up an event handler to catch bytes sent from the dialbox but I hadn't figured out exactly what was happening at a bytes-exchanged level. Your explanation is entirely clear. What I _think_ I'm seeing is the Python code sends a mode switch command to get the dial box to auto-send dial events, so I wonder if there are any firmware differences with units destined for HP and units destined for SGI. They could behave the same way when in the same mode, but perhaps they are coming up in different modes. It's of course quite likely that I have a broken unit and there are no internal differences. Thanks for the helpful response! -ethan