FS [EU] Keithley 2000-scan-20 pcb (never mind, pcb is faulty)

[hhoef]

Edit:
Sorry, never mind my post. My pcb's are faulty and unusable.

I wanted to build the 2000-scan-20 scan card from https://www.christidis.info/index.php/personal-projects/keithley-dmm-scanner-card-with-ssr. The minimum order for pcb's is 5, so I have 4 left.

So, if someone with a Keithley would like one of these bare pcb's (no components) for free...
You only have to pay for shipping.

p.s.
I would be very happy if someone could spare me a STM32G070KBT6 LQFP32 (so I can build my own scan card).

[maat]

Beware. This design is broken. The connector is not centered as it should be. It does "fit" if you force it in, but I don't consider this the way to go. I also found the firmware to be fairly buggy with a couple of memleaks, when writing the debug output.

I redid the PCB from scratch and fixed the bugs I found. Details are here https://github.com/PatrickBaus/SCAN2000 .

Unfortunately, then Murphy struck and I realised, that the Model 2002 is too fast for the MCU and I now have a card with an FPGA in the pipeline. I hope the new boards arrive on Monday.

[voltsandjolts]

There is an alternative 20 channel card which uses a PIC16F18875 (which is available) and the DIN connector is in the right place

[voltsandjolts]

too fast for the MCU and I now have a card with an FPGA in the pipeline

IIRC the firmware by George Christidis uses an interrupt on every data bit from the DMM. I don't know why he chose that method, it's a simple serial shift register protocol, so I just used the SPI port in a 8-bit PIC. No need for an FPGA.

[hhoef]

Thanks for the info. Seems it's best to scrap my pcb's and order new version.

BR,
Hubert

[hhoef]

Thank you for informing me. I will scrap this pcb.

BR,
Hubert

[maat]

too fast for the MCU and I now have a card with an FPGA in the pipeline

IIRC the firmware by George Christidis uses an interrupt on every data bit from the DMM. I don't know why he chose that method, it's a simple serial shift register protocol, so I just used the SPI port in a 8-bit PIC. No need for an FPGA.

Been there, done that. That was my second thought, but Murphy struck again and I guess the reason they increased the bus frequency was, that there are other devices on the same bus in the K2002. Now that other (or might be two) device does not transmit a number of bytes bits divisible by 4. I guess it is the front panel, but anyway as soon as that device butts in, the frame alignment is gone. This isn't a problem with the original shift registers, as they 'freeze' the last 24 bits, when the latch is triggered, but it doesn't work with the SPI controller. I will write all of that up when the new version arrives tomorrow.

Edit: Fixed a typo

[voltsandjolts]

device does not transmit a number of bytes divisible by 4

AFAIK any MCU SPI implementation will allow byte transfers and to get an interrupt at the end of a byte transfer.

they 'freeze' the last 24 bits, when the latch is triggered

Just receive bytes via SPI and then on a 'latch' signal interrupt, capture the last 3 SPI bytes.

If the protocol was weird enough that the number of bits was not a multiple of 8, then that would limit the choice of MCU to those which have programmable bit count SPI implementations. Not common but e.g. PIC18 K42, NXP LPC1768, some EFM32G, some STM32 I think.

[maat]

device does not transmit a number of bytes divisible by 4

AFAIK any MCU SPI implementation will allow byte transfers and to get an interrupt at the end of a byte transfer.

they 'freeze' the last 24 bits, when the latch is triggered

Just receive bytes via SPI and then on a 'latch' signal interrupt, capture the last 3 SPI bytes.

If the protocol was weird enough that the number of bits was not a multiple of 8, then that would limit the choice of MCU to those which have programmable bit count SPI implementations. Not common but e.g. PIC18 K42, NXP LPC1768, some EFM32G, some STM32 I think.

Sorry I missed your reply.  Indeed there is a typo in my last post. I meant to say bits not bytes. Let me explain further. I have attached a capture of a data transfer on the K2002 bus. As you can see on the left, there is a proper command for the scanner card. It has 24 bits and the latch is asserted. See the second attachment.

The problem can be seen on the right hand side in the third attachment. Here we have most likely two more devices chatting on the data lines. I assume it is two devices, because the clock pulses differ. Here you can see that the first device is sending 24 bits as well, no problem here, a ringbuffer would simply drop them. The third device is causing the issues. Every once in a while I see this one bit in between two commands for the scanner card. So all in all you will end up with either 0, 1 or 24 bits or any combination thereof in between two commands for the scanner.

This screws with the byte alignment of a typical SPI controller found in an MCU and you will get corrupted bytes.

I hope this clears the matter. This issue only happens with the Model 2002 (and likely the 2001).

[voltsandjolts]

Thanks for fixing your typos and adding the logic captures.
That errant clock pulse does indeed screw with an implementation which uses a mcu spi peripheral.

[voltsandjolts]

Do you have any comprehensive captures of the bus data and timing, perhaps in sigrok PulseView format?

I ask because looking at the timing on your plots (assuming time axis is correct), things are happening very slowly. This could allow ample time for an mcu to implement a strategy to mitigate the errant pulse, if bus timing is consistent and predictable. For example, a simple solution might be switching the SPI reception off for 120ms (or whatever) after the scan card 'strobe' pulse, to blank out the errant pulse.

If that doesn't help, then a hardware solution would be to use 3 byte-wide shift register ICs along with an mcu. Upon the strobe pulse, the mcu could read the shift register data, either by parallel or serial connection. I think I'd go for that method rather than cpld.

[maat]

Do you have any comprehensive captures of the bus data and timing, perhaps in sigrok PulseView format?

I did the capture with my RTH1004, because it is mighty convenient. Attached you will find the raw dump. The timings I plotted are correct.

I ask because looking at the timing on your plots (assuming time axis is correct), things are happening very slowly. This could allow ample time for an mcu to implement a strategy to mitigate the errant pulse, if bus timing is consistent and predictable.

I would have to check the other dumps. I only copied this one from the scope, because I did not need the others.

For example, a simple solution might be switching the SPI reception off for 120ms (or whatever) after the scan card 'strobe' pulse, to blank out the errant pulse.

I wouldn't do that. There is no guarantee, that the 24 bits you are looking for are the first to be seen on the bus. So your byte alignment might already be bogus, by the time the first strobe pulse comes in.

If that doesn't help, then a hardware solution would be to use 3 byte-wide shift register ICs along with an mcu. Upon the strobe pulse, the mcu could read the shift register data, either by parallel or serial connection. I think I'd go for that method rather than cpld.

I guess that would be the most solid way. Might even be a little more compact than the FPGA. I guess that depends on personal preference and what you have on hand. I can say it was an nice educational holiday project to get to grips with Verilog. 

[voltsandjolts]

Thanks Maat, I'll take a look at that file.

For example, a simple solution might be switching the SPI reception off for 120ms (or whatever) after the scan card 'strobe' pulse, to blank out the errant pulse.

I wouldn't do that. There is no guarantee, that the 24 bits you are looking for are the first to be seen on the bus. So your byte alignment might already be bogus, by the time the first strobe pulse comes in.

The 24bits of interest wouldn't need to be the first to be seen. The requirements would be the spi reception is enabled (1) after the errant pulse, (2) when the bus is idle, so the spi peripheral is 'bus byte aligned', and (3) before the 24 bits of interest have started. Thereafter, you store all received bytes and use the strobe pulse to capture the last 3 bytes that arrived.