I setup a NonBeacon (w/Coordinator) network with three XBee Series 1 modules. One is configured as coordinator. The other two are configured as end devices. The firmware version and configuration are as below.
Firmare
Modem: XBEE Function Set Version
XB24 XB24 802.15.4 10CD
Coordinator
Parameter Value Comments
CH (Channel) 0x0F Identical
ID (PAN ID) 0x5241 Identical
DH 0x0
DL 0x0
MY (Source Address) 0xFF01 Unique
CE (Coord. Enable) 1
A2 (Coord. Assoc.) 0x04 allow end devices to associate to it.
End device
Parameter Value Comments
CH (Channel) 0x0F Identical
ID (PAN ID) 0x5241 Identical
DH 0x0
DL 0x0
MY (Source Address) 0xFF02 Unique
CE (Coord. Enable) 0
A1 (End Dev Assoc.) 0x04 allow associate to coordinator.
When end device 1 sends out the data, the coordinator can receive the data, but the end device 2 can't. I want end device 2 to receive data from end device 1 in this network. My current solution is to let the coordinator broadcasts the data, so end device 2 can receive it. I'm not sure if this is good solution to resolve the communication issue among end devices. Is there any other solution?
With Digi XBee 802.15.4 modules (also know as Digi XBee Series 1 modules), there is no penalty to using broadcasts on the coordinate to speak with your end devices.
If on the other hand you wanted to be able to establish communication between any two Digi XBee 802.15.4 modules you'd need to use unicast addressing. Unicast addressing is performed the following way:
Set an address on each node by setting the MY parameter to a unique value
Set the coordinator's DL parameter to the MY value of the *end device node you wish to speak with.
Note that each end device will always be able to speak to the coordinator (the node with CE set to 1) by setting DL to 0.
It can be very clumsy to have to change the DL parameter on the coordinator to be able to speak with each end device in turn. This is why many end up using the Digi XBee radios in API mode.
If you download the manual from the Documentation section of Digi XBee 802.15.4 Support Page, you'll find a section entitled "API Operation". If you set the AP parameter to > 1 it will enable this mode.
If you send some data from an end device to the coordinator in API mode you'll see RX frames (API type 0x81) emerge from the radio. Likewise if you send packets of a similar format using API type 0x01) and specify the MY address of an end device as a destination, you'll see the data emerge from the serial port of the end device XBee.
If you search for "XBee API library" you'll find lots of useful links for libraries which can speak to Digi XBee modules using your language of choice such as this handy one for the Java language
Related
I'd like to get the states of the relays on the board from the relay, but I can get only ACK back.
I have two XBee modules, one is connected to a computer with USB, and acts as a Serial device, the other is connected to a TOSR0X-T relay. I am planning to add more XBee modules to the network with more relays later, so I am using API mode, not the simple AT mode, because I need to address them separately.
I am sending TX frames with 64bit address to the remote XBee to open or close relays. That works fine, I get the ACK response frames properly. However if I send a message to get the relay states by sending 0x5B, I get back an ACK only, and I can find no way to get the actual data back indicating the relay states.
I am using node-serialport and the X-CTU software, but could not read the data, and the only example I found used both XBees connected to the same machine - that way an RX appeared on the destination XBee - but I need to get that remotely somehow.
TOSR0X-T documentation here only tells me about talking to it via TX messages, so I have no clue if I can achieve anything with commands (and how to do that).
The ACK you're seeing is likely the network-layer ACK, telling you that the remote XBee module received your packet. You need to use "AT mode" on the XBee connected to the TOSR0X-T, and address your TX API frames correctly for that mode (cluster 0x0011 of endpoint 0xE8).
If you've configured the XBee on your computer as the coordinator, the default settings of 0 for DH and DL on the relay's XBee module will result in all received serial bytes getting relayed back to the XBee on your computer, and coming through as RX frames.
After some experiments I could solve my problem.
Considering the CH (Channel) and ID (PAN ID) are matching - that is a requirement to be able to set up the network, I set up my XBees like this:
The Coordinator XBee (the one attached to the computer):
CE = 1 (for being coordinator)
MY = 0001
DH = 0
DL = 0
AP = 1 (in API mode)
The first End Point (the one attached to the TOSR0X-T):
CE = 0 (for being an endpoint)
MY = 000A (whatever you want), use FFFF for 64 bit responses
DH = 0
DL = 0001 (This is one I missed. It should be the Coordinator's MY)
AP = 0 (in AP mode)
So basically I did everything right, except the DH/DL addressing. For the Endpoint the DL must be set to the MY of the Coordinator. I read some articles where using FFFF and FFFE and things like that to set broadcasting, and I think I was confused by those informations.
I have a sound processor device with MIDI interface over USB. I would like to control the device from my PC besides the official app to the device. However I don't have the command protocol description.
I could get managed to dump a couple of USB packets to the device with the help of usbmon. They look like:
0x0B 0xB0 0x00 0x00
0x0C 0xC0 0x05 0x00
If I send this command from my app, then the device activates program no 5.
The protocol seems to be MIDI, but if I follow it and try to interact with another functions of the device, I get no desired result.
So, I am looking for any help to get it working. For example I need to learn how to select an effect or control the volume and another parameters.
Regards,
Dmitry
You'll find what you need in the Universal Serial Bus Device Class Definition for MIDI Devices and the MIDI specification.
Your example consists of two packets, each containing a MIDI event. They can be decoded as follows:
cable: 0
event: control change
channel number: 0
controller number: 0 (bank select)
controller value: 0
cable: 0
event: program change
channel number: 0
program number: 5
The Zoom G3X device uses the standard USB MIDI protocol.
However, just because it uses MIDI messages does not automatically imply that you know what these messages mean.
There are additional standards, such as General MIDI, but when the device is not a 'normal' synthesizer but an effect processor, most standard messages would not make sense.
To find out what MIDI messages the device accepts, look into the documentation.
If the messages are not documented (like in this case, where the device was meant to be used only with the supplied software), you have to do the changes on the device, and record any MIDI messages that it sends out (with amidi --dump, or aseqdump).
If the device does not send out messages to show changes in its current status, you have to capture the messages sent by the official app with a USB monitor (like usbmon in Linux).
I am trying to communicate to the Nonin Pulse oximeter device to read the data (Pulse rate and SPO2 level) via Bluetooth. Nonin device supports SPP and HDP profile. I want to communicate through SPP profile. I am able to scan and pair with the device by the sample code available in Bluez.
Please tell me next steps how to send command and read data from the device. I have got struck at this point.
I realize this is a late response, but I recently setup data acquisition from a Nonin PalmSAT 2500A VET unit. I am using the RTC-1000 cable and an RS232 to USB converter.
This is straight from the manual:
"Information from the device, in the real-time mode, is sent in an ASCII serial format at 9600 baud with 9 data bits, 1 start bit, and 1 stop bit. The data are output at a rate of once per second.
NOTE: The 9th data bit is used for odd parity in memory playback mode. In real-time mode, it is always set to the mark condition. Therefore the real-time data may be read as 8 data bits, no parity.
Real-time data may be printed or displayed by devices other than the pulse oximeter. On power up a header is sent identifying the format and the time and date. Thereafter, the data are sent once per second in the following format:
SPO2=XXX HR=YYY
where “XXX” represents the SpO2 value, and “YYY” represents the pulse rate. The SpO2 and pulse rate will be displayed as “---” if there are no data available for the data reading."
Link to manual:
http://www.proactmedical.co.uk/proshop_support_docs/2500aman.pdf
What model oximeter are you working with?
i'm writing a C program to manage certain aspects of a wireless network (Access Point + Client Devices)
One Part of the program runs on the Devices an another runs on the AP. The AP is a simple Linux-Station (a Cubietruck, later on exchanged with a Intel Celeron holding Board; Access Point setup with hostapd and dnsmasq)
Some features are already implemented. I've done a lot with cfg80211/nl80211 and a bit with Wext and some Communication Routines over BSD Sockets are standing.
But now a problem came up. In the C program running on the Access Point i need the Received Signal Strength of the associated Devices.
On the Devices everything works well. With nl80211 i can get nearly every information about the connection. But on the Access Point i don't know how to obtain the RSS. I've tried some nl80211 requests with some attributes but can't get it to work.
Sure, on the Devices it's easy, because they have a single connection. But on the AP i had expected something like a nl80211 answer with a linked list or nested attributes, but nothing. I checked the contained attributes of the answers from certain requests and the messages contain nothing usable.
Does somebody know how to solve this? It shouldn't be a big deal like that to obtain the Received Signal Strength of the associated devices on a WLAN AP.
Would be really nice if it were doable with nl80211 but another solution would also be welcome.
Maybe with some WiFi Package Parsing? I heared that there is something like a RSSI (Received Signal Strength Indicator) but i'm not familiar with it.
Thanks in advance
Here's a wrokaround: the wireless channel attenuation from AP to a station/device and from that station to the same AP are identical at the same time. So, if transmission power of AP and stations are all the same, stations may report their RSS to AP using you current solution, and the work is done. Surely tx powers at different stations may be different, but they are constant. So find them out and make adjustments accordingly. Here's a simple example:
AP tx power 20 dBm;
Station 1 tx power 15 dBm with RSS -37 dBm;
Then the RSS from station 1 to AP link should be -42 dBm
I want to setup an xBee network with four serial 1 modules. Any two of them can communicate with each other in two-way. The transmitted data is string other than a single byte.
My original design is to setup a nonbeacon (with coordinator) network: One module is configured as coordinator. The left three modules is configured as end devices. The coordinator broadcasts the data from end devices.
The communication workflow is: If end device 1 want to send data to end device 2, it sends data to coordinator first. Then the coordinator broadcasts the data received from end device 1. End device 2 can receive the broadcast data. The communication workflow finishes.
I want the received string to be atomic. If end device 1 and end device 3 send out the data in the same time, there would be conflict. The two strings would combined together. And the end device 2 can't distinguish which byte is from which device. That is, end device 1 sends out string "{AAAA}" (quotes aren't included). In the meanwhile, end device 3 sends out string "<2222>". The end device 2 may receive the string like "{A<22AA2A2}>", which isn't what I want. My expected string is "{AAAA}<2222>" or "<2222>{AAAA}".
How do I setup the network to meet my requirements?
There are two ways to achieve atomic transmissions using Digi's XBee modules. The method varies depending on if API-mode (AP parameter > 0) is in use or not.
If API mode is not in use (AP = 0) then the atomicity of data can be encouraged by setting the RO time to be greater than the number of characters of the longest string you are going to send from one of your nodes. This will make the XBee buffer wait the specified number of character times (the time it takes to send a character at a particular baud rate) before starting the over-the-air transmission. Note: you'll have to ensure that you send your entire string all at once to the radio in order for this scheme to work.
If API mode is being used (AP > 0) then it is very easy to get the behavior you want. You'll simply use the Tx Request frame (API frame type 0x1) and specify the string data you want to send. The data will always be sent atomically.
If API mode is being used on the on the receiving node (i.e. in this case, the coordinator) then the frame data will always arrive atomically as well.
Please refer to the Digi XBee 802.15.4 product support page for more information on how to use API mode and search the Internet for the many wonderful XBee libraries which allow you to use Digi XBee modules in API mode easily.