I am new to this domain.
I want to transmit data using GFSK modulation using GNU Radio which response to the following specifications :
Deviation : +/-2,4 kHz +0,2%
Modulation index : 2
Filter index : 0.5 BT
Bitrate : 2400 bit/s
I want to transmit this data (data is in HEXA):
Preamble : 55 55
Synchro : F6 72
L-field ( data + CRC) : 20
Please start with the gr-digital (part of GNU Radio dist) GFSK Mod block. Take a peek at the source python, and then you'll want to look at the gr-analog frequency_modulation.h source for details about FM, specifically frequency deviation. For some reason, the doxygen output does not generate the embedded formula, which is why looking at the header file is suggested.
Then I suggest you do some simple experiments in GNU Radio Companion to better understand the GFSK Mod block.
Hope this helps.
I have based on this example of FSK transmitter, https://nccgroup.github.io/RFTM/fsk_transmitter.html
so you need juste to put the value of BT equal to 0.5 to make a GFSK transmitter. And everthing works correctely.
Related
In my use-case I have to provide codec specification within the HTML5 video source's MIME type. But even a type="video/mp4; codecs=avc1" is not detailed enough for Firefox. Firefox needs the extra detail of for example type="video/mp4; codecs=avc1.64001E". My problem is that I don't know where to get this 64001E part from.
The whole identification happens on server side. So far I was using ffprobe and that's perfectly supplies me JSON format output, like so:
ffprobe -select_streams v:0 -v info -of json -show_entries stream=codec_name,level,profile,width,height -i 1CE89B23-F9BD-43B9-805B-C49ACA9E5FFB_xxxxxxx.mp4
"streams": [
{
"codec_name": "h264",
"profile": "High",
"width": 1080,
"height": 1920,
"level": 50
}
]
}
I can get the profile and the level, but nothing like 64001E. In my local environment I also have mediainfo:
mediainfo 8038B652-106B-4FBB-BAD6-AF7E32913FDE_xxxxxxx.mp4
General
Complete name : 8038B652-106B-4FBB-BAD6-AF7E32913FDE_xxxxxxx.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/iso2/avc1/mp41)
File size : 1.18 MiB
Duration : 6 s 634 ms
Overall bit rate : 1 496 kb/s
Writing application : Lavf57.83.100
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High#L3
Format settings : CABAC / 5 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 5 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 6 s 634 ms
Bit rate : 1 396 kb/s
Width : 360 pixels
Height : 480 pixels
Display aspect ratio : 0.750
Frame rate mode : Constant
Frame rate : 30.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.269
Stream size : 1.10 MiB (93%)
Writing library : x264 core 152 r2854 e9a5903
Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=15 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=17.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Codec configuration box : avcC
Audio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : mp4a-40-2
Duration : 6 s 632 ms
Duration_LastFrame : -9 ms
Bit rate mode : Constant
Bit rate : 90.4 kb/s
Channel(s) : 1 channel
Channel layout : C
Sampling rate : 44.1 kHz
Frame rate : 43.066 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 73.2 KiB (6%)
Default : Yes
Alternate group : 1
What we see here is that the AAC part has a longer Codec ID mp4a-40-2, but the video stream is still just avc1.
I'm looking at lists https://tools.woolyss.com/html5-canplaytype-tester/ and https://wiki.whatwg.org/wiki/Video_type_parameters and I think maybe there's a programmatic way to convert the codec profile + level to the code what the MIME type codec specification has.
In https://developer.mozilla.org/en-US/docs/Web/Media/Formats/codecs_parameter I see that "avc1.4d002a" means Main Profile, Level 4.2. Looking at the list I linked earlier I figured that the 6 hex digits can be broken down into groups of two. The last two is the level. In this latest example the Level is 4.2, we just have to remove the dot => it becomes 42, which is 2a hex. The other 4 hex digits are related to the profile as Main, High, etc and then Progressive, but I haven't found a definition yet, and I wonder if the ffprobe is able to output things like High 4:2:2 Intra Level or High Progressive Level. We'll see.
https://www.rfc-editor.org/rfc/rfc6381#page-12 has some examples, but I followed the links and still don't see any definitive list or anything.
The ITU-T H.264 specification Annex A lists 14 profiles. In those listings there's a profile_idc mentioned, which seems to be the decimal for the first two hex digits, for example High's profile_idc is 100 decimal, which is 64 hexa. Now we just need to figure out the middle two hexa digits. Preferably a GitHub repo source file would be great where these things are curated into a sane concise const literal array.
It is described in e.g. Mozilla link ("PPCCLL is six hexadecimal digits specifying the profile number (PP), constraint set flags (CC), and level (LL)"). If you don't find a tool fitting your needs, we could extend e.g. MediaInfo for that, let us know.
Note: the CC indicated in the list are the expected flags, not the ones really in the file, it should be OK 99.99% of the time but you can not be sure it is the real content. MediaInfo internally reads the flags but it does not export them for the moment.
I'm using Atollic TrueSTUDIO for STM32 as an Eclipse Based IDE to perform Digital Signal Processing on audio signal. I'm looking for a way to plot an array (16 bits audio samples) from RAM memory. For the moment I'm using :
The memory View
The SWV real time data time line
None of this tools are powerful to analyse signal on an array, and it doesn't have to be on real time : Just ploting an array after reaching a breakpoint.
Is there an Eclipse Plugin or some other ways to do this ?
I'm considering to export the RAM memory and in a file and plot it in Matlab, but it seems really inapropriate for such a simple thing.
Thanks for any advices
In Atollic, you can easily attach gdb commands to breakpoints. Doing this, allows you to automaticly dump any variables. Additionally, you can execute an external programm once afterwards, to plot the content of the dumped variable.
To do so, goto breakpoint properties and create a new action. Select "Debugger Command Action" and use dump binary value x.bin x to dump variable x to file x.bin
You can also start a python script from the breakpoint to plot the data.
Use an additonal "External Tool Action" and select your python location. Make sure to select your current Working Dictonary. Use the arguments to pass the full path of the python file. The following file will import a float array and plot it.
import struct
import numpy as np
import matplotlib.pyplot as plt
import os
def readBinaryDump(filename):
result = []
N=8
with open(filename,'rb') as f:
while(True):
b = f.read(4*N);
if len(b) ==0:
break
fn = "f"*N
result.append(struct.unpack(fn,b))
result = np.array(result)
return result.ravel()
plt.plot(readBinaryDump("x.bin"))
Don't forget to add the actions to the current breakpoint. Now once the breakpoint is reached, the variable should be dumped and plotted automaticly.
While it's surprising nothing could be embeded in Atollic/Eclipse, I followed the idea of writing an specific application. Here are the steps I used :
Dump Memory :
Debug your software
Stop on a BreakPoint
View > Memory > Export Button > Format : "Plain Text"
The file representing a sine wawe looks like this :
00 00 3E 00 7D 00 BC 00 FB 00 39 01 78 01
B7 01 F6 01 34 02 73 02 B2 02 F0 02 2F 03
You should read these int16 samples like this :
1. 0x0000
2. 0x003E
3. 0x007D
4. etc...
Write this Matlab script :
fileID = fopen('your_file','r');
samples = textscan(fileID,'%s')
fclose(fileID);
samples = samples{1};
words = strcat(samples(2:2:end,1), samples(1:2:end,1));
values = typecast(uint16(hex2dec(words)),'int16');
plot(values) ;
The sinus wave plotted in Matlab
While there aren't any Eclipse plugins that would do what you're asking for that I'm personally aware of, there's STM Studio whose main purpose is displaying variables in real-time. It parses your ELF file to get the available variables, so the effort to at least give it a try should be minimal.
It's available here: https://www.st.com/en/development-tools/stm-studio-stm32.html
ST-Link is required to run it.
Write the simple app in C#. Use semi hosting to dump the memory to the text file. Open it and display.
Recently I had problem with MEMS-es and this was written in less than one hour. IMO (In My Opinion) it is easier to write program which will visualize the data instead of wasting hours or days searching for the ready made one:
I am reworking the programmer for the Olimex iCE40HX1K board (targetted towards a STM32F103 ma) where I also would like to implement the "SPI Slave" mode to configure an image directly into RAM without using the serial flash.
Looking at the Lattice "programming and Configuration guide" (page 11), it is noted in table 8 that a EPROM for a ICE40-LP/LX1K must be at least 34112 bytes. (which -I guess- means that the configuration-files can be up to that size).
However, all images I have (sofar) created with the icestorm tools are 32220 octets.
I am a bit puzzled here.
Can somebody explain the difference between these two figures?
Does the HX1K need a configuration-file of 32220 or 34112 bytes?
I don't know how Lattice arrived at this number. A complete HX1K bin file with BRAM initialization but without comment and without multiboot header is 32220 bytes in size. The (optional) multiboot header would add another 160 bytes (32220 + 160 = 32380). The lattice tools usually add about 80 bytes to the comment field (32220 + 80 = 32300). Whatever I do, all numbers I have are more than 1000 short of 34112.
I don't know if there is a maximum length for the comment. Maybe there is and 34112 is the size of a bit stream with a comment of maximum length?
34112 - 32220 = 1892. Maybe someone decided to add 8kB (8192 bytes) just in case, but that person accidentally swapped the first two digits? Idk..
If you don't care about comments or multiboot headers, then iCE40 1K bit-streams have a fixed size, and that size is 32220 bytes.
My top level verilog module declares signals for the four LEDs on the myStorm ice40 board, which are labelled "LED1-LED4".
module top (
output [4:1] LED
);
assign LED = 4'b1010;
endmodule
I use the same numbering in the .pcf file:
set_io LED[1] 37
set_io LED[2] 38
set_io LED[3] 39
set_io LED[4] 41
But in the .blif output, yosys has renumbered the signals:
.model top
.inputs
.outputs LED[0] LED[1] LED[2] LED[3]
...
so arachne-pnr complains:
top.pcf:4: fatal error: no port `LED[4]' in top-level module `top'
Does yosys expect that top level vector ports are always numbered from zero?
The reason for this is that the Yosys BLIF back-end was not using the hints for start offset and direction (upto/downto) stored in a Yosys Wire object for generating the single-bit net names.
This is now fixed in commit 5c2c78e2dd. Thanks for bringing this to my attention.
Update to latest git head of Yosys and you should get the results that you are expecting.
How do I get all the information regarding the header of an audio file, so it can be displayed in a readable format like ASCII values?
The audio file maybe of any format, most preferably .wav format.
EDIT:- OS can be windows 8.1 or ubuntu. I actually have to understand all the properties of the file like whether it is mono or stereo, its encoding, etc. maybe specifically .wav file, i would say.
I have knowledge about the C++ language, so that would be better.
There is a very powerful command you can use in a bash script: sox.
To get all the info you need about a wav file, you just have to run:
soxi file.wav
and you'll get something like:
Input File : 'file.wav'
Channels : 1
Sample Rate : 8000
Precision : 16-bit
Duration : 00:02:08.40 = 1027236 samples ~ 9630.34 CDDA sectors
File Size : 2.05M
Bit Rate : 128k
Sample Encoding: 16-bit Signed Integer PCM
sox is available for Windows as well, although I have never used there.
You can use FFPROBE utility from FFMPEG: http://ffmpeg.org/
"ffprobe" gathers information from multimedia streams and prints it in human- and machine-readable fashion.
For example it can be used to check the format of the container used by a multimedia stream
and the format and type of each media stream contained in it.
Code
ffprobe -i <file_name>
ffprobe -i myfile.wav
Output will look something like this
Input #0, wav, from 'myfile.wav':
Duration: 00:04:16.88, bitrate: 16 kb/s
Stream #0:0: Audio: g729 ([131][0][0][0] / 0x0083), 8000 Hz, 2 channels, s16p, 16 kb/s
Output Explanation:
g729 is encoding type here.
16 kb/s is the bit-rate.
2 channels
Sample rate 8000 Hz
For detailed information
ffprobe -i <file_name> -show_streams