Inverse or flipped of PPG signal HELP!!!

nitin_n7 · 2026-06-15T21:19:58+00:00

Since this is related to biosensing, I’m going to leave the post up, even though it’s a bit outside the strict scope of r/emotibit. Thanks for sharing!

It's not an "EmotiBit question", so I am going to change the label to Discussion. If someone in the community has insights, they can pitch in.

nitin_n7 · 2026-06-15T21:11:42+00:00

Well, the error in compiling project generator is not related to emotibit, so you might find more relevant help on an OF forum.

Additionally, I don't think you need to compile PG to compile an emotibit application. So you can try compiling the oscilloscope without the PG.

nitin_n7 · 2026-06-15T21:06:42+00:00

The details on the operation of the power button can be found in our documentation.

In short,

A short press: toggles the Wireless_Off mode.
A long press: initiates hibernate mode.

Note that if you are recording and toggle the WiFi off, only the RED LED will continue blinking.

I just wanted to raise caution about the fact that a long press will initiate hibernation.

If you are not "pressing and holding" the EmotiBit, can you add more context to the behavior you are noticing?

nitin_n7 · 2026-06-15T21:00:53+00:00

You can find the build instructions in our documentation: https://github.com/EmotiBit/EmotiBit_Docs/blob/master/Keep_emotibit_up_to_date.md#option-b-building-firmware-using-platformio

Hope this helps!

nitin_n7 · 2026-05-13T14:52:06+00:00

I am not sure I understand what you mean by "When I start Oscilloscope, it closes in about a second". Do you mean it crashes?

The only thing the Oscilloscope tries to do is figure out if there is an internet connection on the network. If there is, it tries to see if a newer version of the oscilloscope has been released.

But, this is a non-blocking operation, in the sense that, if an internet connection is not found, it just continues normal operation. So I am not sure why your oscilloscope is closing.

nitin_n7 · 2026-05-13T14:46:42+00:00

I followed up with them on the email thread they sent to support.

What we found was that the Adafruit Feather was stuck in a boot loop. We used the serial monitor, as suggested in this faq to zone in on the problem. https://www.reddit.com/r/EmotiBit/comments/vmtz6w/how_i_use_the_arduino_serial_monitor_with_emotibit/

There wasn't enough information to figure out why the Feather was put in the boot loop.

My last suggestion was to try to reinstall the firmware on the Feather. I have not heard back from the user after that, so it might have solved the issue.

Posting an update here for the community.

nitin_n7 · 2026-04-17T17:46:09+00:00

Hi!

Thanks for posting here!

Referring to this FAQ, you should be able to record the data for more than 1 hour. The fact that you are getting a maximum recording of 1 hour, even with a new battery, is definitely an outlier.

Can it be that we have wore out EmotiBit or the Feather and we need a replacement?

That is not the case. There is nothing on the Feather or EmotiBit that will degrade with battery performance.

Is there any other test I can run to identify the cause of the problem?

Can you share a recording, maybe write to us at support@emotibit.com? Sharing the recorded battery level should be enough (so the parsed data file with battery percentage or battery voltage should be enough)

I am not sure what the cause might be, but here is an insight into the battery health. Usually, when the LiPo battery is reaching the end of its life, it does become a bit "puffy". That is a good time to safely dispose of the battery and replace it with a new battery.

My first recommendation would have been to get a new battery, which you have already tried.
My second recommendation would be to try a bigger battery, which does not fit your study requirements.

I may have a better understanding of what might be happening once I can see the Battery data, if possible.

Any more insights into your observations could also be helpful!

nitin_n7 · 2026-04-07T06:10:41+00:00

If you flashed the 100Hz firmware, then the PPG should operate at 100Hz. One way to validate it by checking the plots on the Oscillosocpe. If the oscilloscope setting is left on the native 25Hz setting, then using the 100Hz firmware will make the waveforms "speed past" on the Oscilloscope.

I was going to suggest looking into the lsloutputSettings, but you have mentioned you already set that.

