I need to read/write cards using a RFID Reader
more specifically this:
https://www.parallax.com/product/28440
I am not very clear about how to do this since it is my first time with hardware devices connected to the USB port.
I find out there is a TComPort library, I allready installed it on my Delphi Berlin 10.1
From the parallax documentation I found this:
Serial Communication (9600 baud default) Timeout is 100ms
Write to RFID card:
Send ASCII character 'w' to initiate write mode.
Device will respond with 0x01 and will expect 4 bytes of data in return which will be the information entered in
the 'Membership Year' Text box.
Device will respond with 0x02 and will expect 4 bytes of data in return which will be the information entered in
the 'Membership ID' Text box.
Read:
Send ASCII character 'r' to initiate read mode.
Device will send 4 bytes of data (send to Card ID text box) and wait for a 0x01 response.
Device will send a further 4 bytes of data (Membership Year), and wait for a 0x01 response.
Device will send a final 4 bytes of data (Membership ID Number)
The question here is, how can I perfom these actions to write/read using the TComPort component?
By using Windows' CreateFile call you're able to connect to a connected USB device directly. All you need is the full, correct 'port name', see the GetPortName method here
Related
I am having an app in Delphi that monitors UDP traffic. What is the proper way to detect when a QUIC protocol is used? I have the data in a TBytes buffer.
QUIC rfc: https://datatracker.ietf.org/doc/html/rfc9000
Depending on how much of a positive match you're looking for, the effort varies between "walk in the park" and "a bit of a nightmare".
QUIC has a complex handshake, during which the encryption keys are derived, and then it moves into the fully-encrypted, application data phase. On top of this, the protocol is also designed to allow migration of endpoints during the exchange (such as a mobile device jumping between wifi and mobile data), so simply tracking IP addresses and ports isn't going to catch everything.
If all you want is basic detection of QUIC connections being initiated, then all you need to do is to look for the initial packets, which have a clear format, and are only obfuscated (not encrypted).
From RFC9000:
17.2.2. Initial Packet
An Initial packet uses long headers with a type value of 0x00. It
carries the first CRYPTO frames sent by the client and server to
perform key exchange, and it carries ACK frames in either direction.
Initial Packet {
Header Form (1) = 1,
Fixed Bit (1) = 1,
Long Packet Type (2) = 0,
Reserved Bits (2),
Packet Number Length (2),
Version (32),
Destination Connection ID Length (8),
Destination Connection ID (0..160),
Source Connection ID Length (8),
Source Connection ID (0..160),
Token Length (i),
Token (..),
Length (i),
Packet Number (8..32),
Packet Payload (8..),
}
So a quick and dirty way of detecting a QUIC version 1 initial packet, is to check for the following (psuedocode):
( packet[ 0 ] & 0xf0 ) == 0xc0
packet[ 1 ] == 0x00
packet[ 2 ] == 0x00
packet[ 3 ] == 0x00
packet[ 4 ] == 0x01
If you want to go beyond this, it quickly gets exponentially more complicated.
I'd strongly recommend downloading and running wireshark and seeing for yourself what it looks like on the wire.
I am using Ebyte ttl-1w-433 RF module attached with a raspberry pi. When I send a packet, the receiver receives it but in my program(application layer) it prints the data in two fragments. I am using pySerial for my program. Below is the scenario that I am facing problem with-
sender sending 2 packets of 58 bytes each.
receiver receives two transmissions, and two only (receiver LED light blinks only twice)
receiver pushes the data in the application layer as 48, 10, 48, 10 fashion, instead of 58, 58 bytes fashion.
4.application layer(python script) prints four print statements (instead of two)
I am not loosing any data, I am just curious why data arriving app layer fragmented. tried with different serial baud rate and air data rate combination, but I always see the same pattern.
I am not familiar with the Ebyte ttl-1w-433 module but it uses the Semtech SX1276 chip. The SX1276 has a register RegPayloadLength (see SX1272 datasheet, page 114) which defines the payload length. Maybe your Raspberry Pi library (or whatsoever) which controls the access to the module, defines a fixed length of max. 48 bytes on initialization. Since you did not provide any code this is just a wild guess.
I can make USB HID work in Delphi (2010) for simple stuff (one endpoint, ReportID = 0).
But now I need to send 96 words (192 bytes) of data every millisecond. I see how to do that in the slave (PICmicro) with three 64 byte endpoints. (Full speed Interrupt transfer is limited to 64 bytes per endpoint.) But I don't see either a more flexible USB/Delphi object or a way to specify endpoints in the JvclHIDDeviceController object.
Is ReportID telling me the received endpoint?
Is ReportID telling me the received endpoint?
No. When used, it is the first of the 64 (maximum) data bytes.
I need to send 96 words (192 bytes) of data every millisecond
Using WinUSB (or LibUSB-win32) and a bulk pipe sounds simpler to me than trying to create and access a composite device with 3 HID interfaces.
I'm developing an IOS app that reads Arduino serial output via redpark cable.
In the Arduino side, it uses Serial.println() to send out strings.
The string is in the format of "12.34x334.45x0.34x123x33". Essentially it's a combination of doubles with "x" in between as a special split character.
My initial thought was that in the app side, it would get the Arduino output line by line so I would just use
NSString *testString= #"12.34x334.45x0.34x123x33";
NSArray *array = [testString componentsSeparatedByString:#"x"];
to get a NSArray contains 12.34 334.45 0.34 123 and 33.
Somehow after reading questions and answers posted here, I figured out there is no way for redpark sdk to treat the Arduino output line by line, it's always in a X bytes basis.
In order to parse the Arduino output string correctly, what should i do? Would it be a good idea to add leading and tailing 0 to my double data to make the original string to be sent in a fixed length?
(i.e. "03.45x45.50x02.30" to make it 17 bytes and try to read 17 bytes of data using redpark sdk?)
The Redpark SDK only grabs the incoming serial data stream, but doesn't (despite having a few helper routines) interpret it as packets. You'll need to code that yourself. As suggested by agentatlarge in the comments to your question, read the data into a buffer using readBytesAvailable:numBytes until you get a new line character (ASCII 13), at which point you have your string to parse and can start over.
Alternatively, skip the initial string: read the incoming data until you get an "x" (at which time you add a string to an NSMutableArray) or a new line character (at which point you process the array and start a new one.
Be aware that, using the default settings (configurable in redparkSerial.h) data will be fed to you in chunks limited to 100ms (rxForwardingTimeout) or 16 bytes (rxForwardCount), whichever comes sooner. So your system will need to be able to handle multiple reads until it is certain that it has received all the data in a packet (printed line), evidenced by the arrival of the new line character.
I want to write a receiver program using raw socket
it will use recvfrom() to receive packets
so I want to check the IP header and tcp header of a packet
when a program sends a packet, it will pay attention to the network byte order and host byte order problem
but for my recever program, when I use recvfrom(sockfd,mesg,1000,0,(struct sockaddr *)&cliaddr,&len);
what is the byte order of the data in the packets? it is network byte order or host byte order?
and how to deal with it?
for this example
http://www.binarytides.com/packet-sniffer-code-in-c-using-linux-sockets-bsd/
the author doesn't take into account the byte order problem when dealing with the received packets, why?
thanks!
what is the byte order of the data in the packets?
The convention is that network order is big endian order. However, the data you receive is the data you sent: nobody magically modifies "integers" to change their endianness.
and how to deal with it?
Use ntohl and ntohs when interpreting integer data
Be aware that bitfield endianness isn't standard
the author doesn't take into account the byte order problem when
dealing with the received packets,
The link you posted shows ntohs and ntohl calls. The author does handle endianness at least to some extent.