TDC7201-ZAX-EVM: Is there a datasheet for the board?

Hi Scott,

For (1), thanks, I think that answers my hardware question enough to build the interface board.

For (3), I'm trying to decide on the best measurement strategy. Most of the pulses will be from cosmic ray muons passing through the detector. There will be maybe a couple hundred such pulses per minute, so a few per second on average. They are pretty much completely uniform random in timing. Every once in a while, a particularly low-energy muon will stop in the detector, making a pulse that is indistinguishable from the pass-through pulses. That muon will undergo radioactive decay with a half life of 2.2 uS, so also random but with exponential timing. The decay will emit an electron (or positron for an antimuon) which will also make a pulse. After some reasonable time (say 20 to 40 uS), there's no point continuing to wait for a decay pulse because most of the muons would have already decayed. All pulses come on the same line.

So, one strategy would be to connect the data line to both START and STOP, wait for a pulse and use it as START, then wait for another pulse and use it as STOP. As you note, there would be some dead time where we couldn't detect the second pulse. If we see a second pulse, fine, take that measurement as a decay time and go back to waiting for a START pulse. If we don't see one within 20 uS or so, time out and either discard the pulse or record it as a pass-through.

The other strategy would be to have the computer (e.g. Arduino) generate a START pulse, and have the data line connected only to STOP. Then we would wait for 2 STOP pulses, for a much longer time (say something like 1 mS). If we see both STOP pulses, record the inter-pulse time as if the first one was a muon stopping pulse and the second one was the decay pulse. If we see 0 or 1 pulse, skip it or treat as a pass-through. It seems like the advantage of this approach is less dead time (even very short pulse pairs can be measured), and possibly more precision, but with the complication of a little more computer control.

Did I explain those clearly enough? Does either strategy seem obviously better to you? Is there some other strategy I should be considering, possibly using both 1 and 2 sides of the chip?

    Howard

After several hours of painfully correlating the Launchpad pinout, the EVM board top and bottom layer layouts, and the schematic, I think I finally have all the information I wanted. To save anyone else from having to go through that, I put it all in a Google Sheet TDC7201-ZAX-EVM header pinout. Comments and corrections welcome. The few remaining uncertainties are marked in light red.

    Howard

I'm happy to report that I built an interface board between my Raspberry Pi 3 and the TDC7201-ZAX-EVM. So far I have only tried reading and writing registers, and bumping the SPI speed up from the RPi default of 0.5 MHz to 16 MHz, but it all works fine so far. This takes the normal 40-wire ribbon cable from the Pi.

Signals:

Red: 3.3V

Black: GND

Green: ENABLE and OSC_ENABLE (using arbitrary RPi GPIO pins set to output).

Yellow: SPI (MOSI,MISO,SCLK,CS1,CS2) Note that the SPI pins are hardwired on the RPi, so there's no choice about the pins for these wires.

Blue: TRIG1, INT1, TRIG2, INT2 (using arbitrary RPi GPIO pins set to input).

Note that DOUT2 is not hooked up yet. I don't need it to test converter #1, and I'm still uncertain about how the Rpi spidev library handles the chip selects, so I didn't want to short it to DOUT1 without further investigation.

Also note that I did not add pull-up resistors to CS1 and CS2 yet. That would probably be good engineering practice so they're guaranteed to be high during power up. But with DOUT2 still disconnected, there's no danger.

If I was doing it over again, I would use a keyed box header for the 2x20 pin RPi header. But this is good enough for bring-up.

The test software is in Python. I'll put it up on Github after I clean it up a bit. I don't think there's any need to move to C for a speedup, since it's going to be spending most of its time waiting for measurement-complete interrupts anyway.

One thing that was a little tricky (using the spidev xfer2() function) is that you have to send null padding bytes after your read command to provide time for the returning data to be clocked. For an 8-bit register you need 1 padding byte and the data you want is in position [1] (not [0]) of the vector return value; for 24-bit you have to send 3 padding bytes and the data is in positions [1][2][3]. Other than that it's been pretty easy going.

I spent some time looking at Arduino too, but the lack of a file system or any real time clock would have meant a lot of extra work to get data logging going. The Raspberry Pi is a Real Computer (TM). :-)