I have an embedded wireless driver for wireless communication that I would like to run in a simulated environment so that I don't have to own hundreds of the devices to test my code.
Ultimately I would like to be able to specify a network connection between nodes, which would be an instance of the C++ code that is used in the embedded device. The connection should simulate the wireless medium such that no packets arrive to the node whilst it is transmitting and no packets arrive at the node if two or more nodes are trying to transmit. Connections modelled by a basic connectivity graph.
I wonder if such a model is possible in the Python Twisted framework. If it is not are there any networking frameworks that would make such a task simple.
Language preferences are Python or Java.
Thanks.
You can use Network Simulator 2 (NS2). Its a awesome network simulator. Its uses C++ and TCL.
Related
My requirement is, there are four ethernet switches connected in a straight daisy chain manner. But no ring/loop is formed. To each switch's PHY ports, there are I/O modules connected. A main CPU is interfaced to the first switch.
My problem is how will the main CPU the location of these ports(I/O modules)? Is there a way to send the MAC table data to another device/switch connected in the same network via a port.
Thanks
Need any other possible ways to implement this.
I want to know if it's possible to use a BLE module for both mesh networking and point-to-point connections at the same time.
Rationale:
The embedded linux (EL) product that I am designing needs to be able to connect to BLE peripherals like a heart rate monitor (sports grade, not medical) and the product needs to communicate with others of its kind.
I also need a very low power way of sending data from all EL devices to the internet. Ideally with only one of the products supplying a connection to the internet.
I am open to other solutions or reasons why this might not be a good approach even if it's possible.
Here is a rough block diagram of what I'm trying to achieve:
The block diagram does not show a HR connected to every EL device, however this would be a possibility as well.
Green = Embedded Linux Devices
Red = Heart Rate Monitors
Blue = An internet connection to the cloud
Yellow = connections between Embedded Devices
Option 1 - WiFi
The first option I considered was a wifi connection between the EL devices, however this will consume much more power than BLE.
Option 2 - BLE mesh
Using a BLE mesh seems like the best solution, if and only if, it's possible to do point-to-point connection at the same time.
Yes, this behaviour is specified in the BLE Mesh Profile specification in chapter 2.3.11. What you are looking for is a Proxy Node:
Proxy feature – the ability to receive and retransmit mesh messages between GATT and
advertising bearers.
Also take a look at the Ultimate Mesh Tutorial where they also describe the proxy node:
To allow communication with a mesh network from a non-mesh-supported BLE device, a special type of node called a proxy node can be utilized. A proxy node acts as an intermediary and utilizes GATT operations to allow other nodes outside of the mesh network to interface and interact with the network.
The protocol used in this case is called the proxy protocol, which is intended to be used with a connection-enabled device (using GATT).
This is of course hardware and software dependent. Not every hardware or software stack supports BLE mesh functionality.
The wikipedia article for Bluetooth mesh networking has a list of currently availible software stack supporting BLE mesh.
I would like establish a mesh network using Zigbee modules and ATmega8.
I need some basic c routines for establishing the network. My Controller is running with ATmega32. and end nodes will be on ATmega8.
I want plug and play wireless connection between Controller unit and nodes.
Please help me.
The Digi XBee series of RF modules is popular for plug and play wireless. In it's simplest configuration, a pair of modules operates as a serial cable replacement, with bytes going in on one module coming out on the other.
If you want to have a multi-node network, you'll have to use the radios in API mode, where frames include a header with addressing information and checksum in the footer. Digi has released an ANSI C XBee Host Library as Open Source on GitHub that could be a good starting point for that since you mention using C. It looks like there's even a fork of the library targeting the AVR platform.
#user2031622, zigbee nowdays has builtin microcontroller such as CC2530 provided by TI stack (Texas instruments).CC2530 has a inbuilt 8051 microcontroller which supports mesh networking.
Why is it must that all interfaces (routers and bridges) involved support LRO/TSO technique ?
Routers don't. Bridges do.
External routers, hubs, switches or anything else that is externally connected to the network will not see the effects of TSO, only interfaces inside the device with TSO will experience any effects - it's a software thing.
A router is an external device which is connected to the network by ethernet cables, fibre optic cables, wireless comms etc. These communication mediums adhere to internation standards such as 803.2 for ethernet or 803.11 for wireless - they're hardware devices, and hardware devices have very strict rules on how they communicate.
A bridge is an internal software construct and is specific to your OS.
Let's use 803.2 (ethernet) and a linux host for an example.
An application calls for a socket to be created and then pushes a large data chunk into the socket. The linux kernel determines which interface this data should be transitted on. The kernel will next interrogate the driver for this interface to determine its capabilities, if the interface is TSO capable the kernel will pass an sk_buff with a single "template" header and a huge chunk of data (more than 1 packets worth) to the interface driver.
Let's consider a standard interface straight to a hardware NIC first:
Some interfaces have fake TSO (they segment the packet in the driver) and some have true TSO (the template header and data are passed to the hardware with minimal alterations). At this point ether the driver or the NIC hardware will convert this large segment of data into multiple, standard compliant, 803.2 ethernet frames, it is these compliant frames that an external device, such as a router, hub, switch, modem or other host will see on the wire.
Now let's consider several NICs behind a software bridge:
Although the kernel is aware of each NIC at a low level, the network stack is only aware of the bride, thus only capabilities that ALL of the underlying NICs have should be passed up to the bridge. If an sk_buff is passed to a bridge, then ALL the interfaces in the bridge will receive the same sk_buff. We'll assume that the kernal has once again passed our large TSO sk_buff to a bridge, if any of the underlying interfaces does not support TSO then the packet will most likely be dropped by the hardware NIC in question.
In summary:
Worst case scenario is the bridge will repeatedly retry to send the same data chunk on the broken interface and the whole bridge will lock up until the application decides to give up. Best case scenario, the non TSO NIC will simply appear to be dead.
That said, if the NIC has unsafe code in its driver then this could cause a segmentation fault that could bring the whole system down.
My application will be having many microcontrollers with sensors monitoring a large area. The application requires all these microcontrollers to send the data to the master microcontroller. From the master microcontroller the data must go to desktop PC via serial connection and to a mobile application. Which one (Zigbee/GSM) will be suitable?
This completely depends on what you mean by "Wide Area." A few hundred square meters? A few hundred square kilometers? Zigbee is more cost effective and simpler to implement if you're within range. You could even mesh your nodes together to extend the collective reach of your network. Otherwise, well, you have no choice but to use something like GSM.
RF Line-of-sight range on readily available XBee Modules can be up to 2 miles. Higher power models can be had with 40 mile LOS range.
If you are within range, I would recommend ZigBee as that saves you the cost from having a sim-card in each device.
Buy zigbee modules that have SDK and HW ability for mesh networking. That will give you ability to talk to far nodes via routing nodes. Unfortunately zigbee can not do adhoc mesh networking so you need to know in advance what your routers will be, or to program your nodes routing your self. Another 802.15.4 module (by Synapse) can solve all this since it supports ad hoc mesh networking for you via SNAP protocol. It is not zigbee compatible, but Synapse modules are already adopted by big players like Garmin so this should not bother you. They also run much longer on batteries then zigbee modules. They can also give onboard analog and digital IO accessible without need for additional MCU (although you can connect it and give control to it if you wish). There is also USB stick that will enable your PC to talk to these modules.