I have used two RFID readers (different vendors), which provide two different identifiers for the very same RFID tag:
Reader A shows 5BFA0746 (decimal 1543112518)
Reader B shows 4607FA5B (decimal 1174927963)
Can you explain why?
There are no similarities with the last bytes nor prefixes.
I'm not sure that I completely understand your question, but the two values are identical except for their byte-order. Hence, both readers do read the same value (possibly an ISO/IEC 14443-3 UID/anti-collsion identifier?). They just present them in reversed byte order:
+--------+--------+--------+--------+
Reader A: | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
| 5B | FA | 07 | 46 |
+--------+--------+--------+--------+
Reader B: | Byte 3 | Byte 2 | Byte 1 | Byte 0 |
| 46 | 07 | FA | 5B |
+--------+--------+--------+--------+
I can think of two reasons this may be happening:
1) CRC or checksum calculations at the start vs. end of the tag ID (vendors may implement this differently) but it sounds like you've already investigated that
2) The readers are configured to read different areas of the tag. For example, are you sure you are getting the tag ID in both cases? For passive UHF RFID Tags, you might be configured to read the TID Serial # vs. EPC. For HF MiFare readers, perhaps you are reading a data bank on one reader and the ID in the other. This is a long way of saying, are you sure both of your readers are actually configured the same way?
Related
So I have some data going through a serial port at regular intervals. Eight bytes are sent every 2 seconds.
I would read this data. Because transmission is constant, I can't just start reading at any moment. I need to align the data. So clearly, the way to do this is to send a header or some sort of separator bytes.
With the Read trait, I can read a certain number of bytes into my buffer. It might look like this:
let mut serial_buf: Vec<u8> = vec![0; 16];
loop {
match port.read(serial_buf.as_mut_slice()) {
Ok(t) => print_data(&serial_buf[..t]),
Err(ref e) if e.kind() == std::io::ErrorKind::TimedOut => (),
Err(e) => eprintln!("{:?}", e),
}
}
But the output I get will look something like this without alignment (with bytes 'abcd' being sent every 2 seconds):
abcd
a
bcd
abc
d
a
bcd
ab
cd
So what's the most practical way of reading and discarding until an alignment bit is found, then making sure that all subsequent reads are aligned?
Thanks,
You need a way to recognize a packet. For this you need to define your protocol.
I guess you want to keep it really simple and low-overhead, so I'll give an example.
+----------+-------+------+------+------+------+------+------+------+------+-----------+
| Byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
+==========+=======+======+======+======+======+======+======+======+======+===========+
| Function | Start | Data | Data | Data | Data | Data | Data | Data | Data | CheckSum |
+----------+-------+------+------+------+------+------+------+------+------+-----------+
| Value | 0 | X | X | X | X | X | X | X | X | XOR 0..=8 |
+----------+-------+------+------+------+------+------+------+------+------+-----------+
So what do we have here?
Our message always starts with a 0. This way we can recognize the start of the message. The data can still contain 0's because we don't rely on it, it just makes our job easier.
(This could be any value, really, but 0 will do the job just fine)
After our start byte, we get our data. This is just the ABCD you used in your example.
Our last byte is a very simple checksum. We simple XOR together all the bytes.
How does this all work then?
Collect some data.
If data < 10 bytes, go to 1
If data[0] != 0 (our start byte), then remove the first byte from our buffer. Go to 2.
XOR together all bytes to get our calculated checksum.
If data[9] != calculated_checksum, then remove the first byte from our buffer. Go to 2.
(We did detect a start byte, but the checksum is incorrect. Therefore we know that the current data is not a packet)
We've got the packet! (Probably*) Read bytes 1..=8 for processing. Then remove the first 10 bytes from the buffer. Go to 2.
That's it!
But there's a lot of things to improve for performance and reliability.
Better start header that supports dynamic lengths and multiple message types.
Better checksum. XOR is not very good for reliability. A CRC is one of the best.
Buffer management. You could use a cyclical buffer so you don't have to remove any bytes.
I'm not sure if this is the correct place to ask this, but basically I have a .txt file containing values that came from 2 separate sensors.
Example of some data:
{"t":3838202,"s":0,"n":"x1","v":-1052}
{"t":3838203,"s":0,"n":"y1","v":44}
{"t":3838204,"s":0,"n":"z1","v":-84}
{"t":3838435,"s":0,"n":"x1","v":-1052}
{"t":3838436,"s":0,"n":"y1","v":36}
{"t":3838437,"s":0,"n":"z1","v":-80}
{"t":3838670,"s":0,"n":"x1","v":-1056}
{"t":3838671,"s":0,"n":"y1","v":52}
{"t":3838672,"s":0,"n":"z1","v":-88}
{"t":3838902,"s":0,"n":"x1","v":-1052}
{"t":3838903,"s":0,"n":"y1","v":48}
{"t":3838904,"s":0,"n":"z1","v":-80}
{"t":3839136,"s":0,"n":"x1","v":-1056}
{"t":3839137,"s":0,"n":"y1","v":40}
{"t":3839138,"s":0,"n":"z1","v":-80}
x2:-944
y2:108
z2:-380
{"t":3839841,"s":0,"n":"x1","v":-1052}
{"t":3839842,"s":0,"n":"y1","v":44}
{"t":3839843,"s":0,"n":"z1","v":-80}
x2:-948
y2:100
z2:-380
{"t":3840541,"s":0,"n":"x1","v":-1052}
{"t":3840542,"s":0,"n":"y1","v":40}
{"t":3840543,"s":0,"n":"z1","v":-84}
{"t":3840774,"s":0,"n":"x1","v":-1052}
{"t":3840775,"s":0,"n":"y1","v":40}
{"t":3840776,"s":0,"n":"z1","v":-84}
x2:-948
y2:108
z2:-368
I'm trying to get the data into excel, so that for each "chunk" of data in the x1y1z1 section, I take the last set of recorded data and discard the rest and "pair" it with the next set of x2y2z2 data. I don't think I'm explaining it very well, but I basically want to take that text file and get this in excel:
+---------+-------+----+-----+------+-----+------+
| t | x1 | y1 | z1 | x2 | y2 | z2 |
+---------+-------+----+-----+------+-----+------+
| 3839138 | -1056 | 40 | -80 | -944 | 100 | -380 |
| 3839843 | -1052 | 44 | -80 | -948 | 100 | -380 |
| 3840776 | -1052 | 40 | -84 | -948 | 108 | -368 |
+---------+-------+----+-----+------+-----+------+
I'm really stuck as to where I should even start
I think like a programmer, so I would approach this problem in steps. If you are not a programmer, this might not be so helpful to you, and I am sorry for that.
First, define the data. How does each line of data get read and understood.
Second, write a parsing utility. A piece of code which interprets the data as it is read in and stores it in the form you want for your output
Third, import data into Excel.
So, based on the limited data you provided, I am not sure how you are able to determine the x1,y1,z1,x2,y2,z2 for each t, but I assume that the values enclosed in curly braces have something to do with that based on the values for s, n, and v I'm seeing in there. So, first of all you need to clearly determine the way you read the data. Take it one line at a time, and determine how you would build your output table based on each line of data. I assume you would treat the lines enclosed in curly braces differently from the lines with standalone x/y/z values for example.
I hope this points you in the right direction.
I have survey data with the age of individuals in a variable named agen. Originally, the variable was string so I converted it to numeric using the encode command. When I tried to generate a new variable hhage referring to the age of head of household, the new variable generated was inconsistent.
The commands I used are the following:
encode agen, gen(age)
gen hhage=age if relntohrp==1
The new variable generated is not consistent because when I browsed it: the age of the hh head in the first houshehold is 65 while the new number generated was 63. When I checked the second household, the variable hhage reported 28 instead of 33 as the head of the housheold head. And so on.
Run help encode and you can read:
Do not use encode if varname contains numbers that merely happen to be stored
as strings; instead, use generate newvar = real(varname) or destring;
see real() or [D] destring.
For example:
clear all
set more off
input id str5 age
1 "32"
2 "14"
3 "65"
4 "54"
5 "98"
end
list
encode age, gen(age2)
destring age, gen(age3)
list, nolabel
Note the difference between using encode and destring. The former assigns numerical codes (1, 2, 3, ...) to the string values, while destring converts the string value to numeric. This you see stripping the value labels when you list:
. list, nolabel
+------------------------+
| id age age3 age2 |
|------------------------|
1. | 1 32 32 2 |
2. | 2 14 14 1 |
3. | 3 65 65 4 |
4. | 4 54 54 3 |
5. | 5 98 98 5 |
+------------------------+
A simple list or browse may confuse you because encode assigns the sequence of natural numbers but also assigns value labels equal to the original strings:
. list
+------------------------+
| id age age3 age2 |
|------------------------|
1. | 1 32 32 32 |
2. | 2 14 14 14 |
3. | 3 65 65 65 |
4. | 4 54 54 54 |
5. | 5 98 98 98 |
+------------------------+
The nolabel option shows the "underlying" data.
You mention it is inconsistent, but for future questions posting exact input and results is more useful for those trying to help you.
Try taking a look at this method? Sounds like you may have slipped up somewhere in your method.
I'm implementing a DNS(multicast DNS in fact) in c#.
I just want to know if I must encode my uint/int/ushort/... with the LSB on the left or the MSB on the left. And more globally how I could know this? One of this is standard?
Because I didn't found anything in the IETF description. I found a lot of things(each header field length, position), but I didn't found this.
Thank you!
The answer is in RFC 1035 (2.3.2. Data Transmission Order)
Here is the link: http://www.ietf.org/rfc/rfc1035.txt
And the interesting part
2.3.2. Data Transmission Order
The order of transmission of the header and data described in this
document is resolved to the octet level. Whenever a diagram shows a
group of octets, the order of transmission of those octets is the
normal order in which they are read in English. For example, in the
following diagram, the octets are transmitted in the order they are
numbered.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Whenever an octet represents a numeric quantity, the left most bit in
the diagram is the high order or most significant bit. That is, the
bit labeled 0 is the most significant bit. For example, the following
diagram represents the value 170 (decimal).
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
Similarly, whenever a multi-octet field represents a numeric quantity
the left most bit of the whole field is the most significant bit.
When a multi-octet quantity is transmitted the most significant octet
is transmitted first.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
So the boss just came buy to tell me he's buying a Wii + Wii Fit for the office. At first I'm thinking this is awesome, we're getting a Wii. But, we're a pretty fit group, why do we need the Wii Fit too? Of course, I opened my stupid mouth to ask that very question when I should have been basking in the glory of the moment. sigh...the work never ends...
Apparently the Wii Fit saves some sort of data to an SD card and he wants to know if we can access that data. A quick search yielded nearly nothing, except a note that the data is stored as a text file, but in Japanese. The boss is still out shopping so I can't yet see for myself.
Has anyone tried to get at the Wii Fit data? Any luck?
It is possible to decode the WiiFit save data.
Once the WiiFit savedata is stored to a SD card it will be named private\wii\title\RFNP\data.bin (for pal) or private\wii\title\RFNN\data.bin (for NTSC)
This is a standardized Wii format that all games use and it is described at http://wiibrew.org/wiki/Savegame_Files
Once you have decrypted the header and data area with he keys from http://hackmii.com/2008/04/keys-keys-keys/ you will find that data.bin contain the files:
RPFitCap.dat
RPHealth.dat
RPWiiFit.dat
These files are unencrypted, but I have not analyzed their content more then just to be able to extract weight and bmi data for my own Mii.
I have a really dirty vb6 class that produces a CSV file with dates and weight but its faaaaaar away from any kind of release.
Heres some of my extracted data:
15.11.2008 13:18:00;92
16.11.2008 15:30:00;91,1
17.11.2008 19:02:00;91,3
18.11.2008 08:23:00;90,8
19.11.2008 07:20:00;90,5
20.11.2008 09:34:00;90,5
21.11.2008 09:32:00;91,1
22.11.2008 09:11:00;91,3
23.11.2008 10:25:00;91,6
24.11.2008 10:36:00;91,2
25.11.2008 10:37:00;91,4
26.11.2008 13:40:00;90,8
27.11.2008 10:45:00;91,2
28.11.2008 11:32:00;91,4
29.11.2008 13:09:00;91
30.11.2008 13:18:00;90
01.12.2008 12:38:00;90,1
02.12.2008 13:16:00;91,2
03.12.2008 10:34:00;91,2
04.12.2008 12:06:00;91
05.12.2008 13:05:00;91,2
06.12.2008 16:28:00;90,3
07.12.2008 14:03:00;90,9
08.12.2008 12:38:00;91,3
09.12.2008 14:18:00;90,4
10.12.2008 13:43:00;90,5
11.12.2008 13:36:00;90,5
12.12.2008 14:15:00;90,3
13.12.2008 14:17:00;89,9
14.12.2008 10:42:00;90
./Al
I was able to use this info to create a table of where the data is stored in the Wii Fit savegame files.
There is more detail in the following blog post: http://jansenprice.com/blog?id=9-Extracting-Data-from-Wii-Fit-Plus-Savegame-Files
File FitPlus0.dat
-----------------
Byte Offset | Length | Description
-----------------------------------
0x0 | 8 | RPHE0000 (header)
0x8 | 22 | Name of Mii
0x1E | 1 | Unknown
0x1F | 1 | Height (in cm)
0x20 | 4 | Date of birth (stored in BCD: e.g. 1980 0228)
0x24 | | Unknown
0x95 | | Dates with data (rowlen=10)
0x35CF | | Start of some other section (unknown)
0x38A1 | | Body Test measurement data section (rowlen=21)
+0 | 4 | Date (in bitfield format)
+4 | 2 | Weight (in kg * 10)
+6 | 2 | BMI (* 100)
+8 | 2 | Balance percent (* 10)
+10 | 2 | simple value 4 ??
+12 | 1 | extended 1 ??
+13 | 1 | extended 2 ??
+14 | 1 | extended 3 ??
+15 | 1 | extended 4 ??
+16 | 2 | extended 5 ??
+18 | 1 | extended 6 ??
+19 | 1 | extended 7 ??
0x9288 | 1 | Last byte of profile