I got some error like "error from Property Node (arg 8) in VISA Configure Serial Port." How to know which arg is arg 8?, which is arg 1 etc.
This is flow control.
Specifies the flow control method used for both transmitting and receiving data. Valid values include: (0) Flow None, (1) Flow XON/XOFF, (2) Flow RTS/CTS, (3) Flow XON/XOFF and RTS/CTS, (4) Flow DTR/DSR, (5) Flow XON/XOFF and DTR/DSR. Certain values or combinations of values may not be supported by all serial ports and/or operating systems.
(0) None—Does not use flow control, and buffers on both sides of the connection are assumed to be large enough to hold all data transferred.
(1) XON/XOFF—Uses the XON and XOFF characters to perform flow control. The transfer mechanism controls input flow by sending XOFF when the low-level I/O receive buffer is nearly full, and it controls the output flow by suspending transmission when XOFF is received.
(2) RTS/CTS—Uses the RTS output signal and the CTS input signal to perform flow control. The transfer mechanism controls input flow by unasserting the RTS signal when the low-level I/O receive buffer is nearly full, and it controls output flow by suspending the transmission when the CTS signal is unasserted.
(3) XON/XOFF and RTS/CTS—Uses both values 1 & 2.
(4) DTR/DSR—Uses the DTR output signal and the DSR input signal to perform flow control. The transfer mechanism controls input flow by unasserting the DTR signal when the low-level I/O receive buffer is nearly full, and it controls output flow by suspending the transmission when the DSR signal is unasserted.
(5) XON/XOFF and DTR/DSR—Uses both values 4 & 5.
Please have a look on the picture.
Related
I have been experimenting with message passing in the Signal Source block in GNU Radio companion. I can see from its source code that we can pass messages to change the frequency, amplitude, offset and phase of the source. For example, the following message PMT sent from a message strobe can change the amplitude of the signal to 0.5.
pmt.dict_add(pmt.make_dict(), pmt.intern("ampl"), pmt.from_double(0.5))
But when I viewed the code of UHD USRP Sink, I couldn't get a clear idea as to what commands can be sent to this block or that which parameters can be changed. I have read at some places in the documentation that frequency, gain, LO offset, timestamp, center frequency and other transceiver related settings of the USRP Sink can be manipulated through command messages.
What commands can be sent to the USRP Sink block from a message strobe (in the pmt format) and which parameters (and their keys) can be modified?
This is officially documented:
https://www.gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax
Command name
Value Type
Description
chan
int
Specifies a channel. If this is not given, either all channels are chosen, or channel 0, depending on the action. A value of -1 forces 'all channels', where possible.
gain
double
Sets the Tx or Rx gain (in dB). Defaults to all channels.
power_dbm
double
Sets the Tx or Rx power reference level (in dBm). Defaults to all channels. Works for certain devices only, and only if calibration data is available.
freq
double
Sets the Tx or Rx frequency. Defaults to all channels. If specified without lo_offset, it will set the LO offset to zero.
lo_offset
double
Sets an LO offset. Defaults to all channels. Note this does not affect the effective center frequency.
tune
tune_request
Like freq, but sets a full tune request (i.e. center frequency and DSP offset). Defaults to all channels.
mtune
tune_request_t
Like tune, but supports a full manual tune request as uhd::tune_request_t. Defaults to all channels.
lo_freq
double
For fully manual tuning: Set the LO frequency (RF frequency). Conflicts with freq, lo_offset, and tune.
dsp_freq
double
For fully manual tuning: Set the DSP frequency (CORDIC frequency). Conflicts with freq, lo_offset, and tune.
direction
string
Used for timed transceiver tuning to ensure tuning order is maintained. Values other than 'TX' or 'RX' will be ignored.
rate
double
See usrp_block::set_samp_rate(). Always affects all channels.
bandwidth
double
See usrp_block::set_bandwidth(). Defaults to all channels.
time
timestamp
Sets a command time. See usrp_block::set_command_time(). A value of PMT_NIL will clear the command time.
mboard
int
Specify mboard index, where applicable.
antenna
string
See usrp_block::set_antenna(). Defaults to all channels.
gpio
gpio
PMT dictionary including bank, attr, value, mask for GPIO. See notes.
I'm writing a very specific application protocol to enable communication between 2 nodes. Node 1 is an embedded platform (a microcontroller), while node 2 is a common computer.
Such protocol defines messages of variable length. This means that sometimes node 1 sends a message of 100 bytes to node 2, while another time it sends a message of 452 bytes.
Such protocol shall be independent on how the messages are transmitted. For instance, the same message can be sent over USB, Bluetooth, etc.
Let's assume that a protocol message is defined as:
| Length (4 bytes) | ...Payload (variable length)... |
I'm struggling about how the receiver can recognise how long is the incoming message. So far, I have thought about 2 approaches.
1st approach
The sender sends the length first (4 bytes, always fixed size), and the message afterwards.
For instance, the sender does something like this:
// assuming that the parameters of send() are: data, length of data
send(msg_length, 4)
send(msg, msg_length - 4)
While the receiver side does:
msg_length = receive(4)
msg = receive(msg_length)
This may be ok with some "physical protocols" (e.g. UART), but with more complex ones (e.g. USB) transmitting the length with a separate packet may introduce some overhead. The reason being that an additional USB packet (with control data, ACK packets as well) is required to be transmitted for only 4 bytes.
However, with this approach the receiver side is pretty simple.
2nd approach
The alternative would be that the receiver keeps receiving data into a buffer, and at some point tries to find a valid message. Valid means: finding the length of the message first, and then its payload.
Most likely this approach requires adding some "start message" byte(s) at the beginning of the message, such that the receiver can use them to identify where a message is starting.
I have some simple vulkan app which have:
3 command buffers for each swapchain image (#1, #2, #3)
1 uniform buffer with projection matrix data
I want to bind uniform buffer once. i'm using command buffer #1 to bind uniform buffer:
begin();
bindDescriptorSets();
end();
submit();
waitIdle();
reset();
Then i record commands for each swapchain image (3 times):
begin()
bindVertexBuffers()
beginRenderPass()
bindPipeline()
draw()
endRenderPass()
end();
Drawing works as expected, but validation layer logs an error:
[ UNASSIGNED-CoreValidation-DrawState-DescriptorSetNotBound ] Object: 0x1a57aad7910 (Type = 6) | VkPipeline 0x21 uses set #0 but that set is not bound.
If i move the bindDescriptorSets(); line to the second recording block, like this:
begin()
bindDescriptorSets();
bindVertexBuffers()
beginRenderPass()
bindPipeline()
draw()
endRenderPass()
end();
Validation is OK, but there is no difference in rendering.
So, the question is: do i have to bind descriptor sets for each buffer recording? If yes, why does the app work fine when i'm binding descriptor sets once?
I believe it relates to the current state of the Vulkan application. Let's see what specification says about the state:
2.2.1. Queue Operation
Commands recorded in command buffers either perform actions (...), set state (bind pipelines, descriptor sets,
and buffers, set dynamic state, push constants, set render
pass/subpass state), or perform synchronization (...). Some commands
perform more than one of these tasks. State setting commands update
the current state of the command buffer.
Notice I marked in bold that binding a descriptor set is a state command.
You bind descriptor set to a command buffer end that buffer and submit. Next, you start other command buffers. Let's see again what specification tells us about the command buffers:
Command Buffers
Each command buffer manages state independently of other command buffers. There is no inheritance of state across primary
and secondary command buffers, or between secondary command buffers.
When a command buffer begins recording, all state in that command
buffer is undefined.
So the specification and layers tell you that you have to bind descriptors to every command buffer that uses that state. Why it works even with warnings? I don't know, probably your implementation allows it, but I wouldn't recommend to keep it as it is.
I have built an OFDM transceiver with rayleigh channel using standard PDP's Like EPA,EVA and ETU.The problem is I am getting very high BER even for BPSK i.e 50-60 % or higher bits in error.Scatterplotting confirms it.My OFDM transceiver blocks include:
---- Random Data -- Modulation(BPSK,QPSK,QAM) -- Serial2Parallel -- IFFT -- CyclicPrefix >>> Rayleigh Ch >>> Remove CP Data---FFT --- Par2Ser ---DeMod --- Sink Data.
I have used builtin matlab function to create Rayleigh channel passing standard PDP as parameter.
channelObj = rayleighchan(tSampling,fDoppler,tau_in_sec,pdb_in_dB);
channelObj.ResetBeforeFiltering=0; % channel remains static before filtering
Filtering for n-OFDM symbols & calculating CIR
for symb=1:OFDMSymb
ofdm_td_rx_signal(:,symb) = filter(channelObj, ofdm_td_TXdata(:,symb));
channel_cir(tapIndices,symb)= (channelObj.PathGains).';
end
channel_cfr = fft(channel_cir,nCarrier); % freq. response from CIR
Similarly at receiver,after FFT block,I just tried to use this CFR by dividing received symbol by CFR as
fft_RXdata=fft_data./channel_cfr;
What I am getting is very high SNR and scattered constellation symbols.Rest of transceiver blocks are simple and all verified as bug free...Do let me how to improve it.
How I could get improve BER?
Any need of equalizer?Should a match filter would help?Thanks in advance.
NOTE:ONLY RAYLEIGH CHANNEL IS USED AWGN NOISE IS NOT ADDED AT ALL ...
One possible solution that have helped me is use of block based pilots(reference dummy data) transmission with OFDM symbols.Least square channel estimation is performed at RX using received pilots data which inherently captured the channel behavior.
I would like to send string of chars from one proc (master) to another (slave) and then read string from a slave.
Currently im mixing up the arduino and LPC1788, using lpc as master and arduino as slave.
LPC sent's the string correctly which is received by the arduino in ISR. In loop function i check if all of the chars are received and then try to send string back. On LPC side ISR is not working for some reason. I have set SR as
SR = (1<<TNF) | (1<<RNE);
So i have put delay after sending the string from LPC and then initiate read from arduino.
What i see on LA for sending the string is:
but reading of string from Arduino looks odd (string should be "Pong\n", it is not always P that i received... it varies)
i guess majority of problem is within the sync of sending and reading of SPI buffer. How do i achieve that without functional ISR on LPC?
The SPI specification states that the CS (SSEL) line should be active during a frame and become inactive in between. NXP interpreted this as a word being one frame. This means that the CS as generated by the SSP block (the same goes for the legacy SPI) is only active during one transaction of up to 16 bits.
Note also that there is always a gap in between the words/frames being sent. So even when you fill the FIFO or use DMA you will see 16 clock pulses, a short delay and then 16 more pulses.
When using a GPIO pin as SSEL, please note you have to wait for SSEL assertion or de-assertion until the peripheral is idle.