I want to transmit QPSK modulated signal and simply receive it simultaneously to a file using SDR platform (Bladrfx40), but no output shows on received side.
Here is the flow graph I implemented:
Here is what I want to receive and what is being transmitted:
Here is what I actually receive:
Constellation plot on transmitter side:
Constellation plot on receiver side:
Zoomed Constellation on receiver side image
Can i know where i am lacking in my procedure?
Related
I have a third party device that is UART programmable.
I need to create a USB - UART bridge with a functional password (programming only after entering the correct password)
generated the code using the latest version of STM32CubeMX for Atollic TrueSTUDIO for STM32 9.3.0 ...
I transfer data between USB and UART through a buffer (one for usb-uart, and another one for uart-usb)
when I try to transfer several characters everything is OK, but when I try to transfer a large data packet, problems start due to the fact that the USB speed is much higher than the UART ...
there are two questions:
1.How do I tell USB that I need to stop transferring data and wait until the UART (buffer) is busy
2.How on the side of the microcontroller to get the baud rate set on the PC (set when the terminal is connected to the virtual COM port)
USB provides flow control. That's what you need to implement. A general introduction can be found here:
https://medium.com/#manuel.bl/usb-for-microcontrollers-part-4-handling-large-amounts-of-data-f577565c4c7d
Basically, the setup for the USB-to-UART direction should be:
Indicate that the code is ready to receive a USB packet
Receive a USB packet
Indicate that you are no longer ready to receive a USB packet
Transmit the data via UART
Start over
Step 0: Initial setup
Call USBD_CDC_SetRxBuffer to set the buffer for receiving the USB data. Unless you use several buffers to achieve higher throughput, a single call at the start of the program is sufficient.
Step 1: Ready to receive data
Call USBD_CDC_ReceivePacket. Other than what the name implies, this function indicates that the app is ready to receive data. It immediately returns before the data has actually been received.
Step 2: Receive a USB packet
You don't need to do anything here. It will happen automatically. Once it's complete, CDC_Itf_Receive will be called.
Step 3: Indicate that you are no longer ready to receive a USB packet
Nothing to do here. This happens automatically whenever a packet has been received (and double buffering is not enabled).
Step 4: Transmit the data via UART
I guess you know how to do this. It's up to you whether you want to do it in a blocking fashion or using DMA.
Since a callback is involved, you cannot put this code into the main loop. It might be possible to put all code into CDC_Itf_Receive if blocking UART is used. It would appear in the order 2, 3, 4, 1. Additionally, initialization is needed (0 and 1).
In the UART-to-USB direction, you would need to implement flow control on the UART. The USB flow control is managed by the host. Even though USB is much faster than UART, flow control is relevant as the application on the host can process data as slow as it likes to.
Regarding question 2: I'm not sure I understand it... The microcontroller cannot set the baud rate on the host. Either the host can specify a baud rate (transmitted over USB and applied to UART), or if the UART has a fixed baud rate, you can ignore baud rate (any baud rate set on the host side will work as it does not apply to USB).
I have a couple of gnuradio apps that communicate across the internet. The flow graphs are rather complex, so I boiled them down to simplest form to re-create an issue I'm seeing.
The issue is that, when I invoke the client, it connects to the server as expected, but immediately throws an exception "Value nan can not be represented in the target integer type" and appears to be coming from the wavfile sink block.
I simplified the server down to a simple dial tone flow graph that presents the dial tone signal on a TCP port. The client can connect to that port and expect to receive the dialtone signal.
If I run the client and server on the same computer and connect using localhost, the client connects fine and works as expected. However if the client and server are separated at a distance (over the internet) then I receive the nan exception every time.
Theories:
Perhaps the client is starting up and not receiving data soon enough (connect time + 20ms latency) and the wavfile block is receiving NaN's from the socket PDU or stream to tagged stream block?
Perhaps the data is being mangled as it cross the internet in such a way that the packets aren't arriving as expected - fragmentation? I tried MTU 512 but the problem still exists. Trued MTU 10000: same result.
Maybe I'm overlooking a simple usage/syntax error when building my flowgraph
There's a bug in the wavfile sink and it should more gracefully handle the absence of data.
UPDATE 1:
Logged a bug report to gnuradio project https://github.com/gnuradio/gnuradio/issues/1763
UPDATE 2:
The socket PDU block seems to play a significant role. If I tweak the packet length parameter of the stream to tagged stream block, along with the MTU parameter of the socket PDU block, I can get either error free stream with dropped packets (low MTU) or a dead stream with NaN exception (high MTU).
Server Flowgraph
Client Flowgraph (XYZ.com is of course not my real IP)
wav result across the internet (20-100ms latency)
This wav file is 1k and is truncated probably at the same time as the exception but it's hard to tell for sure.
wav result across local interface (1ms or less latency)
Across the local interface the client runs happily until I stop it. Received signal is as expected.
One small thing - notice the glitchy initial first few samples? Not sure if this is a factor. Probably not. But the data is junk for the first 10ms or so even across local interface.
we are using one usrp x310 with two UBX 160 in a full duplex mode (one ubx for transmitting and the second one for receiving, with a 10G connection). In the code, two separate TX and RX flowgraphs are established (under a single process).
top_block:
self.txpath = tx_hier(...)
self.rxpath = rx_hier(...)
self.source = uhd_receiver(...) # set up usrp, subdev: A:0
self.sink = uhd_transmitter(...) # set up usrp, subdev B:0
self.connect(self.source, self.rxpath)
self.connect(self.txpath, self.sink)
However, in the actual test, we found that once RX flowgraph is busy at processing data, the transmitter will suffer from severe underflow problem while sending packets. Sample rate is just 5Msps, using TX flowgraph alone will not have underflow and RX flowgraph alone no overflow either under the same sample rate.
Since these two flowgraphs are separate, and that gnuradio will assign one thread to one block, it seems to me that processing data should not have impact at transmitting (independent). I am wondering how could this happen. I tried to use gr::hier_blocks::set_processor_affinity to separate core resources also, but it didn't work. Maybe blocks at transmitter can't get the resource it needs while RX flowgraph is busy at processing?
Any explanations to this observation and any advice about how to tackle this will be greatly appreciated!
I'm in trouble with programming my Arduino. I've two XBee Series 2 Modules and an Arduino UNO. I use the XBee-API library from: http://code.google.com/p/xbee-api/.
I generate three RemoteATRequest Packets (0x17) to control a Digital Pin of the Remote Sleepy Node and send it out of a SoftwareSerial to the XBee Coordinator which is plugged via a Sparkfun XBee Arduino Shield (https://www.sparkfun.com/products/10854) to the Arduino UNO. The Communication works fine. Every Request Packet is sending out to the Remote. And for every Request Packet a Remote Packet is received. I checked this with a Serial Monitor and a RS232<-> TTL Converter. But in my Arduino Software it seems to be that only one Remote Packet is received. Curious is the point that when I send the Request Packets in the time the Remote is sleeping than I read three Response if it is awake and takes the Requests from the Coordinator.
Does anyone try the same or hase the same problems? I've tried so much until know another Baudrate, delays befor sending out. Nothing works.
My recollection of ZigBee and/or 802.15.4 is that the parent node for a sleepy end device will only hold/queue a single frame for when the sleepy device wakes up. And note that in ZigBee it's only guaranteed to queue it for 7.5 seconds. You may need to modify your code to send a single Remote AT Request at a time, and wait for the response before sending another.
This page has a good description about how the MAC layer works:
Once the frame is assembled, there are actually two ways to send it.
If its going to another router or an end device whose receiver is
always on, the frame will be sent directly via the radio. Otherwise,
if the destination is a sleepy end device, the frame will need to be
sent as an indirect transfer. The frame will go to the indirect queue
until the destination device wakes up and polls the parent. Once the
poll comes in, the frame will get sent to the destination.
It would be great if the XBee module supported a frame type that contains multiple AT commands, but as far as I can tell, that isn't an option.
I am using a SAM4E-EK board, and the processor is SAM4E. The board is equiped with a ADS7843 touch controller, contected from the processor through a SPI channel.
The chapter of SPI in datasheet of SAM4E said that
While the data in the Shift Register is shifted on the MOSI line, the MISO line is sampled and shifted in the Shift Register. Receiving data cannot occur without transmitting data.
But in an example for ADS7843 from ASF, it just sends data(8 bits) three times at first, and then it can receives data(8 bits) three times! I have test it, and it work fine.
So I think there is a hardware FIFO buffer in SPI receiver. But I can not find any related information in the datasheet and internet.
Am I right? or is there others mechanism making the example runs correctly?
The SAM4E manual says that SPI Receive Data Register has the size of 2 bytes
The ADS7843 manual says:
One complete conversion can be accomplished with three serial
communications, for a total of 24 clock cycles on the DCLK input
The figure 5 shows that byte0 is a request to ADS7843 and bytes1-2 are response.
You should send 1 byte of command and 2 dump bytes to provide SPI clocking while the ADS7843 is responsing (the manual says
Receiving data cannot occur without transmitting data
And when you reading 3 bytes, you get the 2 bytes of answer, stored in the SPI Receiver register