FS [EU] Keithley 2000-scan-20 pcb (never mind, pcb is faulty) - Page 1
Forum section: electronics / general

author: hhoef
author_rank: Newbie
timestamp: February 19, 2022, 08:31:52 pm
content: Edit:Sorry, never mind my post. My pcb's are faulty and unusable.I wanted to build the 2000-scan-20 scan card fromhttps://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).

author: maat
author_rank: Regular Contributor
timestamp: February 20, 2022, 10:06:30 am
content: 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 herehttps://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.

author: voltsandjolts
author_rank: Unknown
timestamp: February 20, 2022, 10:53:28 am
content: There is an alternative20 channel cardwhich uses a PIC16F18875 (which is available) and the DIN connector is in the right place

author: voltsandjolts
author_rank: Unknown
timestamp: February 20, 2022, 11:37:28 am
content: Quote from: maat on February 20, 2022, 10:06:30 amIIRC 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.

author: hhoef
author_rank: Newbie
timestamp: February 20, 2022, 12:20:19 pm
content: Thanks for the info. Seems it's best to scrap my pcb's and order new version.BR,Hubert

author: hhoef
author_rank: Newbie
timestamp: February 20, 2022, 12:44:57 pm
content: Thank you for informing me. I will scrap this pcb.BR,Hubert

author: maat
author_rank: Regular Contributor
timestamp: February 20, 2022, 07:13:37 pm
content: Quote from: voltsandjolts on February 20, 2022, 11:37:28 amBeen 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 ofbytesbits 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

author: voltsandjolts
author_rank: Unknown
timestamp: February 21, 2022, 10:45:03 am
content: Quote from: maat on February 20, 2022, 07:13:37 pmAFAIK any MCU SPI implementation will allow byte transfers and to get an interrupt at the end of a byte transfer.QuoteJust 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 ofbitswas 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.

author: maat
author_rank: Regular Contributor
timestamp: June 12, 2022, 06:18:50 am
content: Quote from: voltsandjolts on February 21, 2022, 10:45:03 amSorry 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).

author: voltsandjolts
author_rank: Unknown
timestamp: June 12, 2022, 09:36:34 am
content: 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.

author: voltsandjolts
author_rank: Unknown
timestamp: June 20, 2022, 03:32:42 pm
content: 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.

author: maat
author_rank: Regular Contributor
timestamp: June 20, 2022, 06:32:41 pm
content: Quote from: voltsandjolts on June 20, 2022, 03:32:42 pmI did the capture with my RTH1004, because it is mighty convenient. Attached you will find the raw dump. The timings I plotted are correct.Quote from: voltsandjolts on June 20, 2022, 03:32:42 pmI would have to check the other dumps. I only copied this one from the scope, because I did not need the others.Quote from: voltsandjolts on June 20, 2022, 03:32:42 pmI 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.Quote from: voltsandjolts on June 20, 2022, 03:32:42 pmI 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.

author: voltsandjolts
author_rank: Unknown
timestamp: June 20, 2022, 06:46:51 pm
content: Thanks Maat, I'll take a look at that file.Quote from: maat on June 20, 2022, 06:32:41 pmThe 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.