Saturday, November 4, 2017

System architecture (top); and prototype (bottom). Data encoding A typical smartphone magnetometer with a magnetic sensor can measure magnetic flux on 3 distinct axes simultaneously [20]. Therefore, it is possible to transmit data over these axes in parallel. To maintain a short distance between the device and the magnetic field generator ( i.e. , solenoid) (...)



Figure 1. System architecture (top); and prototype (bottom). Data encoding A typical smartphone magnetometer with a magnetic sensor can measure magnetic flux on 3 distinct axes simultaneously [20]. Therefore, it is possible to transmit data over these axes in parallel. To maintain a short distance between the device and the magnetic field generator ( i.e. , solenoid), we use only the z and x axes and ignore the y-axis. To improve the data transmission speed, we use a 4-level amplitude-shift keying (4-ASK) scheme to encode the data. Before transmission, the magnetic signal is briefly calibrated (between 1.6 and 3.2 seconds) to ignore any background magnetic noise. To calibrate, the encoder transmits a series of sequences between 0000 and 1111. The data uses ASCII encoding. Our coding scheme uses a constant period length (t 0 = 80 ms), which is long enough to account for the smartphone’s magnetometer limitations. During a period, each of the two channels can transmit 2 bits (given our 4-level ASK coding), and therefore the system can transmit in total 4 bits per period. As a convention, the X channel deals with higher bits, while the Z channel deals with lower bits. Finally, we define data packets to consist of 8 periods (4 bytes) each. For example, let us assume that we want to transmit the character ‘H’ whose ASCII representation is 0100 1000. In period 1 we transmit the first 4 bits (0100): the X channel (Figure 2, in blue) transmits 01 while the Z channel (Figure 2, in red) transmits 00 in parallel. This process continues until all bits are transmitted. Figure 2 shows a magnetic signal transmitting the message “Hello world!\n”. Since this message requires multiple packets, we use [x] to indicate an empty period (t 0 ) between two consecutive packets. We acknowledge that our prototype’s network protocol does not introduce packet types, sequence numbers, or CRC to minimize the amount of bits transferred. 

https://www.researchgate.net/figure/263090343_fig1_Figure-1-System-architecture-top-and-prototype-bottom-Data-encoding-A-typical

No comments:

Man in the Rain