Why isn't the sound volume of a device tied to decibels? And could you deduct the decibels from the source of the sound and the volume, or at least the percentual difference of decibels between two moments?
Decibels is a unit of measure for the amplitude of a sound wave, it's also used for the SPL(sound pressure level) of a sound wave. It is a measurement of the sound waves passing through the air, not the output of the device at any given time. If you ever see a dB rating on a device or speaker, that is just a notation of what the device is capable of. That output value will always vary based on local conditions, speaker type, amplifier type and many other factors. Even humidity.
So with that said, manufactures could not place a dB rating for when you are changing a volume on a device. Theoretically, the volume setting of a device and the SPL of a sound wave, are not related at all.
Related
I'm designing temperature control system based on Peltier elements. And it's needed to work on a very wide temperature range - from below zero to more than 100°C. So there is two work modes - cooling and heating.
I've implemented a PID controller, made different gains for two modes. And I can adjust them to go to a specific temperature (e.g. 100° or -5°) from room temperature (25°). But when I want to go e.g. from -5° to 60° it may go into oscillations or conversely grow very slowly. Should I break my large range in smaller subranges? Or maybe different gains depending on difference between current and target temperature (∆T)?
Also, I thought to implement auto tune algorithm, but I didn't found anything for the Arduino?
Your system of mass, heater and cooler is subjected to some delays. (imagine you are tuning temperature of the water shower with two water knob, that kind of delay!)
And, PID control strategy is not capable to compensate delays. That's why there are oscillations.
One of the best ways to control delayed systems is using the MPC controllers.
Looking at:
OMNET++: How to obtain wireless signal power?
and
https://github.com/inet-framework/inet/blob/master/examples/wireless/scaling/omnetpp.ini
there seem to be no power consumption related settings to packets that are sent in a UnitDiskRadio.
Is there a way of setting packet power consumption in a unit disk radio medium, or, conversely, communication range in ApskScalarRadioMedium?
UnitDiskRadio is a simplified version of a radio, where you are not interested in the transmission, propagation, attenuation etc. details. You just want to have a clear cut transmission distance. Above that, the transmission always fails, below that the transmission always succeed. This is simple, fast and suitable if you want to simulate high level behavior like application level or routing. You really don't care how much your radio draws from a power grid (or battery) in this case.
On the other hand, if you are interested in low level details, the whole radio transmission process should be modeled. In this case, you model the power draw and based on that transmission and there is no clear cut transmission range. Whether a transmission succeeds is a probabilistic outcome depending on power, antenna configuration, encoding, modulation, noise and a lot of other stuff, so you cannot set it as a simple "range".
TLDR: No, you cannot set both of them on the same radio.
PS: and make sure that you do not mix and match various power parameters. The first question you linked is about getting the power of a received packet (i.e. how strong that signal was when it was received). The second link show how to configure the transmission power (that goes out on the antenna), and in the question you are referring to power consumption which is a third thing, meaning how much you draw from a battery to make the transmission. They are NOT the same thing.
Is it possible to calculate distance between BLE-BLE or Beacon-BLE device using Time(T) taken on packet received on receiver device with measured power or RSSI value?
Is there any formula for that?
You can get a formula for estimating distance from time of flight measurements from this paper.
However, commercially available Bluetooth chipsets do not provide accurate timers capable of measuring time of flight. Further, smartphones do not provide access to such time of flight data. As a result, such a formula is if little practical value for most use cases.
I have several Microsoft bands, to be used as part of a group health initiative. I intend to develop a single app on a tablet which will pull the data from the bands. This will be a manual process, there will not be a constant connection to the tablet and no connection to Microsoft Health.
Does anyone know if this is possible?
Thanks
Emma
The general answer is no: Historical sensor values are not stored or buffered on the Band itself.
It does however depend on what sensors you are interested in. The sensor values are not buffered, so you can only read the current (realtime) value of the sensors.
But sensors such as pedometer and distance are incrementing over time, so these values will make sense even though you are only connected once in a while. Whereas for, e.g., the heart rate and skin temperature, you will only get the current (realtime) value.
So it depends on your use case.
I want to ask about I Beacon advertising, especially Tx Power.
I used two BLE module HM10 and HM11. I make one as a ibeacon (HM10). and other one used to connect and listen to HM10 broadcasting.
I used MCU ATmega32 AVR tied with HM11 and I used scanf function to read the broadcast. I want to extract the last byte (Tx Power). I want to measure the distance with AVR programming.
Could you tell me the algorithm?
The formula Apple uses to calculate a distance estimate to an iBeacon is not published. There are a number of alternative formulas including this one, based on a best fit power curve, that we wrote for the Android Beacon Library.
Further research we have done shows that the formula above basically works, but it has two main imperfections:
It does not work well for weaker beacon transmitters. With weaker broadcasts, the distance is underestimated.
It does not account for varying signal gains in receivers. Different receivers have different antennas and receivers which measure the same signals differently.
There is an ongoing discussion of the best formula here.
A bit late but hopefully useful to others. I have given up on Apple's "Accuracy" number; as #davidyoung points out, different devices will have different signal gains. Now I am not an engineer but more of a math and statistics person, so I have gone down the route of "fingerprinting" an indoor space instead. Essentially I read all RSSI from all beacons installed in a certain "venue". Some might not be within reach and therefore I just assume, in such cases, an RSSI of -95 dBm (which seems to be the floor past which a signal is not read any more). Such constituted array has the same beacons in the same positions at all times (even across app launches). I compute a 5 seconds moving average for each beacon (so a I se 5 arrays to do that). The resulting avg array is then shifted up by 95 units and normalised so that the sum of all of its values is one. If you want to tag an an indoor "point" you collect many of these normalised average arrays on that specific spot. I go ahead and construct a database of "spots". To forecast your proximity to any spot in a database you simply compute a quadratic distance of your current reading and the all of the fingerprints in the database.
Which beacons to use? At least class 2 in power. How many? At least a couple per room (put them in two adjacent corners, on the ceiling or high up).
The last step that you need to do is match the fingerprints with an x,y coordinate on your map. I never did this step, because I am mainly interested in proximity applications and not fully fingerprint and indoor space.
Perhaps the discussion above will serve you as a guidance on a technique that is used by many indoor location companies.
Disclosure: I have recently open sourced my code doing the above calculations.