DIY scan card for Keysight 34970A

[voltsandjolts]

I've cobbled together a scan card to fit in the 34970A card slot. It's basically a re-hash of my Keithley 20 channel card.

I haven't written the firmware yet and first job is to decode the uart serial protocol, which runs at 187500 baud 9N1.

I've searched but can't see any info out there about the command structure.
Does anybody have any info on this?
...if not I'll dig out the logic analyser, but thought I'd ask first.


Edit 19JUN2022:
I have attached here the schematic pdf, gerbers, firmware source and altium files.
This card seems functional to me but has not been extensively tested, there may be gremlins
SAFETY NOTICE:
Your choice of SSR bus relays must withstand the maximum voltage placed on the bus by any card in the DAQ.
Perhaps armature relays would be a better choice for the bus relays.
You must not exceed manufacturer ratings for the DAQ voltage capabilities (300V IIRC?).
This design is openly published in the hope that it is useful for development of your own card(s).
This design is not extensively tested and comes with no warranty, express or implied.

Edit 27JUL2022:
Firmware updated to include relay cycle counters to demonstrate the DAQ commands.
They are just in RAM, so start at 0 on every power-up.

[Kean]

I don't have any info, but I do have 2 x 34970A and 1 x 34972A, plus 2 each of 34901A/903A/907A.  So I'd be happy to assist with verifying any protocol info.

One of my 34970As I bought cheaply second hand.  It needs some cleanup and a replacement fan, so I'm happy to do "guinea pig" testing with it.

[strawberry]

dont know if DS75S temp sensor is crucial part for temperature measurement

[H.O]

Same here, no info on the protocol but very interested. I have 2 1/2 34970 and a couple of different modules. Let me know if there's anything I can do to help.

[voltsandjolts]

Thanks for the offers of help.

dont know if DS75S temp sensor is crucial part for temperature measurement

I'm focused on voltage measurements, don't need thermocouple scanning, but if I get this card running, you could easily adapt it to add a cold junction temperature measurement. The pyhysical cold junction on the 34901A is not that impressive, just a couple of copper planes, but I suppose its adequate given the plastic enclosure/stable conditions in the meter. The Keithley 2001-TSCAN is better with it's copper block.

[strawberry]

recently got 34970A
could make some PCB layout ,schematics

[strawberry]

https://whatever.sdfa3.org/hp-34970a-data-acquisition-unit-communication-protocol.html

[voltsandjolts]

Interesting, thank you.
Yes, that protocol for the display panel might be similar or even same as the card slot protocol.

[Gribo]

You might want to check the 34980's breadboard module. Their protocol might be the same.

[voltsandjolts]

You might want to check the 34980's breadboard module. Their protocol might be the same.

I think the 34959A is just Keysights way of keeping the protocol proprietary while allowing custom circuitry.
It just provides relay control lines etc to custom circuits.

[H.O]

I hooked up the logic analyzer (to a 34901A placed in slot 1) and played around a bit.
It looks like the baudrate is indeed 187500 but, to me, it doesn't seem to be 8E1 like with the front panel but a rather weird 9N1.

First, manually closing/opening channels:

Communication starts with the DAQ sending 0x109 to which the card responds with 0x121:


Then the DAQ sends [COMMAND] followed [CHANNEL] where:


COMMAND =
0x1E9 for CLOSE
0x1E1 for OPEN

CHANNEL =
0x040-0x049 for channels 1 to 10
0x080-0x089 for channels 11 to 20
0x015-0x016 for channels 21 to 22.

When the DAQ is in scan-mode things are a slightly different.
First the DAQ sends 0x1D9 followed by the channel as per above. Then, after some delay (anything between 15ms and 1500ms depending on channel configuration) the DAQ sends 0x109 to which the card responds with 0x101.

Obviously there's more to it than this but hey, it's a start :-)

[strawberry]

boot up sequence, card sends card number and slot number(avoiding slot com conflict)
0x109 could be slot number

[H.O]

I captured the bootup sequence with the 34901A in each of the three slots, no other cards:

34901A in slot 1 of 34970A:

Code: [Select]

At startup the uC RST-pin and the SRQ-pin is held high for aproximately 50ms.
Then, after about 1400ms the following happens:

DAQ sends 0x119
Card responds 0x101

DAQ sends 0x121
SRQ-signal goes high for 200ns, low for 16us and then high (where it stays)
Card responds 0x121
DAQ sends 0x11A
DAQ sends 0x11B

200ms of silence

DAQ sends 0x169, 0x030, 0x000
Card responds 0x121

5ms of silence

DAQ sends 0x169, 0x030, 0x000
Card responds 0x121

8ms of silence

DAQ sends 0x1B9, 0x000, 0x000, 0x000, 0x010

170ms of silence

DAQ sends 0x109
Card responds 0x120

DAQ sends 0x109
Card responds 0x120

DAQ sends 0x109
Card responds 0x120

DAQ sends 0x109
Card responds 0x120

DAQ sends 0x109
Card responds 0x121
34901A in slot 2 of 34970A:

Code: [Select]

At startup the uC RST-pin and the SRQ-pin is held high for aproximately 50ms.
Then, after about 1400ms the following happens:

