I wanted to compare the energy consumption of directional vs omnidirectional antennas in WSN specifically. Couple of questions:
1-) How the direction of the incoming signal determined? In which parameter the nodes (both sender and receiver) can store it? simply I need to find out the signal's coming angle if possible. I guess there is sth in Castalia related to that.
2-) The coordinator node's coordinates should be specified, isn't it?
3-) Any tutorial on the Battery depletion models for Castalia?
4-) If I just accept/transmit signals from/to a certain direction (with higher gain) can this be regarded quick-dirty directional antenna? How can this be done?
5-) I need more examples on these, especially on 802.15.4 stuff.
Sorry just a beginner in Castalia...
Thanks...
There is no directional signal propagation model in Castalia, so you can't use Castalia for your purposes. You could built that model for Castalia, but this is a huge task.
There is no connection between the directionality of signal (physical layer) and the MAC protocol used (MAC layer). I am not sure why you are asking about it.
The battery model is yet another topic (note: it's better not to ask multiple unrelated questions within a StackOverflow question). Castalia's battery depletion model is a the most simple one: linear depletion. Other people have built more advanced models but I am not sure they are publicly available.
Related
I am working on a smartwatch project. I want the display to be turned off and only come on when the user brings his hand into the watch-viewing position.
I am running my application on the NRF52 MCU which means machine learning is out of the question. I am using a 3-axis accelerometer from STM.
How can I detect when a user moves his hand into the typically watch viewing position? How is this achieved in smartwatches?
I have the following ideas so far:
- Constantly poll accelerometer and calculate pitch and roll values. Then determine what range of pitch and roll values corresponds to this gesture. This seems a bit wasteful because the CPU will have to be always active.
Is there a simple signal processing algorithm or something similar that can achieve this?
Look into Galvanic skin response sensor - It can measure electrical connectivity of the skin.
When internal or external forces cause arousal — of any kind — the skin becomes a better conductor of electricity. Essentially, when you start to sweat, either from exercise or something else, the band will be able to monitor that.
Detecting when someone is sweating gives the software more information about what a user is doing, which allows for better health tracking. Being able to correlate the level of activity with a different source than just gravity from the accelerometer, allows these programs to take on a more trainer-like role — recommending specific exercises and levels of exertion.
Hope this helps!
I have a question about iBeacons. I've been checking the stability of the iBeacons by using different applications to detect them and the distance from the device to the beacons itself.
What I've noticed is that if two beacons are put directly next to each other or on top of each other, the distance isn't correct anymore.
So my question is, do iBeacons interrupt each others signal?
Thanks in advance.
Bluetooth LE beacons generally do not cause significant disruption in eachothers' signal. While they share the same radio band, there are multiple channels for advertising and the devices automatically detect collisions and retry transmitting when needed.
When you get in extreme density (hundreds of beacons in radio range) it can start to reduce detection counts for individual beacons, but this is an extreme scenario that is not what is described in the question.
For normal operations the above is true. For signal strength readings, any radio signals, noise, reflections or obstructions can affect the signal strength that is used to provide distance estimates. The important thing to note is that these are just estimates and many things can throw them off. Rarely are they very accurate.
I have a simple traffic light intersection in which I have already set the traffic light logic. Suppose the vehicle density is increasing in one road and I want to retrieve this data in Omnet and use the C++ logic to direct the traffic lights to change state. Is it possible to do this in Omnet++?
In short I am looking to control the traffic using the network information obtained by running SUMO and coupling through SUMO. Is it possible to control the traffic through Omnet++? If yes, then can you tell me an example of how to do so?
Veins already includes some TraCI commands to retrieve the state of a SUMO simulation, as well as to change traffic lights. SUMO includes many more TraCI commands which should be able to do what you describe. You would just need to implement them in Veins as well, building on what is already there.
I am doing a project on improving the transit times of buses using 802.11p. Currently I have a SUMO model made and simulating and I am moving on to modeling the network using Omnet++ and Veins. I have completed the TicToc tutorials to become familiar with Omnet++.
I am wondering how I could use the traffic lights in SUMO as Road Side Units in Omnet++. Would I need to write code in Veins to allow Omnet++ "see" the traffic lights as it does with vehicles?
Thanks in advance,
Ciaran
You are right: In order to model whether a transmission from a car to a certain "point" in the simulation is received, you will need to instantiate an OMNeT++ module (let's call it a Virtual Induction Loop, VIL) with an 802.11p radio at that position.
A design decision will be how to estimate where these VILs will need to be.
Naturally, VILs will need to be close to the lanes that are controlled by traffic lights. Each traffic light can control any number of intersections, so putting a VIL at the center of "the intersection" will likely not be possible. This means that, ideally, you would hand-pick the positions.
Alternatively, you can try to estimate a good position automatically. As of Veins 4a2, only rudimentary commands for traffic lights (such as to set a traffic light program) are implemented. SUMO, however, offers many more commands for reading traffic light information. If you implement the commands to enumerate which traffic lights exist, which lanes they control, and where those lanes are, you might be able to derive good position estimates for the VILs.
Partly a coding problem, partly math problem.
Q1. I have an iOS device with compass active. If it knows I'm moving through the field of an iBeacon - or the Beacon is moving through my detection range - would it be possible for a phone to work out (roughly) the relative direction/bearing of that beacon with a series of readings by comparing signal strengths? Has anyone had a try at this?
Q2. Would it be possible to change the Major and Minor values of a beacon regularly (eg: every second) to pass small pieces of info - such as a second user's Bearing and Course?
Q1. It MIGHT be possible but you would need a controlled environment. Either the beacon or the phone needs to be fixed. You also need to be in an area with no obstructions or sources of radio interference.
Then you'd need to use the signal strength (which is sloppy and varies by a fair amount) as one input, and the device's heading info (which is also grossly inaccurate) and do some petty gnarly math on it.
Assuming you could work out the math, the slop in the input readings might make the results too iffy to be useful. (For example, how would you distinguish moving directly towards the beacon from moving 30 degrees to one side or the other? The signal strength would still increase, just not as quickly.
And your algorithm would have to deal with edge cases like moving along a circle around the beacon. In that case the signal strength should not change.
My gut is that even with clever algorithms that input data is just too unreliable to make much sense out of it, beyond "getting warmer" and "getting colder."
As mentioned above, you'd have to track your device's movement within the field, including distance covered and direction, then with multiple readings of signal strength you could theoretically calculate relative direction to the beacon to some degree of accuracy.
As to your second question about changing the minor version number, I have not seen any beacon APIs that allow that, either from the beacon manufacturers or from Apple's implementation.
However, a typical beacon is an ARM or other low power processor with a BLE transceiver, running a program. In theory it should be possible to create your own iBeacon transmitter that changed one of the parameters in order to transmit changing information. You'd have to set up the iOS device with the beacon region only specifying the UUID or UUID and major ID (depending on whether you wanted to change just the minor or change both the major and minor ID in order to transmit changing information.)
Note, too, that iBeacons are a special case of BLE, and the BLE standard does support the sending of arbitrary, changing data. You might be better off implementing your own BLE scheme either instead of or in addition to iBeacons.