i have 3 Xbee s1 module, and want make mash topology network with Bidirectional communication.
The system I'm trying to make is:
about xbee module x1, x2, x3, (x1 is end device)
1 - x1 sends a message to x2, and x2 responds.
2 - when x1 receive a message, x1 sends a message to x3.
3 - when x3 receive a message, it sends respond to x1.
From what I've looked for, xbee didn't seem to be able to communicate between end devices in mash form.
Please advise me if it is possible to make, and what part of xbee should I study for it.
thanks...
Related
In every 5G diagram, they have the N1 interface directly connected to the UE. Is it really a direct connection? or is it still going through the radio? If so what is the difference from N2?
RAN uses N2 (control plane) and N3 (user plane) to interface to the core and transparent N1 interface to the user devices. N1 is a transparent interface from 5G-UE to AMF of core(via NG-RAN).
N1 interface is used by UE for transmitting non radio signalling between UE and AMF (something like NAS) which includes information related to connection, mobility and session related messages to the AMF which handles cases related to connection, mobility messages, but forwards session management info to SMF.
N2 interface supports control plane signalling between RAN and 5G core covering scenarios related to UE context management, PDU session/resource management procedures. N2 uses SCTP (NGAP) between 5GCN and access network.
N1 is for the Non-Access Stratum (NAS) protocol between the core network and the handset, N2 is a network interface between the core network and the base station.
N1 : Between UE and AMF (The N1 interface is used by the UE for non-radio signaling mainly NAS layer signaling.)
N2: Between gNB and AMF
N1/N2 : between gNB and AMF (supporting UE and non-UE related services.)
and 3) both are valid between gNB and AMF.
The N1 is a direct connection between the UE and the 5G core network (AMF). As any connection is transmitted over the air, and it´s therefore a radio connection at whichever frequency. The difference here is that the NAS messages are transmitted "transparently" through the radio protocol stack within the gNodeB (without being processed through the L1-L3 layer stack, where PDUs get headers/padding added), but it is still going "through" the radio, there is no real (as in physical) connection between UEs and 5G core (actually the 5G core can be located many miles away from the gNodeB). Hope it helps.
I need to implement the following scheme (in C, however the language is not the case here):
client(192.168.1.2) <-> proxy(addr4: 192.168.1.1:1000, addr6: FE80:0000:0000:0000:0202:B3FF:FE1E:8329) <-> some_remote_host(remote_addr6)
The thing is addr6 on proxy side must be dynamically changed according to incoming ipv4 port. For example:
client connects to 192.168.1.1:1000, outgoing connection is made via addr6_0
client connects to 192.168.1.1:1001, outgoing connection is made via addr6_1
etc ...
The most straight-forward implementation would be: assign multiple static ipv6 addrs to ethernet interface and use bind() on socket before outgoing connection. The problem is that the number of incoming ports/outgoing addrs can be ~10000 (and as far as I understood recommended value for net.ipv6.conf.all.max_addresses is 32 or 64, default is 16).
The questions are:
What possible problems can I expect if I assign 10000 ipv6 addrs to one interface, I assume performance issues?
Is there a better way to achieve the goal?
I tried to change ZigBee's PAN ID and node discovery, but as soon as I changed its PAN ID, I received a modem status packet (0x03) that apparently described disassociation. After that, I send ATND command for node discovery, and I got modem status (0x06) -- coordinator start, but no discovery result.
I found that if I send any ATND command again after first ATND command, it worked as I expected. Why was a disassociation packet received from ZigBee after I changed the PAN ID?
When you change the PAN ID on a coordinator, it's shutting down one network (disassociation) and then creating another (coordinator started). You then need to wait for nodes to join that new network before you can discover them. It doesn't make sense to perform node discovery on a device that isn't currently joined to a network.
If you set ATJN to 1 on the coordinator, the host will receive Join Notification frames (type 0xA5) as devices join the network. Maybe this is what you're looking for?
As a part of my project I am using XBee. I want sample Python code to make two XBees to communicate with each other in Windows. I have written code, but it has a problem.
What would like to sent a message like "hello" from one XBee, and it should be printed on the other XBee side. How can I do this?
Take a look at the great python-xbee library, and Digi's examples.digi.com as two excellent resources for someone new to the XBee. Between those two sites, you should be able to get your XBee radios joined to each other (using the second link) and then get them working in Python (with the first link).
Before doing anything else you have to configure the devices, use XCTU software:
First device - Coordinator API mode:
- ID 7777(or any random value)
- DL set to FFFF
Second device - Router AT mode:
- ID 7777(has to be the same for every device)
- DL set to 0
Code for coordinator (listen mode):
import serial
import time
from xbee import ZigBee
PORT = "COM1" #change the port if you are not using Windows to whatever port you are using
BAUD_RATE = 9600
ser = serial.Serial(PORT, BAUD_RATE)
# Create API object
xbee = ZigBee(ser)
# Continuously read and print packets
while True:
try:
response = xbee.wait_read_frame()
print("\nPacket received at %s : %s" %(time.time(), response))
except KeyboardInterrupt:
ser.close()
break
Code for the remote device:
import serial
PORT = "COM1" #change the port if you are not using Windows to whatever port you are using
BAUD_RATE = 9600
ser = serial.Serial(PORT, BAUD_RATE)
while True:
try:
data = raw_input("Send:")
ser.write(data) #if you are using python 3 replace data with data.encode()
except KeyboardInterrupt:
ser.close()
break
Run the code and send data from the remote device to the coordinator. You will be able to see the packets printed in the console and in the rx_data field will be the payload.
I hope this is helpful.
Not terribly familiar with ALSA, but I'm supporting an application that uses it.
Is it possible to record audio from both the mic and line-in simultaneously? Not necessarily mixing the audio, though that is a possibility that has been requested. Can both be set to record and use ALSA to read each individually?
Documentation on ALSA is not terribly helpful, and this is basically my first sojourn into sound mixing on Linux using ALSA.
Any and all help would be greatly appreciated; hoping there is someone out there that has done something like this in the past and either has a sample to share or a link to point me in the right direction.
Maybe this can be done: Not sure, but from http://www.jrigg.co.uk/linuxaudio/ice1712multi.html ,not tested, but this will give you 1 virtual device with 4 channels.
pcm.multi_capture {
type multi
slaves.a.pcm hw:0
slaves.a.channels 2
slaves.b.pcm hw:1
slaves.b.channels 2
bindings.0.slave a
bindings.0.channel 0
bindings.1.slave a
bindings.1.channel 1
bindings.2.slave b
bindings.2.channel 0
bindings.3.slave b
bindings.3.channel 1
}
I dont know if you can mix them with route or the correct sintax:
pcm.route_capture {
type route
slave.pcm "multi_capture"
ttable.0.0 0.5
ttable.1.1 0.5
ttable.0.2 0.5
ttable.1.3 0.5
}
or
pcm.route_capture {
type route
slave.pcm "multi_capture"
ttable.0.0 0.5
ttable.1.1 0.5
ttable.2.0 0.5
ttable.3.1 0.5
}
If someone test, please tells us the results? Thank you!
I wish you luck!
arecord -l will give you a list of available capture devices. In my case:
**** List of CAPTURE Hardware Devices ****
card 0: M2496 [M Audio Audiophile 24/96], device 0: ICE1712 multi [ICE1712 multi]
Subdevices: 1/1
Subdevice #0: subdevice #0
So, with my card, you would be out of luck - there is only one device (i.e. only one distinct source). This device will give you all data routed to it by hardware, as configured by an external mixer application.
With some cards it might, however, be possible to route MIC to channel 1 (left) and LINE to channels 2 (right), and then record 2 channels, separating them as needed in your application. Of course, if supported by hardware, you could also use two channels each and record four channels.