I'm working on a project in order to exchange large data from PC to Android device throught NFC. I'm using ACR122.
The following is a general exemple of data sent :
// ADPU
FF FF 00 00 00 nn // CLA, INS, P1, P2, Le, Lc
D4 40 // TFI, PD0
01 // (Mi), Target
// LLCP
13 20 // DSAP, PTYPE, SSAP
00 // Sequence
D4 40 // TFI, PD0
// SNEP
10 02 // Protocol Version, Action
nn nn nn nn // Total SNEP Length
// NDEF Header
A2 // First byte (MB = 1, ME = 0, Cf = 1, SR = 0, Il, TNF)
22 // Type length
mm mm mm mm // Payload length
// NDEF Content
61.....65 // Type (34 bytes in that case)
01.....01 // Payload (mm mm mm mm bytes)
Here, I send a Record (not short record).So the NDEF header allows to enter a 4 bytes payload length.
Finaly, my question is how could we send a such large payload regarding the 1 byte APDU Lc ?
If this limitation is only due to the pn532 chip or PS/SC, what alternative hardware would you suggest ?
Thank you for any clarification
EDIT :
I found what I was looking for here :
Sending Extended APDU to Javacard
It's a hardware problem, PN532 don't support Extended APDU.
As you've already found out the ACR122 does not support extended APDU due to a limitation of the PN532 chip.
However, there is no need to pack the entire SNEP transfer into a single APDU. You can split the payload into multiple smaller frames and send them one after another. It's only important that the NDEF header gets transmitted as a whole in the first frame.
Related
Sometimes the source reader returns incorrect video size. It happens with some H265 video files.
This is the reference video: https://drive.google.com/file/d/12oH9x7MCW7YFZu1MDKGbOnIt4VvxrgtZ/view?usp=share_link
3840x2160 pixels
CComPtr<IMFSourceReader> r;
CComPtr<IMFMediaType> NativeMT;
MFCreateSourceReaderFromURL(L"file.mp4" 0, &r);
r->GetCurrentMediaType((DWORD)MF_SOURCE_READER_FIRST_VIDEO_STREAM, &NativeMT);
UINT wi = 0,he = 0;
MFGetAttributeSize(NativeMT, MF_MT_FRAME_SIZE, &wi,&he);
This returns 3840x2176. Why?
I will follow up with more problems because this format fails to be converted to another H264/H265 video with Media Foundation.
So you have this media type for the video track:
MF_MT_FRAME_SIZE, 16492674418816 (Type VT_UI8, 3840x2176)
MF_MT_MINIMUM_DISPLAY_APERTURE, 00 00 00 00 00 00 00 00 00 0F 00 00 70 08 00 00 (Type VT_VECTOR | VT_UI1)
The latter quoted attribute reads as this:
{OffsetX={fract=0 value=0 } OffsetY={fract=0 value=0 } Area={cx=3840 cy=2160 } }
{fract=0 value=0 }
{fract=0 value=0 }
{cx=3840 cy=2160 }
You should take this into account and be ready to accept samples with 3840x2160 payload being carried in 3840x2176 buffers.
Related Q: Handling Image data from IMFSourceReader and IMFSample.
IMO this is still a bug since H.265 demultiplexer is aware that this is encoded video, and padding does not make sense. Decoder would apply this when it sets up textures or buffers with padding, it starts being important only there.
Also, this is a behavior different from H.264 codec AFAIR. And then, again, this side effect AFAIR causes a problem with property sheet handler which displays this wrong resolution for media files.
Introduction:
Okay so to start I just want to say that the sensor does send its data when commanded as I've tested this on Python connected to a COMPORT on a pc. I will include the Python Code I created that works with the sensor, so that all information is available to you guys. I also will include a link to the PJRC Forum that I've asked the same question on, because I've already gotten responses on the issue, but it still persists, and I want you guys to have what they've said at your disposal.
(Python Code & PJRC Link will be at the very bottom of the post)
Problem:
So, my problem is I cannot figure out how to properly send ASCII commands from the Teensy 3.5 and in return read the output of the Flowmeter with the Teensy 3.5. I am afraid that the hardware is connected wrong or I'm just going about something wrong.
The Serial Console will stay blank meaning nothing is available to be read in
What I've Tried - Software:
This is basic code I was given that should work for my use:
char s;
void setup() {
// put your setup code here, to run once:
Serial.begin(9600);
while (!Serial && (millis() < 5000)) {};
Serial1.begin(115200);
delay(1000);
Serial1.print("?\r\n");
}
void loop() {
// put your main code here, to run repeatedly:
while (Serial1.available()){
s = Serial1.read();
Serial.print(s);
}
}
What I've Tried - Hardware:
Image of TSI FlowMeter 5130 w/Cables
Black Wire - USB_C to USB_A - connected to a 5v power supply
Blue/White Wire - USB_A to MALE DB9
Image of Cables that connect the Flowmeter & Teensy 3.5
Blue/White Wire - Male DB9
Tan Serial Gender Converter - Female DB9 to Female DB9
Black Converter Board - Male DB9 to 4-Wire TTL (Red - VCC, Yellow - Transmit, Blue - Receive, Black - GND)
Image of RS232 to TTL Wiring
Yellow Wire - Teensy Transmit Pin 1
Blue Wire - Teensy Receive Pin 0
Red Wire - Currently Set to 5v, but I've tried 3.3v to no avail
Black Wire - GND
Image of LEDs Wired into Rx/Tx of Teensy to watch for data being sent
Blue LED - (Yellow - Teensy Receive Pin 0, Orange - GND)
Green LED - (Red - Teensy Transmit Pin 1, Brown - GND)
Image - 5v Power Supply
White Wire - Teensy 5v
Purple Wire - Teensy GND
Python Code:
import serial
import time
index = 0
total = 0
i = 0
avg = 0
# Serial Connection
time.sleep(.5)
ser = serial.Serial(
port="COM2", baudrate = 115200,
parity=serial.PARITY_NONE, stopbits=serial.STOPBITS_ONE,
bytesize=serial.EIGHTBITS, timeout=1)
# Write ASCII Commands To TSI 5300 Flow Sensor
ser.write(b'?\r\n') # Ask Sensor if it is getting a signal (Returns "OK")
ser.write(b'SUS\r\n') # Set Flow type to SLPM (Returns "OK")
ser.write(b'SG0\r\n') # Set Flow Gas to Air (Returns "OK")
ser.write(b'SSR0005\r\n') # Set Sample Rate to 5ms (Returns "OK")
ser.write(b'LPZ\r\n') # Zero Low Pressure Sensor
# Read serial output to remove all 'OK's from buffer
while (i <= 4):
OK = ser.readline() # Read one line of serial and discard it
print(OK)
i += 1
# Ask for 5 Flow readings
ser.write(b'DAFxxxxx0005\r\n') # Read 5 sensor Flow Reading
ser.readline() # Read one line of serial data and discard it
byte = ser.readline() # Read one line of serial data and store it
print("Unfiltered Bytes: " + str(byte))
string = byte.decode('utf-8') # Convert from BYTE to STRING
array = string.split(',') # Convert from STRING to STRING ARRAY
print("String Array of all 5 readings: " + str(array))
# Convert each element of the ARRAY to FLOAT then add them together
for data in array:
index += 1
data = float(data)
total += data
avg = total / index # Find the average Flow in LPM
print("Average Flow Rate: " + str(avg) + " LPM")
time.sleep(1)
ser.close()
PJRC LINK:
https://forum.pjrc.com/threads/69679-Sending-ASCII-Commands-to-a-Teensy-3-5-Via-RS232-to-TTL-Converter
Yes, you should be able to connect it to the second USB port of the Teensy. This port acts as Host. Whether it works of course depends on which USB interface your flowmeter implements. If it implements some standard (e.g. CDC aka virtual serial or some HID interface) the USB Host lib can probably communicate with it. If they did a proprietary interface you would need to write a corresponding driver first...
I assume they implemented a CDC interface. You can easily check: if you connect the flowmeter to a PC a COM Port (Windows) should appear in the device manager.
I found the solution! It didn't matter which serial it was on (serial1 or serial2), however the problem is I had to start the teensy before the flowmeter and give the flowmeter 20sec to boot up before letting the teensy send any commands! This sensor is so slow though, it takes 50 seconds to fully boot up to the test screen! I just used a 5v relay to delay the flowmeter turning on. Thanks for your help!
I am trying to read a RFID tag/card using MFRC522. I have used the rfid-master library, and trying to read the card using the "dumpinfo" from "examples". but the serial monitor is showing me this-
WARNING: Communication failure, is the MFRC522 properly connected?
and of course not reading any card when I scan them. I have checked the port and it's connected to its legal comm port.
What can be a reason for this communication failure?
/*
* --------------------------------------------------------------------------------------------------------------------
* Example sketch/program showing how to read data from a PICC to serial.
* --------------------------------------------------------------------------------------------------------------------
* This is a MFRC522 library example; for further details and other examples see: https://github.com/miguelbalboa/rfid
*
* Example sketch/program showing how to read data from a PICC (that is: a RFID Tag or Card) using a MFRC522 based RFID
* Reader on the Arduino SPI interface.
*
* When the Arduino and the MFRC522 module are connected (see the pin layout below), load this sketch into Arduino IDE
* then verify/compile and upload it. To see the output: use Tools, Serial Monitor of the IDE (hit Ctrl+Shft+M). When
* you present a PICC (that is: a RFID Tag or Card) at reading distance of the MFRC522 Reader/PCD, the serial output
* will show the ID/UID, type and any data blocks it can read. Note: you may see "Timeout in communication" messages
* when removing the PICC from reading distance too early.
*
* If your reader supports it, this sketch/program will read all the PICCs presented (that is: multiple tag reading).
* So if you stack two or more PICCs on top of each other and present them to the reader, it will first output all
* details of the first and then the next PICC. Note that this may take some time as all data blocks are dumped, so
* keep the PICCs at reading distance until complete.
*
* #license Released into the public domain.
*
* Typical pin layout used:
* -----------------------------------------------------------------------------------------
* MFRC522 Arduino Arduino Arduino Arduino Arduino
* Reader/PCD Uno/101 Mega Nano v3 Leonardo/Micro Pro Micro
* Signal Pin Pin Pin Pin Pin Pin
* -----------------------------------------------------------------------------------------
* RST/Reset RST 9 5 D9 RESET/ICSP-5 RST
* SPI SS SDA(SS) 10 53 D10 10 10
* SPI MOSI MOSI 11 / ICSP-4 51 D11 ICSP-4 16
* SPI MISO MISO 12 / ICSP-1 50 D12 ICSP-1 14
* SPI SCK SCK 13 / ICSP-3 52 D13 ICSP-3 15
*/
#include <SPI.h>
#include <MFRC522.h>
#define RST_PIN 9 // Configurable, see typical pin layout above
#define SS_PIN 10 // Configurable, see typical pin layout above
MFRC522 mfrc522(SS_PIN, RST_PIN); // Create MFRC522 instance
void setup() {
Serial.begin(9600); // Initialize serial communications with the PC
while (!Serial); // Do nothing if no serial port is opened (added for Arduinos based on ATMEGA32U4)
SPI.begin(); // Init SPI bus
mfrc522.PCD_Init(); // Init MFRC522
mfrc522.PCD_DumpVersionToSerial(); // Show details of PCD - MFRC522 Card Reader details
Serial.println(F("Scan PICC to see UID, SAK, type, and data blocks..."));
}
void loop() {
// Reset the loop if no new card present on the sensor/reader. This saves the entire process when idle.
if ( ! mfrc522.PICC_IsNewCardPresent()) {
return;
}
// Select one of the cards
if ( ! mfrc522.PICC_ReadCardSerial()) {
return;
}
// Dump debug info about the card; PICC_HaltA() is automatically called
mfrc522.PICC_DumpToSerial(&(mfrc522.uid));
}
Are you the one who soldered the pins of mfrc522? I think you should double check your connection if it was shorted or not. Also if you're using 5v instead of 3.3v it might damage the mfrc522.
I'd like the arduino to write to a file whenever an ajax call is made. The ajax works, but it doesn't write to the file. All other code inside the ajax handler does execute.
void handle_ajax(){
int startUrlIndex= HTTP_req.indexOf("button");
int endUrlIndex = HTTP_req.indexOf(" HTTP");
String url = HTTP_req.substring(startUrlIndex, endUrlIndex);
int startButtonIndex = url.indexOf("device-") + 7;// 7 is length of device-, I really just want the number.
int endButtonIndex = url.indexOf("&");
String button = url.substring(startButtonIndex, endButtonIndex);
int startStateIndex = url.indexOf("state=") + 6; // 6 is length of state=, I really just want the number.
String state = url.substring(startStateIndex);
int device = button.toInt();
int newState = state.toInt();
dim_light(device, newState * 12);
write_config("", "text");
}
bool write_config(String line, String text){
configFile = SD.open("config.ini", FILE_WRITE);
if(configFile){
configFile.write("Dipshit");
}
configFile.close();
Serial.println("Works.");
return true;
}
I don't see anything wrong with the code provided.
Check the basics first:
SD card is either a standard SD card or a SDHC card.
SD card is formatted with a FAT16 or FAT32 file system.
The correct pin has been used for the CS pin in the SD.begin() command. This depends on the hardware used. http://www.arduino.cc/en/Reference/SDCardNotes
The SPI is wired up correctly (pins 11, 12, and 13 on most Arduino boards).
The hardware SS pin is set as an output (even if it isn't used as the CS pin).
I know from past experience that these little Arduinos can run out of SRAM quite quickly when reading and writing to an SD card. The ReadWrite example program uses about 50% of the UNOs SRAM alone!!
To test if this is your problem, run the SD card read/write example program (with the correct CS pin in the SD.begin() command). If this works then the problem is likely that you have run out of SRAM. Try using an Arduino MEGA 2560 instead which has 4x the amount of SRAM.
Edit: The latest Arduino IDE (v1.6.8) actually calculates how much SRAM is used by global variables. It does not take into account local variables.
Found the problem: Ram
The arduino had insufficient ram at the point of opening the SD card resulting in a failure.
If anyone else ever encounters the same issue, you need 300 or more bytes of ram. Check this by serial printing FreeRam()
I'm finding an example of simple play-thru application using built-in mic/speaker with kAudioUnitSubType_VoiceProcessingIO subtype(not kAudioUnitSubType_HALOutput) in macosx. The comments on the core audio api says that kAudioUnitSubType_VoiceProcessingIO is available on the desktop and with iPhone 3.0 or greater, so I think that there must be an example somewhere for macos.
Do you have any idea where the sample is? or Is there anyone who know how to use the kAudioUnitSubType_VoiceProcessingIO subtype in macos? I already tried the same way that I did in iOS, but it didn't work.
I discovered a few things enabling this IO unit.
Stream format is really picky. It has to be
LinearPCM
FlagsCononical
32 bits per channel
(I did 1 channel but it might work with more)-
sample rate 44100 (might work with others might not)
You don't set EnableIO on it. IO is enabled by default and that property is not writable.
Set stream format before initialization.
As with other core audio work, you just need to check the error status of every single function call, determine what the errors are and make little changes at each step until you finally get it to work.
I had two different kAudioUnitProperty_StreamFormat setup based on the number of the channels.
size_t bytesPerSample = sizeof (AudioUnitSampleType);
stereoStreamFormat.mFormatID = kAudioFormatLinearPCM;
stereoStreamFormat.mFormatFlags = kAudioFormatFlagsAudioUnitCanonical;
stereoStreamFormat.mBytesPerPacket = bytesPerSample;
stereoStreamFormat.mFramesPerPacket = 1;
stereoStreamFormat.mBytesPerFrame = bytesPerSample;
stereoStreamFormat.mChannelsPerFrame = 2;
stereoStreamFormat.mBitsPerChannel = 8 * bytesPerSample;
stereoStreamFormat.mSampleRate = graphSampleRate;
and
size_t bytesPerSample = sizeof (AudioUnitSampleType);
monoStreamFormat.mFormatID = kAudioFormatLinearPCM;
monoStreamFormat.mFormatFlags = kAudioFormatFlagsAudioUnitCanonical;
monoStreamFormat.mBytesPerPacket = bytesPerSample;
monoStreamFormat.mFramesPerPacket = 1;
monoStreamFormat.mBytesPerFrame = bytesPerSample;
monoStreamFormat.mChannelsPerFrame = 1; // 1 indicates mono
monoStreamFormat.mBitsPerChannel = 8 * bytesPerSample;
monoStreamFormat.mSampleRate = graphSampleRate;
with this audio stream formats when using the I/O unit as a kAudioUnitSubType_VoiceProcessingIO
AudioComponentDescription iOUnitDescription;
iOUnitDescription.componentType = kAudioUnitType_Output;
iOUnitDescription.componentSubType = kAudioUnitSubType_VoiceProcessingIO;
iOUnitDescription.componentManufacturer = kAudioUnitManufacturer_Apple;
iOUnitDescription.componentFlags = 0;
iOUnitDescription.componentFlagsMask = 0;
I can clearly see a interruption in the audio output, as the buffer size was smaller than the one from this AudioUnit.
Switching back to the kAudioUnitSubType_RemoteIO
iOUnitDescription.componentSubType = kAudioUnitSubType_RemoteIO;
That interruption disappear.
I'm processing audio input from microphone and applying some real time calculations on the audio buffers.
In the methods the graphSampleRate is the AVSession sample rate
graphSampleRate = [AVAudioSession sharedInstance] sampleRate];
and maybe here I'm wrong.
At the end the configuration parameters values are the following:
The stereo stream format:
Sample Rate: 44100
Format ID: lpcm
Format Flags: 3116
Bytes per Packet: 4
Frames per Packet: 1
Bytes per Frame: 4
Channels per Frame: 2
Bits per Channel: 32
The mono stream format:
Sample Rate: 44100
Format ID: lpcm
Format Flags: 3116
Bytes per Packet: 4
Frames per Packet: 1
Bytes per Frame: 4
Channels per Frame: 1
Bits per Channel: 32
Thanks to SO post here I realized I should have used this flag:
audioFormat.mFormatFlags = kAudioFormatFlagsCanonical;