I know that some Snapdragon QUALCOMM chipsets can send communication logs to upper level access. I also know the High-Level Data Link Control (HDLC) frame structure which each frame ends with 0x7e.
But this chip set sends some super frames that have a special structure and can violate this convention. As we know, the schema will be as follows:
And byte stuffing is not used in super frame header, just in frames.
So, what is the structure of the super frame header or the convention which is used in that? In more precise terms, what is the representative of the bytes in the super frame header?
Is there a link? Or can some body tell me about it?
Related
I can encoded an NFC Sticker with a website that will open when I tap it with a mobile phone. For the application I want to use it for I need to be able to expire that link so the user can't just save the URL and use it again. Basically I need to be able to put a random string in the URL that changes each time it gets scanned, such as www.mywebsite.com/TCHQ23, www.mywebsite.com/LQ8FT, ect.
Is this possible with a regular NFC sticker? If not, what kind of device would I use to make this happen? I know there are Arduino modules that can do this, but is there a simpler method or a ready made product that can act as an NFC but have the URL changed by a computer via a USB cable?
Thanks
NFC tags (some) have a feature called "Mirroring". You can mirror the read counter value to the URL, which gets incremented every time you tap it to reader i.e. Every time read command is called, the counter increases by 1. Tags like NTAG 213, NTAG 215 etc have that feature.
Update:
If your requirement is to get a portion of URL to to return random data and on a cheaper tag or sticker then I would suggest considering NTAG 213 tag, which is cost friendly and also have Mirroring feature supported.
If your URL data is http://www.abc#xyz.com then once the counter Mirroring is enabled (read counter must be enabled first) it will look something like
http://www.abc#xyz.com?000001
The last 6 digit value gets increased by value 1,every time a read command is invoked. (000002, 000003, 000004 and so on)
you can refer this link for more info
So your card/device has to present when read a NDEF record with a link in it (A "Well Known Type 1 with a record type definition of type U, etc), this will cause most phones to open a browser automatically
Some details on the Record type needed at https://www.oreilly.com/library/view/beginning-nfc/9781449324094/ch04.html
Most cards have the ability to store some static data, some have as #Adarsh Rotte says have counters, random number generators, crypto, password protection, mirroring (backup) of data, other functions but non of these will help as these custom functions and are card specific and don't / cannot present the data to match the NFC NDEF specification.
There is one type of card that can do this called JavaCard as these can run fully programmable Java Apps. These can be programmed to respond to NFC read request with the right NDEF measure where the URL can be generated on the fly.
There is a github repo with an example Java App to run on these cards that shows how to respond with and NDEF message at https://github.com/OpenJavaCard/openjavacard-ndef.
Watch out for https://github.com/OpenJavaCard/openjavacard-ndef/issues/10 if trying to use this, the default magic AID number is not the right one for NDEF and should be configured at the time you install the App on the Card.
This app emulates the behaviour of an NFC Type 4 spec card.
You would also need to customise it to have the right NDEF payload data with the right generated URL ending.
There are examples of the Card make/model supported by this App listed on the the github pages some are dual interface cards but there are some without the chip contacts and only NFC interface.
Generating the URL ending could be challenging or easy depending on level of security/validation you need.
Starting from a Random String which would be easy to fake because it has no level of validation, to a obfuscated counter, to a public key type encrypted counter.
There are also other solutions to generating the NDEF data with the right URL that don't use a Card and usually require there own power to run.
Some options:-
An Android phone can do what is call Host Card Emulation (HCE) which is very like what the JavaCard is doing, it is pretending to be a NFC Type 4 Card and the response it sends if fully programmable and could be the right type of NDEF message as per the JavaCard.
There are some "Card Reader" Devices that can be attach to a PC/Raspberry Pie via USB can also do HCE like the Android phone. e.g. https://www.acs.com.hk/en/products/342/acr1252u-usb-nfc-reader-iii-nfc-forum-certified-reader/ - this is well documented in the datasheets on how to do.
There are some other "Card Reader" modules that can connect via I2C to Arduino that can do HCE as well. (Technically most Arduino PN532 Chip's which are used in a lot of USB readers as well can do HCE but it is a bit undocumented on how to do it - see section 4 of https://www.nxp.com/docs/en/user-guide/141520.pdf)
There are some other chips that can act as static data NFC devices the also have an I2C interface to write the static data but allow a "pass through" mode to the I2C interface, again these tend to be NFC Type 4 but do some of the HCE type work for you.
e.g. the M24SR04-Y https://www.st.com/resource/en/datasheet/m24sr04-g.pdf can do it
So technically possible with a variety of methods but all not that simple to implement BUT not "Sticker" type format of NFC devices tend to be very simple NFC device as the format restricts the complexity of the hardware contained in them.
I'm trying to implement S-MAC protocol on waspmote xbee sensors and i know it has its own CSMA/CA. So first of all I need to understand the basic of xBee collision avoidance.
Two senders set up in api mode in libraries and both periodically sending single bytes to a common receiver. I reduce the delay and many changing in libabries to make collision and to see how algorithm works. But when i monitor data at the receiver all looks as expected at the receiver .. byte1, byte 2 .. byte1, byte2.
Do u have any idea how can i make collision?
Are you sniffing the 802.15.4 traffic? That's the only way you'd see a collision.
The XBee module buffers the data you want to send, using the host communication parameters (baud rate, API mode, etc.) and then sends it out over 802.15.4 at 250kbps. The module has all of the collision avoidance built in, and will retransmit as necessary to deliver your message. If it's unable to deliver after some number of transmission attempts, you'll get a Transmit Status frame indicating failure.
On the receiving end, it buffers the data and delivers it to the local host using local serial settings (baud rate and API mode).
If you're trying to implement S-MAC, you need a different radio processor where you have low-level control over the radio. The XBee module provides an application layer and handles the MAC layer itself.
We're trying to write a driver/API for a custom data acquisition device, which captures several "channels" of data. For the sake of discussion, let's assume this is a several-channel video capture device. The device is connected to the system via an 8xPCIe Gen-1 link, which has a theoretical throughput of 16Gbps. Our actual data rate will be around 2.8Gbps (~350MB/sec).
Because of the data rate requirement, we think we have to be careful about the driver/API architecture. We've already implemented a descriptor based DMA mechanism and the associated driver. For example, we can start a DMA transaction for 256KB from the device and it completes successfully. However, in this implementation we're only capturing the data in the kernel driver, and then dropping it and we aren't streaming the data to the user-space at all. Essentially, this is just a small DMA test implementation.
We think we have to separate the problem into three sections: 1. Kernel driver 2. Userspace API 3. User Code
The acquisition device has a register in the PCIe address space which indicates whether there is data to read for any channel from the device. So, our kernel driver must poll for this bit-vector. When the kernel driver sees this bit set, it starts a DMA transaction. The user application however does not need to know about all these DMA transactions and data, until an entire chunk of data is ready (For example, assume that the device provides us with 16 lines of video data per transaction, but we need to notify the user only when the entire video frame is ready). We need to only transfer entire frames to the user application.
Here was our first attempt:
Our user-side API allows a user application to register a function callback for a "channel".
The user-side API has a "start" function, which can be called by the user application, which uses ioctl to send a start message to the kernel driver.
In the kernel driver, upon receiving the start message, we started a kernel thread, which continuously monitors the "data ready" bit-vector, and when it sees new data, copies it over to a driver-allocated (kmalloc) buffer. It keeps doing this until the size of the collected data reaches the "frame size".
At this point a custom linux SIGNAL (similar to SIGINT, SIGHUP, etc) is sent to the process which is running the driver. Our API catches this signal and then calls back the appropriate user callback function.
The user callback function calls a function in the API (transfer_data), which uses an ioctl call to send a userspace buffer address to the kernel, and the kernel completes the data transfer by doing a copy_to_user of the channel frame data to userspace.
All of the above is working OK, except that the performance is abysmal. We can only achieve about 2MB/sec of transfer rate. We need to completely re-write this and we're open to any suggestions or pointers to examples.
Other notes:
Unfortunately, we can not change anything in the hardware device. So we must poll for the "data-ready" bit and start DMA based on that bit.
Some people suggested to look at Infiniband drivers as a reference, but we're completely lost in that code.
You're probably way past this now, but if not here's my 2p.
It's hard to believe that your card can't generate interrupts when
it has transferred data. It's got a DMA engine, and it can handle
'descriptors', which are presumably elements of a scatter-gather
list. I'll assume that it can generate a PCIe 'interrupt'; YMMV.
Don't bother trawling the kernel for existing similar drivers. You
might get lucky, but I suspect not.
You need to write a blocking read, which you supply a large memory buffer to. The driver read op (a) gets gets a list of user pages for your user buffer and locks them in memory (get_user_pages); (b) creates a scatter list with pci_map_sg; (c) iterates through the list (for_each_sg); (d) for each entry writes the corresponding physical bus address and data length to the DMA controller as what I presume you're calling a 'descriptor'.
The card now has a list of descriptors which correspond to the physical bus addresses of your large user buffer. When data arrives at the card, it writes it directly into user space, into your user buffer, while your user-level read is still blocked. When it has finished the descriptor list, the card has to be able to interrupt, or it's useless. The driver responds to the interrupt and unblocks your user-level read.
And that's it. The details are nasty, of course, and poorly documented, but that should be the basic architecture. If you really haven't got interrupts you can set up a timer in the kernel to poll for completion of transfer, but if it is really a custom card you should get your money back.
I want to learn and implement CAN BUS protocol. I have implemented UART,SPI,I2C and One Wire Bus protocol using MSP430 Launchpad in software. Now I want to learn about CAN Bus protocol. I have mBed LPC 1768 Cortex M3 Development board. mBed has Can Bus Library but I want to write my own library so that I can learn it in detail, i.e. the way I did for other communication protocols.
I am not able to find suitable resources to start with and the material appears to be scattered on net. Can any one guide how do i write and implement CAN Bus protocol with the development boards available with me.
Thanks
Developing CAN library is relatively easy as compared to I2C or SPI. This is because CAN Controller of your Cortex will take care of most of complex things.
To transmit the data, You have to write ID and Data in designated registers and set bit to transmit data.
This Application note from NXP can be very useful for you.
I would recommend you to implement following functions:
InitCAN - This should set specified Baud Rate of CAN.
SetFilters - Most CAN Controllers come with Acceptance Filters, So it's good to have that
SendData - Make sure you accept Parameters like ID_Type and RTRs etc.
RecieveData - This can be blocking or Interrupt based.
Before beginning, do read CAN Basics to understand. Application notes AN713 and AN754 from Microchip is a good source. Also Vector's site and Wikipedia Article.
Plus, You can always post your doubts here or on Electronics.StackExchange.com :)
Okay so this post is quite old but people may look at it again so:
First of all Can bus is not user friendly protocol like USART or IC2 at all so you have to be very precise about your can bit timing there are tools for that but I suggest you to calculate them by hand. For a microcontroller I would suggest STM32 and be away from PIC series in my opinion. If it's only CAN-BUS without higher level protocols such as SAE J1939, steps are pretty simple and straight forward:
1)Initialize Can
2)Put CAN to configuration mode and remember that you can set baudrate, mask and filters only in configuration mode!
3) Set the baud rate registers.
4) Set the mask and filters. If you need to receive all messages just simply set mask to 0x00. Then filter will be do not care.
5) Set the CAN to the normal or loopback mode. (loopback mode is used for debugging purposes mostly.)
Some remarkable points people try to implement can at the beginning may miss:
*** You need at least 2 working CAN nodes for successfull transmission. (of course with matching baud rate). So if you want to send some data via CAN with 1 node it will not be succesfull. Because your transmitter node will not receive ACK.
*** Most likely you will need a CAN tranciever. Do not forget to put a 100 ohm or similar value resistor between Tx and Rx pins of your tranciever.
I used the software canking to talk to a mcp25050 when I learned how to implement can protocol using an hcs12 dragonboard. It helped a lot because canking will initialize everything for you when u go on the bus and all you have to do is learn how to write and recieve. If you want to learn how to initialize the steps are:
Enables can bus by setting bit on CAN Control Register 1
Enable can initialization Control Register 0
wait until can bus is in initialization mode by checking control register 1 bit
Enables can bus by setting bit on CAN Control Register 1 again and set clock source - Ethier bus clock or eclock
set prescaler baudrate and Tq with Bus timing register
set sample time and prop_seg1, prop_seg2, and phase_seg
set acceptance id on Identifier acceptance register 0-3 or 0-7 - to set your can to recieve everything set those to 00 because when doing a compare the can bus does a ones complement compare with the id coming in
set Identifier mask register 0-3 or 0-7, if you want to not care about any of the bits set them all to FF
set identifier acceptance control register to 32 bit extended or 11 bit - i use 32
set Control Register 0 back to normal mode
wait until bus is normal mode by checking Control Register 1
after this you can start changing registers or reading data to do this you must select the empty can buffer, write your id to write or request data, and then input the address, mask, and value in the 3 transmitter registers if writing and then specify the dlc (3 if writing and 8-1 if reading). to transmit the id and data you then have to set the can transmit flag to equal the can Transmit buffer selection.
** depending on what id you use bit shifting can be tedious so if you are having a problem I would suggest debugging and looking at what your Transmit buffer selection registers are holding. I had this error because i did not shift correctly when i was sending messages to the mcp25050
If your MCU supports CAN Bus, you should start from the related datasheet.
I have set up an experiment to measure Wireless communication parameters using two laptops. I am injecting custom packets into the network on a monitor interface using one laptop programmed as a transmitter(Macbook Pro using Broadcom BCM 4331 interface card) and another laptop ( Dell Latitude E6410 using the Intel Corporation Centrino Ultimate-N 6300 interface card) programmed as a receiver sniffs the network for the custom injected packets and reports parameters such as Received signal strength, propagation delay etc... The transmission is working fine and i am able to get the injected packets on the receiving side.
However , When i use Wireshark to analyze the incoming packets using the monitor interface created using airmon-ng, the radio tap header seems to be malformed. This is the same for all packets .
Also why is the Noise parameter now shown in the radio tap details?
Could anyone help me out with this?
The header might well be malformed, due to, for example, a driver bug. (I.e., a bug in the Linux driver for the Centrino adapter on your laptop.)
Unfortunately, Wireshark didn't put in any indication of what was malformed, so it's hard to diagnose this problem.
I just checked into the Wireshark trunk a change to add expert info for malformed radiotap headers; if you could try building the current SVN trunk head and see what it reports, that might indicate what's wrong with the header.
What's wrong is probably that the length field in the radiotap header is wrong.
If when you said "Also why is the Noise parameter now shown in the radio tap details?" you meant "Also why is the Noise parameter not shown in the radio tap details?", the length field being too short would explain that - the presence bitmap says that the noise parameter is present, but the header field specifies a length not large enough to include the noise parameter, so when Wireshark tries to fetch that field, it discovers that it's run past the end of the radiotap header, and reports a problem.
In addition, that would also explain why the 802.2 LLC header on several of those frames look bogus - if Wiretap skips past the length specified in the radiotap header to find the 802.11 header, and that puts it in the middle of, for example, the Noise parameter, and it tries to dissect that as if it were an 802.11 header, and tries to dissect what's after the 802.11 header as an 802.2 header, both of them could be bogus.