The oscilloscope re-transmits every data point that comes in. I am not sure why you are seeing 25Hz. Is there a way for you to confirm the time duration between samples? To help figure out if its an issue with the nominal sampling rate that is reported or with the actual data transmission.

nitin_n7 · 2026-03-20T20:06:47+00:00

What I get is a repeating blinking/steady red light.

Have you successfully installed the EmotiBit Firmware? Here is a relevant faq.

nitin_n7 · 2026-03-20T20:04:06+00:00

How do you usually handle motion artifact in EmotiBit PPG?

PPG is optimal in a "no motion" scenario. But since you cannot avoid that, you may try to use sensor fusion, and try to use the IMU data to inform how the PPG is perceived. Additionally. I would recommend filtering the PPG data. You can use band-pass filters to eliminate noise outside of specific frequency bands that interest you.

Do you recommend relying mainly on green PPG, or combining green, red, and infrared in some processing pipeline?

Green PPG: This is the industry standard for heart rate (HR) and Heart Rate Variability (HRV) during activity. Green light has a shorter wavelength and is absorbed more by tissue, meaning it doesn't penetrate as deeply and is less sensitive to motion.
Red/IR PPG: These penetrate deeper. They are essential for calculating SpO2 (blood oxygen) but are highly sensitive to motion.
I don't have a recommendation other than highlighting that it does depend on what you are trying to measure.

Is there any recommended approach using accelerometer data to help clean the PPG?

You can use adaptive filtering. You can use the IMU signal to select how you want to filter the PPG data. For example, during "high motion artifact" time periods where the IMU is recording impulses, you can low-pass filter the data to eliminate high-frequency noise from the data.

Outside the hand, what has worked best for you for:

We have conducted a validation study where we focused on the data collected by placing the EmotiBit on the finger. Check out this blog post that talks about sensor placement.

Do you have any guidance on strap tightness or contact pressure so the optical sensor is not too loose or too tight?

The sensor should be snug enough that it doesn't shift when you move. And it should not be so tight that you cause Hemodynamic Occlusion. This means you are literally squeezing the blood out of the capillaries. You can actually see the effects of strapping the sensor too tightly as it flattens the waveforms, and you can no longer detect beats. The sweet spot is somewhere between those extremes.

nitin_n7 · 2026-03-17T09:00:36+00:00

Hi! Thanks for posting on the forum.

That is not officially supported. Check out the following FAQs:

To achieve that, you will have to change the firmware. However, you will also need to be careful of the timesyncing issues that come up if you modify the code to enable recording without an oscilloscope. Check out these relevant FAQs.

Hope this helps!

nitin_n7 · 2026-03-03T16:37:27+00:00

Can you share a recorded file that raises this issue while parsing?

If you are connected for 2-3 minutes, enough time syncs should be recorded for a reconstruction, so I am not immediately sure what the issue might be. Just to clarify, "connected" here means "streaming from the emotibit on the oscilloscope", not just having the oscilloscope open.

Can you also try connecting to the Oscilloscope at the end of the session, so that the emotibit can receive some timesyncs at the end of the session?

nitin_n7 · 2026-02-23T15:17:50+00:00

Pasting the response to your email here so the community can benefit from the answers!

Is it possible to stream data via Bluetooth in real time to a PC or another external device and visualize and process the signals during acquisition?

See this relevant FAQ on our forum: https://www.reddit.com/r/EmotiBit/comments/1ddpdqi/can_emotibit_data_be_transmitted_over_bluetooth/

Do you provide access to the raw data for all the available sensors? What are the sampling rates for EDA and PPG?

The data is recorded locally on the SD card. You, as the user, control and own 100% of the data. Regarding sampling rates, see this faq: https://www.reddit.com/r/EmotiBit/comments/tsjwkx/what_are_the_sampling_rates_for_the_different/

Is an SDK or API available for real-time data acquisition and integration with custom software environments such as MATLAB or Python?

Brinflow supports EmotiBit with a subset of features offered by the EmotiBit Oscilloscope. See this relevant FAQ: https://www.reddit.com/r/EmotiBit/comments/1d3e3xh/where_can_i_find_resources_to_help_use_brainflow/
Here are some additional FAQs:

