My Galaxy 5 has strange behaviour when i'm emulate a card on the ACR122U.
I think the problem occured when i ran an Android update. When the application isn't on the foreground my intent filters doesn't catch the tag anymore because the emulated tag is seen as a JIS 6319-4 instead of a ISO/IEC 14443-4 tag.
The sequence i get when the application isn't on the foreground OR is on the foreground and running in foregroundDispatch:
TgInitAsTarget
> FF 00 00 00 27 D4 8C 04 04 00 01 23 45 20 000000000000000000000000000000000000000000000000000000000000
< D5 8D 08 E0 80 90 00
TgGetData
> FF 00 00 00 02 D4 86
Target has been released error
< D5 87 29 90 00
I loop this 5 times, but none of the TgInitAsTarget will work. When i'm using enableReaderMode (without NDEF skip) i get the correct sequence:
...
> FF 00 00 00 02 D4 86 //TgGetData
< D5 87 00 00 A4 04 00 07 D2 76 00 00 85 01 01 00 9000 //SELECT command
> FF 00 00 00 05 D4 8E 02 6A 82 //file or application not found
< D5 8F 00 90 00 //Ack
> FF 00 00 00 02 D4 86 //TgGetData
< D5 87 00 00 A4 04 00 07 D2 76 00 00 85 01 00 90 00 //SELECT command
> FF 00 00 00 05 D4 8E 02 6A 82 //file or application not found
< D5 8F 00 90 00 //Ack
> FF 00 00 00 02 D4 86 //TgGetData
< D5 87 00 00 A4 04 00 07 D2 76 00 00 85 01 00 90 00 //SELECT command
> FF 00 00 00 05 D4 8E 02 6A 82 //file or application not found
< D5 8F 00 90 00 //Ack
TgGetData
> FF 00 00 00 02 D4 86
//Recieving data
Question 1
Why does Android send nothing back when the application isn't on the foreground or with enableForegroundDispatch? It's very weird because it was always working, but it looks like the update changed the behaviour of NFC.
Question 2
Is it normal that the behaviour of enableReaderMode (without NDEF skip) is different from the behaviour of enableForegroundDispatch?
Note that reader-moder mode is enabled with the following command:
nfcAdapter.enableReaderMode(this, this, NfcAdapter.FLAG_READER_NFC_A, null);
Regarding the ACR122U in host card emulation mode being detected as FeliCa (JIS X 6319-4) rather than ISO-DEP (ISO/IEC 14443-4):
This seems to be a known issue with the PN532 NFC controller. So far I did not find any solution to this. That's the same problem that you already discovered in this question of yours.
Regarding question 1: Why does Android send nothing back when the application isn't on the foreground or with enableForegroundDispatch?
Well, as you already found out, the Android device shows that it detects the emulated card as FeliCa. The response to the tgInitAsTarget command (D5 8D 08 E0 80 90 00) indicates, however, that the PN532 was activated as ISO-DEP though. Consequently, it seems that the Android device initiated the communication with the emulated ISO-DEP card but must have immediately dropped it without ever sending command frames (hence you receive the error in response to the tgGetData command). Instead, the Android device must have detected (and possibly talked to) the emulated FeliCa (actually NFCIP-1) card (which relates to the problem in the first part of my answer).
As this was working before, the update must have introduced some changes to the polling/peer-discovery algorithm of your Android device.
Regarding question 2: Is it normal that the behaviour of enableReaderMode (without NDEF skip) is different from the behaviour of enableForegroundDispatch?
That depends on what you consider "normal behavior". As you enabled Android's reader-mode with the command
nfcAdapter.enableReaderMode(this, this, NfcAdapter.FLAG_READER_NFC_A, null);
you explicitly instruct Android to behave differently than with the default tag/peer discovery mechanism (that's used with enableForegroundDispatch and the normal tag dispatch system).
The default polling will try to discover all different tag technologies (NfcA, NfcB, NfcF (fast), NfcF (slow), NfcV (possible with multiple modes), NFCIP-1 active mode, NfcBarcode; usually not in this order), hence it can discover the ACR122U in FeliCa/NFC-DEP mode.
With your enableReaderMode command, you explicitly instruct Android to only poll for NfcA. Hence, your device will properly activate the ACR122U in ISO-DEP mode and, consequently, it will start the NDEF discovery procedure.
Related
I am sending HDMI CEC command to Power on and Standby my LG LED TV 2015 make. The device is a Amlogic S922x based SBC running Android 9. The Power On commands work but the Standby commands don't. Can someone tell me what is wrong with this?
Power ON command (works):
echo 0x40 0x04 > /sys/class/cec/cmd
Power OFF command (does not work):
echo 0x40 0x36 > /sys/class/cec/cmd
Output of
echo 0x40 0x36 > /sys/class/cec/cmd && sleep 0.1 && cat /sys/class/cec/dump_reg
AO_RTI_PWR_CNTL_REG0: 0x00004200
AO_CEC_GEN_CNTL: 0x00000000
AO_CECB_CLK_CNTL_REG0: 0xd02db2dc
AO_CECB_CLK_CNTL_REG1: 0x0000a007
AO_CECB_GEN_CNTL: 0x0000710a
AO_CECB_RW_REG: 0x02010300
AO_CECB_INTR_MASKN:0x0000003f
AO_CECB_INTR_STAT: 0x00000000
CEC MODULE REGS:
CEC_CTRL = 0x03
CEC_MASK = 0x00
CEC_ADDR_L = 0x10
CEC_ADDR_H = 0x00
CEC_TX_CNT = 0x05
CEC_RX_CNT = 0x02
CEC_LOCK = 0x00
CEC_WKUPCTRL = 0x10
RX buffer: 04 83 00 e0 91 00 00 00 00 00 00 00 00 00 00 00
TX buffer: 4f 84 10 00 04 00 00 00 00 00 00 00 00 00 00 00
Try 0xF0 0x36 instead of 0x40 0x36.
Get codes from here: https://www.cec-o-matic.com/
Looks like 0x40 is when source is "playback 1". If you set the source to "unregistered" the result code for standby is 0xF0 0x36. Worked for me on Amlogic and Samsung TV.
I'm running an android app (custom) that scans for nearby Bluetooth low energy devices, and I am noticing that some devices have longer advertised packets than specifications provision for. The scanning device is a Nexus 5 running Android 6.0.
I am using the following line on a ScanResult object result.getScanRecord().getBytes(); to get the byte array
I know that the ScanRecord's byte array is actually constructed of the advertised data (mac address not included) and the scan response, so I expect 31 bytes each for a total of 62 bytes in the array. This is the size of the total array that I receive, but it looks like the advertised data makes it into the response portion of the array. The format follows the specification, where the first byte of a GAP is the length, next byte is GAP type, and next length-1 bytes is data.
But with this format, the devices in question have data fields that extend over into the response portion. Here's an example of the array in hex, with each GAP on a different line:
02 01 06 (flags)
0D FF DF 00 57 30 46 30 30 33 43 45 56 5A (manufacturer specific data)
11 07 6D 69 73 66 69 74 A6 34 4A 7D 7F 95 01(<-expected end of advertise) 00 DA 3D (UUID, 128-bit)
07 09 46 6F 73 73 69 6C (device name)
03 03 12 18 (UUID, 16-bit)
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (leftover bytes)
I don't really care about the scan response data, but I am confused as to how a BLE device could send advertisement packets larger than 31 bytes if it is on 4.2 specification (I know Bluetooth 5 allows larger packets, but the manufacturer states it uses 4.2). I can also see the name of the device showing as it should, but in the response portion.
Would anyone know why this is the case here? Thanks.
Probably those devices simply don't follow the specification (which requires an entry not to cross the packet boundaries). So your device might send
02 01 06 0D FF DF 00 57 30 46 30 30 33 43 45 56 5A 11 07 6D 69 73 66 69 74 A6 34 4A 7D 7F 95
as the Advertising Data and
01 00 DA 3D 07 09 46 6F 73 73 69 6C 03 03 12 18
as the Scan Response Data. You can see for example in the HCI log if this is correct. If it is so, you should complain to the manufacturer of that BLE device.
I have a device to run (gsensor, MPU6050) with an Android system.
I can't build it directly because it does not exist with the 3.4 kernel, but I wonder if I can modify the MPU3050 driver for my device works.
I have found this readme, but I wonder if it will work ?
Edit: After half of work*, here a part of dmesg:
<7>[ 13.283019] i2c-core: driver [mpu3050] registered
<6>[ 13.283119] init: command 'insmod' r=0
<4>[ 13.312403] industrialio: module is from the staging directory, the quality is unknown, you have been warned.
<6>[ 13.315656] init: command 'insmod' r=0
<4>[ 13.320725] kfifo_buf: module is from the staging directory, the quality is unknown, you have been warned.
<6>[ 13.321687] init: command 'insmod' r=0
<4>[ 13.329837] ring_sw: module is from the staging directory, the quality is unknown, you have been warned.
<6>[ 13.330847] init: command 'insmod' r=0
<6>[ 13.354793] hub 4-0:1.0: [hub_activate 872]
<4>[ 13.392922] inv_mpu_iio: module is from the staging directory, the quality is unknown, you have been warned.
<7>[ 13.395860] i2c-core: driver [inv-mpu-iio] registered
i2ctools detect this:
# i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: UU UU UU UU UU UU UU UU -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
# i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: UU UU UU UU UU UU UU UU -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
# i2cdetect -y 2
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: UU UU UU UU UU UU UU UU -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
# i2cdump -f -y 2 0x68
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 89 75 81 e1 1e 0f fb 1e fe 8d 00 a8 28 51 50 b9 ?u????????.?(QP?
10: 86 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?...............
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
60: 00 00 00 00 00 00 00 00 00 00 00 40 00 00 00 00 ...........#....
70: 00 00 00 00 00 68 00 00 00 00 00 00 00 00 00 00 .....h..........
80: 89 75 81 e1 1e 0f fb 1e fe 8d 00 a8 28 51 50 b9 ?u????????.?(QP?
90: 86 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?...............
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 00 00 00 00 00 00 00 00 00 00 40 00 00 00 00 ...........#....
f0: 00 00 00 00 00 68 00 00 00 00 00 00 00 00 00 00 .....h..........
# i2cget -f -y 2 0x68
0x75
# i2cget -f -y 2 0x68
0xe1
# i2cget -f -y 2 0x68
0x0f
# i2cget -f -y 2 0x68
0x1e
# i2cget -f -y 2 0x68
0x8d
#
*Just the drivers has been compiled, the kernel hasn't been modified. The following here.
Yes, you can.
Consult the data sheets for the difference between the capabilities and registers of each device, but I believe you will find that the mpu-6050 is a superset of the mpu-3050 so extending a driver for one to accommodate the other should be a simple case of programming-by-example.
Your question as asked is borderline inappropriate here - Stackoverflow exists to provide assistance with specific problems and you have not stated any actual issue beyond wondering if it possible, to which the answer as given above is yes, provided that you do the work and learn from the resources available to you.
I have an audio recording app on android, and I've encountered a strange issue on a friend's phone.
One of the recordings did not work and throws:
E/MediaPlayer-JNI(5996): QCMediaPlayer mediaplayer NOT present
E/MediaPlayer(5996): Unable to create media player
E/com.audioRec.player.MediaPlayer(5996): setDataSourceFD failed.: status=0x80000000
E/com.audioRec.player.MediaPlayer(5996): java.io.IOException: setDataSourceFD failed.: status=0x80000000
but it is playing with success on windows media player, vlc player, etc !!!!!!!!!
Could someone take a look over the header of the "RecordingNotOk.wav" file?
Here are both recordings
For the RecordingNotOk.wav file, it sounds like the specified size of the data chunk is bigger than the file size:
00 F8 0A 00 in little endian is 718848 bytes while the whole file size is only 716844 and the actual data size available for this chunk is only 716800
This number can be found here (3rd line after 'data'):
52 49 46 46 24 F0 0A 00 57 41 56 45 66 6D 74 20 RIFF $ð?? WAVE fmt
10 00 00 00 01 00 02 00 80 3E 00 00 00 FA 00 00 ???? ???? >?? ?ú??
04 00 10 00 64 61 74 61 00 F8 0A 00 00 00 00 00 ???? data ?ø?? ????
Basically it seems that your file has been truncated. Some players might ignore this and try to play whatever is available up to the end of the file. I guess on Android it tries to read the whole file first according to the expected size hence the IOException
Based on this article, i'm trying to emulate mifare card managing APDU on android.According to the APDU receive, my application should answer the right APDU, thus simulating the mifare behaviour.
with rfidiot.py, reading a mifare card give me :
> FF CA 00 00 00
< CD EA 7D 2B 90 0
Tag ID: CDEA7D2B
ATR: 3B8F8001804F0CA000000306030001000000006A
Setting Mifare Key A: FFFFFFFFFFFF
Authenticating to sector 00 with Mifare Key A (FFFFFFFFFFFF)
> FF 82 20 00 06 FF FF FF FF FF FF
< [] 90 0
> FF 88 00 00 60 00
< [] 90 0
OK
Dumping data blocks 01 to 01:
> FF 88 00 01 60 00
< [] 90 0
> FF B0 00 01 01
< [] 6C 10
> FF B0 00 01 10
< 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90 0
01: 00000000000000000000000000000000 ................
With my app simulating the card i got a wrong comportment:
> FF CA 00 00 00
< 08 F0 82 65 90 0
Tag ID: 08F08265
ATR: 3B80800101
Setting Mifare Key A: FFFFFFFFFFFF
Authenticating to sector 00 with Mifare Key A (FFFFFFFFFFFF)
> FF 82 20 00 06 FF FF FF FF FF FF
< [] 90 0
> FF 88 00 00 60 00
< [] 90 0
OK
Dumping data blocks 01 to 01:
> FF 88 00 01 60 00
< [] 90 0
> FF B0 00 01 01
< [] 69 81
Failed: Command incompatible with file structure
An error appear on FF B0 00 01 01 APDU command. And i don't know where the 6981 APDU command comes from..
Does someone can help me on this "bug" ?
It is not possible what you are trying to do... What #NikolayElenkov has done is emulate a ISO 7816-4 compliant card. MIFARE Classic is not ISO 7816-4 compliant (it does not use APDU commands and responses for communication). In fact, it is not even ISO 14443-4 compliant: it uses proprietary encryption on top of ISO 14443-3.
The fact that the communication looks like APDUs from the reader side, is because your reader strips off all encryption before it passes the data on and wraps that data inside "virtual" APDUs. In that way, MIFARE cards can be used with software that can only deal with ISO 7816-4 compliant cards.