I want to implement an protocol with two radios switched on different frequencies. Can I just add an additional PhyLayer80211p module in the Nic80211p module?
If so, how do I address them? If I see it correctly, the findModule method used in Mac1609_4.cc:37 has no attribute to specify which Phy-module he should return. That way i can't specify which of the two radios should be set to RadioState TX (as well as which frequency it is set to).
Would it differ automatically between the two channels if i just send a message two the right gate to the phyModule and set them on seperate frequencies before? e.g.
sendDelayed(mac, RADIODELAY_11P, lowerLayerOut); vs. sendDelayed(mac, RADIODELAY_11P, lowerControlLayerOut);
Any other tips? Thanks!
Related
I am developing a model on RepastHPC, where I have multiple types of agents inhabiting the same discrete grid projection. On each tick the agents of one of the types need to query the grid projection and find the agents at their current location. However, they need to only consider the agents of a specific type. I use Moore2DGridQuery to get all agents at that grid position, however I cannot find a quick way to filter the set of agents to only get the agents of a specified type. I am currently iterating normally through the vector of agents, however that could result is slow-downs when I have great counts of agents running in the model.
Is there any way I could filter them quicker? Thanks in advance!
Unfortunately, I don't think there's a quick filter you can apply. If you iterate through the vector as part of the model behavior you could check the type there, or use the standard library to copy only the agents you want into another vector. See https://www.cppstories.com/2021/filter-cpp-containers/
I'm working with veins and OMNeT++ in a scenario that has different types of nodes (cars, pedestrians, and others). For evaluation purposes, I'm getting the std::map using the TraCIScenarioManager::getManagedHosts method based on this post (I also answered one of my related questions).
Now, I want to check the type of each node in the scenario. To be clearer, I want to obtain some kind of list that indicates the type of each node (is it a pedestrian? Is it a bus?). Is there any way to obtain this from the map? Is there any attribute that identifies the node type?
I already can identify the type of nodes through messages adding specifics tags to it, but now I need to obtain the type of node independent of the arrival of messages.
I really appreciate any help you can provide.
TraCIScenarioManager::getManagedHosts returns a std::map<std::string, cModule*> which maps each SUMO identifier to one OMNeT++ cModule*. Depending on how cars, buses, etc differ in your simulation, I can think of multiple ways of figuring out what type of SUMO object a host models.
Maybe they are named differently in SUMO? Then you can use the std::string to tell them apart.
Maybe they are named differently in OMNeT++? Then you can use getFullName() of the cModule* to tell them apart.
Maybe they use different C++ classes as models for their application layers? Then you can use something like getSubmodule() of the cModule* to get a pointer to their application layer module and check if a dynamic_cast<ApplicationOfACar*> of this pointer is successful.
I'm trying to model a port that consists of several signals. Each signal can be one two signal types. Each signal type has a signal level and impedance. Some signals have a pulse duration. What is the best way to model this? I have made an interface port with each signal represented as a flow property. Then I made two value types each with its own constraints on impedance and voltage level. Each signal in the interface block's flow property list is then marked with the value type. Is this the best way to do this?
Thanks
Since each "signal" has several properties a way to bind the set of properties together is needed. I would therefore use an Interface-Block for each "signal".
Please note, that SysML uses the word "signal" with a different meaning.
While it is possible to use flow properties, I don't think they are the best fit here. Usually they are used to show that something is flowing. The thing flowing here would be electrical charge - and this is probably not the level of detail appropriate here. We could say, that the information about the voltage is flowing, but what about the impedance?
So, my suggestion is to use required value properties:
These can then be used individually, or as nested ports, when a grouping is required:
Veins supports several analogue models for the wireless channel to address the large-scale, medium-scale and short-scale fading.
If I would like to try different models to compare them, which models should I set in the config.xml?
For example, can I try SimplePathLossModel+SimpleObstacleShadowing+NakagamiFading or BreakpointPathLossModel + LogNormalShadowing+JakesFading? What are the sensible combinations here?
Thanks!
As far as I know you can only use 2 analogue models at the same time and also the sensitivity would depend on what you want to emphasize in your output signal.
In my default Veins scenario (the one in the example) I need a second antenna on my car. In Car.ned I entered the following code (doing copy and paste from connections block):
nic2.upperLayerOut --> appl2.lowerLayerIn;
nic2.upperLayerIn <-- appl2.lowerLayerOut;
nic2.upperControlOut --> appl2.lowerControlIn;
nic2.upperControlIn <-- appl2.lowerControlOut;
veinsradioIn2 --> nic2.radioIn;
Now I have two antennas on my node (and they work!). But how can I decide who sends and who receives? In this way I just changed the topology of the network, but I can't handle the communications! I need to reach this scenario: node->node (first antenna) and node->RSU (second antenna). I think I should work on TraCIDemo11p.cc and TraCIDemoRSU11p.cc, but the code is immense and I get lost too easily. The final target is to make sure that these two antennas work with different protocols, but at the moment I make do with the same protocol and with these two different channels I mentioned earlier.
It's a bit difficult to give a concise answer to your question, because it has multiple components, but here are some important things you should look at:
First off: right now, what you've done is specified a car with two network interfaces (nic and nic2) and two separate applications (appl and appl2). I think, by your description, that is not what you want. I would suggest that your first step is to create an application interface that has connections to two network interfaces. This means creating the corresponding .ned file. You can use ./veins/modules/application/traci/TraCIDemo11p.ned as an example. Make sure to define your application object appl (in Car.ned) as that .ned file and connect both of these in the way you described. You'll then have 8 channels from your application to the two network interfaces (I'd call them appl.nic1LayerIn, appl.nic1ControlIn, appl.nic2LayerIn and so on).
After that, you will want to write logic that decides whether a particular message should go to the one network interface, or to the other, and put that code in your application's source. To communicate with the different network interfaces you'll just use the respective channels. To see how this works you'll need to dig in the veins source code a little bit: the code interacting with the channels is not directly in the TraCIDemo11p source, but somewhere in a super class there-of (I think it is BaseWaveApplLayer, but I'm not 100% sure). You could either modify those files to work with multiple antennae, or create new source files -- I'm not sure which one is less code, though.
Another thing to remember is that you'll need to provide the corresponding settings in the omnetpp.ini too (*.**.nic2..., analogous to *.**.nic...). I'm not sure what veins will do with two antennae at the same position (it might lead to some weird effects), but I also don't remember where the antenna position is specified.