Symbol Sync parameters - gnuradio-companion

I'm trying to implement a flowgraph in gnuradio that is a basic OFDM transceiver to communicate between two USRP devices (Ettus N210). I'm using an Octoclock of National Instruments to have the same clock source for both devices. My problem is that I don´t want to use this octclock to synchronize the devices, instead of using this octoclock device I would like to use the Symbol Sync block to achieve synchronism between devices, but I'm not getting any good results from that. Can anyone help me with the parameters or does anyone have ever worked with this block?

There's no Symbol Sync Parameters that can solve this!
The largest part of your flow graph makes no sense:
Your USRP takes baseband signals and shifts them to the frequency you want. You shouldn't mix this yourself.
Your receive-side mixer (don't use that at all) is totally broken; you're missing the low-pass filter. Again, don't mix at all. That's your USRP's job.
If you want to only occupy an upper 1/4 of the bandwidth, simply select these carriers with the carrier map parameter. No need for resampling. Really no reason to use the arbitrary resampler for a rate of 4.
Your receive side first throws away half of your signal, don't do that, if you want an analytical signal.
These are digital complex signals, if you really wanted to do the mixing (don't!), you could simply multiply with a single complex sine, or use the "rotator" block. Again, don't mix.
Your low-pass filter is totally wrong; your signal of interest has more than 240 kHz of bandwidth.
Your sync block hurts you – your OFDM receiver has built-in synchronization.
You're completely missing channel coding, which won't turn out in your favor even at really good SNR. Which is strange - you even have the definition of a decoder in your flow graph, you just don't use it.
Essentially:
everything after the OFDM Transmitter should be removed.
everything before the OFDM Receiver should be removed.
Add channel coding.
I'm a bit confused: This really looks like you took the working ofdm_loopback.grc example that comes with GNU Radio and reworked it until it didn't work anymore. Also, GNU Radio 3.8 has been out for a year – might be worth to update your system.

Thanks for the answer.
The purpose of those blocks of sine and cosine, both on the transmitter and the receiver sides, is to put the signal to an intermediate frequency, before apply the carrier of USRP sink/source. Basically, I need the signal on intermediate frequency (on both Tx/Rx sides) to do some tasks. In the attached file I try to give you a better explanation of what I want to do. The variable O it's the oversampling factor (O=4).
Tx_Rx_scheme
Best Regards

Related

CAN Bus Communication: Same Bit Rate, Different Time Segments

I would like to preface that I am new to CAN, so I apologize if this is an obvious question.
I am using an STM32 microprocessor that has CAN communication, whose bit rate I have set to 500 kBit/s. I am trying to communicate with another node (whose source code I do not have access to) and their bit rates are the same (500 kBit/s). I am wondering if they're using the same bit rate but different bit time parameters (Prescaler, SyncJumpWidth, TimeSeg1, TimeSeg2), will they still be able to communicate with each other?
Possibly, but it isn't certain. Propagation delay caused by long wires for example, will make it more or less critical where the sample point is located. Stubs or poorly terminated buses may suffer from signal reflections that make the sample point location more or less critical. Higher baudrate leads to more bit length inaccuracies. As does a poor clock source. And so on. Also if you go with some strange and exotic settings, nothing tends to work but you get error frames.
I have good experience from following the requirements of the CANopen standard, which is to place the sample point as close to 87.5% as possible. The easiest way to achieve that is by a total of 16tq where phase seg2 is 2tq long. 16 tends to work well with most prescaler clocks as well. Note that there's a hard requirement by the CAN standard not to use more than 25tq.

Getting FPS and frame-time info from a GPU

I am a mathematician and not a programmer, I have a notion on the basics of programming and am a quite advanced power-user both in linux and windows.
I know some C and some python but nothing much.
I would like to make an overlay so that when I start a game it can get info about amd and nvidia GPUs like frame time and FPS because I am quite certain the current system benchmarks use to compare two GPUs is flawed because small instances and scenes that bump up the FPS momentarily (but are totally irrelevant in terms of user experience) result in a higher average FPS number and mislead the market either unintentionally or intentionally (for example, I cant remember the name of the game probably COD there was a highly tessellated entity on the map that wasnt even visible to the player which lead AMD GPUs to seemingly under perform when roaming though that area leading to lower average FPS count)
I have an idea on how to calculate GPU performance in theory but I dont know how to harvest the data from the GPU, Could you refer me to api manuals or references to help me making such an overlay possible?
I would like to study as little as possible (by that I mean I would like to learn what I absolutely have to learn in order to get the job done I dont intent to become a coder).
I thank you in advance.
It is generally what the Vulkan Layer system is for, which allows to intercept API commands and inject your own. But it is nontrivial to code it yourself. Here are some pre-existing open-source options for you:
To get to timing info and draw your custom overlay you can use (and modify) a tool like OCAT. It supports Direct3D 11, Direct3D 12, and Vulkan apps.
To just get the timing (and other interesting info) as CSV you can use a command-line tool like PresentMon. Should work in D3D, and I have been using it with Vulkan apps too and it seems to accept them.

can iPhone detect digital signal through microphone?

I'm working on a project which needs the iPhone to detect a small set of voltage data (two different values of voltage representing 0 and 1 respectively). My initial thought is to detect it through microphone, but I'm not sure if iPhone would be able to detect these signals since it contains no info of frequency. I searched in iOS Developer resources and on google, but nothing clear about this problem. Can anyone help me with this question? Thanks a lot!
as per our discussion, it seems you want to send a digital signal to the iphone. Now there are two main ways to do this.
Either sign up to Apples MFi hardware licensing program which allows you to create hardware for the iPhone. MFi program. Or,
There is an easy way to do this but it would require the use of the headphone jack. For demonstration and testing purposes you can use the headphone jack and if its a simple on and off signal then you can get good results with the headphone jack overall and might not require to create yourself a piece of hardware. Here's a link to that Grab sensor data and send it through the iPhone headphone jack
In fact, using the headphone approach is not as bad as it may sound, you can receive a nice signal if needed. Anyway, it will suffice for your purposes. Have a look what this guy is doing. I suggest you start with the video demonstration to get an overall idea of this approach.
UPDATE 1
Have a look at this link. People are using the headphone port to detect voltage. The reason this works is because the iPhone jack is a combination earpiece (output only) and microphone (input only) connector. The microphone input is a single wire, with common ground to the earpieces.
The usual problem when trying to use an audio signal as digital signal input is that it is high-pass-filtered to avoid offsets (long term pressure changes which could destroy the dynamic range of the soundcards Analog-to-Digital converters). This means you will get only the changes of the digital signal (like "clicks"). Actually you will be better of the higher frequency your signal has, but it will be non-trivial to process it well then (this was what ordinary modems did very well).
If you can control the digital signals sent as sound (or to the microphone jack), make sure they are modulated the signal with one or more tones, like a morse transmitter or modem. Essentially you want to use your iPhone as an Aucoustic Coupler. This is possible, but of course a bit computationally expensive considering the quite low bandwidth.
Start by using some dirt simple modulation, like 1200-1800 Hz and make an FFT of it. There's probably some reference implementation for any sound card out there to get started with.
There have been some cool viruses recently that was said to be able to jump air-gaps, they used similar techniques as this one.
If you still really want a DC (or slowly changing digital signal), check out a solution using a separate oscillator that is amplitude-modulated by the incoming signal

Really simple wave synth/table in ios

I want to make a really simple synth.
In short, i want to play a wav file, and have it loop at certain points until touch is released.
I am looking for some example code, (doesn't need to be free).
Sorry for such a basic question, i have been googling this, though there seems to be nothing on this exact topic, unless I'm missing some important term.
Also, is what i'm describing, a wavetable synth, or a soundboard?
I'd call it a sampler.
Here's a sample project that will get you started:
https://sites.google.com/site/iphonecoreaudiodevelopment/remoteio-playback
See also:
The Audio Programming Book
The Core Audio Book
A sample project of mine
You need to store the sound data in memory, and have some sort of read() command that fills an array of bytes to send to the sound card. The read() command has to keep track of its position between reads, so a persistent pointer must be maintained. You will test the position of the pointer and see if you've reached the end or not, and reset to the beginning when needed.
The specifics are going to depend upon your chosen language, of course.
I did this with Java, with the added the possibility of playback at different speeds.
http://www.hexara.com/VSL/VSL2.htm
It's a little laggy. I've learned a bit since posting that, but haven't gone back to fix it yet. The program asks permission and has you load a wav file from your computer. It should be 16-bit, stereo, 44100fps, little-endian.
WaveTable synthesis is a bit different, in that only a single iteration of a wave is stored and used as source data.
Here is a short discussion, from Stanford's CCRMA website:
https://ccrma.stanford.edu/~bilbao/booktop/node9.html
I used this method to make a Java "Theremin"
http://www.hexara.com/VSL/JTheremin.htm
With a WaveTable, you decide on the size of the array. If it is a power of 2, one can bitmask the pointer after every increment, which is faster than doing a comparison and reset.

Custom robotics for building an auto CD-loading arm

Where would you recommend that I find a company to develop or buy a CD/DVD loading arm similar to: http://www.dextimus.com/
Preferably programmable via USB but if I only can get one with a serial interface that would be fine. Drivers dont matter - I can interface directly with the unit as my situation is very unique.
If you have some experience with electronics, you can give it a shot and build it yourself, like this or this.
I should add that the schematics and the source code are included, and in more details in the first project.
I suppose I might just shorten this by giving a list of resources first:
http://www.embedinc.com/ I trust this company to do good work. Expensive (actually, they are reasonably priced in the design community, but would be considered expensive by most hobbyists and individuals). Not great at people skills, but very very very good at what they do.
You should check out the various microcontroller communities and forums for hobbyists and professionals that can do this. Search for microchip, atmel, msp430, arm, powerpc, etc.
Sparkfun is a supplier to the electronics community - they have great forums where you can post your request, and you'll find people who might do it for fun with only the cost of materials. Might take longer, might not be as 'professional' or well packaged and delivered, but it might be your best low cost option.
There are many electronic design companies that could do this (for instance, I can do this sort of thing).
But there are many questions you haven't answered (and may not have researched) that could prevent success:
Is this patented?
What CD loading/unloading methods are not patented, are out of patent, or otherwise available?
What is your design goal - a one off just for you, or a device that can be built in the hundreds for industrial use, or a device meant for general office workers/consumers that is built in the millions?
Do you realize that this design qould surely cost mroe than simply buying one, if one is all you need?
As an example, assuming you don't need the nice enclosure and don't mind a 'prototype' look, just the mechanicals, electronics, and firmware design (no software on the PC) would likely be 100-250 billable hours for a design firm. At a cheap $90/hr, that's $9k to nearly $25k for one prototype. Add PC software and the nice enclosure, etc and you'll double that.
If you can find a local 'Make' group (techshop, GoTech, or similar) then you might be able to find a hobbyist that is willing to play with this idea for the cost of materials.
But if you define what your goal is, and give us an idea of your resources you may find a better answer.
-Adam
You can create a very nice simple solution using radio control servos. They come in many sizes, but even the small ones have enough torque to move a big arm to move a cd.
The real bonus with servos is that they normally have 180 degrees of rotation and internally have a variable resistor (rheostat) for positioning feedback. Positioning accuracy is normally within 1 degree of rotation which should be fine for a cd loader.
For picking up the CDs, nothing will beat a vacuum. I recommend a small battery powered vacuum cleaner. Funnel the suction into a 1/4 inch pipe. At the other end of the pipe a one inch diameter cup should provide more than enough lift from the small amount of suction.
As for the pile of blank CDs to be burnt, I would advise in moving the pile up rather than an arm down to it. probably having the top blank cd about 1/4 inch higher than the cd tray - By doing this, the arm only needs to rotate in one axis and the vacuum should be enough to suck the cd back out of the tray.
Now, for the electronics. For the servo control I suggest an rs232 serial servo controller. I've used the one from http://www.basicx.com/Products/servo/servo8t.htm as it also gives back torque information from the current draw.
For the low sample rate digital i/o, i suggest (for windows) inpout32.dll which is a dll to give you direct access to the bits of a parallel port. This will allow you to turn on the vacuum at the correct time and possibly sense when cd's have run out. Note that a parallel port can sink more current than it sources so for outputs you should connect to the 5v power line and set the output pin to 0 to turn on the output and 1 to turn it off.
The other nice option, which is very, very simple to interface and very cheap is to get hold of a picaxe from http://www.rev-ed.co.uk/picaxe/. These use a very simple programming language (a BASIC spin off) allowing you to read serial data in and control the servos and digital I/O on one chip. Last time I used one, the language was a bit simple - if statements had to jumped labels, else didn't exist.
If you do use a microcontroller and servos, it is best to use a dual voltage power supply as servos are noisy and can cause the microcontrollers to reset.
As for switching loads such as the vacuum on, you'll need to use a mosfet or (if money is no object) the simpler option, a solid state relay.
All digital inputs you use on the microcontroller should be pulled either to +V or ground with say a 5k resistor so they never float.
I cannot stress how simple and cheap the picaxes are. They have a built in interpreter so although code space is minimal on the small 8 pin units, they are programmable via a simple serial lead.
Good luck. Once you get into automation control, you'll never be able to stop. I'm in the middle of building a 3 axis CNC router so I can cut parts for other projects (I tell my girlfriend it's so she can cut out xmas decorations!).
You might want to contact Aaron Shephard about his Florian project.
I've found that a really easy board to control stepper motors or sorvos are produced by phidgets - the API is incredibly easy, and available for a vast array of platforms.

Resources