I'm trying to set up a practical DIY method of unlocking a garage or front door by coming into the range of a reader; even if that means standing in a specific line of sight. Essentially once I reach the garage, the ID is read and raises
I'd prefer to have passive ID's, but the reader itself would be able to have a fixed power source that doesn't need to be changed.
I've done a lot of searching on google and there are RFiD scanners that read cars to open tolls booths, but those are commercial grade products and much more expensive than anything I'm trying to make. Should I continue looking into RFiD's, or is there a more efficient method of approaching this?
Also, if my tags are active, and powerful enough, would that compensate for a low frequency reader?
You'll easily achieve to read passive tags from a distance of a few meters (up to 10m) by using any industrial UHF RFID reader (Impinj, ThingMagic, Stid, ...).
Some tags are similar to labels that can be directly stuck on the windscreen of the cars. Tags are rather inexpensive.
But in that case you will need to spend a few hundreds of dollars to buy a single reader with its antenna.
That is what makes me think that any RFID based system is an option only when the number of users of the system is quite important (i.e: check the access to a company park or to a residence).
In that case, the investment of the reader is dispatched on all the users, whereas the global investment for the tags stay low.
Related
I'm currently working on a project that requires gathering data from a car's wheel speed sensors(4 hall efect speed sensors). Those sensors are connected to the car's ECU responsible for ABS/ESP/Stability control etc.
In order to extract the data from the ECU i need to make a request with a specific PID(parameter ID) AND know how to decode/compute the answer in order to extract any meaningful data. Unfortunately vehicle manufacturers don't seem to make such information public.
So far i've ordered an arduino CAN BUS shield and a OBD2 to RS232 cable in order to make the physical connection.
I have tried using a specialized hardware/software(that costs more than 1500euro) capable of extracting those parameters, but unfortunately it lacks logging functions. I tried using Wireshark to sniff the PIDs called, but had no luck there either.
If you guys have any ideas, questions or suggestions, please write them down.
I'm open to criticism and know that i might be missing something important.
Thanks.
P.S. This is a university project im working on. I need data samples from the wheel speed sensors and further computing of the data sample is done with the purpose of researching car safety and behavior in dynamic road scenarios.
You can only read the OBD data from the OBD-port. The OBD PIDs are generalized in ISO/CD 15765-5. You probably find non reliable descriptions also in Wikipedia. But in order to get the other PIDs, firstly you should know that those data are heavily under control by the car manufacturers and you have to hack them. One way to find them (but very unlikely to find one!) is the try and error method.
You should access the main CAN-BUS wires and the buy a connector device so you can sniff the packets. then monitor all the packets and make a small change. Monitor it again and compare these two. Maybe maybe maybe you have a chance to find some non-safety features with this method but finding security functionalities like ABS is heavily in doubt.
UNLESS you are some sort of genius hacker who can do weird stuff! If you can do it, then call the manufacturer and show them what you have so you would likely get a nice job and salary by them!
ONCE I saw a youtube clip that a guy could control a TOYOTA (if I remember correctly) with a laptop! and also maybe you can buy such info on the dark web which I advise highly against it!
Can anyone tell me what major and minor (contained within the advertisement packet of BLE signals) are used for? I've heard that it's used for differentiating signals with the same UUID, but that raises questions like "why use two" and "is that just how certain receivers use it". It would be useful to have a decent explanation of it.
As per #Larme's comment, I presume you are asking about iBeacon advertisements - these are a special use of BLE. Bluetooth Low Energy service advertisements have a different format and don't include the major/minor.
The iBeacon specification doesn't say how to use major and minor - this is defined by the people that implement solutions using iBeacon. Two numbers just gives more flexibility.
A lot of effort went into making BLE use very little power. Accordingly the iBeacon advertisement has to be quite small in order to minimise the transmission time. I guess the designers decided two 16 bit numbers was a reasonable compromise between power consumption and a useable amount of information.
A typical retail use case could use the major to indicate a store (New York, Chicago, London etc) and the minor to indicate the department (shoes, menswear etc). The app that detects a beacon can then pass this information to a server which can send back relevant information - the user's location on a map or specials for that department etc. This was discussed in the guide that #Larme linked to.
A solution that presented information on museum exhibits might just use the major number to determine which exhibit the person was near and ignore the minor number. The minor number would still be in the advertisement, of course, the app just wouldn't use it for anything.
I have some information about magnetic cards that control the building access, and need to reverse engineer the way the software stores data on the cards to make something with more features. (We have lost contact with the original programmer.)
I have no idea how writing the order is done; I'm no magnetic card expert.
I know a few things:
Data is on the third track.
all readers are standalone and have batteries.
There is a master card that can add or remove some cards for a reader(currently, you need to go through all the doors to add or remove a card from the system).
Each card is different, and must have a unique identifier.
There is a expiration date, but I have no idea if it's a date format or just a number incrementing in the door readers.
There is a "flag" which gives access to special places (parking) and it isn't affected by the expiration date... weird.
I've got a reader and some software to read it. It gives me hexadecimal numbers.
As example here is a few cards I've got.
BAC716863B8CB32832BABAB40E1739BAB677563B3AF8BA3ABABABEBABABABABABAC0 (card with parking)
BDC011813CB9B4CBB53DBDB21FD2BCBDBEEA3EBDBDFFBD3DBDBDB1BDBDBDBDBDBDC0 (card with parking)
9DE031A11CA9912E951D9D9225369D1D9FCE6C9D1DDF9D1D9D9D9D9D9D9D9D9D9DC0 (normal card, no special access)
I just hope it's not secured by anything that could make this impossible to reverse-engineer.
This question comes up high on google, i experienced a similar issue and solved it.
Data on magnetic card encoded in ANSI/ISO ALPHA Data Format (on Track 1) and ANSI/ISO BCD Data Format (on Track 2 and 3). Most magnetic card readers decode this data before returning so you don't have to but some reader don't and here we are.
You can find encoding table and more information here: http://www.abacus21.com/Magnetic-Strip-Encoding-1586.html
Say you have a conference room and meetings take place at arbitrary impromptu times. You would like to keep an audio record of all meetings. In order to make it as easy to use as possible, no action would be required on the part of meeting attenders, they just know that when they have a meeting in a specific room they will have a record of it.
Obviously just recording nonstop would be inefficient as it would be a waste of data storage and a pain to sift through.
I figure there are two basic ways to go about it.
Recording simply starts and stops according to sound level thresholds.
Recording is continuous, but split into X minute blocks. Blocks found to contain no content are discarded.
I like the second way better because I feel there is less risk for losing data because of late starts, or triggers failing.
I would like to implement in Python, and on Windows if possible.
Implementation suggestions?
Bonus considerations that probably deserve their own questions:
best audio format and compression for this purpose
any way of determining how many speakers are present, assuming identification is unrealistic
This is one of those projects where the path is going to be defined more about what's on hand for ready reuse.
You'll probably find it easier to continuously record and saving the data off in chunks (for example, hour long pieces).
Format is going to be dependent on what you in the form of recording tools and audio processing library. You may even find that you use two. One format, like PCM encoded WAV for recording and processing, but compressed MP3 for storage.
Once you have an audio stream, you'll need to access it in a PCM form (list of amplitude values). A simple averaging approach will probably be good enough to detect when there is a conversation. Typical tuning attributes:
* Average energy level to trigger
* Amount of time you need to be at the energy level or below to identify stop and start (I recommend two different values)
* Size of analysis window for averaging
As for number of participants, unless you find a library that does this, I don't see an easy solution. I've used speech recognition engines before and also done a reasonable amount of audio processing and I haven't seen any 'easy' ways to do this. If you were to look, search out universities doing speech analysis research. You may find some prototypes you can modify to give your software some clues.
I think you'll have difficulty doing this entirely in Python. You're talking about doing frequency/amplitude analysis of MP3 files. You would have to open up the file and look for a volume threshold, then cut out the portions that go below that threshold. Figuring out how many speakers are present would require very advanced signal processing.
A cursory Google search turned up nothing for me. You might have better luck looking for an off-the-shelf solution.
As an aside- there may be legal complications to having a recorder running 24/7 without letting people know.
I'm thinking about making a networked game. I'm a little new to this, and have already run into a lot of issues trying to put together a good plan for dead reckoning and network latency, so I'd love to see some good literature on the topic. I'll describe the methods I've considered.
Originally, I just sent the player's input to the server, simulated there, and broadcast changes in the game state to all players. This made cheating difficult, but under high latency things were a little difficult to control, since you dont see the results of your own actions immediately.
This GamaSutra article has a solution that saves bandwidth and makes local input appear smooth by simulating on the client as well, but it seems to throw cheat-proofing out the window. Also, I'm not sure what to do when players start manipulating the environment, pushing rocks and the like. These previously neutral objects would temporarily become objects the client needs to send PDUs about, or perhaps multiple players do at once. Whose PDUs would win? When would the objects stop being doubly tracked by each player (to compare with the dead reckoned version)? Heaven forbid two players engage in a sumo match (e.g. start pushing each other).
This gamedev.net bit shows the gamasutra solution as inadequate, but describes a different method that doesn't really fix my collaborative boulder-pushing example. Most other things I've found are specific to shooters. I'd love to see something more geared toward games that play like SNES Zelda, but with a little more physics / momentum involved.
Note: I'm not asking about physics simulation here -- other libraries have that covered. Just strategies for making games smooth and reactive despite network latency.
Check out how Valve does it in the Source Engine: http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
If it's for a first person shooter you'll probably have to delve into some of the topics they mention such as: prediction, compensation, and interpolation.
I find this network physics blog post by Glenn Fiedler, and even more so the response/discussion below it, awesome. It is quite lengthy, but worth-while.
In summary
Server cannot keep up with reiterating simulation whenever client input is received in a modern game physics simulation (i.e. vehicles or rigid body dynamics). Therefore the server orders all clients latency+jitter (time) ahead of server so that all incomming packets come in JIT before the server needs 'em.
He also gives an outline of how to handle the type of ownership you are asking for. The slides he showed on GDC are awesome!
On cheating
Mr Fiedler himself (and others) state that this algorithm suffers from not being very cheat-proof. This is not true. This algorithm is no less easy or hard to exploit than traditional client/server prediction (see article regarding traditional client/server prediction in #CD Sanchez' answer).
To be absolutely clear: the server is not easier to cheat simply because it receives network physical positioning just in time (rather than x milliseconds late as in traditional prediction). The clients are not affected at all, since they all receive the positional information of their opponents with the exact same latency as in traditional prediction.
No matter which algorithm you pick, you may want to add cheat-protection if you're releasing a major title. If you are, I suggest adding encryption against stooge bots (for instance an XOR stream cipher where the "keystream is generated by a pseudo-random number generator") and simple sanity checks against cracks. Some developers also implement algorithms to check that the binaries are intact (to reduce risk of cracking) or to ensure that the user isn't running a debugger (to reduce risk of a crack being developed), but those are more debatable.
If you're just making a smaller indie game, that may only be played by some few thousand players, don't bother implementing any anti-cheat algorithms until 1) you need them; or 2) the user base grows.
we have implemented a multiplayer snake game based on a mandatory server and remote players that make predictions. Every 150ms (in most cases) the server sends back a message containing all the consolidated movements sent by each remote player. If remote client movements arrive late to the server, he discards them. The client the will replay last movement.
Check out Networking education topics at the XNA Creator's Club website. It delves into topics such as network architecture (peer to peer or client/server), Network Prediction, and a few other things (in the context of XNA of course). This may help you find the answers you're looking for.
http://creators.xna.com/education/catalog/?contenttype=0&devarea=19&sort=1
You could try imposing latency to all your clients, depending on the average latency in the area. That way the client can try to work around the latency issues and it will feel similar for most players.
I'm of course not suggesting that you force a 500ms delay on everyone, but people with 50ms can be fine with 150 (extra 100ms added) in order for the gameplay to appear smoother.
In a nutshell; if you have 3 players:
John: 30ms
Paul: 150ms
Amy: 80ms
After calculations, instead of sending the data back to the clients all at the same time, you account for their latency and start sending to Paul and Amy before John, for example.
But this approach is not viable in extreme latency situations where dialup connections or wireless users could really mess it up for everybody. But it's an idea.