I'm working with Movesense 2.0.0 on a HR+ sensor and I have to minimize the power consumption when device is not worn.
I can't turn it completely off since I need it to keep the correct time so, to reduce the battery usage, when I don't receive a HR notification for a certain amount of time I unsubscribe from all sensors.
What's the most power efficient way to determine when device is worn again? I was thinking about subscribing to accelerometer (as I understand it is the sensor with the lowest power consuption) and when I detect movement I resubscribe to HR and check for incoming data.
Is it a valid approach?
I also noticed that when device isn't worn but still connected to the strap I sometimes receive incorrect HR notifications, like the strap is acting as an antenna for electromagnetic noise. Is there a way to detect when the device is in that status except for looking at HR data to see if they make sense?
Your question is a bit vague in what you mean by "wear a sensor" (I'm assuming you mean HR-strap on chest). In that case if you look at the power consumption documentation (see the PowerOff measurements compared to no-wakeup) you'll notice that
HR wakeup (/System/States/2 (=Connector)) is ~0.2 uA
Movement wakeup (/System/States/0 (=Movement)) is ~4 uA
All other measurements are much higher starting from 10 uA for Acc # 13 Hz.
So the easiest and lowest power determination is to SUBSCRIBE the /System/States/2.
If you base your firmware on version >=2.1 and you measure HR or ECG you also get updates during measurement when the connection is lost (so called Leads-Off detection), so this should help to filter out the spurious HR detections. For firmware 2.0 and earlier you get Connector state 2 (=Unknown) when measuring.
Note: the leads on detection (/System/State/2 when no HR measurement is ongoing) is very sensitive and can give "connected" state when the HR-strap is sweaty.
Full disclosure: I work for the Movesense team
I'm trying to implement action.devices.types.AC_UNIT in google home.
My hub is the IR transmitter, it saves previous states and commands with a packet.
As you might understand the device does not know anything about room temperature.
It seems like thermostatTemperatureAmbient is required for setTemperature execution.
I can report the desired temperature as the ambient one, but then google reports this value when I ask for the temperature at home.
You should be using thermostatTemperatureSetpoint for your desired temperature setting. Ambient temperature should be the actual temp reading from the device. However, since your device does not actually read the temperature, you may consider using the TemperatureControl trait instead.
I want to rebuilt my High-Speed Ebike after it went down.
I tried a Chinese out-of-the-box controller ($40) but it only rotates the 36DC 400W motor at 3 speeds.
Since I want to enhance the bike (GPS, RasPi) I might better intergrate the whole thing, so now I'm thinking of a bare PCB to regulate the speed of the 3 phase motor. Regulation is done by an analogue pot with knob. Could be this one
I'm looking for a way to replace the knob with a electronic version, that takes its input from the speedsensor. This is magnetic switch (Hall?), normal open.
So I'm looking for something that builds up a voltage between 1.8 and 4.9v, depending on the frequency of pulses from the sensor.
I hope this makes sense and somebody is able to get me on track for a solution.
TIA!
It works the other way around. There's no voltage to be 'build up', rather there should be a max voltage (5V) availlable that's dimmed to lower levels by a 10K digital potentiometer. The lever is controlled by a SPI-signal that's generated by the Pi.
Microchip Technology has quite a bunch of them: https://www.microchip.com/paramChartSearch/chart.aspx?branchID=11026
Still have to work this out on a board, though.
Yamaha InfoSound and ShopKick application use technologies that allow to transfer data using ultrasound. That is playing an inaudible signal (>18kHz) that can be picked up by modern mobile phones (iOS, Android).
What is the approach used in such technologies? What kind of modulation they use?
I see several problems with this approach. First, 18kHz is not inaudible. Many people cannot hear it, especially as they age, but I know I certainly can (I do regular hearing tests, work-related). Also, most phones have different low-pass filters on their A/D converters, and many devices, especially older Android ones (I've personally seen that happen), filter everything below 16 kHz or so. Your app therefore is not guaranteed to work on any hardware. The iPhone should probably be able to do it.
In terms of modulation, it could be anything really, but I would definitely rule out AM. Sound has next to zero robustness when it comes to volume. If I were to implement something like that, I would go with FSK. I would think that PSK would fail due to acoustic reflections and such. The difficulty is that you're working with non-robust energy transfer within a very narrow bandwidth. I certainly do not doubt that it can be achieved, but I don't see something like this proving reliable. Just IMHO, that is.
Update: Now that i think about it, a plain on-off would work with a single tone if you're not transferring any data, just some short signals.
Can't say for Yamaha InfoSound and ShopKick, but what we used in our project was a variation of frequency modulation: the frequency of the carrier is modulated by a digital binary signal, where 0 and 1 correspond to 17 kHz and 18 kHz respectively. As for demodulator, we tried heterodyne. More details you could find here: http://rnd.azoft.com/mobile-app-transering-data-using-ultrasound/
There's nothing special in being ultrasound, the principle is the same as data transmission through a modem, so any digital modulation is -in principle- feasible. You only have a specific frequency band (above 18khz) and some practical requisites (the medium is very unreliable, I guess) that suggest to use a simple-robust scheme with low-bit rate.
I don't know how they do it but this is how I do it:
If it is a string then make sure it's not a long one (the longer the higher is the error probability ). Lets assume we're working with the vital part of the ASCII code, namely up to character number 127, then all you need is 7 bits per character. Transform this character into bits and modulate those bits using QFSK (there are several modulations to choose from, frequency shift based ones have turned out to be the most robust I've tried from the conventional ones... I've created my own modulation scheme for this use case). Select the carrier frequencies as 18.5,19,19.5, and 20 kHz (if you want to be mathematically strict in your design, select frequency values that assure you both orthogonality and phase continuity at symbol transitions, if you can't, a good workaround to avoid abrupt symbols transitions is to multiply your symbols by a window of the same size, eg. a Gaussian or Bartlet ). In my experience you can move this values in the range from 17.5 to 20.5 kHz (if you go lower it will start to bother people using your app, if you go higher the average type microphone frequency response will attenuate your transmission and induce unwanted errors).
On the receiver side implement a correlation or matched filter receiver (an FFT receiver works as well, specially a zero padded one but it might be a little bit slower, I wouldn't recommend Goertzel because frequency shift due to Doppler effect or speaker-microphone non-linearities could affect your reception). Once you have received the bit stream make characters with them and you will recover your message
If you face too many broadcasting errors, try selecting a higher amount of samples per symbol or band-pass filtering each frequency value before giving them to the demodulator, using an error correction code such as BCH or Reed Solomon is sometimes the only way to assure an error free communication.
One topic everybody always forgets to talk about is synchronization (to know on the receiver side when the transmission has begun), you have to be creative here and make a lot a tests with a lot of phones before you can derive an actual detection threshold that works on all, notice that this might also be distance dependent
If you are unfamiliar with these subjects I would recommend a couple of great books:
Digital Modulation Techniques from Fuqin Xiong
DIGITAL COMMUNICATIONS Fundamentals and Applications from BERNARD SKLAR
Digital Communications from John G. Proakis
You might have luck with a library I created for sound-based modems, libquiet. It gives you a handful of profiles to work from, including a slow "Ultrasonic whisper" profile with spectral content above 19kHz. The library is written in C but would require some work to interface with iOS.
My question is very similar to this one: iPhone Proximity Sensor. There's clearly some manner of thermometer within the iPhone that's readable by the OS. Has anyone uncovered the super-secret undocumented APIs to read this sensor?
I doubt this sensor is for ambient temperature - rather I suspect it is for overheating of the circuits. If that is all you want then great, but again, I think it would be useless for ambient temperature.
just my opinion.
All i could find was CTGetTemperature in CoreTelephony of all places.
I don't know about previous models, but my iPhone4 goes from cool-ish to very warm in a matter of minutes depending on the various radio usages. So unless "good enough" = "within 20 degrees F or so", then probably not good for ambient measurement.
Unless (maybe you meant this) you could also track radio usage and subtract a temperature variable depending on radio usages. phew. complicated. Easier to just query NWS.
command to get all super-secret names which related with temperature in CoreTelephony framework
nm "/Applications/Xcode463.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/6.1 (10B141)/Symbols/System/Library/Frameworks/CoreTelephony.framework/CoreTelephony" | grep empera