Can anyone tell me how I can see all XBee modules linked in my Pan ID? I want to send from Coordinator the command and receive the number, and Network ID, of all XBee modules linked in same Pan ID.
My modules are all Series 2.
The command for this is ATND.
Just send the packet 0x7E 0x00 0x06 0x08 0x01 0x41 0x54 0x4E 0x44 0xCF to the coordinator.
Related
I'm trying to communicate between board and sensor with i2c but I can't quite figure out how to do it. in the datasheet i checked all the registers and how to access them and the address of the sensor. once this was done I retrieved the HAL_I2C_Mem_Write and HAL_I2C_Mem_Read functions from the HAL library for reading and configuration. for example, to enable the sensor clock and make the ADC work I have to write raise the last two bits of the byte of the register 0x00, so I wrote the following line:
buf[0]=0x03;
HAL_I2C_Mem_Write(&i2c2, address, 0x00, 1, buf, 1, 1000);
then when I go to read the register with HAL_I2C_Mem_Read I get the value 0. the same goes for the others, for example if I read the register 0x12 I get the decimal value of 0x12 and not its content. Where am I doing wrong?
I add that I have checked the correctness of the hardware connections between the card and the sensor.
I am having problem in finding the difference between between API 1 and API 2 mode of XBee . I have done my programming stuff and i have my master's thesis defence on Wednesday. I know how to use XBee but i am very weak in basics of RF. Please explain this difference in few basic words which i can speak in my thesis defense.
I personally don't like API mode 2 because it adds to the complexity of sending and receiving data unless you handle it at a low level of your serial driver.
The benefit of API mode 2 is that you can watch the byte stream and know that any 0x7E byte you see is definitely a "start of frame". With API mode 1, it's possible to see that byte within a frame's contents.
If you pick up a stream in the middle, you need to do additional work to verify you've found the start. It isn't very difficult to do, especially if you include a sanity check on the 16-bit frame length following the 0x7E start of frame. In most cases you'll be decoding complete frames and not need to look for the start of the next frame.
Since escaping also include XON and XOFF characters, I guess API mode 2 might be necessary if there are other devices in the serial stream (wired in between the XBee and the host sending/receiving frames) that can't handle those characters.
Edit to include details on API mode 2:
In either API mode, the byte 0x7E indicates start of frame.
In mode 2, if the following bytes appear inside the frame, they're replaced with an escaped two-byte sequence of 0x7D followed by the original byte XORed with 0x20:
byte in frame
escaped sequence
0x7E (start of frame)
0x7D 0x5E
0x7D (start of escape sequence)
0x7D 0x5D
0x13 (XOFF)
0x7D 0x33
0x11 (XON)
0x7D 0x31
Note that the frame length and checksum are based on the original, unescaped sequence of bytes. If you are writing code to handle escaping outbound frames and unescaping inbound frames, you want it to happen at a fairly low level of your serial driver.
everything is explained in here. good luck with your thesis
https://www.digi.com/resources/documentation/Digidocs/90001456-13/tasks/t_configure_operating_mode.htm?TocPath=XBee%20API%20mode%7COperating%20mode%20configuration%7C_____0
Its my first post here. Correct me if im wrong
I'm using free scale controller with G620 module for connecting to server.
I started to implement MQTT client.
The communication with G620 GPRS module through UART.
Through AT commands i connected to the MQTTbroker.
As soon as i sent the connect packet, broker closing the connection.
Need help or suggestion.
The connect packet is: { 0x10,0x12,0x00,0x04,M,Q,T,T,0x04,0x00,0x3C,0x00,0x00,0x06,Z,1,2,1,2,3
}
There are two scenarios the server is disconnecting you as per MQTT Protocol.
1. If you are violating protocol format
2. If the timeout of the connection is exceeded
Reasons for Protocol Violation termination:
- You might have wrongly framed out some protocol bytes. Cross verify with the protocol document.
- You might be already connected and trying to connect again. Check for server side logs if you have access.
- As you are sending the frame through UART, you might have used a for loop to send the bytes. If the for loop counter is based from "strlen(Connectpacket)", you will not get the exact count as "strlen" will terminate after 0x00. So the server will receive half packet and disconnects you for violation.
Your protocol seems to be invalid,
0x10 - MQTT Control Packet type
0x12 - Remaining Length
0x00 - Length MSB
0x04 - Length LSB
M
Q
T
T - Protocol Name
0x04 - Protocol Level
0x00 - Connect Flags
0x3C - Keep Alive MSB
0x00 - Keep Alive LSB
0x00,0x06,Z,1,2,1,2,3 - What are there bytes used for? Cross verify with protocol document.
Set clean session bit as 1. Set keep alive for 0x00 MSB 0x3C LSB.
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 interface with a module using the i2c protocol.
the modules(slave) address is 0x48.
What I am trying:
send 0x48(it's adress) to the module. After which I should receive an ACK.
But it seems as if i don't receive an ack or am I wrong?
If I do effectively don't get a proper ACK, how does it come?
All i do is reset the module, so it is in a known state and afterwards I just send 0x48 (and 0x00 as data).
for info: i am using a 32-bit ARM controller and 1k5 pullup resistors
an image of what I see on an oscilloscope: