Power consumption & missing deep sleep

[dumblob]

Currently if one wants to run the HEG on batteries, it has really high power consumption and the batteries need to be exchanged very frequently. It's down to the HW (e.g. the voltage regulator is inefficient - there are (much) more efficient ones on the market) but also SW (e.g. there seems to be no deep sleep in case of inactivity between wifi beacons and other wifi requests).

Are there any plans to improve on this?

[joshbrew]

RE battery, yeah the wifi sucks for battery, BLE is a bit better off. There is a deep sleep mode but it doesn't trigger unless the sensor routine is off if you leave it sitting, and I'm adding some switches to the board for this one to make it a bit easier to swap modes.

Current plans are to move to my own design with a BLE5.2 and 8 channel 24bit ADC (ADS131M08). This is radically power efficient (like 20mA running at full ADC speed w/ BLE5.2) and will be my first custom solution. I have already tested the ADC and for about 5 bucks I get quality EEG data (noise levels near the FreeEEG32). The impedance at the higher gain is good enough for EEG, and then of course this is overkill for optical signals so hopefully this gets me the FNIRS-DOT working too.

[dumblob]

Current plans are to move to my own design with a BLE5.2 and 8 channel 24bit ADC (ADS131M08). This is radically power efficient (like 20mA running at full ADC speed w/ BLE5.2) and will be my first custom solution.

Hm, will you want to change the "HEG board is the web server" architecture then (e.g. to run a server on the client and make the HEG board only a "dumb" provider of data - i.e. client which just gathers and pre-filters data)?

Or will the current architecture stay (I'd say ESP32's wifi is very low-performant and might be a bottleneck if one wanted to connect more than one client to the wifi or even use the ESP32 wifi AP as a "normal" beefier AP to connect e.g. notebooks together in a LAN and send some data between these notebooks)?

Will the new architecture (if any) also support more than one HEG user in the same room (each having their own HEG device on their head)?

Sorry for so many questions - it all just popped in my head immediately after I read your paragraph 😉.

[joshbrew]

@dumblob The web server is super cool but there are a lot of tradeoffs. This next device will be doing EEG and I can't isolate well enough to not pollute the signal if running a wifi server. I'll keep the current esp32 architecture for the Delobotomizer because it's easy and keeps costs low, but I'm trying to move into a more legitimate standard, though may find a better ESP32 breakout if one pops out at me.

[dumblob]

So this next device is will not provide any HEG functionality, but only EEG?

I hope this next device's architecture will alow multiple next devices in one room 😉 (i.e. no AP name clashes, no interference and thus loss of samples, etc.).

[joshbrew]

Its going to be multimodal, HEG and EEG, built on a generic sensor frontend. As far as access points, one task on the list while building this next round of assemblies is having the devices create random Ids the first time they start, thats just a firmware oversight. Also testing the BLE updater