poc:2025:raspberry-pi-vep

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
poc:2025:raspberry-pi-vep [2025/07/28 13:57] – fabriciopoc:2025:raspberry-pi-vep [2025/08/20 18:41] (current) – fabricio
Line 3: Line 3:
 ===== Quick Summary ===== ===== Quick Summary =====
  
-  * **Status**: ⏸️ On Hold +  * **Status**: 🟡 In Progress 
-  * **Duration**: ~February 2025  +  * **Duration**: Attempt 1) February-April 2025 (failed); Attempt 2) August 2025 (success!) 
   * **Type**: Hardware/Possible Product     * **Type**: Hardware/Possible Product  
   * **Repository**: [[https://code.rekonas.com/fabricio/vep_rpi|Code Repo]] |  [[https://code.rekonas.com/fabricio/vep_ADR/|ADRs]]     * **Repository**: [[https://code.rekonas.com/fabricio/vep_rpi|Code Repo]] |  [[https://code.rekonas.com/fabricio/vep_ADR/|ADRs]]  
Line 19: Line 19:
   * OS: Raspbian without Desktop   * OS: Raspbian without Desktop
   * Access via SSH in WIFI, directly providing credentials when writing the Image onto the SD card   * Access via SSH in WIFI, directly providing credentials when writing the Image onto the SD card
 +  * video goggles (Bigeyes H3). 57 Degrees field of view.
  
 ** Software Used **: ** Software Used **:
-  * C + Cmake, using libDRM +  * Visual Stimuli with C + Cmake, using libDRM 
-  * Translated the Python Code from [[https://github.com/pieeg-club/EEGwithRaspberryPI|the EEGwithRaspberryPI Repo]]+  * Initial attempt on EEG Recording were with  C. Second Attempt relied on rust, with more optimized code using an interrupt listener for the GPIO events. 
 +  * The Setup is done via ansible playbooks, which are available in the repo. 
 +  * Reference Python Code used is from [[https://github.com/pieeg-club/EEGwithRaspberryPI|the EEGwithRaspberryPI Repo]]
   * Code available under: [[https://code.rekonas.com/fabricio/vep_rpi|https://code.rekonas.com/fabricio/vep_rpi]]   * Code available under: [[https://code.rekonas.com/fabricio/vep_rpi|https://code.rekonas.com/fabricio/vep_rpi]]
- 
-======= Additional Notes ======= 
- 
-A few initial key insights about the PiEEG Code: 
-  * The code uses the BOARD numbering mode for the GPIO pins. 
-  * Pin 37 is used as the "DRDY" (data ready) pin. 
-  * A lot of settings are set to the ADS1299, but in an intransparent way via encoding the bit flags via hex codes. 
- 
- 
-Quite a few things may be set via the ads1299 registers: 
- 
-  * The sampling rate is set in "config1" and defaults to 250 but can be changed.  By default config1 is set to 0x96, which translates to the binary number `10010110`. The last 3 digits denote the sampling rate. You can find the encoding in Table 13 [[https://www.ti.com/document-viewer/ADS1299/datasheet#detailed-description/SBAS4597851|here]] 
  
  
Line 41: Line 32:
 ===== Key Findings ===== ===== Key Findings =====
 ==== What Worked ==== ==== What Worked ====
-  * A small test with the Pi-EEG shield when looking at alpha waves seemed promising in terms of the data quality.+  * Eyes Open / Closed + Chewing worked fine. {{ :poc:2025:eyesopenclosed.png?400 |}}
   * The Checkerboard pattern using the libdrm worked well. Synchronization via the screen refreshment rate is possible.   * The Checkerboard pattern using the libdrm worked well. Synchronization via the screen refreshment rate is possible.
   * Setting a high priority to the process in combination with a preemptible Kernel setting (i.e. Desktop mode- NOT server mode) works well in terms of latency, although it is not a full substitute for the realtime kernel.    * Setting a high priority to the process in combination with a preemptible Kernel setting (i.e. Desktop mode- NOT server mode) works well in terms of latency, although it is not a full substitute for the realtime kernel. 
   * Using the Video-Display-Glasses with the rPi was no issue at all and worked well, even though the display was a bit small. No software changes were required, as it was simply treated as another display.   * Using the Video-Display-Glasses with the rPi was no issue at all and worked well, even though the display was a bit small. No software changes were required, as it was simply treated as another display.
   * The low-level graphics interface worked well, but it can get quite complicated very quickly. There is a need to write ahead into the buffer to avoid tearing.   * The low-level graphics interface worked well, but it can get quite complicated very quickly. There is a need to write ahead into the buffer to avoid tearing.
 +  * VEP Measurements {{ :poc:2025:recording_1.png?400 |}}{{ :poc:2025:recording_2.png?400 |}}
  
 ==== What Didn't Work ==== ==== What Didn't Work ====
Line 59: Line 51:
 The C code is outdated, and there is essentially no explanation. It was necessary to look at the python code and translate it to C. The C code is outdated, and there is essentially no explanation. It was necessary to look at the python code and translate it to C.
  
-**Measuring the actual VEPs**: 
  
-I did not manage to nicely measure the VEP. It's unclear what the cause is, as too many things were changed at once. +==== Surprises & Insights ==== 
-Possible culprits are:+  * Moving to rust did help for a more reliable implementation and easier testing and building. 
 +  * There are a LOT of different ways for low-level interaction with the display. The "displaybuffer" is ancient and should NOT be used. The newer kernel mode setting is absolutely overkill and hard to work with. Libdrm seemed like a nice middleground.  
  
-  * Parallel Processing in C without unit tests (or in general C code, as I'm inexperienced there). 
-  * The PiEEG / ads1299 interface I used in C. I reused the same GPIO pins  and signals as in the python code, but the code translation might have introduced some oversights. 
-  * Higher Sampling Rate: The initial test was done on a lower (default) sampling rate. The sampling rate was increased by a large factor, and it is unclear to me if this is a.) supported by the shield and b.) if any flags on the ADS1299 shield have to be changed. 
  
- +A few initial key insights about the PiEEG Code:
-==== Surprises & Insights ====+
   * The PiEEG code is not very helpful, and continuation of the project requires understanding of the underlying ADS1299 chip.   * The PiEEG code is not very helpful, and continuation of the project requires understanding of the underlying ADS1299 chip.
-  * Moving to rust would help for a more reliable implementation and easier testing and building. +  * The code uses the BOARD numbering mode for the GPIO pins. 
-  * There are a LOT of different ways for low-level interaction with the display. The "displaybuffer" is ancient and should NOT be used. The newer kernel mode setting is absolutely overkill and hard to work with. Libdrm seemed like a nice middleground. +  * Pin 37 is used as the "DRDY" (data ready) pin. 
 +  * A lot of settings are set to the ADS1299, but in an intransparent way via encoding the bit flags via hex codes. 
 + 
 +Quite a few things may be set via the ads1299 registers: 
 + 
 +  * The sampling rate is set in `config1` and defaults to `250` but can be changed.  By default config1 is set to `0x96`, which translates to the binary number `10010110`. The last 3 digits denote the sampling rate. You can find the encoding in Table 13 [[https://www.ti.com/document-viewer/ADS1299/datasheet#detailed-description/SBAS4597851|here]] 
  
 ===== Recommendations ===== ===== Recommendations =====
-**Should we proceed?**: Maybe+**Should we proceed?**: Yes
  
 **If yes, what needs to happen?** **If yes, what needs to happen?**
   * A reimplementation either in rust, or by someone with a better understanding of C.   * A reimplementation either in rust, or by someone with a better understanding of C.
   * More fine grained practical tests to rule out error sources.    * More fine grained practical tests to rule out error sources. 
 +====== Open Issues ====== 
 +The scale / unit that is measured is off / wrong.
  
 ====== External Ressources ====== ====== External Ressources ======
Line 88: Line 83:
   * Code for PiEEG can be found [[https://github.com/pieeg-club|here]], but it is mostly undocumented and barely working out of the box. Key to understanding the code is linking the set registers of the code to its functionalities according to the ads1299 manual.   * Code for PiEEG can be found [[https://github.com/pieeg-club|here]], but it is mostly undocumented and barely working out of the box. Key to understanding the code is linking the set registers of the code to its functionalities according to the ads1299 manual.
  
 +======= Papers =======
 +  *  [[https://pubmed.ncbi.nlm.nih.gov/19762276/|High test-retest reliability of checkerboard reversal visual evoked potentials (VEP) over 8 months]]
 +  *  [[https://www.sciencedirect.com/science/article/abs/pii/016855979190145N|Clinical relevance of phase of steady-state VEPs to PIO0 latency of transient VEPs]]
 +  *  [[https://repository.library.northeastern.edu/files/neu:4f197h92d|Portable brain and vision diagnostic system for age-related macular degeneration and multiple sclerosis/optic neuritis]]
 +
 +
 +====== Images ======
 +{{:poc:2025:pieeg_vep_glasses.jpg?200|}}
 +{{:poc:2025:pieeg_vep_whitebg.jpg?200|}}
 +{{:poc:2025:pieeg_vep_closeup.jpg?200|}}
 +{{:poc:2025:pieeg_vep_checkerboard_in_glasses.jpg?200|}}
  • poc/2025/raspberry-pi-vep.1753711050.txt.gz
  • Last modified: 2025/07/28 13:57
  • by fabricio