What I understand is for Explicit Transmit Beamforming scenario in 802.11n, the Transmitter sends an NDP packet(aka HT Sounding) which consist of OFDM training symbols in packet preamble (HT-LTF) which are randomly generated +/-1 for each subcarrier frequency(say 56).
I do not have much understanding on this, but if anyone can help me to understand or provide any solid link on how these training symbols are calculated at the receiver end to evaluate CSI(channel state information) will be helpful.
Related
The following image is from the datasheet of SRAM IS64WV51216BLL(page 15).
It is a SRAM's write timing diagram.I don't know the meaning of double transitions for WE signal.I have circled it in red.
SRAM write timing diagram
Timing Diagram Basics
Understanding Timing diagrams of digital systems
How to Read Timing Diagrams: A Maker’s Guide
Acturally I have searched many material,but nothing I wanted.Please help me!Thank you very much.
That is not multiple transitions, rather it is a timing window where the transition can happen which is bounded by two timing constraints: tSA and tPWE.
tSA is the Address Setup time which is the earliest that W̄ can be asserted. tPWE is the latest W̄ can be asserted and not violate the Pulse Width.
This is an architectural question regarding gnuradio(-companion) and since I am not sure how to tackle this problem in the first place I first describe what I want to achieve and then how I think I would to it.
Problem
I implement a special form of an RFID reader with an Ettus X310 SDR: The transmitter sends an OOK/AM modulated (PIE encoded) request, followed by a pure Sine wave. The RFID tag backscatters its response onto this sine wave using OOK/AM modulation in FM0 or "Miller subcarrier" coding (a form of a differential Manchester coding). I want to receive its response, translate it into bits (and form a PDU), buffer different responses in a FIFO and send them for further processing. The properties of the tag response are:
It is asynchronuous. I do not know when the response is coming and if it does, when the proper sampling times are: I cannot simply filter, sample, decimate the signal and use a simple slicer because I do not know what the sample points are.
The response comes into very small "bursts" (say, 100 bits). Hence I cannot afford performing timing recovery on bits and waste them (except I buffer the entire signal somehow which I do not think is the way to do it).
The signal starts with a small preamble (UHF RFID Gen2 preamble) which is 6 bits (~8 bit transitions). This may not be enough for for time recovery but can be used to identify the start of a response somehow.
It uses mentioned FM0 encoding, so I have a guaranteed transition every bit. For that reason, I do not have to sample them but could detect the transitions and convert them into bits. I would not need conventional clock recovery (e.g. M&M) either.
My Thoughts
"Ordinary" gnuradio preprocessing brings me to the received oversampled bits: Downconversion, filtering; possibly a slicer which uses a lowpass filter to subtract the mean value and a comparator (note that even this may be challenging because the lowpass filter may have a large settling time of few bits until it obtains the right mean value).
In order to detect the actual transmission, I do not think I have much choice other than a simple squelch that detects a higher signal level than the noise floor (is this true or is there a way to detect the transmission using the preamble only?)
Once the squelch block detects a transmission, I could use a differentiator (or similar) to get the edges. But my understanding of the transition between this "baseband land" and "bits/PDUs" ends: I would need a block that triggers asynchronously (rather than samples at fixed intervals). In an actual system, the edges from the described detector could act as clock input of a flip flop. However, I do not see which standard gnuradio block would allow me to do this.
Once in "bits land", the bits (or PDUs) would be processed at a much lower rate. However, two clock domains are crossed: the normal baseband sampling rate, an irregular rate by which the transitions are detected and the rate at which the bits are read. For that reason, I would be looking for a FIFO or shift register, in which the detected bits are shifted in at whichever edge transition rate they come in and read out at the regular bit rate on the other side.
Question
What is the correct architecture/approach to implement this in gnuradio?
I could imagine to implement this with my own blocks. But as much as possible I would like to use standard block, gnuradio-companion. I would like to resort to own blocks (in particular C++) only as last resort if either not possible otherwise or if it would really not be the right way to so it otherwise.
I have seen two different kinds of CRC algorithms. The one kind is called "direct" the other kind is called "non-direct" or "indirect". The code for both is a bit different. Both are able to calculate the same checksum if direct type is supplied with a converted initial value.
I can successfully run both algorithms and I know how to convert the initial value. So this is no problem.
What I couldn't find out: Why do these two algorithms exist? Is there something that one can do what the other can't? Are they redundant from the user's point of view?
UPDATE You can find a testable online implementation (and C implementations of both aglorithms) here. However these terms (or one of them) are mentioned in some more places. Like here ("direct table algorithm"), in a microcontroller reference document, in forums etc.
The "direct" is referring to how to avoid processing n zero bits at the end for an n-bit CRC.
The mathematical definition of the CRC is a division of the message with n zero bits appended to it. You can avoid the extra operations by exclusive-oring the message with the CRC before operating on it instead of after. This requires processing the initial value of the register in the normal version through the CRC, and having that be the new initial value.
Since it is not necessary, you will never see a real-world CRC algorithm doing the extra operations.
See the section "10. A Slightly Mangled Table-Driven Implementation" in the document you link for a more detailed explanation.
I need to use keyboard as input for musical notes, and digilent speaker as output.
I plan to use only one octave.
My most intriguing questions are:
How do I represent the musical notes in VHDL code.
How do I (or do I need to) implement a DAC module that uses Spartan 3E Starter's built-in DAC? I have read on other forums that it can't be implemented. I need to use it in order to transmit the note to the speaker. The teacher who supervises my and my colleagues' projects suggested me to look into PWM for that(but all I've found is explained in electronic manner, no accompanying code, or explanation on implementation).
Besides keyboard controller, a processing module(for returning the note corresponding to the pressed key from the notes vector) and DAC, that I have figured out so far that I need, what else do I need.
There is a DAC (see comments)
There is no DAC on the Spartan-3E Starter Kit. Using a low-pass PWM signal is a common way to generate analog signal level from digital output.
You need to define a precision for your PWM, let's say 8 bits or 256 levels. For each audio sample you want to output, you need to count from 0 to 255. When the counter is less than the desired sample level, output 1, otherwise output 0. When the counter reach 255, reset it and go to the next sample.
Thus, if you want 8 bits precision (256 levels) and 8KHz signal, the counter will have to run at 256*8000 = 2.048MHz.
For your other questions, there is no easy answer. It's your job, as designer, to figure that out.
I'm using the Spartan 3E Starter Kit and I'm trying to receive Ethernet frames on it via a 100 MBit link.
For those who don't know, the board features a PHY chip, exposing the receiving clock with 25 MHz. I have (pretty much) verified that receiving works fine by buffering the received frames and resending them via a serial link.
Furthermore, I'm using a CRC32 generator from outputlogic.com. I aggregate the received nybbles to bytes and forward them to the CRC. At the end of the frame, I latch the generated CRC and display it on the LCD, together with the CRC I found in the ethernet frame.
However, (as you might have guessed) the two numbers do not match.
527edb0d -- FCS extracted from the frame
43a4d833 -- calculated using the CRC32 generator
The first one can also be verified by running the package through pythons crc32 function, both with the frame captured by wireshark and the frame captured and retrieved via serial port from the FPGA.
I guess it must be something more or less trivial. I pasted the receiving process over here. I stripped off everything which was not neccessary. When capturing the output via serial, I added a fifo (readily made unit from Xilinx) which latched at the same time as the CRC generator to get exactly the same bytes.
Does anyone have an idea what's wrong with that?
I started working on an ethernet MAC a while back, and although I never got round to finishing it I do have a working CRC generator that you can use here:
CRC.vhd
Its based on a Xilinx App note on the IEEE 802.3 CRC, which you can find here.
The CRC is instantiated in the ethernet receieve component, if you look at the ETH_RECEIVE_SM process you can see how the FCS is loaded into the checker.
Hopefully you can spot your mistake by comparing with my code.
Edit:
I took the sample ethernet frame from fpga4fun and passed it through the CRC checker, see the simulation screenshot below (right click, copy URL and view in a new browser tab for full resolution):
You can see the residual C704DD7B at the end there, try doing the same with your own CRC checker and see what you get.
The generator you used may not be pre-processing and post-processing the data. If that generator takes a string of zeros and produces a zero crc, then that's the problem. A string of zeros should not produce zero. (What it produces depends on the number of zeros.)
The processing for the Ethernet crc is to invert the crc, then apply the crc algorithm, then invert the crc again.