I need to calculate number of characters passed over 1800 baud line and I am confused weather in asynchronous serial transmission start bit is 0 or 1?
Related
I have a question about the UDP protocol.
I want to stream data from a particle sensor (Xilinx FPGA Dev Board) to a raspberry pi (or Windows 10 laptop) via UDP byte socket as binary data. I don't care if some packets are lost, because there are many particles coming after anyways... But if a packet gets lost, all of the particles information should get lost.
The connection is a short lan cable over the 1 Gbit/s Ethernet port.
The "minimum" amount of data is 192 Bit (24 Byte) per particle (16 x 12 Bit value) and the maximum amount of particles is 3300 per second.
So I have to transfer max. 192 x 3300 = 79200 Byte/s plus Header etc.
Maximum packet size of UDP 65.507 Byte
As I understand the packet size has to be devidable by 24 Byte in my application.
Which leaves me with a packet size range of 24 to 65.496 Byte.
But if the concentration is lower I don't want to wait minutes until a packet is filled and ready to be send.
What would you guys suggust in regard of repitition rate and size?
E.g. a 1008 Byte packet has to be send about every 13 ms at max. particle concentration.
best regards
I just tested a UDP socket with 1024 Byte Buffer, which works nice with strings or Bitvectors for single test packets.
Background Information
I am trying to make sure I will be able to run two ADXL345 Accelerometers on the same I2C Bus.
To my understanding, the bus can transmit up to 400k bits/s on fast mode.
In order to send 1 byte of data, there are 20 extra bits of overhead.
There are 6 bytes per accelerometer reading (XLow, XHigh, YLow, YHigh, ZLow, ZHigh)
I need to do 1000 readings per second with both accelerometers
Thus,
My total data used per second is 336k bits/s which is within my limit of 400k bits/s.
I am not sure if I am doing these calculations correctly.
Question:
How much data am I transmitting per second with two accelerometers reading 1000 times per second on i2c?
Your math seems to be a bit off; for this accelerometer (from the datasheet: https://www.sparkfun.com/datasheets/Sensors/Accelerometer/ADXL345.pdf), in order to read the 6 bytes of XYZ sample data, you need to perform a 6-byte burst read of the registers. What this means in terms of data transfer is a write of the register address to the accelerometer (0x31) then a burst read of 6 bytes continuously. Each of these two transfers requires sending first the I2C device address and the R/W bit, as well as an ACK/NAK per byte, including the address bytes, as well as START/REPEAT START/STOP conditions. So, over all, an individual transfer to get a single sample (ie, a single XYZ acceleration vector) is as follows:
Start (*) | Device Address: 0x1D (7) | Write: 0 (1) | ACK (1) | Register Address: 0x31 (8) | ACK (1) | Repeat Start (*) | Device Address: 0x1D (7) | Read: 1 (1) | ACK (1) | DATA0 (8) | ACK(1) | DATA1 (8) | ACK (1) | ... | DATA5 (8) | NAK (1) | Stop (*)
If we add all that up, we get 81+3 bits of data that need to be transmitted. Note first that the START, REPEAT START and STOP might not actually take a bits worth of time each but for simplicity we can assume they do. Note also that while the device address is only 7 bits, you always need to postpend the READ/WRITE bit, so an I2C transaction is always 8 bits + ACK/NAK, so 9 bits in total. Note also, the I2C max transfer rate really defines the max SCK speed the device can handle, so in fast mode, the SCK is at most 400KHz (thus 400Kbps at most, but because of the protocol, you'll get less in real data). Thus, 84 bits at 400KHz means that we can transfer a sample in 0.21 ms or ~4700 samples/sec assuming no gaps or breaks in transmission.
Since you need to read 2 samples every 1ms (2 accelerometers, so 84 bits * 2 = 164 bits/sample or 164Kbps at 1KHz sampling rate), this should at least be possible for fast mode I2C. However, you will need to be careful that you are taking full use of the I2C controller. Depending on the software layer you are working on, it might be difficult to issue I2C burst reads fast enough (ie, 2 burst read transactions within 1ms). Using the FIFO on the accelerometer would significantly help the latency requirement, meaning instead of having 1ms to issue two burst reads, you can delay up to 32ms to issue 64 burst reads (since you have 2 accelerometers); but since you need to issue a new burst read to read the next sample, you'll have to be careful about the delay introduced by software between calls to whatever API youre using to perform the I2C transactions.
I'm reading data from serial port through MATLAB. The serial port is connected by an XBee module.
I have sucessully read the data and can also send the data correctly. Here's the code; it's quite simple:
s = serial('COM4', 'BaudRate', 9600, 'Terminator', 'CR', 'StopBit', 1, 'Parity', 'None');
fopen(s);
while(1)
while(s.BytesAvailable==0)
end
fprintf(s,'1');
fscanf(s)
s.BytesAvailable
end
So, as you can see at the first stage of the main loop, I'm waiting until data is available in the input buffer. Once the code detects data, immediately a character is sent. However the execution is not fast as I expected. Using an oscilloscope, probes on Xbee DIN and DOUT, I measure 34 ms between when the data is sent to the PC and when the data comes from the PC.
For my application, 34 ms is a critical time.
How can I fix this?
Why do you use USRT (universal serial receiver/transmitter) at 9600 Baud rate?
Your USRT setup, "'BaudRate', 9600, 'StopBit', 1" means one byte (8 bit) of data is transferred by 10 bits (1 start bit, 8 data bit and 1 stop bit) on the wire whose speed is 9600 bit per second, so 960 bytes per second is the maximum speed of data.
It is about one byte per ms (millisecond).
XBee use 5 byte for the header, so its header overhead is about 5 ms.
34 ms is not so bad if you use 25-28 bytes of data. If you use only few bytes of data, you may have another problem.
To improve on this problem, you should use a higher rate for USRT.
If you use the following setup, transmission of your data may be achieved within 3 ms - 4 ms.
s = serial('COM4', 'BaudRate', 115200, 'Terminator', 'CR', 'StopBit', 1, 'Parity', 'None');
I would just change the Baud rate from 9600 to 115200 in your code.
I'd like to send multiple signals (4 inputs and outputs and 7 outputs) from my Laptop to a microcontroller. I'm thinking of using a USB to serial converter and multiplexing the data through the port. I'll need to write codes both in the laptop end and in the microcontroller to multiplex the data.
Eg:
Tx of microcontroller:
1.Temperature sensor ADC output->Laptop
2.Voltage sensor to laptop
3.Current Sensor to Laptop
4.Photodiode current to Laptop
So I need to write a program in the microcontroller to send the data in this order. How can I accomplish this? I was thinking of an infinite loop which sends the data with time delays in between.
At the Rx pin of Microcontroller,
Seven bit sequences. Each bit sequence will be used to set the duty cycle of a PWM generated by the microcontroller.
I also need the same multiplexing or demultiplexing arrangement in the matlab end. Here too, I'm thinking of allotting some virtual 'channels' at different instants of time. What kind of algorithm would I need?
In case you always send all the inputs/outputs at the same rate, you could simply pack them into 'packets', which always start with one or more bytes with a fixed value that form a 'packet header'. The only risk is that one of the bytes of the sensor data might have the same value as the start-byte at the moment you try to start receiving bytes and you are not yet synchronized. You can reduce this risk by making the header longer, or by choosing a start-byte that is illegal output for the sensors (typically OxFF or so).
The sending loop on the microcontroller is really easy (pseudocode):
while True:
measure_sensors()
serial.send(START_BYTE)
serial.send(temperature)
serial.send(voltage)
serial.send(current)
serial.send(photodiode)
end while
The receiving loop is a bit more tricky, since it needs to synchronize first:
while True:
data = serial.receive()
if data != START_BYTE:
print 'not synced'
continue #restart at top of while
end if
temperature = serial.receive()
voltage = serial.receive()
current = serial.receive()
photodiode = serial.receive()
do_stuff_with_measurements()
end while
This same scheme can be used for communication in both directions.
I'm currently learning about interrupts but don't understand how you
calculate the data rate for the question below. I have the answers but
I have no idea how you get there. If someone could please explain to
me how it is calculated it would be really appreciated.
Here is the question...
This question concerns the use of interrupts to handle the input and
storage in memory of data arriving at an input interface, and the
consideration of data rates that be achieved using this mechanism. In
this particular question, the arrival of each new data item triggers
an interrupt request to input and store the data item in a queue in
memory.The question is about calculating the maximum data rate
achievable in this scenario.
You are first required to calculate the time to respond to an
interrupt from the interface, run the interrupt service routine (ISR)
and return to the interrupted program.From this and the number of data
bits input on each interrupt, you are required to calculate the
maximum data rate in bits per second, that can be handled. Below you
are given: the number of clock cycles the CPU requires to respond to
the interrupt and switch to the ISR, the number of instructions
executed by the ISR, the average number of clock cycles executed per
instruction in the ISR, the number of bits in the data item input on
each interrupt, and the clock frequency. [You can assume that when the
CPU can be immediately interrupted again as soon as the ISR completes,
but not before this]
clock cycles to respond to interrupt = 15
instructions executed in ISR= 70
average clock cycles per instruction = 5
number of bits per data item = 32
clock frequency = 10MHz
Questions
a) What is the time in microseconds to respond to an interrupt from
the interface, run the interrupt service routine (ISR) and return to
the interrupted program?
b)What is the maximum data rate in Kbits/second?
Answers
a) 36.5 - I understand this
b) 876.7 - ????
Because each ISR takes 36.5 us, the absolute maximum number of ISRs that can happen in a second is 27,397.2603.
In each ISR, 32 bits of data are processed.
Therefore, 27397.2603 * 32 bits = 876.712.33 bits processed per second