Skip to content

Ats9360 driver only#860

Merged
jenshnielsen merged 28 commits intomicrosoft:masterfrom
jenshnielsen:ATS9360DriverOnly
Feb 21, 2018
Merged

Ats9360 driver only#860
jenshnielsen merged 28 commits intomicrosoft:masterfrom
jenshnielsen:ATS9360DriverOnly

Conversation

@jenshnielsen
Copy link
Collaborator

This is the driver only part of #816 which is hopefully easier to review.

I still have to address @damazter points from the other pr before this is ready to review

@jenshnielsen
Copy link
Collaborator Author

jenshnielsen commented Nov 9, 2017

Comments from #816

  • TODO comment isn't it the case that multiple boards are already supported?
    Have not tested but it looks like it so removed the comment
  • sample rates external/internal
    these are quite different in general so we can either have separate parameters or change the validator depending on the settings. I think at the moment that it makes the most sense to have different parameters. We anyway have to get the sample rate from a special function due to the decimation. I have simplified the logic which was overly complex any way and there is now only one way of getting the effective sample rate.
  • comments about ctypes call annotation with argtypes
    The purpose is to ensure that the function is called with the correct types.
    I added a bunch of these at some point when the driver did not work to debug but
    IMHO its a good idea in general as the c-code may segfault if you use the wrong types
  • Generalised to more than 2 channels
    The array sizes should now be calculated correctly for 4,8 and 16 channels too. There is no real support for handling more channels as this is left up to the controllers.
  • pep8
  • Move ctypes argtype annotation
    It's probably more logical to put this in the init function so I have done that
  • Handle buffer API
  • Time spent on logging
    Part of the point of the logging module is that the cost is much smaller overhead when the messages are not being printed. That being said its not zero so I have lowered the level to debug as the lowest possible for the timing messages, removed the call to dll logging and wrapped all the code in a conditional so that the formatting only happens when needed saving a bit more
  • Get raw vs get
    After the latest changes to the parameter class it will automatically wrap either get or get_raw with a wrapper that takes care of calling _save_val if enables and applying any transform and so on, I prefer calling this get_raw so you can access it without the wrapper too
  • Valid options for AUX_IN_AUXILIARY
    Options are defined on page 101 of the sdk manual http://www.alazartech.com/support/Download%20Files/ATS-SDK-Guide-7.1.4.pdf does include option 13 not sure if it's relevant for all cards?. I don't see any indication that this should not be supported for the 9870
  • Missing label added

@Dominik-Vogel
Copy link
Contributor

We should remember to include scipy in the environment.yml file. For your ATS9630 branch this is required.

@jenshnielsen
Copy link
Collaborator Author

I am not so sure. I think it should be an optional dependency, and definitely not for this branch as it does not use Scipy at all

@nulinspiratie
Copy link
Contributor

@jenshnielsen Could you let know when it is ready for review? We're using the ATS9440, which has some quirks such as 4 channels instead of 2. It also uses ATS.py, and I'd like to double check if the updated file is still compatible

@jenshnielsen
Copy link
Collaborator Author

@nulinspiratie @damazter @sohailc I think this is more or less ready for review. I will do one more pep8 pass over it before merging

@nulinspiratie the only major api break that I know about is the change to the signature of handle parameter which now needs to take another parameter.

the number of samples (per channel) per second
"""
if self.sample_rate.get() == 'EXTERNAL_CLOCK':
if (self.clock_source.get() == 'EXTERNAL_CLOCK_10MHz_REF'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where did the decimation part of this function go?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

furthermore, is th elogic here correct? when there is an external clock, then the sample rate is still determined by the internal clock setting I think

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The decimation is handled below like its always been.

If clock_source == 'EXTERNAL_CLOCK_10MHz_REF' and there is a external_sample_rate parameter it will use that. Alternatively it will fall back to the internal sample rate if that parameter is not defined. That is to accommodate for the 2 different Alazar Cards. One has a freely settable sample rate with a 10 MHZ external clock and the other one only has one possible rate in that case.

If there is a pure external_clock there is still no automatic way to infer the sample rate.

# We use the matching one and mark the order one
# as up to date since it's not being pushed to
# the instrument at any time and is never used
if clock_source == 'EXTERNAL_CLOCK_10MHz_REF':
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do you not put a call to self.get_sample_rate here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because that would include the decimation which we don't want here but I have changed the code to make the decimation correction optional instead.

This reverts commit 7b15644.

It does not work due to the way alazar parameters must be updated before
they can be get
Copy link
Contributor

@nulinspiratie nulinspiratie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aside from the binary handle (to support 4-channel ATS instruments) it looks good!

@@ -408,9 +459,10 @@ def config(self, clock_source=None, sample_rate=None, clock_edge=None,
self.parameters['coupling' + str(i)],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

handle should be binary, i.e. 2**(i-1). This should only matter for 4-channel ATS, like the ATS9440

self.parameters['bwlimit' + str(i)])
if bwlimit is not None:
self._call_dll('AlazarSetBWLimit',
self._handle, i,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure if handle should be binary here as well, the ATS9440 doesn't have bw limit

acquisition_controller.handle_buffer(buf.buffer)
try:
for buf in self.buffer_list:
self._call_dll('AlazarPostAsyncBuffer',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When performing long acquisitions, AlazarPostAsyncBuffer has sometimes return an ApiFailed error. I haven't figured out why yet. Anyone else experienced this as well? If so, does this PR fix this issue? Otherwise, would it make sense to add a try except statement here that frees the buffer memory?

@codecov
Copy link

codecov bot commented Dec 18, 2017

Codecov Report

Merging #860 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #860   +/-   ##
=======================================
  Coverage   78.59%   78.59%           
=======================================
  Files          45       45           
  Lines        6415     6415           
=======================================
  Hits         5042     5042           
  Misses       1373     1373

@jenshnielsen jenshnielsen merged commit 6126ebe into microsoft:master Feb 21, 2018
giulioungaretti pushed a commit that referenced this pull request Feb 21, 2018
Author: Jens Hedegaard Nielsen <jenshnielsen@gmail.com>

    Ats9360 driver only (#860)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants