I want to implement a Morse code to ASCII converter in vhdl and then to transmit that ASCII character to PC terminal through UART. I have completed the UART part.
But i don't know how to implement the converter part. The problem is with varying symbol rate of input Morse code. I want to detect dot, dash, character space and word space.
Please help me for the following implementation:
detection of Morse code symbols with variable symbol rate
binary search tree to traverse the Morse code tree to find the corresponding ASCII character.
It seems as if you're planning to do the converter in two stages, which sounds like a decent idea - first stage for decoding dots, dashes and pauses, second stage for assembling these into characters.
For the first stage, you'll need to define some minimum and maximum timings for your input - that is, what is the shortest and longest a dot / dash / etc can last (I'd take it there are some standards for this?).
With these timings it should be possible to use a counter and an edge detector to decode your input morse signal.
For the second stage, you can create a finite state machine or maybe even just a look-up-table to decode the incoming dots and dashes of a single character, and send this along to your UART.
You need to create a module which sample your input and from the pattern you record, use some fixed pattern to out the corresponding letter. You need to study the width of your received signal to estimate how much your sample rate should be. You can try to read and understand the following shared code on github. https://github.com/altugkarakurt/Morse-Code-Converter which will do the reverse process of generating morse code. This can be used as a test generator for your Morse Reader. The code ASCII extract from Morse detector can be feed into a FIFO, which is a standard circuit and connected to your UART. The Morse detector write the ASCII into the FIFO if the FIFO is not full, while the UART read the ASCII from the FIFO and transmit it to the UART. The FIFO acts as a buffer. If you need some standard UART code look at the Xilinx website which has one UART part of the Microblaze design, it is very simple to interface it.
Related
Edit:
All ASCII that starts with 0011 can resync frame. While other characters that starts with 01 can't and garbage results after closing and opening serial software. Now is the answer why more clear?
I tried it out right out of the MCU hardware. A crystal running at 8 MHz. It's an old MCU.
Please try any MCU (even new ones) and send "Hello" and after the last alphabet "o", add "space" (or !, #, $) and compare this to using other characters. If you will use other characters (I used "|" for example in the following), the following garbage will result (after closing and opening the terminal software many times). All the serial software I tried have same results or effects.
In the following I used "space" (or !, #, $ will also work) that can somehow resync the word "Hello":
What kind of terminal emulator/software that can report any framing error and buffer overflow? The MCU I sent is old serial UART displayed in PC using serial to USB converter.
Better yet. Please share any software that can show how the UART receiver is receiving the patterns (with start and stop) bit so I can understand why some characters can attain frame sync in ANY terminals (I tried many like Teraterm, Serial Port Monitor, etc).
Original message:
I'm writing a program in the microcontroller that would output alphabet characters in the terminal like the world Hello using the ordinary asynchronous serial protocol (UART). I noticed that whenever I closed and opened the serial PC software while the MCU was running the same firmware, it can run garbage, this is because it can't tell which is the start bit and stop bit in the middle of the stream when the port opens.
But there is something so puzzling, whenever I used the characters "space", !, ", #, $ and add it to Hello() the stream can somehow resync itself. Is there any reason why these characters can do it? (Note the baud used is fixed at 9600, No Parity, Stop Bits and 8 bits for all cases. And firmware didn't use any delay loop in all cases)
The UART synchronizes on the falling edge at the start of the start bit.
Characters which have less other falling edges are less likely to cause mis-synchronation when a device starts listening to a busy line.
More significantly, characters which end with sequences that don't contain a falling edge will be more likely to allow a re-synchronization on the start bit of the next byte, whatever it is.
Since characters are output little-end first, to get the last wrong falling edge as far away as possible from the right one, you need the longest sequence of zeros followed by ones.
If you are outputting 7-bit ASCII characters in 8-bit frames then the most significant bit will always be 0, so the best chance of resynchronization will be when there are more high-order zeros.
The printing characters with the most high-order zeros are punctuation and digits (note that digits are somehow missing from your ASCII table link).
Control characters have even more zeros, so horizontal tab or newline should resync you even more quickly.
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 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.
This might look a repetition to my earlier question. But I think its not.
I am looking for a technique to convert the signal in the Decimal format to binary format.
I intend to use the Simulink blocks in the Xilinx Library to convert decimal to binary format.
So if the input is 3, the expected output should in 11( 2 Clock Cycles). I am looking for the output to be obtained serially.
Please suggest me how to do it or any pointers in the internet would be helpful.
Thanks
You are correct, what you need is the parallel to serial block from system generator.
It is described in this document:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_1/sysgen_ref.pdf
This block is a rate changing block. Check the mentions of the parallel to serial block in these documents for further descriptions:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_1/sysgen_gs.pdf
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_1/sysgen_user.pdf
Use a normal constant block with a Matlab variable in it, this already gives the output in "normal" binary (assuming you set the properties on it to be unsigned and the binary point at 0.
Then you need to write a small serialiser block, which takes that input, latches it into a shift register and then shifts the register once per clock cycle with the bit that "falls off the end" becoming your output bit. Depending on which way your shift, you can make it come MSB first of LSB first.
You'll have to build the shift register out of ordinary registers and a mux before each one to select whether you are doing a parallel load or shifting. (This is the sort of thing which is a couple of lines of code in VHDL, but a right faff in graphics).
If you have to increase the serial rate, you need to clock it from a faster clock - you could use a DCM to generate this.
Matlab has a dec2bin function that will convert from a decimal number to a binary string. So, for example dec2bin(3) would return 11.
There's also a corresponding bin2dec which takes a binary string and converts to a decimal number, so that bin2dec('11') would return 3.
If you're wanting to convert a non-integer decimal number to a binary string, you'll first want to determine what's the smallest binary place you want to represent, and then do a little bit of pre- and post-processing, combined with dec2bin to get the results you're looking for. So, if the smallest binary place you want is the 1/512th place (or 2^-9), then you could do the following (where binPrecision equals 1/512):
function result = myDec2Bin(decNum, binPrecision)
isNegative=(decNum < 0);
intPart=floor(abs(decNum));
binaryIntPart=dec2bin(intPart);
fracPart=abs(decNum)-intPart;
scaledFracPart=round(fracPart / binPrecision);
scaledBinRep=dec2bin(scaledFracPart);
temp=num2str(10^log2(1/binPrecision)+str2num(scaledBinRep),'%d');
result=[binaryIntPart,'.',temp(2:end)];
if isNegative
result=['-',result];
end
end
The result of myDec2Bin(0.256, 1/512) would then be 0.010000011, and the result of myDec2Bin(-0.984, 1/512) would be -0.111111000. (Note that the output is a string.)