Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure S4 EMG lab as-written actually samples at the correct rate (etc.) #15

Open
adamkewley opened this issue Feb 17, 2023 · 1 comment

Comments

@adamkewley
Copy link
Contributor

adamkewley commented Feb 17, 2023

High-prio: the lab was delivered in 2022, but it required sampling at a much lower frequency than desired because the library/hardware that was used was faulty.

The S4 lab experiment worked in 2022 but students consistently reported that their sampling rate was lower than expected. The reason (we think) was that the software library used in S4 was not able to sample at the rate that the hardware was advertized to sample at.

Whoever works this ticket has to:

  • Go through S4 and ensure the content logically works (i.e. it results in a working EMG that records data)
  • Figure out whether works to the required performance constraints (i.e. the sampling rate is high enough)
  • Update the software libraries etc. if the sampling rate sucks
@adamkewley adamkewley changed the title Test S4 EMG actually works (sampling rate etc.) Ensure S4 EMG lab as-written actually samples at the correct rate (etc.) Mar 2, 2023
@adamkewley adamkewley changed the title Ensure S4 EMG lab as-written actually samples at the correct rate (etc.) High-priority: Ensure S4 EMG lab as-written actually samples at the correct rate (etc.) Mar 2, 2023
@adamkewley adamkewley changed the title High-priority: Ensure S4 EMG lab as-written actually samples at the correct rate (etc.) Ensure S4 EMG lab as-written actually samples at the correct rate (etc.) Mar 2, 2023
@adamkewley
Copy link
Contributor Author

@JanneLuijten I've only recently had time to look into the code behind the EMG. You probably already know this information, but, based on the source code, the recommendation I'd have is:

# BEFORE
ads = ADS.ADS1115(i2c)

# AFTER: change mode
from adafruit_ads1x15.ads1x15 import Mode
ads = ADS.ADS1115(i2c, mode=Mode.CONTINUOUS)

# ALTERNATIVELY: change data rate (default is 128: https://github.com/adafruit/Adafruit_CircuitPython_ADS1x15/blob/main/adafruit_ads1x15/ads1115.py#L69)
ads = ADS.ADS1115(i2c, data_rate=256)

Notes:

The ADS1115 class (parent class: ADS1x15) can take a data rate:

Which seems to affect non-continuous mode:

(the mode flag is):

So, for students in 2023, I'd recommend:

  • Try CONTINUOUS mode and see how that works
  • Try changing the data_rate

Example fixes:

# BEFORE
ads = ADS.ADS1115(i2c)

# AFTER: change mode
from adafruit_ads1x15.ads1x15 import Mode
ads = ADS.ADS1115(i2c, mode=Mode.CONTINUOUS)

# AFTER: change data rate (default is 128: https://github.com/adafruit/Adafruit_CircuitPython_ADS1x15/blob/main/adafruit_ads1x15/ads1115.py#L69)
ads = ADS.ADS1115(i2c, data_rate=256)

I also looked at the lower-level I2C class, but that is deeper inside Adafruit_Blinka. The relevant class code is in busio:

It internally allocates a concrete i2c connection based on what it has detected as connected to the Pi, but we're really digging into the weeds to figure out where, if anywhere, there's an optimization route:

The only recommendation I'd have for I2C is to try different frequency arguments:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant