I don't understand the inputs in the Vector Source block in the fourth flowchart in the GNU Radio Guided PSK Tutorial. What is behind the three dots? Please state, in full, the input to the Vector line in the first couple of Vector Source blocks so that I can see and understand the inputs. The tutorial is at: https://wiki.gnuradio.org/index.php/Guided_Tutorial_PSK_Demodulation.
The problem I have is in the section called Recovering Timing. There is no link to any file that explains the inputs to the Vector Source blocks. The tutorial shows the surface of the block but not the input. The surface shows 49*[0,]+[1,]+5... and then the next one is 50*[0,]+[1,]+4... I don't understand the input to these Vector Source blocks.
When we updated that tutorial to 3.8, it was decided that only the final flowgraph source would be included in the active gnu radio tree. However, all of the previous ones from 3.7 can be found in https://github.com/gnuradio/gr-tutorial/tree/master/examples/tutorial7 You can get the specific parameters there.
Also note that both the old and new versions of mpsk_stage6.grc were incorrect. Look at https://github.com/gnuradio/gnuradio/issues/3599 to find the solution. NOTE: As of 9 July 2020, that flowgraph has been incorporated into the gnu radio tree, so the link in the tutorial is correct.
that's just a pythonic way of making vectors that are
0,0,0,0,…,0,1,0,…,0
49*[0,] is of the shape integer * list, and that just means "generate a list containing integer repetition of list. So 49*[0,] is a list containing 49 zeros. You can append more lists using +.
Here, the first source contains data that's 49 zeros, followed by a single one, followed by more zeros (likely, 50).
The secons source contains 50 zeros, followed by a one, followed by more zeros (probably 49), and so on.
The idea here is just that they contain the same signal, but shifted!
Related
This is probably a rather basic question, but I'm having a bit of trouble figuring it out, and it might be useful for future visitors.
I want to get at the raw data inside a PDF file, and I've managed to decode a page using the Python library PyPDF2 with the following commands:
import PyPDF2
with open('My PDF.pdf', 'rb') as infile:
mypdf = PyPDF2.PdfFileReader(infile)
raw_data = mypdf.getPage(1).getContents().getData()
print(raw_data)
Looking at the raw data provided, I have began to suspect that ASCII characters preceding carriage returns are significant: every carriage return that I've seen is preceded with one. It seems like they might be some kind of token identifier. I've already figured out that /RelativeColorimetric is associated with the sequence ri\r. I'm currently looking through the PDF 1.7 standard Adobe provides, and I know an explanation is in there somewhere, but I haven't been able to find it yet in that 756 page behemoth of a document
The defining thing here is not that \r – it is just inserted instead of a regular space for readability – but the fact that ri is an operator.
A PDF content stream uses a stack based Polish notation syntax: value1 value2 ... valuen operator
The full syntax of your ri, for example, is explained in Table 57 on p.127:
intent ri (PDF 1.1) Set the colour rendering intent in the graphics state (see 8.6.5.8, "Rendering Intents").
and the idea is that this indeed appears in this order inside a content stream. (... I tried to find an appropriate example of your ri in use but cannot find one; not even any in the ISO PDF itself that you referred to.)
A random stream snippet from elsewhere:
q
/CS0 cs
1 1 1 scn
1.5 i
/GS1 gs
0 -85.0500031 -14.7640076 0 287.0200043 344.026001 cm
BX
/Sh0 sh
EX
Q
(the indentation comes courtesy of my own PDF reader) shows operands (/CS0, 1 1 1, 1.5 etc.), with the operators (cs, scn, i etc.) at the end of each line for clarity.
This is explained in 7.8.2 Content Streams:
...
A content stream, after decoding with any specified filters, shall be interpreted according to the PDF syntax rules described in 7.2, "Lexical Conventions." It consists of PDF objects denoting operands and operators. The operands needed by an operator shall precede it in the stream. See EXAMPLE 4 in 7.4, "Filters," for an example of a content stream.
(my emphasis)
7.2.2 Character Set specifies that inside a content stream, whitespace characters such as tab, newline, and carriage return, are just that: separators, and may occur anywhere and in any number (>= 1) between operands and operators. It mentions
NOTE The examples in this standard use a convention that arranges tokens into lines. However, the examples’ use of white space for indentation is purely for clarity of exposition and need not be included in practical use.
– to which I can add that most PDF creating software indeed attempts to delimit 'lines' consisting of an operands-operator sequence with returns.
I'm trying to teach myself basics of GNU Radio and DSP. I created a flowchart in GNU Radio Companion that takes a vector that is the binary representation of a single character (the character "1" as "00110001"), modulates, demodulates, and writes to a file sink.
The scope sink after demodulation looks like the values are returned (see below; appears to be correct pattern of 0s and 1s), but the file sink, although its size is 19 bytes, appears empty, or at least is not returning the correct values (I've looked at it in ASCII and Hex text editors). I assumed the single character transferred would result in 1 byte (or 8 bits) -- not 19 bytes. Changing some of the settings in the Polyphase Sync and adding a Repack Bits block after the binary slicer results in some characters in the output file, but never the right character.
My questions are:
Can GNU Radio take a single character, modulate/demodulate it, and return the same character?
Are there errors in my flowchart?
I'd appreciate any insights or suggestions, thank you.
I want to read a particular line of a file, e.g. the 3rd line of the input.dat file. My present code :
Program Read_a_line
Implicit None
Integer:: i
Real*8:: x,y
open (10, file='input.dat', status='old')
do i=1,3
read (10,*) x, y
end do
print*,'x=',x,' y=',y
End Program Read_a_line
However, the code reads all the data till it reaches the 3rd line. Can we just read the 3rd line? Can we read several particular lines, eg. the 2nd and 4th lines only.
Online available examples do a similar trick. I was wondering if there exists a direct way in modern fortran version.
I'm a bit curious!
if you have fixed size records you can seek to the correct point
see also Can I move the file pointer to a particular (byte) location in a formatted file?
I've been trying to write a simple script compiler for a custom language used by the Game Boy Advance's Z80 processor.
All I want it to do is look at a human-readable command, take it and its arguments and convert it into a hexadecimal value into a ROM file. That's it. Each command is a byte, and each may take a different number of arguments - arguments can be either 8, 16, or 32 bits and each command has a specific number of arguments that it takes.
All of this sort of code is handled by the game and converted into workable machine code within the game's memory, so I'm not writing a full-on assembly compiler if you will. The game automatically knows how many args a command has, what each command does, exactly how to execute it as it is, etc.
For instance, you have command 0x4E, which takes in one 8-bit argument and another 32-bit argument. In hex that would obviously be 4E XX YY YY YY YY. I want my compiler to read it from text as foo 0xXX 0xYYYYYYYY and directly write it into a file as the former.
My question is, how would I do that in VB.NET? I know it's probably a very simple answer, but I see a lot of different options to write it to a file--some work and most don't for me. Could you give me some sample code as to how I would do this?
Writing an assembly compiler as I understand it is not so simple. I recomed you to use one already written see: Software Development Tools for Z80 Family
If you are still interested in writing it here are instructions:
Write the text you want to translate to some file (or memory stream)
Read it line by line
Parse the line either splitting it to an array or with regular
expressions
Identify command and arguments (as far as I remember it some commands
does not have arguments)
Translate the command to Hex (with a collection or dictionary of
commands)
Write results to an array remembering the references for jump
addresses
When everything is translated resolve addresses and write them to
right places.
I think that the most tricky part is to deal with symbolic addressees.
If you are still interested write a first piece of code (or ask how to do it) and continue with next ones.
This sounds like an assembler, even if it for a 'custom language'.
Start by parsing the command lines. use string.split method to convert the string to an array of strings. the first element in the array is your foo, you can then look that up and output 4E, then convert the subsequent elements to bytes.
I started using CGAL for a project, and I wanted to test alpha shapes with the alpha shapes 2 demo, furnished with CGAL. My input file has been correctly formatted (cf http://pastelink.me/dl/c83d1b warning 22087 lines), but I still have an outlier (cf http://bit.ly/YYZjtp). Is it due to a bug in the demo or too much points on the input ?
The file format is not the correct one, it should be:
x1 y1
...
xn yn
Simplices in the Alpha-complex will be displayed in light blue.
You should remove the first line that indicates the number of points, because the "open()" function of the demo just read points until end-of-file. The file formats in CGAL are not consistent at all. I fell guilty: as a developer myself, I made my own file formats without trying to unify with others. We all did that. :-(