I have this 3-axis dongle serial accelerometer connected using RS-232 cable. I am putting the baud rate as 9600 and im getting 80 XXXX-YYYY-ZZZZ readout per second. I am trying to justify why does it shows 80 readings in a second, and here is my calculation,
2 Bytes of data x (1 Start bit + 1 Stop bit + 8 bits) = 20 bits
20 bits x 3 axis x 80 readouts = 4800 bits
While im getting 4800 bits instead of 9600 bits, so i am wondering did i miss out anything in justifying the 80 readouts?
Thanks guys :)
You indicate that you're getting 80 XXXX-YYYY-ZZZZ readouts per second. I'm assuming this is ASCII, so each digit is one byte.
So each "message" is len('XXXX-YYYY-ZZZZ')*8 = 112 bits long. Add a start and stop bit and you have 114. Multiply that times 80 messages per second, and you're transmitting 9120 bits per second, which is much close to the theoretical limit.
Related
I am using a dht11 sensor and get the raw bits, where the first 8 Bits are the integral of humidity and following 8 bit the decimals of the humidity. The next 8 Bits are the the integral of temperature, followed by 8 bit decimals of the temperature. In the end there is a 8 bit checksum.
I read some datasheets, but could not find any information about how the decimals have to be read.
Does anyone know if it is a simple fixed-point 8 Bit decimals or do I have to do it differently?
Any help is appreciated
From the dht11 datasheet, only positive values for humidity and temperature can be returned, so no bit reserved for the sign.
This is a Q8.8 fixed point representation (see also https://en.wikipedia.org/wiki/Q_(number_format)).
To translate from the representation to the physical value you have to divide by 2^8, where 8 is the number of fractional bits.
So for example:
0000 0010 1000 0000 = 640 decimal
640/256 = 2.5 decimal
I'm currently learning about transmission delay and propagation. I'm really having a tough time with the conversions. I understand how it all works but I cant get through the converting. For example:
8000bits/5mbps(mega bits per second) I have no idea how to do this conversion , I've tried looking online but no one explains how the conversion happens. I'm supposed to get 1.6 ms, but I cannot see how the heck that happens. I tried doing it this way, 8000b / 5x10^6 b/s but that gives me 1600 s.
(because that would not fit in a comment):
8000 bits = 8000 / 1000 = 8 kbit, or 8000 / 1000 / 1000 = 0.008 mbit.
(or 8000 / 1024 = 7.8 Kibit, or 8000 / 1024 / 1024 = 0.0076 Mibit,
see here: https://en.wikipedia.org/wiki/Data_rate_units)
Say you have a throughput of 5mbps (mega bits per second), to transmit your 8000 bits that's:
( 0.008 mbit) / (5 mbit/s) = 0.0016 s = 1.6 ms
That is, unit wise:
bit / (bit/s)
bit divided by bit => the bit unit disappear,
then divide and divide by seconds = not "something per second", but second,
result unit is second.
I'm having some difficulty calculating the total time it takes a packet to get from A to B, the question is:
"We have 200 bytes of data to send from A to B, with a distance of 200km between them. Calculate the total transmission time, assuming the speed of the signal is 200,000 km/s and that the data rate is 1Mbps and that a header of 40 bytes has to be added to the data before it is sent."
My understanding is that at some point you need to factor in propagation and the speed of light (??) but I'm unsure if it's needed in this case. Is there a formula which can be used to work these types of question out?
So we have a total of 200 bytes of payload + 40 bytes of header = 240 bytes. The data can be put on the wire at a rate of 1 Mbps which equals 1,000,000 bits per second (unless the question actually means Mibps which is 1,048,576 bits per second; we'll work on the assumption that Mbps is correct and it's 1,000,000).
240 bytes is equal to 1920 bits (240 * 8), so it takes
1920 bits / 1,000,000 bits per second = 0.00192 seconds
to get the data on the wire.
Now, for the data to be transmitted, it has to travel 200 km at a rate of 200,000 km/s.
200km / 200,000(km/s) = 0.001 seconds.
Now, to take the data from the wire and read into computer in location B takes the same amount of time as putting the data on the wire = 0.00192 seconds.
So the total amount of time is equal to
0.00192 + 0.001 + 0.00192 = 0.00484 seconds = 4.84 milliseconds.
I am trying to understand how to calculate the throughput for a sliding window data transmission, by solving some numerical examples. Below is the example followed by my analysis.
Example
Host A is sending data to Host B over a full duplex link. A and B are using sliding window protocol, with send and receive window sizes of 5 each. Data packets sent only from A to B, are 1000 bytes each in size, and transmission time for one such packet is 50 us. Propagation delay is 200 us. Assume Ack packets need negligible transmission time. What is the maximum achievable throughput in Mbps?
A. 7.69 B. 11.11 C. 12.33 D. 15.00
Analysis
Round trip-time is 2 * 200 us = 400 us. ... A
Time required to fill the sending window = window size (5) * transmission time of 1 packet (50 us) = 250 us. ... B
Since B < A, sender has to wait for ack to 1st packet before sending the 6th packet. This ack appears at 450 us. (round-trip time is 400 us.)
Between 250 us and 450 us, the sender is idle, that is no new data is being sent over the line.
Assuming sender has an unlimited supply of data frames, the above cycle would repeat.
Thus, in every 450 us, sender sends 5 packets = 5 * 1000 * 8 = 40000 bits of data.
Hence, throughput = 40000 bits / 450 us = 84.7710 megabits per second. (84.7710 Mbps)
However, this is not one of the given options, not even close! Is there any mistake in my analysis above?
As I stated in my comment, your analysis and calculation method is correct. However, I'd check my calculator if I were you because 40000 bits / 450 us = 88.88...Mbps, not 84.7710 Mbps.
I do not think it is mere coincidence that 88.88 is just 11.11*8, so it's a fair assumption that the question was actually asking to get megabytes per second instead of megabits per second.
Throughput = Window /RTT
Here Window size = 5*1000 bytes = 5000 bytes.
RTT = 50us + 2*200 us=> 450us.
Therefore Throughput= 5000 bytes/450 us = 11.11Mpbs
I had a long time decoding IR codes with optimum's Ken Shirriff Arduino Library. I modified the code a bit so that I was able to dump a Samsung air conditioner (MH026FB) 56-bit signals.
The results of my work is located in Google Docs document Samsung MH026FB AirCon IR Codes Dump.
It is a spreasheet with all dumped values and the interpretation of results. AFAIK, air conditioner unit sends out two or three "bursts" of 56 bit data, depending on command. I was able to decode bits properly, figuring out where air conditioner temperature, fan, function and other options are located.
The problem I have is related to the checksum. In all those 7-byte codes, the second one is computed somehow from the latter 5 bytes, for example:
BF B2 0F FF FF FF F0 (lead-in code)
7F B8 8A 71 F6 4F F0 (auto mode - 25 degrees)
7F B2 80 71 7A 4F F0 (auto mode - 26 degrees)
7F B4 80 71 FA 7D F0 (heat mode - 26 degrees - fan auto)
Since I re-create the IR codes at runtime, I need to be able to compute checksum for these codes.
I tried with many standard checksum algorithms, none of them gave meaningful results. The checksum seems to be related to number of zeroes in the rest of code (bytes from 3 to 7), but I really can't figure it how.
Is there a solution to this problem?
Ken Shirriff sorted this out. Algorithm is as follow:
Count the number of 1 bits in all the bytes except #2 (checksum)
Compute count mod 15. If the value is 0, use 15 instead.
Take the value from 2, flip the 4 bits, and reverse the 4 bits.
The checksum is Bn where n is the value from the previous step.
Congraturations to him for his smartness and sharpness.
When bit order in bytes/packets and 0/1 are interpreted properly (from the algorithm it appears that both are reversed), the algorithm would be just sum of 0 bits modulo 15.
It is nearly correct.
Count the 0's / 1's (You can call them what you like, but it is the short signals).
Do not count 2. byte and first/last bit of 3.byte (depending if you are seeing it as big or little indian).
Take the result and -30 (29-30 = 15, only looking af 4 bits!)
Reverse result
Checksum = 0x4 "reverse resultesult", if short signals = 0, and 0xB "reverse resultesult" if long signal = 0.
i used Ken's method but mod 15 didnt work for me.
Count the number of 1 bits in all the bytes except #2 (checksum)
Compute count mod 17. if value is 16, use first byte of mode result(0).
Take the value , flip the 4 bits.
The checksum is 0xn9 where n is the value from the previous step.