Not sampling at 5 ms when I increase NREADINGS to 2 in the Oscilloscope application (TinyOS) - tinyos

In the TinyOS Oscilloscope application on micaz motes, when I set the sampling rate to 5 ms with NREADINGS = 1, I notice the blinking of the green LED going really fast. But when I set NREADINGS = 2 and sampling rate to 5 ms, I notice the blinking becomes slower which means I am sending fewer packets than in the previous case. Is there any way I can get the blinking to be faster, that is, can I do something to increase the number of packets I send at NREADINGS = 2 and sampling rate equal to 5 ms?

The sampling rate determines how often the Oscilloscope application samples a sensor. NREADINGS determines how many samples the application obtains before it sends them in a radio packet. LED blinks each time the application sends a packet. Therefore, if you increase NREADINGS from 1 to 2, it will blink approximately every 10 ms instead of 5 ms (every two samples).
If you want to send packets with the same frequency when you increase NREADINGS, at the same you have to decrease the sampling interval. Note, however, that sampling a sensor as well as sending a packet takes some time, so there are some constraints on how fast the application can work.

Related

How To calculate bandwidth, bitrate and buffer size of switches

Lets say I have 2 switches and 2-2 devices connected to each switch.
Each device sends data to other devices in a cylic manner for example Device1 sends data at 100msec, device 2 at 200ms.
So i want to calculate the required bandwidth for each device and switch if the data size sent is approx 2000bytes.
So now in my simulation I have given bandwidth values of 10Mbps, but after certain period lets say after 1 minute of simulation..
switch buffer starts filling up and messages are getting droped.
So in my conclusion i think bandwith is the problem because messages are not sent or accepted with required bitrates.
So I want to calculate bandwith of each device and switch.enter image description here
2000 bytes every 100 ms is 2000 * 8 / .1 = 160 kbit/s. If you've got four such sources, you're using roughly 6.5% of a 10 Mbit/s link.
Even if each device unicasts that amount to each of the three others, that total bandwidth is only tripled. Only half of those unicasts (~1 Mbit/s) cross the switch interconnect which is your bottleneck. Also, modern Ethernet is full duplex, so a 10 Mbit/s interface can transmit 10 Mbit/s and receive 10 Mbit/s at the same time.
Of course, a better approach would be to use multicast. That way, each data chunk is only propagated through the network in a single instance.
If your network goes down after a few seconds, then the parameters above or the diagram aren't correct, or the simulation is flawed.

Maximum throughput meaning

Host A is sending data to host B over a full duplex
link. A and B are using the sliding window
protocol for flow control. The send and receive
window sizes are 5 packets each. Data packets
(sent only from A to B) are all 1000 bytes long
and the transmission time for such a packet is
50 ps. Acknowledgment packets (sent only from
B to A) are very small and require negligible
transmission time. The propagation delay over
the link is 200 trrs. What is the maximum
achievable throughput in this communication?
This question was asked in gate my question. I have calculated it, but what is the meaning of word 'maximum'? The calculation was just for throughput. How would one calculate minimum throughput?
I think maximum means assuming no packets loss and therefore no retries. Also, no additional transmission time above the 50ms. Basically, given the above transmission time and propagation delay, how many bytes can be sent and acknowledged per sec?
My intuition is to figure out how long it takes to send 5 packets to fill up the window with the propagation delay added. Then add the time for the acknowledgement for the first packet to arrive at the sender. That's your basic window send and acknowledgement time because as soon as the acknowledgement arrives the window will slide forward by one packet.
Since the window is 5 packets and each packet is 1,000 bytes then the maximum throughput should be 5,000 bytes / the time you calculated for the above cycle.

What does a higher clock signal frequency actually mean?

I've got an Arduino with an ATmega328 processor. It can be operated at 3.3V which nets a clock signal frequency of about 12 MHz respectively 16 Mhz at 5V.
I connected an IMU to the Arduino which runs an AHRS algorithm turning accelerometer, gyroscope and magnetometer data into orientation data.
What does the higher frequency of 16 MHz actually mean in this context?
Will the AHRS be calculated faster so I get a lower latency? Can I poll the sensors more often? I want a deeper understanding of what I'm doing here.
Higher frequency means more clock cycles per second which means more operations are done during the same duration of time. This means AHRS runs faster and you will achieve a lower latency and if you are repeatedly reading values from the IMU, you will be able to poll more often.

CSMA/CD: Minimum frame size to hear all collisions?

Question from a networking class:
"In a csma/cd lan of 2 km running at 100 megabits per second, what would be the minimum frame size to hear all collisions?"
Looked all over and can't find info anywhere on how to do this. Is there a formula for this problem? Thanks for any help.
bandwidth delay product is the amount of data on transit.
propagation delay is the amount of time it takes for the signal to propagate over network.
propagation delay=(lenght of wire/speed of signal).
assuming copper wire i.e speed =2/3* speed of light
propagation delay =(2000/(2*3*10^8/3))
=10us
round trip time is the time taken for message to travel from sender to receiver and back from receiver to sender.
round trip time =2*propagation delay =20us
minimum frame size =bandwidth *delay (rtt)
frame size = bandwidth *rtt
=100Mbps*20us=2000bits

Multiple analogRead() calls at timed intervals

I'm looking to add the ability to capture wave forms to an ATmega 328 based product and I've been unable to find details on how responsive the ATmega 328 is when doing A/D conversions. The code is being prototyped on an Arduino, but will be migrated to custom board when done.
My plan is to have a total period (typically 16 to 20 milliseconds, based on local AC line frequency) and sample a single pin on the order of 50 to 100 times during that interval. Can the ATmega 328 reliably perform that many conversions successively? The minimum interval per conversion is 16ms / 100 = 160us.
I can add a code example if anyone has to see code, but right now I'm more concerned about the minimum period between multiple successive A/D conversions.
The easiest way would be to write a Arduino script and do some timing benchmarks for yourself.
The other way - doing this by spec - requires some more input for each involved level.
On the lowest level is the ATmega328 chip. The docs on the ADC part says:
By default, the successive approximation circuitry requires an input clock frequency between 50 kHz and 200 kHz to get maximum resolution. If a lower resolution than 10 bits is needed, the input clock frequency to the ADC can be higher than 200 kHz to get a higher sample rate.
Assuming a 16 MHz clock for the ATMega the only available prescaler value for the ADC clock is 128 which is 125kHz for 10 bit resolution. You could use the prescaler value 64 (250kHz) if you can get away with 8 bit resolution.
Next: The doc says:
A normal conversion takes 13 ADC clock cycles. The first conversion after the ADC is switched on (ADEN in ADCSRA is set) takes 25 ADC clock cycles in order to initialize the analog circuitry.
So taking the 125kHz ADC clock this would mean ~9600Hz sample rate in "single conversion" mode. This is 104µs per sample. These are the Arduino defaults.
Compared to your requirement of 160µs this seems good.
BUT: So far only the conversion alone have been considered. You have to transfer the data somewhere. ALSO the Arduino analogRead() function has some overhead as you can see in the file wiring_analog.c in the Arduino dist.
This overhead might be to much - you have to test it for yourself.
On the other hand: Nobody forces you to use the Arduino analogRead function. Some available choices:
you can ditch the overhead of analogRead and/or
you can reconfigure the ADC to your needs (8 bit only, higher ADC clock) and/or
you can use "advanced" modes like continuous sampling ("freerunning mode"9 of the ADC or
you can use even interrupts to trigger the conversions.
Of course all of these choices heavily depend on your knowledge and time budget. :-)

Resources