- Welcome to Olimex Support Forum.
Olimex Support Forum
Recent posts
#1
KiCAD / Re: New eeg Device for arduino...
Last post by LubOlimex - May 14, 2025, 11:53:31 AMYou can see in the schematic here:
https://www.olimex.com/Products/EEG/Electrodes/EEG-PE/resources/MOD-EEG-PE_sch.pdf
Notice that these are open source electrodes and you can find sources at the product page at our web-site.
https://www.olimex.com/Products/EEG/Electrodes/EEG-PE/resources/MOD-EEG-PE_sch.pdf
Notice that these are open source electrodes and you can find sources at the product page at our web-site.
#2
KiCAD / New eeg Device for arduino usi...
Last post by stams007 - May 13, 2025, 11:42:58 PMHello and good day. i purchased some Passive Electrodes from olimex and i would like to know how to connect the female jack in the pcv im making.Cause i checked with polymeter and it seems the electrodes read through Ring (middle part). When i use continuity it beeps there and not in the Tip. So i would like to know how to connect the electrodes to the 2 Pins (2-3) of the AD620.
Thank you
Thank you
#3
RT5350F / Re: RT5350F Evb Rev A How to i...
Last post by Ariel19 - May 13, 2025, 11:22:13 AMIt is possible that the OpenWrt 15.05-rc3 version you flashed does not include the default LuCI web interface. Try logging into the device with SSH (via PuTTY or terminal) and installing LuCI using the opkg update && opkg install luci command. Then reboot the device using reboot and try accessing the website at http://192.168.2.1 again. If you do not have an internet connection on the device to install LuCI, you will need to establish a network connection first or try flashing again using the firmware that already has LuCI.
#4
Biofeedback - EEG, ECG, EKG / Re: New Windows application fo...
Last post by michaloblastni - May 13, 2025, 02:59:08 AMThanks for the links! I've looked into this, and it seems the attachment method and use of gel really depend on whether you're using active or passive electrodes. With passive electrodes, you typically need conductive gel—or at least water—to reduce impedance. But I'm using active electrodes, and they seem to be working fine even without gel.
I've tried headbands too, but they press on the head a bit too much—same with EEG caps. Right now, I'm just using a bandaid to hold the electrodes in place, and it's surprisingly effective. Some people use 3D printed EEG caps. Not sure if they are are available for download somewhere for Olimex SMT-EEG, and if they are lightweight.
By the way, once I've collected data with the EEG-SMT, am I analyzing it correctly?
Here's my current Jupyter notebook for processing the signals:
👉 https://github.com/michaloblastni/local-neural-monitoring/blob/main/EEG_data_analysis.ipynb
I've tried headbands too, but they press on the head a bit too much—same with EEG caps. Right now, I'm just using a bandaid to hold the electrodes in place, and it's surprisingly effective. Some people use 3D printed EEG caps. Not sure if they are are available for download somewhere for Olimex SMT-EEG, and if they are lightweight.
By the way, once I've collected data with the EEG-SMT, am I analyzing it correctly?
Here's my current Jupyter notebook for processing the signals:
👉 https://github.com/michaloblastni/local-neural-monitoring/blob/main/EEG_data_analysis.ipynb
#5
ESP32 / Re: ESP32P4 DevKit bricked aft...
Last post by rweickelt - May 12, 2025, 09:44:34 AMThank You for taking the time to reproduce the problem and for Your suggestion. Highly appreciated. A 1.50m USB extension cable was indeed enough to stop the bus enumeration failure and by the command line posted above I was able to recover the ESP.
Unless I run erase_flash, I can now at least flash new images and work with the board to some extent, but only with the extension cable in between.
Thanks again.
Unless I run erase_flash, I can now at least flash new images and work with the board to some extent, but only with the extension cable in between.
Thanks again.
#6
ESP32 / Re: ESP32P4 DevKit bricked aft...
Last post by LubOlimex - May 12, 2025, 08:16:31 AMHello,
The board is recoverable. It appears that erasing the flash memory also erases the secondary bootloader and this makes the board constantly reset and the chip to consume more power (but in the safe threshold).
Notice that I forced similar behavior here, I took one ESP32-P4-DevKit from the shop and erased its flash memory via esptool (with command "esptool.py --chip esp32p4 -p COMXX -b 460800 erase_flash") and then observed the same behavior and got similar invalid header responses. I also noticed that while flash is empty the chip heats more compared to when bootloader is present, we will forward that info to espressif, seems like something related to the ROM or bootloader behavior and they should take a look at it.
Overall this is strange behavior but some issues are expected with development samples. We appreciate the feedback and as I wrote we will relay the feedback to Espressif themselves.
First try something different - use your LONGEST USB cable and, even, if possible and if you have USB type A male to type A female also connect it to the regular USB type A - type C cable (as sort of USB extension) or maybe connect some USB hubs. The idea of this is to have cabling with higher resistance between the board and the computer.
Now it should be possible to restore the board via esptool. What to do exactly:
1) Find or download esptool or esptool.py. It can be found in Arduino for ESP32 installations or if you can't find it being on your computer you can install it. It is an important tool for ESP32 chips. You can find more info here (but I am sure there are many guides online on how to install it):
https://docs.espressif.com/projects/esptool/en/latest/esp32/installation.html
2) Download the three binaries we place during production and place them in the folder where the executable for esptool is, the binaries are here at the FTP:
https://ftp.olimex.com/TEMP/ESP32-P4-CAM-binaries/
3) Connect the board in question via the USB and put it in forced bootloader mode - this is done by: press and hold button BOOT1, press and release button RST1, release button BOOT1.
4) Open the terminal and navigate to the folder where the esptool executable is. Run the following command (remember to edit according to the COM port given to the board and the exact name of the executable):
esptool.py --chip esp32p4 -p COMXXX -b 460800 --before=default_reset --after=hard_reset write_flash --flash_mode dio --flash_freq 80m --flash_size 2MB 0x2000 bootloader.bin 0x10000 camera_lcd.bin 0x8000 partition-table.bin
5) This should revert the board to original state witch proper secondary bootloader and you will able to program it via the USB without the need to press the buttons.
Again make sure to use your longest USB cable or USB extension cable or USB hub, this will solve the issue with rebooting constantly.
The behavior will return if you erase the board. In that case repeat the steps above to revert to default state.
Keep us updated on how it goes.
The board is recoverable. It appears that erasing the flash memory also erases the secondary bootloader and this makes the board constantly reset and the chip to consume more power (but in the safe threshold).
Notice that I forced similar behavior here, I took one ESP32-P4-DevKit from the shop and erased its flash memory via esptool (with command "esptool.py --chip esp32p4 -p COMXX -b 460800 erase_flash") and then observed the same behavior and got similar invalid header responses. I also noticed that while flash is empty the chip heats more compared to when bootloader is present, we will forward that info to espressif, seems like something related to the ROM or bootloader behavior and they should take a look at it.
Overall this is strange behavior but some issues are expected with development samples. We appreciate the feedback and as I wrote we will relay the feedback to Espressif themselves.
First try something different - use your LONGEST USB cable and, even, if possible and if you have USB type A male to type A female also connect it to the regular USB type A - type C cable (as sort of USB extension) or maybe connect some USB hubs. The idea of this is to have cabling with higher resistance between the board and the computer.
Now it should be possible to restore the board via esptool. What to do exactly:
1) Find or download esptool or esptool.py. It can be found in Arduino for ESP32 installations or if you can't find it being on your computer you can install it. It is an important tool for ESP32 chips. You can find more info here (but I am sure there are many guides online on how to install it):
https://docs.espressif.com/projects/esptool/en/latest/esp32/installation.html
2) Download the three binaries we place during production and place them in the folder where the executable for esptool is, the binaries are here at the FTP:
https://ftp.olimex.com/TEMP/ESP32-P4-CAM-binaries/
3) Connect the board in question via the USB and put it in forced bootloader mode - this is done by: press and hold button BOOT1, press and release button RST1, release button BOOT1.
4) Open the terminal and navigate to the folder where the esptool executable is. Run the following command (remember to edit according to the COM port given to the board and the exact name of the executable):
esptool.py --chip esp32p4 -p COMXXX -b 460800 --before=default_reset --after=hard_reset write_flash --flash_mode dio --flash_freq 80m --flash_size 2MB 0x2000 bootloader.bin 0x10000 camera_lcd.bin 0x8000 partition-table.bin
5) This should revert the board to original state witch proper secondary bootloader and you will able to program it via the USB without the need to press the buttons.
Again make sure to use your longest USB cable or USB extension cable or USB hub, this will solve the issue with rebooting constantly.
The behavior will return if you erase the board. In that case repeat the steps above to revert to default state.
Keep us updated on how it goes.
#7
Biofeedback - EEG, ECG, EKG / Re: New Windows application fo...
Last post by LubOlimex - May 12, 2025, 08:02:41 AMMost people use tight headbands to attach the electrodes to the head. Check this blog post:
https://olimex.wordpress.com/2015/12/10/control-things-with-your-brain-and-openeeg-eeg-smt/
Also this video:
https://www.youtube.com/watch?v=arORVzdgXG0
It is good idea to use conductive gel. Unfortunately, specific spots might require shaving for precise measurement.
https://olimex.wordpress.com/2015/12/10/control-things-with-your-brain-and-openeeg-eeg-smt/
Also this video:
https://www.youtube.com/watch?v=arORVzdgXG0
It is good idea to use conductive gel. Unfortunately, specific spots might require shaving for precise measurement.
#8
Biofeedback - EEG, ECG, EKG / New Windows application for EE...
Last post by michaloblastni - May 10, 2025, 06:56:35 PMI developed a new application for EEG-SMT https://www.olimex.com/Products/EEG/OpenEEG/EEG-SMT/open-source-hardware It includes a help system that explains how to use the device for local neural monitoring. It also covers troubleshooting and additional topics that new users want to know about. The application is distributed with an MIT license allowing any modifications, reuse (incl. in commercial products), etc. The full source code is included, as well as a working release for Windows.
https://github.com/michaloblastni/local-neural-monitoring
Unlike Python, Java, etc. this is developed in C using WinAPI and it does not have any dependencies. The whole application incl. help has around 100kB. Performance is also much better because your EEG signal will refresh faster.
I am looking for any contributors, constructive criticism, information that is missing in help, or other suggestions for improvement. The application will stay forever free and Open Source.
One of the goals is to make it easier for an average computer user to buy the cheapest BCI that still works, and to make it possible for this user to monitor his neural activity without having to configure/troubleshoot anything. The application should check if anything that EEG-SMT needs is misconfigured and ask the user if he agrees to fix it, then fix it for him automatically. This is probably the first and the only application that automatically detects the serial mouse issue that occurs when the device is plugged in and it offers to fix it, and upon a confirmation it fixes it in the registry by setting sermouse to disabled.
This application should be usable for ordinary people who are not neuroscientists, or engineers, but ordinary computer users. Every user could benefit from Olimex EEG-SMT because it is a low-cost device that opens the doors to local neural monitoring at home for any purposes.
I am looking for information:
https://github.com/michaloblastni/local-neural-monitoring
Unlike Python, Java, etc. this is developed in C using WinAPI and it does not have any dependencies. The whole application incl. help has around 100kB. Performance is also much better because your EEG signal will refresh faster.
I am looking for any contributors, constructive criticism, information that is missing in help, or other suggestions for improvement. The application will stay forever free and Open Source.
One of the goals is to make it easier for an average computer user to buy the cheapest BCI that still works, and to make it possible for this user to monitor his neural activity without having to configure/troubleshoot anything. The application should check if anything that EEG-SMT needs is misconfigured and ask the user if he agrees to fix it, then fix it for him automatically. This is probably the first and the only application that automatically detects the serial mouse issue that occurs when the device is plugged in and it offers to fix it, and upon a confirmation it fixes it in the registry by setting sermouse to disabled.
This application should be usable for ordinary people who are not neuroscientists, or engineers, but ordinary computer users. Every user could benefit from Olimex EEG-SMT because it is a low-cost device that opens the doors to local neural monitoring at home for any purposes.
I am looking for information:
- How did you attach the electrodes to your head to make them stick for accurate measurement?
- How have you trained an AI classifier, in any application, to detect something that interests you?
#9
FPGA / Re: How to reset the GateMateA...
Last post by talpa - May 09, 2025, 11:12:13 PMI don't know if openFPGALoader is capable of programming the RP2040
(I just put it into bootloader mode (depressing RP-BOOT while pressing RP-RESET) and dragged the firmware into the drive)
But a new enough openFPGALoader actually resets the GateMateA1 when programming it.
(So I no longer have to push FPGA-RST1 before programming the FPGA)
(I just put it into bootloader mode (depressing RP-BOOT while pressing RP-RESET) and dragged the firmware into the drive)
But a new enough openFPGALoader actually resets the GateMateA1 when programming it.
(So I no longer have to push FPGA-RST1 before programming the FPGA)
#10
ESP32 / ESP32P4 DevKit bricked after u...
Last post by rweickelt - May 09, 2025, 09:22:35 PMI bought the ESP32P4 devkit and flashed the hello_world example from IDF v5.4.1 on a Ubuntu 24.04 machine. I did not do any modifications to it, just build and flash. When I wanted to verify whether the example works, I noticed that /dev/ttyACM1 disappeared and did not come back when reconnecting the board.
I noticed that the PC fails to recognize the board. dmesg prints the following output in a loop:
By holding BOOT1 while pressing RESET1 I can trigger a reenumeration when releasing the RESET1 button, but then the loop continues.
When leaving the board disconnected for a while and reconnecting it,
When running
That changes something. The enumeration loop stops. The /dev/ttyACM1 device remains. But yet I cannot talk to the ESP32. The MCU also gets quite warm after a while, but I read that may be normal.
I tried the same with different USB cables and on different Linux computers without luck. Did I brick the board?
I noticed that the PC fails to recognize the board. dmesg prints the following output in a loop:
Code Select
12102.125291] usb 1-2.1: new full-speed USB device number 108 using xhci_hcd
[12102.252563] usb 1-2.1: device descriptor read/64, error -32
[12102.484460] usb 1-2.1: device descriptor read/64, error -32
[12102.716220] usb 1-2.1: new full-speed USB device number 109 using xhci_hcd
[12102.843268] usb 1-2.1: device descriptor read/64, error -32
[12103.077552] usb 1-2.1: device descriptor read/64, error -32
[12103.181679] usb 1-2-port1: attempt power cycle
By holding BOOT1 while pressing RESET1 I can trigger a reenumeration when releasing the RESET1 button, but then the loop continues.
When leaving the board disconnected for a while and reconnecting it,
- the host suddenly enumerates it correctly, the /dev/ttyACM1 device appears, but only for 2 seconds
- Then it is reenumerated successfully a second time
- After 2 seconds, it gets back into the failure loop
When running
Code Select
esptool.py -p /dev/ttyACM1 -b 115200 erase_flash quickly after successfully enumerating the board, I get:Code Select
$ esptool.py -p /dev/ttyACM1 -b 115200 erase_flash
esptool.py v4.8.1
Serial port /dev/ttyACM1
Connecting...
Traceback (most recent call last):
File "/home/rw/.espressif/python_env/idf5.3_py3.12_env/bin/esptool.py", line 37, in <module>
esptool._main()
File "/home/rw/.espressif/python_env/idf5.3_py3.12_env/lib/python3.12/site-packages/esptool/__init__.py", line 1314, in _main
main()
File "/home/rw/.espressif/python_env/idf5.3_py3.12_env/lib/python3.12/site-packages/esptool/__init__.py", line 803, in main
esp = esp or get_default_connected_device(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/rw/.espressif/python_env/idf5.3_py3.12_env/lib/python3.12/site-packages/esptool/__init__.py", line 1193, in get_default_connected_device
_esp = detect_chip(
^^^^^^^^^^^^
File "/home/rw/.espressif/python_env/idf5.3_py3.12_env/lib/python3.12/site-packages/esptool/cmds.py", line 99, in detect_chip
detect_port.connect(connect_mode, connect_attempts, detecting=True)
File "/home/rw/.espressif/python_env/idf5.3_py3.12_env/lib/python3.12/site-packages/esptool/loader.py", line 730, in connect
last_error = self._connect_attempt(reset_strategy, mode)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/rw/.espressif/python_env/idf5.3_py3.12_env/lib/python3.12/site-packages/esptool/loader.py", line 606, in _connect_attempt
reset_strategy() # Reset the chip to bootloader (download mode)
^^^^^^^^^^^^^^^^
File "/home/rw/.espressif/python_env/idf5.3_py3.12_env/lib/python3.12/site-packages/esptool/reset.py", line 46, in __call__
self.port.open()
File "/home/rw/.espressif/python_env/idf5.3_py3.12_env/lib/python3.12/site-packages/serial/serialposix.py", line 338, in open
self._update_rts_state()
File "/home/rw/.espressif/python_env/idf5.3_py3.12_env/lib/python3.12/site-packages/serial/serialposix.py", line 708, in _update_rts_state
fcntl.ioctl(self.fd, TIOCMBIC, TIOCM_RTS_str)
BrokenPipeError: [Errno 32] Broken pipe
That changes something. The enumeration loop stops. The /dev/ttyACM1 device remains. But yet I cannot talk to the ESP32. The MCU also gets quite warm after a while, but I read that may be normal.
I tried the same with different USB cables and on different Linux computers without luck. Did I brick the board?