If i buy 7 xbee-zigbee. I setup xbee modules like this.
1 coordinator (C)
3 router (R1-R2 -R3)
3 end device (ED1 - ED2 - ED3)
Can a router scan all end device with "AS" (active scan) command?
Result must be like this;
R1 get rssi value from ED1 : -90 dbm
R1 get rssi value from ED2 : -60 dbm
R1 get rssi value from ED3 : -80 dbm
R2 get rssi value from ED1 : -40 dbm
R2 get rssi value from ED2 : -55 dbm
R2 get rssi value from ED3 : -89 dbm
R3 get rssi value from ED1 : -23 dbm
R3 get rssi value from ED2 : -10 dbm
R3 get rssi value from ED3 : -70 dbm
Is this possible? Or is there another way?
Devices will only respond to a Beacon Request (Active Scan) if they are in the "RX on when idle" configuration. This mostly means Routers (and the Coordinator).
There are a few different types of End Device. If they indicates in their Device Announce message that they are "RX on when idle" then they should respond to Beacon Requests. Very few devices actually work this way (a few light bulbs). Most End Devices are battery powered and will not respond to Beacon Requests because they aren't on to hear them.
The ATAS command was designed for network discovery, and you use it when you aren't connected to an active network. The XBee module will scan multiple channels for networks and dump information on each beacon it receives on those channels. Since you can't join a network through an end device, you're not going to see beacons coming from those devices.
You might be more interested in exploring the ATND (Node Discovery) command, for getting a list of devices on the current network.
Mvut from digi said this:"you can use the S2C ZB module and use the ZDO commands to report the Link status." Any body try this?
you can try API mode , it can sent Remote AT command(0x17) and sent back response(0x97) .
something like:
7E 00 0F 17 01 00 00 00 00 00 00 FF FF FF FF 02 64 62 23
0x7E - package start
0x00、0x0F - package length
0x17 - frame type
0x01 - ! this byte is important about if you want to get the response or not
...
I hope it can help for you~
Related
I'm trying to scan the list of available networks and enumerate the security type for each SSID. I'm at a point where I can issue a SIOCSIWSCAN ioctl and parse the results. However, when I try to differentiate between a WEP network and an open network, I seem to be getting the same type of IE from the AP.
For example, I configured my Dlink DIR-655 router to be of open type vs WEP.
Since the network is a WEP network, I look for the hex byte 0xDD to tell me that this is an IE describing a WPA/WEP/open network. For this case, I only get one byte that says 0xDD for both open and WEP networks and the corresponding IE looks the same for both:
DD 18 00 50 F2 02 01 01 83 00 03 A4 00 00 27 A4 00 00 42 43 5E 00 62 32 2F 00
Does that mean that the router doesn't populate information about open networks under the byte 0xDD and I should be looking somewhere else?
PS: I've been reverse engineering the source from iwlist to tell me how to read the IEs returned. But they only seem to be describing WPA and WPA2 networks
It's not a duplicate. I've read em all.
I have a Nokia-N8-00. It's music player supports USLT (UnSynchronised Lyrics/Text). I use a tool called spotdl (https://github.com/Ritiek/Spotify-Downloader) that fetches song titles from "spotify" and downloads them from other sources (generally youtube) and merges metadata as well.
The problem is then, the music downloaded by that tool have lyrics on all my devices except N8. Fortunately, I got a music that had embedded lyrics that is supported on my phone too. I then analyzed both the files and found that in binary sequence, they have a very little difference (just for USLT section but they are different songs). The differences are :-
The one that supports :
55 53 4C 54 00 00 0A 56 00 00 03 58 58 58
The one that doesn't :
55 53 4C 54 00 00 07 38 00 00 01 58 58 58
(These sequences are for "USLT" declaration in the file)
I think it's an encoding difference. If I am right, what encoding is present and in which one? If it's not encoding, what is it?
I know these sequences can't elaborate the situation. So, here are the files I'm trying https://github.com/gaurav712/music.
I don't need supported USLT, I am just curious about it as I wanna make an implementation of it in C (I don't need language specific help though).
Here is what I got:
55 53 4C 54
Translates to:
USLT
So we got that right. Now, I believe we can merge that result with this answer:
Frame ID $xx xx xx xx (four characters)
Size $xx xx xx xx
Flags $xx xx
Encoding $xx
Text
(Taken from: ID3v2 Specification)
(or see this: https://web.archive.org/web/20161022105303/http://id3.org/id3v2-chapters-1.0)
Now, I couldn't get this from the source (because the site was down) but there is also this:
Encoding flag explanation:
• $00 ISO-8859-1 [ISO-8859-1]
• $01 UTF-16 [UTF-16]
• $02 UTF-16BE [UTF-16]
• $03 UTF-8 [UTF-8]
So, according to these findings (which I'm not too sure about), the one that is supported is UTF-8 encoded and the one not supported is UTF-16.
EDIT
I've downloaded and viewed your mp3 files for further inspection. Here are my new findings:
First of all, we were correct about the encodings:
UTF-8 is on supported:
UTF-16 is on unsupported:
Does this mean you can just turn '01' into '03' and it'll magically work? I doubt. It depends on the driver. What if the driver sees '\x00' bytes and iterprets it as end of string (as in end of USLT payload). To test this, you can try manually converting the encoding on the file (by removing extra bytes).
Secondly, running eyeD3 on linux on both files, I recovered that:
supported.mp3 -> ID3 v2.4
unsupported.mp3 -> ID3 v2.3
Perhaps that's an issue?
Also, note that the location of USLT tag in both files are different:
supported.mp3:
unsupported.mp3:
On linux, there are further tools to give you extra information, if need be:
mp3info, id3info, id3tool, exiftool, eyeD3, lltag
Are a couple examples. However, I think the main problem is in the text encoding. I was able to recover the lyrics quite fine using the above tools. But some of the tools give different answers because of ID3 version being different and so on.
So I've been working on coding the C version of an SNMPGET request on linux. I open a UDP socket, form the message, and send it out only to continually get a reply saying the OID isn't found. The OID I was using was:
1.3.6.1.2.1.1.1.0
Hex:
00 03 06 01 02 01 01 01 00
After running tcpdump on the packets being sent by snmpget, I realized that even with the same OID the packet being sent actually contained the hex:
2B 06 01 02 01 01 01 00
When I tried that hex with my program it worked. So, question is, why is it 2B instead of 01 03? I've looked everywhere but I can't wrap my head around the logic of it. It seems that every SNMP get message is sent this way where the iso.org translates to 2B but I've yet to see a reason why.
First two numbers (1.3 in your case) are encoded differently. The calculation will be:
1*40 + 3 = 43(dec) = 2B(hex).
That's the reason for your 2B.
Read this for more info.
And here is an online tool to encode/decode.
I have two XBee chips - one of them is connected to a relay switch, the other one - to my computer via USB cable.
I can configure the locally connected XBee to send its D0 value to the remote XBee, so that when I toggle the D0 line of the local XBee the remote relay switch toggles as well.
What I want to do is be able to send a command to the local XBee over its serial connection and have the local XBee send a command to the remote XBee that would toggle the relay switch without having to physically interact with the D0 line on my local XBee.
The XBees are S1, so they don't (seem to?) support ATIO command, at least my tests didn't show that working. I also tried using ATAP 1 with API command 83 as shown here but that didn't work.
The hardware setup works - attaching a button to D0 transmits its status to the remote XBee, so how do I get the same to happen with software alone?
You need to send a "Remote AT Command" frame, for parameter ATD0, as described in this page on Digi's website.
Although that page is for the Series 2 radio modules, if you look at the documentation for the Series 1, you can find the frame format for a remote AT command.
And, if you're going to use C to send the command, this Open Source, portable, ANSI C XBee Host Library includes a function process_command_remote() in samples/common/_atinter.c to send a remote AT command.
Finally figured it out, thanks for steering me in the right direction #tomlogic
The problem was that Digi's website doesn't tell you to set IA to 0xFFFF (allow all source addresses to change pin state), which by default is 0xFFFF FFFF FFFF FFFF (disable remote pin changes)
Found a better tip on this site.
This is what it looks like in XCTU for Mac:
Here are all the settings that differ from defaults one I got it to work.
Transmitter:
MY=7
AP=1 (API enabled)
D0=3 (Pin 0 Input)
IC=FF (Change detect all)
Receiver:
MY=2
D0=5 (Pin 0 High Output)
IU=0 (UART IO Disable)
IA=0xFFFF (Allow all to change pins)
The commands I used:
7E 00 10 17 01 00 13 A2 00 AA BB CC DD FF FE 02 49 4F 00 8D - Send remote ATIO 0
7E 00 10 17 01 00 13 A2 00 AA BB CC DD FF FE 02 49 4F 01 8C - Send remote ATIO 1
I have a project to create attendance system using MIFARE DESFIRE EV1 cards.
The reader brand that I need to use for this project only supports ISO 7816-x so I need to use DESFIRE ISO7816-4 APDU Wrapping mode to send commands to Card Reader.
I also have access to NXP document resources.
Up to now I can run A few commands like Get Version, Get Application IDs, Free Memory on card.
all these commands can be run in plain with no security required.
however I couldn't create application on this card yet.
I'm sure my command for creating application is correct but it is failing with code 0x7E (Length Error).
here is my create application code which is failing.
-> 90 CA (00 00 05) 414141 0F 0E (00)
<- 91 7E
I like to know:
Am I running the command in correct sequence?
Is it required to authenticate before creating applications in card
The last byte represent the number of keys you want to use in that application. For every Desfire card, only 14 keys can be created per application. So, the number of keys should be from 0x01 to 0x0E.
This command creates an application for me (with AES keys, hence the 0x80 bit in the num_keys byte).
(90) ca (00 00 05) 33 22 11 0b 84 (00)