luyves / time-tagger

ctypes based library for the IDQuantique id800 time-to-digital converter (TDC)

hunahpy

Python 3.6 (32 bits only)

ctypes based library for the IDQuantique id800 time-to-digital converter (TDC)

Shared libraries you need:

• nhconnect.dll
• nhconnect.lib
• tdcbase.dll
• tdcbase.lib
• libusb0.dll (32 bit)

hunahpy package:

hunahpy contains one object only: TDC

TDC is a controller for the id800. Its methods can be access like:

• TDC.getLastTimestamps() (a function)
• TDC.timebase (a value)

config.py is the configuration file for hunahpy. It allows for two different data saving schemes using the cont variable:

• cont = True (or continuous data saving) means it creates only one file and dumps every recorded event there. You need to call the write function again to stop writing.
• cont = False means it creates n data files and writes time tags in one until a set buffer size is reached. It then stops and moves on to the next one automatically.

---

Example script to open or create a file filename.dat saved in /data/ and write 10 seconds worth of events in binary format:

import time
from hunahpy import TDC

tagger = TDC()
tagger.writeTimestamps('/data/filename.dat',binary=True)
time.wait(10)
tagger.writeTimestamps()
tagger.close()

If opening a TDC object don't forget to close connection with TDC.close()

time-tagger's Issues

Is the value you get from calling getTimebase() correct?

Doesn't seem like it. Is the way ctypes handles variable declaration to blame? This an important value as it is the unit for many other outputs in the TDCbase library.

Overflow error when updating counts plot with updatemeta method

Simulating the photon counts with the updatemeta method sometimes raises an overflow error in pyqtgraph's Point.py. It is not consistent and will sometimes start working again when restarting the kernel.
I tried debugging the code but found nothing that would cause an overflow error - even using and updater method without metaprogramming raises this error sometimes. I think it might be because of numpy's float operations when assigning simulated values, I'll revisit when using real data from the TDC.

I tracked down this bug back to 2013 and it seems it hasn't been fixed yet.

I'll keep this issue open until I either fix it or it stops happening.