What is the procedure of implementing TDMA scheme on GNU radio using USRP?
I want to implement TDMA scheme using two USRPs as a transmitter and the third one as a receiver. The requirement is that first transmitter sends some data to the receiver for first 10 seconds and then after a delay of two seconds, the second transmitter sends some data to the receiver for another 10 seconds and this process continues to do so. Anyone who can help or provide with some useful links in order to implement this whole process in GNU radio software?
I am in the middle of implementing a TDMA radio. My design relies on GPS sync on the GR host platform. I use its time to sync my USRP using set_time_unknown_pps using an arg that is 2 seconds in the future.
My MAC block is purely message based, acting as a PDU broker between the application and PHY layer. PDU's to be transmitted are tagged with a tx_time command with time set an appropriate amount into the future. I've had to write several OOT blocks to handle tx_[sob,eob] tagging and other PHY details, but in the end packets come out exactly when they need to. The turn on latency for my B200mini appears to be about 1-2 us, which is fine for my timing requirements.
My advice is to start with simple MAC functions and test all the way along until you are confident with a block, then move down the transmit chain.
Anticipating your obvious question, I cannot release any of my code because it's not my code to release :-)
Here is a useful link, explaining how a TDMA system may be implemented in GNU Radio.
Related
I have one USRP B210 and E312 and all the message transferred between them are via the broadcast message.
Is there any way to transmit a unicast message (point to point) in GNURadio?
If yes, can you please help me with an example?
You're confusing GNU Radio with something it is not:
GNU Radio is a framework for designing signal processing flow graphs. It is especially useful for processing digital radio signals.
Whether a message is "unicast" or "broadcast" or whatever isn't anything that GNU Radio is concerned with. You'd typically just analyze a packet that you received to determine whether it was meant for you.
GNU Radio isn't something that you typically use to implement a network layer. Mostly, you do physical layer signal processing. As soon as you have packets of bits, you usually leave GNU Radio. Your problem arises from a misunderstanding of what GNU Radio does (and maybe, software defined radio in general).
I found a great library, gr-mac which can handle the broadcast and unicast messaging above the gnuradio.
https://github.com/jmalsbury/gr-mac
I hope it will be helpful to other new gnuradio users like me.
I am working on a Free-Space-Optics transceiver that uses the soundcard of a computer, a LED, a photodiode and a lens to transmit data over the air. At the moment I am trying to connect two transceivers with the help of GNU Radio. The GNU Radio tutorials and examples that I know of, all cover USB radio devices.
I already experimented with software called Minimodem which uses Audio Frequency Shift Keying for data transmission over the soundcard. GNU Radio offers a lot of useful blocks like Automatic Gain Control (helpful for changing signals due to light and weather conditions) etc., which is the reason I would like to use it for my experiments.
I understand that using the soundcard as the interface is a limiting factor for the achievable data rate.
I would appreciate advice of how to setup a reasonable flow graph in GNU Radio companion that enables a data transmission between the soundcards of two computers. Thank you!
You essentially need two out-of-tree modules for your soundcard in the Gnuradio. one sink(for transmitter) and one source(for receiver). If you already have some code that can send samples to your sound card, just create an oot module and put it in that module. if not, then write a C++ or Python code that can do this.
I want to interface two microcontrollers with a UART interface and I search a protocol to exchange data between them.
In practice, I want to exchange data periodically (ie: sensors reading) and also data on event (GPIO state). I have around 100-200 bytes to exchange every 100 milli second.
Does anybody know a protocol or library to achieve this kind of task ?
For now, I see protobuf and nano protobuff ? Is there something else ?
It would be nice if I could add a software layer over the UART and use "virtual data stream" like if it was a TCP/IP connection to N ports.
Any idea ?
Thanks
I think the most straight forward way is to roll your own.
You'll find RS232 drivers in the manufacturers chip support library.
RS232 is a stream oriented transport, that means you will need to encode your messages into some frameing structure when you send them and detect frame boundaries on the receiver side. A clever and easy to use mechanism to do this is "Consistent Overhead Byte Stuffing".
https://en.wikipedia.org/wiki/Consistent_Overhead_Byte_Stuffing
This simple algorithm turns zeros in your messages into some other value, so the zero-byte can be used to detect start and end of frame. If a byte gets corrupted on the way you can even resynchronize to the stream and keep going.
The code on Wikipedia should be easy enough even for the smallest micro-processors.
Afterwards you can define your message format. You can probably keep it very simple and directly send your data-structures as is.
Suggestion for a simple message format:
Byte-ID Meaning
---------------------------------
0 Destination port number
1 message type (define your own)
2 to n message data
If you want to send variable length messages you can either send out a length byte or derive the length from the output of the Constant Overhead Byte Stuffing framing.
By the way, UART/RS232 is nice and easy to work with, but you may also want to take a look at SPI. The SPI interface is more suitable to exchange data between two micro-controllers. It is usually faster than RS232 and more robust because it has a dedicated clock-line.
How about this: eRPC https://community.nxp.com/docs/DOC-334083
The eRPC (Embedded Remote Procedure Call) is a Remote Procedure Call (RPC) system created by NXP. An RPC is a mechanism used to invoke a software routine on a remote system using a simple local function call. The remote system may be any CPU connected by an arbitrary communications channel: a server across a network, another CPU core in a multicore system, and so on. To the client, it is just like calling a function in a library built into the application. The only difference is any latency or unreliability introduced by the communications channel.
I have use it in a two processor embedded system, a cortext-A9 CPU with a Context-M4 MCU, which communicate each other with SPI/GPIO.
Erpc can run over UART, SPI, rpmsg and network(tcp). even when using serial or SPI as transport tunnel, it can do bidirectional
calls and with very minimal footprint.
Simple serial point-to-point communication protocol
http://www.zipplet.co.uk/index.php/content/openformats_mise
It depends if you need master/slave implementation, noise protection, point-point or multi-point (and in this case collision detection), etc
but, as our colleague said, I would go with the simplest solution that fits the problem, following the KISS principle http://en.wikipedia.org/wiki/KISS_principle
Just add some header information like ID and length, if necessary CRC checking, and be happy :)
Try Microcontroller Interconnect Network (MIN) 1.0:
https://github.com/min-protocol/min
It has framing using byte-stuffing to keep receiver sync, 16-bit Fletcher's algorithm for checksum, an identifier for use by the application and a variable payload of up to 15 bytes.
There's embedded C code there plus also a Python implementation to make it easier to talk to a PC.
As the first answer starts, the simplest result is to roll your own. Define your header (the "format" above) as needed, perhaps including status information so each processor knows that the other is working properly. I have had success with a protocol that includes
2 byte ascii prefix and suffix such as "[" and "]" so that a
protocol analyzer can show you message boundaries.
The number of bytes.
The command ID (parsed to indicate what command handler to use.
Command arguments (I used 3 32 bit words).
A CRC or checksum to verify transfer integrity
The parser then recognizes the [* as the start of the message, and dispatches the body to the command handler for the particular command ID with the associated arguments as long as the checksum matches.
I want to to execute the SPI protocol operation using GPIO Pins, want to configure to single slave operation, in which way I have to configure that, I am using STM32F100RB Microcontroller and Coocox IDE for this executing in windowsxp.
if any body have example source code regarding the configuration of SPI Protocol operation using GPIO pins, then please send me that.
it very helpful for my project, Thanks in advance.
Regards,
Pavan Neo.
You're asking about Bit banging. This is the process of using an IO (or several) to encode or decode a serial signal. Wikipedia has a good description of this process.
For SPI specifically, you will need two or three outputs (depending on whether or not chip select is needed) and one input. You'll have to ensure that your bits are set or read in the correct order to not violate any setup/hold requirements of your peripheral, and you'll need to pay attention to the polarity needed on the clock signal (to make sure you're reading/writing data on the correct edge).
The Wikipedia link has some example code for bit banging that you may find useful as a starting point.
I have an application on a Parallax BASIC Stamp board that reads text commands and executes test cases based on the commands. One test case that sends data via the SPI bus and reads from the SPI bus is failing, depending upon the burst rate of the DEBUGIN text.
The Stamp Board is connected to a PC (Quad core 2+ GHZ), through serial port at 19200 baud.
When I use the BASIC Stamp Terminal or Hyper Terminal to send commands to the Stamp Board, the test passes. When I send the same commands via a C# application, the test fails. The primary difference is the burst rate at which the text is sent to the Stamp Board.
Humans send text slower than computers (the application). When using Hyper Terminal, one character is sent at 19200 baud. The application is sending 8 characters at 19200 baud with no pauses between characters.
I'm looking for an explanation how the DEBUGIN statement (input through the serial port) affects the SHIFTIN or SHIFTOUT commands, or if anybody knows how to resolve this issue.
Unfortunately, the baud rate of the DEBUGIN command cannot be changed. The alternative is have a custom version (including conversion of text to numbers) using the serial port command at a slower speed (which uses extra valuable space, which there is little of on my project).
If posting to StackEchange is the wrong forum, please migrate and post the reason it was migrated.
It sounds like the microcontroller end is not set up to do a good job of servicing both the UART and the SPI peripherals, and so too rapid an arrival of subsequent characters on the UART is either causing the SPI to not be serviced, or perhaps causing some characters on the UART to be missed.
The robust solution is to understand the problem and fix it in the architecture of the micro controller code. For example, you may need to use interrupts and to have the interrupt service routines move characters between longer software-managed fifos and the often 1- or 2- deep fifo in the peripheral hardware.
A possibly workable but riskier solution is to have your C# application insert delays between the characters it is sending, to take advantage of the apparent working of human-speed typing. A variation on this theme is to have the embedded device echo characters, and have the C# program wait for the echo of each character before it sends the next (you'll also need an escape character to clear the embedded command buffer and start over if the C# program decides to declare the embedded device timed out and start over)
Another idea is to shorten the data that has to be sent. Human readable command languages to embedded systems are great, because as you've noticed you can play with them using a terminal application. However, if the embedded system is extremely constrained, using a packed binary or hex format can make it easier to parse. An extreme of single-character commands with pauses in between for their execution is the simplest case of this (and if you primarily use alphanumerics, you are back to being able to use the terminal program)