Zigbee AT ND command can discover nearby modules if they are in same network (same PAN ID). So in order to find a module that I do not know about its pan id, the only thing came up to my mind was brute forcing pan id. Is there a better way to find out a module other than brute forcing pan id and repeatedly query ND command? I'm currently using libxbee library in c.
You can find nearby nodes by doing an "Active Scan" (ATAS). You'll get the beacons sent by nearby routers and coordinators, with their addresses and PAN IDs. You won't see responses from end devices, and you might not see responses from devices that aren't allowing joining (I can't recall whether they send beacons or not).
This ANSI C XBee Host Library on GitHub has sample code for doing a scan and parsing the results. You can either try that library, or use it to learn the structure of the responses.
Related
I could not find anything which provides the functionality that I want online. The only thing I could think of so far is using the text_search with different location types (e.g. schools, parks, ...) I was wondering if there is an easier way for this.
I also tried using the open street map but the locations that I get are mostly roads and residential areas names.
This is not exactly possible. Generally speaking, the Google Maps APIs are not intended to be used as databases for obtaining exhaustive lists of anything.
The closest you can do is Places API Nearby Search with rankby=distance and different type values. This is limited to the nearest 60 results.
First of all, I must say that I was very hesitant to post the following as I am afraid from getting down votes. However, I've spent days thinking about a solution and I haven't found one. My last hope is to get some answers in this post.
The Problem
Say that you have a large database of drivers connected in real-time to your backend, while you are fetching their lat/long each 5 seconds and posting it back to the backend so you update in real-time a driver's location. Let's suppose that we want to benefit form drivers and their positions to let a particular user find the closer connected driver to it (like in UBER,Lyft, etc..).
The question:
How is it possible to dispatch request to these drivers ? (I want you to share with me only you thoughts and ideas).
What you are looking is called "GeoSpatial search".
If you are looking for algorithms to implement then take a look at Nearest Neighbour Search
The most famous algorithm is k-Nearest Neighbours algorithm.
If you are only interested in using an existing implementation and build your application on top of it then there are existing databases & search applications which provide capability of GeoSpatial search.
Check Apache Solr which provides Geospatial search capabilities. https://cwiki.apache.org/confluence/display/solr/Spatial+Search
you just need to feed your drivers live location into this and query with current location of user. Solr will take care of finding the nearest drivers and you will get a search result with your matching criteria.
You can use this as a starting point to build your app with location based searches. In pratice, Uber, Lyft and other major services have their own in-house application with custom implementations.
Does anyone know of the logic behind a server-less chat client that would be able to interconnect not LAN-wide but internet-wide? It doesn't need to be able to detect other users world wide, it just needs to obtain some kind of unique identification to be able to connect to a user, like an IP or a unique ID of some sort.
To start, you need some information from somewhere. You can't just turn it on and start chatting without knowing where everyone is. You might have one node that is online all the time and knows a few other nodes. The other nodes would know other nodes and those would know more, etc. It is debatable whether or not you would call that static node a "server" or not. It could just be your friend's node, or a publicly available IP. Once you are up and running, you wont need the start node anymore.
In this type of system, you would need to query your neighbors if you want some sort of identification besides IP address. An IP address has its own drawbacks as well, because you might have two people behind a router at a home DSL connection. Unique ID's would require a recursive query across the whole mesh to find out if your ID is unique.
In this type of system, you would only need to know a limited subset of people in order to chat with anyone, as you can query everyone around you (and the query happens recursively) for the location of that person. An artificial limit on the number of people stored on the local node might be implemented with a Least Recently Used algorithm, kind of like a CPU cache.
Greetings!
The idea is simple. Let's say that I have a service wherein people can walk up to a kiosk and "pair their phone" with a bluetooth device on that kiosk. We'll ignore why people would do this, but let's say that they have an incentive to do so.
Let's say that I have convinced thousands (if not millions) of people to do this thing... and they're walking around with their cellphones with bluetooth ON. (Not discoverable.) How do I solve the problem of scanning for "known devices" if there is a possible pool of millions of known devices?
Again, I don't want to connect with them once I've actually done the initial pairing. I simply want to know they are proximate.
Thoughts?
Well, the first thing is that even if your kiosk has a Class 1 Bluetooth radio in it, which can actually go farther than the advertised 100 meters, it's still extremely unlikely that there will be millions of Bluetooth cell phones who have previously paired with your kiosk within the range of your kiosk's radio. So that narrows down the potential number of Bluetooth devices you're dealing with.
Second, if a device is not discoverable, then it doesn't matter if you've paired with it before or not. You will not find it using a general "Hello, is anybody out there?" inquiry scan. If you've paired with a device, you will know its Bluetooth Device Address and can therefore ping it explicitly and get an answer. This doesn't seem like a reasonable thing to do if you're thinking you might have millions of cell phones paired with your kiosk. (Have you thought about the fact that if you have multiple kiosks your users would have to pair with each kiosk separately? Do you really need to pair with the cell phones to do what you need to do?)
Having said all that, a general inquiry scan will produce a list of discoverable Bluetooth devices in the vicinity of your kiosk's radio. You could use that list to search your own list of devices paired with the kiosk. I can't remember if you get back just the friendly name in the first response or if you get a BD_ADDR as well. If you just get the friendly name, there could be multiple devices with the same friendly name, as I doubt many users change their phones' friendly names.
It's been a while since I really delved into the Bluetooth spec so things may have changed.
Pairing may be overkill: that's about establishing secure communications. Worse, ISTR some phone UIs don't separate pairing (having a secure channel) and trust (allowing the remove device to do stuff without asking the user whether it should), although I hope modern phones get this right.
If you just want the other device's Bluetooth address, you could get people to send the kiosk a business card or something. Or tell them to become discoverable and have your kiosk initially find them. Or they could pair, but as Kirsten says, they'd be paired with a single kiosk: you may not care if all you want is their address, though, rather than the secure channel.
Now you've got a list of Bluetooth addresses. You can share these addresses between multiple kiosks if you've got some sort network between them. In an ideal world, detecting proximity would then be a matter of performing BT inquiry (you don't even need full device discovery here, just knowing what addresses are out there is enough) and matching the addresses you get from that against your list. But that only works when remote devices are discoverable (which means they're listening for inquiry packets, doing what the spec calls inquiry scanning). If they aren't, you'd have to try to connect to each one in turn (you can drop the connection once you know the other guy is there). You could parallelise this with multiple BT radios, but you're looking at a few seconds per address per radio. You're doing the old "Redfang" brute-forcing that people got excited about a few years ago, but it's going to be slow: http://www.newswireless.net/index.cfm/article/924
Of course, if people aren't leaving their devices discoverable, the implication is they don't want to be found, so it's not surprising that this doesn't work.
I have a data card with me.
I wanted to know, is there any way programmatically I can tell that, it is data card or it is LAN card?
I have used IFTable, I have used IListManager, INetwork manager provided by Microsoft, but not able to solve the problem.
Edited
I have one lan card and one data card connected on my system, I want to do some operation on data card, but I don't know, when my data card is connected and when my LAN card, enumerating will give me list of all connections, but how to identify LAN and Data card among them.
You should clarify your problem. What problem are you trying to solve? Why do you want to distinguish the cards?
That said, some ideas:
If you just want to identify your specific cards, every network card has a unique ID (the MAC). You can retrieve it using networking tools.
If you want to identify the type of card, you can try to get PCI information, and look for a string. But that is difficult in the general case, because there are so many different types of cards. So you'd need to clarify your question.
There is no clear distinction between the different kinds of networks anymore. On the one hand, LANs have gone wireless with WiFi. On the other hand, public networks have gone local with femtocells. Hence, it becomes increasingly difficult to distinguish the two kinds of networks, and therefore the network cards connecting to them. There is no clear boundary.