Synchronizing USRP source blocks - multiple B2xx devices - gnuradio

I am trying to create a synchronized usrp source block in gnu radio consisting of multiple B210 USRP devices. Lang: C++.
From what I have found I need to:
Instantiate multiple multi_usrp_sptr as each B210 requires one and multiple B210 devices cannot be addressed by using single sptr
Use external frequency and PPS sources - an option that can be selected from block or set programmatically
Synchronize re/tuning to achieve repeatable phase offset between nodes - this can be achieved using timed commands API https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD
Synchronize sample streams using time_spec property issue_stream cmd
The problem is how should I insert these timed commands and set time_spec of stream in GNU radio block or gr-uhd libs?
I looked into the gr-uhd folder where the sink/source code resided and found functions that could be altered.
Unfortunately I don't know how to copy or export this library to do these modifications and later compile to insert my custom blocks to GNU Radio, because gr-uhd seems to be built in and compiled at GR installation.
I attempted coping and then making the lib but that's not the way - it didn't succeed. Should I add my own source block via gr_modtool and insert only the commands I need?
Compatibility with uhd and its functions apart from just adding a few lines would be advantageous not to write the source from scratch.
Please advise
Edit
Experimental flowchart, based on Marcus Müller suggestion:
Experimental usrp synchronization flow

The problem is how should I insert these timed commands and set time_spec of stream in GNU radio block or gr-uhd libs?
For a USRP sink: add tags containing dictionaries with the correct command times to the streams. The GNU Radio API docs have information on how these dictionaries need to look like. The time field is what you need to set with an appropriate value.
For a USRP source: Use the set_start_time on the uhd_usrp_source block; use the same dictionaries described above to issue commands like tuning, gain setting at a coordinated time.

I was trying to find a proper way of synchronizing the USRPs via tags.
There are a few issues I came across in this approach:
Timed commands require the knowledge of the current moment in time, which is done via usrp.get_time_now(), even though I would request the USRP to give the time through tags I would have to somehow extract it from the output. (make some kind of loop and proper triggering) (source: https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD) or maybe plan everything not in a relative way - using absolute values instead of offsets. I have seen an approach to regularly reset the sense of time each PPS (set it to 0.0) and maybe then setting time of commands within range of 0.0-1.0 would be acceptable. Then the loop for reading and inserting time into commands would also be redundant.
I didn't found a way to create dicts in GR via blocks to make the solution scalable (without writing a few lines of code in textbox) or writing OOT block
In the end there is so little information to tell what kind of solution is most appropriate (PDU, events, are tags still relevant in GR
?), and the docs are so very scarce, that after some mailing I decided to add a simple class that inherits from the main top_bock.py and after instantiation of top_block it calls a few functions to synchronize the devices. This kind of solution is not the most flexible one, and the parent class top_block.py has to be called through the inheriting one, but it enables an easy programming interface.
Soon I will add an example of the code used in inheriting class just in case.
If there is any more neat, dynamic or scalable solution please let me know or point me to sources.

Related

Gnuradio software source block