DAQ sends 0x119

DAQ sends 0x11A
Card responds 0x101

DAQ sends 0x122
SRQ-signal goes high for 200ns, low for 16us and then high (where it stays)
Card responds 0x121
DAQ sends 0x11B

200ms of silence

DAQ sends 0x16A, 0x030, 0x000
Card responds 0x121

5ms of silence

DAQ sends 0x16A, 0x030, 0x000
Card responds 0x121

8ms of silence

DAQ sends 0x1BA, 0x000, 0x000, 0x000, 0x010

170ms of silence

DAQ sends 0x10A
Card responds 0x120

DAQ sends 0x10A
Card responds 0x121

34901A in slot 3 of 34970A:
I've added some comments as to what I think is happening.

Code: [Select]

At startup the uC RST-pin and the SRQ-pin is held high for aproximately 50ms.
Then, after about 1400ms the following happens:

DAQ Sends 0x119      (polls slot 1)

DAQ sends 0x11A      (polls slot 2)

DAQ sends 0x11B      (polls slot 3)
Card responds 0x101 (type of card perhaps, 101=34901?)

DAQ sends 0x123      (attention slot 3?)
SRQ-signal goes high for 200ns, low for 16us and then high (where it stays)
Card responds 0x121 (ACK?)

200ms of silence

DAQ sends 0x16B, 0x030, 0x000  (0x16B has something to with the slot, the rest no idea)
Card responds 0x121  (ACK?)

5ms of silence

DAQ sends 0x16B, 0x030, 0x000
Card responds 0x121  (ACK?)

8ms of silence

DAQ sends 0x1BB, 0x000, 0x000, 0x000, 0x010

170ms of silence

DAQ sends 0x10B
Card responds 0x121
The card knows which slot it's in via the backplace connector pins A6, A7 A8.

EDIT: Perhaps I should add that I am probing at the plugin, not at the backplane or logic board - I should probably change that so that one can probe the system when multiple cards are fitted.

[H.O]

Service guide does say 187500 9N1 so that's verified.
It also says that the 9 bits consists of; a start bit, 8 data bits, an attention bit and a stop bit. The attention bit is 1 if the 8 databits are an address/command, or 0 if the 8 data bits modify or provide data for the previously sent command.


I moved the probing from the module itself to the backplane connector. Now the SRQ doesn't do that short pulse that was seen before.

When a slot is polled by the 0x119, 0x11A, 0x11B commands the card in the respective slot responds with it's ID where 0x101-0x108 is 34901-34908 respectively. I've verified this with 34901, 2, 3, 5 and 7.

[voltsandjolts]

Wow, thanks H.O!...you work much faster than me
This is a great start.

9 bits consists of; a start bit, 8 data bits, an attention bit and a stop bit. The attention bit is 1 if the 8 databits are an address/command, or 0 if the 8 data bits modify or provide data for the previously sent command.

Well spotted, I got the baud setting from the manual but missed the explanation of the 9th bit.

[H.O]

No problem, glad I can help.
Not sure how to figure out what the rest of the bootup / configuration stuff actually does. Any ideas?

Reading the relay count from the module was fairly easy to figure out.

With 34901A in slot 1, pressing VIEW->RELAY CYCLES:
(Display shows 7,141,391)

Code: [Select]

DAQ sends 0x169, 0x02C, 0x040
Card responds 0x00F
DAQ sends 0x149
Card responds 0x0F8
DAQ sends 0x149
Card responds 0x06C
DAQ sends 0x149
Card responds 0x100

Rotating the knob to select the next channel:
(Display shows 673,436)

Code: [Select]