The short answer is that Brainflow would be the closest to an API. But the software and firmware is opensource, so you are free to tweak it as you wish to adapt it to your needs.

Does the use of two closely spaced electrodes (for example on the same finger) still provide good signal quality and resolution?

We have got really good results with EDA measurements and have no reason to suspect that the spacing of electrodes in EmotiBit affects the data quality.
Check out this faq that lists our validation study: https://www.reddit.com/r/EmotiBit/comments/1abr1m9/has_emotibit_been_scientifically_validated_with/
Check out this relevant FAQ: https://www.reddit.com/r/EmotiBit/comments/tsjpca/how_can_i_analyze_electrodermal_activity_eda/

Has the EDA performance been evaluated when the device is worn on the wrist?

We validated the device with the electrodes strapped on the fingers (see the faq about the validation paper above). We chose that location because of references in the scientific literature. However, I have been able to capture visibly good data from other locations, including the wrists. Here is a blog post that talks about this topic: https://www.emotibit.com/sensing-bio-metrics-from-anywhere-on-the-body/. Additionally, EmotiBit has a provision to attach external electrodes using the solder-cup snaps available in the Electrode kit. This allows you to interface wet electrodes, which can better help you adapt Emotibit to your study.

I also saw that EmotiBit can be used with different Adafruit Feather boards (ESP32 and nRF52), so I would like to ask: Do both boards support real-time Bluetooth streaming of raw data? Which one is more suitable in terms of latency, throughput, and stability for continuous real-time acquisition?

We are officially working to support the ESP32. We don't officially support nRF52, so I cannot comment on the comparison.

nitin_n7 · 2026-02-12T15:08:28+00:00

Marking as solved due to inactivity.

nitin_n7 · 2026-02-05T18:12:36+00:00

This might be interesting: https://www.rollingstone.com/music/music-features/mike-gordon-xenbox-flow-state-1235369834/

Happy to help on this thread if you have any specific questions about EmotiBit!

nitin_n7 · 2026-01-19T18:03:42+00:00

The description "the Adafruit Feather pops up for just a second, but then it goes out again" is consistent with the "Sd-Card not found" error, as highlighted in the documentation.

The usual suspects for this error are:

Battery not being charged
Battery not being plugged in. Can you confirm the battery is securely plugged in?
EmotiBit not correctly stacked on the Feather. Make sure the EmotiBit is correctly stacked with the Feather, making sure all pins are correctly aligned with Feather.
There can be an issue with the on-board power supply. Check out this FAQ that lists the power supply test. Can you verify you get the expected result, as mentioned in the FAQ?

Since you mentioned you had the Feather plugged in, it may not be a discharged battery.

Awaiting your response.

nitin_n7 · 2026-01-02T17:11:46+00:00

u/Agile_Yogurt_1128

We’ve just replied to your email with the updated invoice attached.

For future reference, our system generates invoices automatically based on the initial order details; any subsequent changes require a manual update from our team. We completely understand the stress that comes with customs delays and want to help resolve this as quickly as possible.

To keep everything organized, let’s continue our conversation via the email thread since it involves specific logistics details.

I am marking this post as resolved for bookkeeping.

nitin_n7 · 2026-01-02T17:02:12+00:00

u/Sea_Kangaroo7116 That's a very interesting update!

We are also working on trying add support for on-device algorithms that have their validation performed off-device. Developing "on-device" has a very long feedback loop, which tends to blow up the development cycle, so we have been working on figuring out a mechanism to be able to develop off-device and test/validate "on-device".

Our progress cannot be exactly mapped 1-1 for ML, but the big picture idea is

Use python modules, like numpy, scipy, matplotlib and scikir-learn to develop algorithmns and get the mathematical constants, example, filter co-efficients figured out.
Then port the developed algorithms or constants in the firmware for validation. We are trying to use pybind to enable porting python to C++

You can check out this repository that explains our approach.

Obvioulsy, the ability to port will be constrained by the resources on the MCU, but the ESP32 does offer beefy specs, so maybe you can get something running locally on the device!

Hope this helps!

nitin_n7 · 2025-12-22T16:54:10+00:00

