PIC32MX: High-speed Wireless Communication - Revision history

AndrewKessler: /* Latency and Data Rates */

2010-09-17T16:10:12Z

Latency and Data Rates

AndrewKessler: /* Latency and Data Rates */

2010-09-17T16:07:50Z

Latency and Data Rates

AndrewKessler: /* Latency and Data Rates */

2010-09-17T16:06:53Z

Latency and Data Rates

AndrewKessler: /* =Throughput */

2010-09-17T16:06:37Z

=Throughput

AndrewKessler: /* Latency and Data Rates */

2010-09-17T16:06:12Z

Latency and Data Rates

AndrewKessler: /* Latency and Data Rates */

2010-09-17T16:05:31Z

Latency and Data Rates

AndrewKessler: /* Latency */

2010-09-17T16:03:53Z

Latency

AndrewKessler: /* Data Rates */

2010-09-17T15:57:54Z

Data Rates

AndrewKessler: /* Circuit */

2010-08-26T21:41:17Z

Circuit

AndrewKessler: /* Initialization Functions */

2010-08-26T21:39:23Z

Initialization Functions

@@ Line 163: / Line 163: @@
 To measure transmission latency, an oscilloscope was used to time how long it took before transmission was complete. For instance, something like this was used:
+ [[Image:nrf-latency.jpg|thumb|Plot of Transmission Latency]]
+[[Image:bps-nrf24l01.jpg|thumb|Plot of Data Rates]]
 <code><pre>
 while(1){
@@ Line 178: / Line 180: @@
 }
 </pre></code>
- [[Image:nrf-latency.jpg|thumb|Plot of Transmission Latency]]
 Three measurements of time to transmit were done for each payload size. It should be noted that these results are completely independent of whether or not the transmission successfully made it to a receiver; in fact, these tests were done without a receiving PIC. The results seem to indicate a latency of 178 microseconds.
 Throughput tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
-[[Image:bps-nrf24l01.jpg|thumb|Plot of Data Rates]]

@@ Line 162: / Line 162: @@
 Basic timed tests were done to find out how long it took to transmit and receive different sized payloads, as well as the latency involved with transmission.
-===Latency===
 To measure transmission latency, an oscilloscope was used to time how long it took before transmission was complete. For instance, something like this was used:
 <code><pre>
@@ Line 182: / Line 181: @@
 Three measurements of time to transmit were done for each payload size. It should be noted that these results are completely independent of whether or not the transmission successfully made it to a receiver; in fact, these tests were done without a receiving PIC. The results seem to indicate a latency of 178 microseconds.
+Throughput tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
-===Throughput===
-These tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
 [[Image:bps-nrf24l01.jpg|thumb|Plot of Data Rates]]

@@ Line 179: / Line 179: @@
 }
 </pre></code>
-Three measurements of time to transmit were done for each payload size. It should be noted that these results are completely independent of whether or not the transmission successfully made it to a receiver; in fact, these tests were done without a receiving PIC. The results seem to indicate a latency of 178 microseconds.
  [[Image:nrf-latency.jpg|thumb|Plot of Transmission Latency]]
+Three measurements of time to transmit were done for each payload size. It should be noted that these results are completely independent of whether or not the transmission successfully made it to a receiver; in fact, these tests were done without a receiving PIC. The results seem to indicate a latency of 178 microseconds.
 ===Throughput===

@@ Line 183: / Line 183: @@
  [[Image:nrf-latency.jpg|thumb|Plot of Transmission Latency]]
-===Throughput==
+===Throughput===
 These tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
 [[Image:bps-nrf24l01.jpg|thumb|Plot of Data Rates]]

@@ Line 183: / Line 183: @@
  [[Image:nrf-latency.jpg|thumb|Plot of Transmission Latency]]
+===Throughput==
 These tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
-[[Image:bps-nrf24l01.jpg|tumb|Plot of Data Rates]]
+[[Image:bps-nrf24l01.jpg|thumb|Plot of Data Rates]]

@@ Line 158: / Line 158: @@
 To establish a bidirectional link, both PICs should have the same bidirectional c-file loaded (but this is not necessary: e.g. one PIC could only be able to transmit, and it would still be a viable one-way link ). If the on air data rate is set to 1 Mbps, then this bidirectional c-file is compatible with the [http://www.sparkfun.com/commerce/product_info.php?products_id=9019 Nordic USB Serial Converter] (note that the Nordic USB-Serial converter is only compatible with a payload width of four bytes). The payload width of the bidirectional link can be adjusted with the "[" and "]" keys, exactly as with the above code.
-==Data Rates==
+==Latency and Data Rates==
+Basic timed tests were done to find out how long it took to transmit and receive different sized payloads, as well as the latency involved with transmission.
-Basic timed tests were done to find out how long it took to transmit and receive different sized payloads. These tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
+===Latency===
+To measure transmission latency, an oscilloscope was used to time how long it took before transmission was complete. For instance, something like:
+[code][pre]
+while(1){
+	if (!swUser){
+			PIN_D1=1; //raise test pin
+			nrf24l01_write_tx_payload(dataToSend, width, true); //transmit char array over RF
+			//wait until the packet has been sent
+			while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active()));
+			PIN_D1=0; //lower test pin
+			nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
+[/code][/pre]
+ These tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
 [[Image:bps-nrf24l01.jpg|center]]

@@ Line 25: / Line 25: @@
 [[Image:Wireless-circuit.jpg|thumb|Schematic of the nRF24L01+ connected to the PIC32_NU32 board]]
-The wireless chip has 8 pins that need to be wired to the PIC (all I/O are relative to PIC):
+The nrf24L01+ chip has 8 pins that need to be wired to the PIC (all I/O are relative to PIC):
 *Vcc: +3.3 Vdc supply<br>

@@ Line 100: / Line 100: @@
    	 OpenUART2( config1, config2, pbClk/16/DESIRED_BAUDRATE-1);	// calculate actual BAUD generate value.
    	 ConfigIntUART2(UART_INT_PR2 | UART_RX_INT_EN);
-   	 //INTEnableSystemMultiVectoredInt();
+   	 //INTEnableSystemMultiVectoredInt(); //interrupts enabled?
  }
 </pre></code>