DAQ sends 0x169, 0x02C, 0x041     (Slot 1, Return relay count, Channel 2)
Card responds 0x09C              (Least significant byte)
DAQ sends 0x149                   (Slot 1, next byte please (0x14A for slot 2, 0x14B for slot 3))
Card responds 0x046
DAQ sends 0x149                   (Slot 1, next byte please)
Card responds 0x00A
DAQ sends 0x149                   (Slot 1, next byte please)
Card resonds 0x100                (That's all I got)
So, 0x169 targets card in slot 1 (will be 0x16A, 0x16B for the other two slots), 0x02C is the command to read relay cycles and 0x041 is the channel number.
The card then returns one byte and the DAQ asks for the next byte by sending 0x149, 0x14A or 0x14B (depending on which slot it's targeting) until the card returns 0x100.
The value is returned most least significant byte first. For my channel 2: 0x0A469C = 673,436 which matches what's displayed on the DAQ itself.

[voltsandjolts]

Looking at the block diagram for the 34901A we can guess at what some of the commands will be used for, e.g.

~ open / close channel relays (as you have researched)
~ open / close channel relays in 4 wire mode (maybe same commands as above?)
~ Bank switches open/close for 4W mode
~ open / close backplane switches for measure / 4w-sense / measureI
~ read cold junction temperature (there are two DS75 chips on board so probably separate command to read each of them)
~ read relay activation counters (as you have researched)

There may also be commands to read 8051 firmware version and card hardware version.
Things we don't understand can just be copied monkey-see-monkey-do for now.

Note that I have not implemented the current measurement or the cold junction temperature measurement hardware. But still need dummy response to those commands of course.

[strawberry]

0x16x execute - 0x02C function - 0x040 value - 0x121 executed / 0x100 end of data / 0x120 not ready/done / ..
0x11x search
0x1Bx write > flash memory ?
0x12x activate - SRQ high - 0x121 executed
0x14x received (card) data
0x10x is data transmitted

[voltsandjolts]

Making some progress on a rainy afternoon.

The DMM sets the 9th bit when the character contains the card address. This reduces interrupt load on the card mcu, since the uart has an option to only interrupt if the 9th bit is set. Once the card is addressed, it listens to all subsequent characters until that command is complete, processes it and then goes back into unaddressed mode again. The low 3 bits are used for card address, I guess they were allowing for an 8 slot dmm that never happened. Thus the command codes are actually 5 bits:

Code: [Select]

// Commands are shifted down 3 bits to remove the address bits and thus
// allow the compiler to make a jump table with 32 entries for command decoding.
#define CMD_IDENTIFY    (0x18 >> 3) // response is 0x101-0x108 for 34901A-34908A cards respectively
#define CMD_SRQ_TEST    (0x20 >> 3) // card holds SRQ low for 16us then responds with 0x121
#define CMD_UNKNOWN     (0xB8 >> 3) // maybe for writing to eeprom...dunno
#define CMD_QUERY_BUSY  (0x08 >> 3)
#define CMD_QUERY_DATA  (0x48 >> 3) // read some data, byte at a time
#define CMD_EXECUTE     (0x68 >> 3) // begin read of relay cycle counts and other unknown stuff
#define CMD_CHAN_CLOSE  (0xE8 >> 3)
#define CMD_CHAN_OPEN   (0xE0 >> 3)
#define CMD_CHAN_SCAN1  (0xD8 >> 3) // TODO don't understand this yet, scan channel list maybe?
#define CMD_CHAN_SCAN2  (0x08 >> 3) // TODO don't understand this yet


When responding to the DMM, the scan card sets the 9th bit to mean 'here is a data byte, and it's the last data byte I have for you right now'.

I've implemented all the commands except the last two scan commands. Not tested yet.

[bsdphk]

The DMM sets the 9th bit when the character contains the card address.

This is the good old "multidrop" bus from the MCS-51, aka intel 8051 microcontroller.

And the 8-slot device exists, I've seen it on ebay, can't remember then umber.

[razvan784]

And the 8-slot device exists, I've seen it on ebay, can't remember then umber.

There is an 8-slot 34980A, but it is of a newer design, having an Ethernet interface and wider modules.

Some time ago I also attempted to design a sort of test board for reverse engineering the protocol and to act as a base for custom modules. Unfortunately I did not find enough time/motivation to actually build it yet, but attached are the schematic and PCB in KiCad 6 format - maybe someone will find them useful. It is centered around an 87C52 MCU, just like the original modules. Theoretically it should work with a MCU pulled from a working module (some versions have them socketed) - I thought that would help the debugging / reversing effort. Also a pin header is provided to monitor and override serial communication.

[strawberry]

AT89S52 seems compatible replacement

[H.O]

I'm getting lost in my own notes...
Sometimes, when being given a 0x109 command (for example during initialization or when manually opening/closing channels) the card responds with either 0x120 or 0x121. But other times (for example during a scan), it responds with 0x100 / 0x101 instead.

Anyone been able to figure out the difference?

(0xc8 >> 3) is likely the command to return reference junction temperature. I'm trying to figure out the data format but no luck so far.

[voltsandjolts]

Sometimes, when being given a 0x109 command (for example during initialization or when manually opening/closing channels) the card responds with either 0x120 or 0x121. But other times (for example during a scan), it responds with 0x100 / 0x101 instead.

Anyone been able to figure out the difference?

Yeh, that has been irking me a bit. My latest guess is that
0x121 ready (i.e. not busy)
0x120 busy opening relays
0x101 busy closing relays
0x100 ...hmm hadn't noticed that one

(0xc8 >> 3) is likely the command to return reference junction temperature. I'm trying to figure out the data format but no luck so far.

Yes, that starts off the read, getting a one byte response which is the LSB.
The 3 remaining bytes are then read with the (0x48 >> 3) "read next byte in the transmit buffer" command. MSB last.
Low 16 bits for ch1-10 CJ, high 16 bits for ch11-20 CJ.
Exactly the same 4 byte transfer mechanism is used for the relay cycle counts.

Looking at details of relay stuff now...
At startup with genuine 34901A, the dmm sends (to card in slot 3) 1BB 000 000 000 010
Been trying to figure that out, thought it might have been fram or CJ related but no.
It ties in with relay driver activity (U102 pin1 toggling), so must be reseting relays....but takes 1.7sec to complete
PulseView capture attached for anyone interested.

Progress so far with my card:
It gets recognised and I can read dummy values for CJ temperatures and the relay cycle counts.

[free_electron]

since its a 85c52 ... anyone tried dumping it ? The guy from The Signalpath did it with the VFD display processor.