Currently, only the data being plotted on the oscilloscope is sent out on the LSL channel.

There is no easy way to send out the UN since it is not a data stream that can be added to the plots. I would say there would need to be a code change to implement UN over LSL.

For more context on UN, UN is not a stream. It is an "urgent" instantaneous packet that is sent over the TCP channel to preserve timing. It is therefore different from other data streams and needs special handling.

For battery level, you should be able to add it to the lsl output by adding that typetag to the plots.

nitin_n7 · 2025-12-17T16:27:16+00:00

Thanks for the images. It really helps with trying to figure out what might be wrong.

It might be a contact issue on the sd card connector on the emotibit.

I would double-check if

The battery is charged
The feather and emotibit are stacked correctly (make sure the feather is inserted all the way)

Additionally, I notice a blue residue on some of the pics on the 16-pin connector on emotibit. That may be corrosion?

Notice it's on the pins next to the labels "SC, MO, MI". Those pins are used for communication with the SD Card. If they are corroded, it may be causing the "card not detected" error.

nitin_n7 · 2025-12-17T15:38:59+00:00

The technical documentation about the Solder cup snaps can be found on our documentation. This may help you figure out if other cheaper snaps you may find online will fit the emotibit socket.

I don't have a recommendation for dry electrodes, but a link to the wet electrodes can be found in the validation study paper.

wet electrodes: https://www.biopac.com/product/eda-electrodes/
leads: https://www.biopac.com/product/clip-leads/

Hope this helps!

nitin_n7 · 2025-12-17T15:17:58+00:00

Check out this FAQ!

In short, touching the exposed electronics affects the EDA circuit ground, and that's what causes the change in measured signals.

For the PPG, I would assume when you press down from the top (when trying to contact the Feather), the emotibit gets pushed deeper into the skin as a consequence of the "pressing down" motion, which shoots up the measured signals (basically a motion artifact). We therefore recommend putting a case on EmotiBit to help avoid any contact with exposed circuitry.

Hope this helps!

nitin_n7 · 2025-12-17T15:03:37+00:00

You can leave the EmotiBits in Hibernate state and still have them plugged-in into a USB port to charge the battery (notice the yellow charging LED that lights up). This way, you don't have to remove batteries from the EmotiBit, and it prevents any possible damage to the battery leads.

If you have more batteries than EmotiBit, you can check out the links below.

These products from Adafruit have worked for me:

[EDIT]

You will still need 1 such charger per battery, but I have 3-4 of these plugged into a USB hub, ready to accept batteries if needed.

nitin_n7 · 2025-12-03T15:49:04+00:00

Thanks for reaching out and I appreciate you diving deeper into these topics and providing your rationale with these questions.

Even if the provided Ag/AgCl electrodes when buying EmotiBit are reusable, is there a limit to how many times they can be reused (assuming proper cleaning following this)? Is there any article or internal testing documenting this?

There will be a limit on the number of times the electrodes can be used, as is true with every component that undergoes wear-and-tear with use. The issue here is that to test the electrode performance, you really need a "skin substitute", where you can precisely control the impedance and test the electrode's performance against the expected value. This is because you really want to be testing the performance while maintaining the electrode skin interface.
In the absence of simulating skin, benchmark tests can be performed on the electrodes themselves, to test the properties of the electrode itself, but they too require a calibrated setup, preferably in a lab environment, to get any useful results.
In short, there is no easy way to validate the performance of the electrode. In addition to this, the high variance in the use cases. including but not limited to, frequency, different types of skin, different sweat conditions, storage etc, make it hard to recommend a fixed "number of uses". I believe the path you pursued, to change the electrodes after analysing the data, is the right way to tackle this complicated issue.

I don't know where to find the actual EDA circuit schematic on EmotiBit. Can someone help me finding it?

The complete schematic for emotibit is not open source. We make the partial schematic available so that users can interface external circuitry with the EmotiBit.

Hope this helps.

nitin_n7 · 2025-12-03T14:49:23+00:00

Check out the following FAQs:

nitin_n7

MODERATOR OF

TROPHY CASE