I'm currently trying to do some real-time signal-processing and I would like to use "gnuradio". I will be processing multiple channels of EEG which come in trough a custom interface (namely "Lab Streaming Layer"; LSL) in python.
Now my question is if there is an existing block already where you can kind of "push" samples into the signal-processing-graph during run-time? The only blocks I've found so far offer support for audio hardware, TCP-streams and files.
You will have to write your own block; that can be done in Python or C++, whatever is better for your case.
The GNU Radio Guided Tutorials (you should really read them in order from 1 to 5, at least) do explain how to do that.
Because we all know that people are lazy at reading, here's a rough preview of what you'll learn:
make a new Out-of-tree module: gr_modtool newmod sensorinterface, change into the newly generated directory: cd gr-sensorinterface
add a new source block: gr_modtool add eeg_sensor_source; the block type you'll want is "source"; you will be asked to fill in some block details.
edit the generated source file (in lib/ or python/, depending on which language you chose:
add a proper io signature: your output will probably have the size of float
edit the central work function; add code to get new samples, and copy those to the output_items buffer.
The guided tutorials are really nice!
The most flexible method is to write your own GNU Radio block, but there are several options for getting data into a flow graph without using any custom blocks. (Naming from the Python perspective.)
gnuradio.blocks.message_source, which takes data from a gnuradio.gr.msg_queue.
You can use a gnuradio.blocks.file_descriptor_source where the file descriptor is one end of a pipe.

Labview diagram creation API

I need to drive a testbench with labview.
The test scenarios are written in a languages that can be automaticaly translated into labview diagrams.
Is this an API that allow to create "labview diagrams" from another software ? or with labview itself ?
I agree that LabVIEW scripting is one approach, but let me throw out another option.
If you are planning to do a one time migration from your test code to LabVIEW than scripting is great, but if you plan to regularly update your test code (because it's easier to use the "test" language than LabVIEW) than it could become quite painful to constantly perform the migration every time your test code has changed.
I've had great success with simply putting my state machine inside of a for loop and then reading in "commands" from a text file that was generated using my "test" language (see pic).
For example, to do an IV sweep my text file might say something like:
SourceV, 5
ReadI
Wait, 1
SourceV, 6
ReadI
This image is greatly simplified - I'm not using a state machine and I don't show how to use "parameters," but I can provide a more comprehensive example if needed. Again, I've had great success doing this with around 30 "commands" controlling multiple instruments and then I generated the text input using VBA or Python.
It's called LabVIEW scripting. You will need to enable an option in the VI Server page in the options dialog to see the relevant features.
A few things to note:
Scripting isn't complicated, but you do need to be aware of how LV code is built.
While scripting is public, it was initially created as an internal tool. There are still corners of it which are incomplete.
Scripting code can be tedious. If you can get away with it, try creating templates of code.
NI has something called CodeGen, which I believe are a series of functions which make some scripting easier, although I never really looked into it.

webrtc AEC algorithm

I have made a software that uses WebRTC DSP libraries (AEC, NS, AGC, VAD). Now I need to know what algorithm uses each one to write my Master´s Thesis, but I don't find any information about that.
Someone knows the algorithms of this libraries, specially the Acoustic Echo Cancellation (like for example NLMS, that I know it's commonly used, but I don't know if WebRTC also uses it).
I've tryed to know the algorithm looking into the source code, but I don't understand enough.
Thanks in advance!
I've just successfully using standalone WebRTC aecm module for android. and there's some tips:
1.the most important is the thing called "delay", you can find the definition of it in dir:
..\src\modules\audio_processing\include\audio_processing.h
quote:
Sets the |delay| in ms between AnalyzeReverseStream() receiving a
far-end frame and ProcessStream() receiving a near-end frame
containing the corresponding echo. On the client-side this can be
expressed as delay = (t_render - t_analyze) + (t_process - t_capture)
where,
t_analyze is the time a frame is passed to AnalyzeReverseStream() and t_render is the time the first sample of the same frame is
rendered by the audio hardware.
t_capture is the time the first sample of a frame is captured by the audio hardware and t_pull is the time the same frame is passed to
ProcessStream().
if you wanna use aecm module in standalone mode, be sure you obey this doc strictly.
2.AudioRecord and AudioTrack sometimes block(due to minimized buffer size), so when you calc the delay, don't forget adding blocking time to it.
3.if you don't know how to compile aecm module, you may learn Android NDK first, and the module src path is
..\src\modules\audio_processing\aecm
BTW, this blog may help a lot in native dev. and debuging.
http://mhandroid.wordpress.com/2011/01/23/using-eclipse-for-android-cc-development/
http://mhandroid.wordpress.com/2011/01/23/using-eclipse-for-android-cc-debugging/
hope this may help you.
From the code inspection of AGC algorithm in WebRtc, it matches closely with the description in http://www.ti.com/lit/wp/spraal1/spraal1.pdf
It's based on NLMS, but has a variable step length (mu).

Simulating multiple instances of an embedded processor

I'm working on a project which will entail multiple devices, each with an embedded (ARM) processor, communicating. One development approach which I have found useful in the past with projects that only entailed a single embedded processor was develop the code using Visual Studio, divided into three portions:
Main application code (in unmanaged C/C++ [see note])
I/O-simulating code (C/C++) that runs under Visual Studio
Embedded I/O code (C), which Visual Studio is instructed not to build, runs on the target system. Previously this code was for the PIC; for most future projects I'm migrating to the ARM.
Feeding the embedded compiler/linker the code from parts 1 and 3 yields a hex file that can run on the target system. Running parts 1 and 2 together yields code which can run on the PC, with the benefit of better debugging tools and more precise control over I/O behavior (e.g. I can make the simulation code introduce certain types of random hiccups more easily than I can induce controlled hiccups on real hardware).
Target code is written in C, but the simulation environment uses C++ so as to simulate I/O registers. For example, I have a PortArray data structure; the header file for the embedded compiler includes a line like unsigned char LATA # 0xF89; and my header file for simulation includes #define LATA _IOBIT(f89,1) which in turn invokes a macro that accesses a suitable property of an I/O object, so a statement like LATA |= 4; will read the simulated latch, "or" the read value with 4, and write the new value. To make this work, the target code has to compile under C++ as well as under C, but this mostly isn't a problem. The biggest annoyance is probably with enum types (which behave as integers in C, but have to be coaxed to do so in C++).
Previously, I've used two approaches to making the simulation interactive:
Compile and link a DLL with target-application and simulation code, and have VB code in the same project which interacts with it.
Compile the target-application code and some simulation code to an EXE with instance of Visual Studio, and use a second instance of Visual Studio for the simulation-UI. Have the two programs communicate via TCP, so nearly all "real" I/O logic is in the simulation program. For example, the aforementioned `LATA |= 4;` would send a "read port 0xF89" command to the TCP port, get the response, process the received value, and send a "write port 0xF89" command with the result.
I've found the latter approach to run a tiny bit slower than the former in some cases, but it seems much more convenient for debugging, since I can suspend execution of the unmanaged simulation code while the simulation UI remains responsive. Indeed, for simulating a single target device at a time, I think the latter approach works extremely well. My question is how I should best go about simulating a plurality of target devices (e.g. 16 of them).
The difficulty I have is figuring out how to make each simulated instance get its own set of global variables. If I were to compile to an EXE and run one instance of the EXE for each simulated target device, that would work, but I don't know any practical way to maintain debugger support while doing that. Another approach would be to arrange the target code so that everything would compile as one module joined together via #include. For simulation purposes, everything could then be wrapped into a single C++ class, with global variables turning into class-instance variables. That would be a bit more object-oriented, but I really don't like the idea of forcing all the application code to live in one compiled and linked module.
What would perhaps be ideal would be if the code could load multiple instances of the DLL, each with its own set of global variables. I have no idea how to do that, however, nor do I know how to make things interact with the debugger. I don't think it's really necessary that all simulated target devices actually execute code simultaneously; it would be perfectly acceptable for simulation instances to use cooperative multitasking. If there were some way of finding out what range of memory holds the global variables, it might be possible to have the 'task-switch' method swap out all of the global variables used by the previously-running instance and swap in the contents applicable to the instance being switched in. Although I'd know how to do that in an embedded context, though, I'd have no idea how to do that on the PC.
Edit
My questions would be:
Is there any nicer way to allow simulation logic to be paused and examined in VS2010 debugger, while keeping a responsive UI for the simulator front-end, than running the simulator front end and the simulator logic in separate instances of VS2010, if the simulation logic must be written in C and the simulation front end in managed code? For example, is there a way to tell the debugger that when a breakpoint is hit, some or all other threads should be allowed to keep running while the thread that had hit the breakpoint sits paused?
If the bulk of the simulation logic must be source-code compatible with an embedded system written in C (so that the same source files can be compiled and run for simulation purposes under VS2010, and then compiled by the embedded-systems compiler for use in real hardware), is there any way to have the VS2010 debugger interact with multiple simulated instances of the embedded device? Assume performance is not likely to be an issue, but the number of instances will be large enough that creating a separate project for each instance would be likely be annoying in the absence of any way to automate the process. I can think of three somewhat-workable approaches, but don't know how to make any of them work really nicely. There's also an approach which would be better if it's possible, but I don't know how to make it work.
Wrap all the simulation code within a single C++ class, such that what would be global variables in the target system become class members. I'm leaning toward this approach, but it would seem to require everything to be compiled as a single module, which would annoyingly affect the design of the target system code. Is there any nice way to have code access class instance members as though they were globals, without requiring all functions using such instances to be members of the same module?
Compile a separate DLL for each simulated instance (so that e.g. if I want to run up to 16 instances, I would include 16 DLL's in the project, all sharing the same source files). This could work, but every change to the project configuration would have to be repeated 16 times. Really ugly.
Compile the simulation logic to an EXE, and run an appropriate number of instances of that EXE. This could work, but I don't know of any convenient way to do things like set a breakpoint common to all instances. Is it possible to have multiple running instances of an EXE attached to a single debugger instance?
Load multiple instances of a DLL in such a way that each instance gets its own global variables, while still being accessible in the debugger. This would be nicest if it were possible, but I don't know any way to do so. Is it possible? How? I've never used AppDomains, but my intuition would suggest that might be useful here.
If I use one VS2010 instance for the front-end, and another for the simulation logic, is there any way to arrange things so that starting code in one will automatically launch the code in the other?
I'm not particularly committed to any single simulation approach; while it might be nice to know if there's some way of slightly improving the above, I'd also like to know of any other alternative approaches that could work even better.
I would think that you'd still have to run 16 copies of your main application code, but that your TCP-based I/O simulator could keep a different set of registers/state for each TCP connection that comes in.
Instead of a bunch of global variables, put them into a single structure that encompasses the I/O state of a single device. Either spawn off a new thread for each socket, or just keep a list of active sockets and dedicate a single instance of the state structure for each socket.
the simulators I have seen that handle multiple instances of the instruction set/processor are designed that way. There is a structure usually that contains a complete set of registers, and a new pointer or an array of these structures are used to multiply them into multiple instances of the processor.

VGA programming without using interrupt (only registers)

I want to develop a VGA graphics driver (for Linux(Ubuntu)) with support for the basic primitives such as putpixel, drawline, fillrect and bitblt. I want to do it in protected mode.
I´ve been googling for a week and the following four links are the best I have found:
http://www.brackeen....vga/basics.html
http://www.osdever.n...VGA/vga/vga.htm
http://bos.asmhacker...sing%20bios.htm
Unfortunately, the first one uses a BIOS call so I cannot use it. The second link has lots of information on the VGA registers but no examples showing how to make them work together. The third example is a example to switch in 13h mode but i've tried it and nothing happened. Can you guys give me a hint? Thanks in advance!
--Vincenzo
my code at http://bos.asmhackers.net/docs/vga_without_bios/snippet_5/vga.php
works fine if you are in 32bit mode with full hardware access. Unfortunately I doubt that any Linux variant will let you directly access the VGA ports. I'm not sure how you develop this driver, but if you made sure that you have full access to the VGA ports it should work. In my example code I only switch between mode 0x03 and 0x13, but in the folders above you'll be able to find port values for most other common VGA modes, as well as C code to do the switch if you prefer that.
Christoffer code include files are found BOS operating system source code like text.inc and font8x16.inc
http://bos.asmhackers.net/downloads.php
This is coming many many years later but I think it's still very relevant and if somebody is struggling I hope they can find it useful.
First of all, it is completely possible to configure VGA only using registers without interrupts, as hard as it may be. A useful resource about registers and how to configure them can be found here, but unless you have a ton of time to spare to learn how to properly do all of it, move to the following section.
If you wish to really learn how to do it, I suggest going through with the documentation provided earlier. However, some of it is already done!
Chris Giese did a great job demonstrating exactly how to do this for MS-DOS system, and while you may think that doesn't help you, it really does.
Chris's code can be found here. If you want another useful codes check here as well.
Now, while it only works for MS-DOS it's actually easy to convert to other systems. The code already contains all data needed to configure the registers in many different modes. And that's the part that saves you a ton of time going through documentation.
The code uses functions outportb, inportb, which are MS-DOS functions, to write/read single byte to/from a port. Therefore, you have to redefine these functions to read/write for your own system. Redefinition complexity depends on the system you operate on.
In addition, you will also need to provide means to write to physical memory region between 0xA0000-0xBFFFF which corresponds to standard VGA memory area. Once you have that allocated, you need to also redefine the functions pokeb pokew peekb which will help you output things (text or pixel data) on the screen.
One last note: the code is already defined to work with many different modes including both text and display modes.