0% found this document useful (0 votes)
73 views

Procedure For Hamming Generator Test

The document describes procedures to test a Hamming code generator and error detection/correction hardware. It involves: 1. Testing the generator by inputting all possible 4-bit combinations and verifying the parity bits match theory. 2. Testing error detection by introducing single bit errors, measuring the syndrome, and verifying it indicates the correct error location. 3. Testing error correction by introducing errors, measuring that the syndrome correctly identifies the location, and that the output matches the original data. 4. Results of the tests are shown to validate the hardware's ability to detect and correct single bit errors using Hamming codes.

Uploaded by

api-26331790
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
73 views

Procedure For Hamming Generator Test

The document describes procedures to test a Hamming code generator and error detection/correction hardware. It involves: 1. Testing the generator by inputting all possible 4-bit combinations and verifying the parity bits match theory. 2. Testing error detection by introducing single bit errors, measuring the syndrome, and verifying it indicates the correct error location. 3. Testing error correction by introducing errors, measuring that the syndrome correctly identifies the location, and that the output matches the original data. 4. Results of the tests are shown to validate the hardware's ability to detect and correct single bit errors using Hamming codes.

Uploaded by

api-26331790
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 22

To accomplish the modulo two addition required for generation of the parity bits, in hardware,

the data bits are connected to XOR gates, the outputs of which are the parity bits. This can be
seen in Fig. 3.2.2. A simple test was then run on the system to verify it was generating the proper
data parity bits. The procedure for this test is as follows:

Procedure for Hamming Generator Test

1. Set up the circuit in Fig. 5.2.2.


2. Measure the parity bits generated with each possible 4 bit combination of data.
3. Compare each P1, P2, and P3 value with what is expected from equations 5.7.1-5.7.3
from theory.

Table 5.7.3 of the Observed and Measured Results section displays the final results of this test.
The results were exactly as expected from theory
To accomplish creating the syndrome in hardware we again use XORs, more specifically
though parity bit checkers are used. Remember that when the syndrome is zero there is an even
number of logic “1s” in the combination of the 3 data bits and the respective parity bit. Using the
odd output of the 74HC280 parity checker, if there are no errors (even number of logic “1s”)
then the odd output will be zero. This is done with a parity checker for each row of the syndrome
as shown in Fig. 3.2.11.
In order to correct the errors in hardware a 74HC138 decoder is used. This decoder has 3
control inputs that are controlled by the syndrome. With each different control input possibility,
one particular output goes to logic “0” while all other outputs go to logic “1”. For example
control input C = 1, B = 1, A = 0, makes only output Y6 go low. Using this output and the
respective data bit that corresponds to the location of the error as inputs to an XNOR will ensure
that if there is an error the bit will be flipped, and otherwise left unchanged. In the previous
example CBA=110 corresponds to the syndrome being 110. Looking at the parity check matrix
H it is observed that 110 corresponds to an error at D3, so XNORing D3 with Y6 will result in
D3bar. If the syndrome indicates no error all the data input will stay the same and Y0 will go low
indicating no error to the user. The hardware implementation of this is also shown in Fig. 3.2.11.
To test both the ability of the Hamming coding hardware to detect and correct bit errors the
following test were run. These tests also check the limitations of Hamming codes ability to
accurately correct.

Procedure for Hamming detecting and correcting test

A. Testing no error scenario


1. Directly connect the data bits and appropriate parity bits to the parity checker of
Fig. 3.2.2. Be sure that they are in the proper order and go to the appropriate
parity generator.
2. Test all 16 combinations of data bit inputs.
3. Measure C, B, and A control inputs of the decoder (syndrome) and ensure they are
zero.
4. Measure output Y0 of the decoder and ensure it remains logic “0” for each data bit
combination.

94
5. Measure all other outputs of the decoder and ensure that they all remain logic “1”
for each data bit combination.
B. Testing each 1 bit error scenario
1. Pick a test set of data for D1-D4.
2. For the test data input find the appropriate parity bits. This can be done either by
looking back at theory or using the Hamming parity generator circuit in
Fig.3.2.2.
3. Directly connect the test data bits and appropriate parity bits to the parity checkers
of Fig. 3.2.11. Be sure that they are in the proper order and go to the appropriate
parity checker.
4. Manually change data bit D1, to be the opposite of what it was in the initial test
data. Keep all other data bits and parity bits the same.
5. Measure and record C, B, and A control inputs of the decoder (syndrome).
6. Measure and record which decoder output that is logic “0”.
7. Verify that the decoder output that is logic “0” is appropriate given the control
inputs.
8. Verify that the control inputs correspond to the appropriate column of the parity
check matrix H, indicating an error in the bit that corresponds to that column.
9. Return D1 to it original value.
10. Repeat steps - with each of the remaining data bit combinations and their
respective parity bits.
11. Repeat entire procedure for at least one other set of test data.
C. Testing that single bit errors are corrected
1. Connect the appropriate outputs of the decoder to XNORs following Fig. 3.2.11.
2. Pick a test set of data for D1-D4.
3. For the test data input find the appropriate parity bits. This can be done either by
looking back at theory or using the Hamming parity generator circuit in Fig.1.
4. Directly connect the test data bits and appropriate parity bits to the parity checkers
and XNORs of Fig. 3.2.11. Be sure that they are in the proper order and go to the
appropriate parity generator/XNOR gate.
5. Manually change data bit D1, to be the opposite of what it was in the initial test
data. Keep all other data bits and parity bits the same.
6. Measure and record C, B, and A control inputs of the decoder (syndrome).
7. Verify that the decoder output that is logic “0” matches the results of step .
8. Measure, record, and verify that the outputs of the XNORs match the initial test
data.
9. Return D1 to its original value.
10. Repeat steps - with each of the remaining data bits and parity bits.
11. Repeat entire procedure for at least one other set of test data.

The result of these test are displayed in Tables 5.7.4 - 5.7.9 in the Observed and
Measured Results section. The results clearly show the Hamming codes ability to detect and
correct single bit errors.
Let us now discuss the errors that were injected during the final prototype test procedure
are presented in Section 3.3. Essentially the issue was that errors started to occur at more than
one bit location. More specifically they occurred in burst at the end of the data at parity bits two

95
and three. To fix the burst error problem CRC is definitely a valid adjustment option. Also the
parity bits could be interleaved with the rest of the data bits rather than being placed at the end of
the serial stream. However there are other options. For one, insignificant bits can be added to the
end of the transmission to pad the data, such that errors will only occur at these insignificant bits.
This still allows for Hamming code’s correction functionality.
Another option that can apply to the two sensor system is to create a hybrid error
detection scheme that not only performs Hamming error detection and correction, but also uses
repetition codes. The repetition code possibility in the two sensor system can be done without
any repeated transmissions. The data bits D1 and D2 can be simply compared with D3 and D4,
since in the two sensor system they are sent as duplicates. Further, when making this comparison
it can be noted that if there is an error, the majority of the time the error will be in D3 or D4
because they are near the end of the transmission.
Other hybrid error detection methods could be created using parity bits or even CRC;
however these methods keep adding more and more bits to the data being transmitted. The
question then becomes how much bandwidth is worth being use to insure error free transmission.
It must be remembered that the errors occurred when the clocks of the baseband transmitter and
receiver largely deviated from one another, so it may not be an issue. The only really way to
fully assess the Hamming error detection and correction uses are to receive naturally occurring
errors from noise on a wireless channel. This however was unable to be tested because of
complications in the Wireless Transceiver Subsystem.

5.7.1 Simulation Results


Before these hardware tests were complete there was also a simulation ran in MATLAB
to demonstrate the functionality of Hamming codes. In the simulation the user has the ability to
control where the bit errors occur. In the simulation n is the number of total bits, and k is the
number of data message bits. Also “recd” refers to the received data that has an error in it. Notice
that while the generator matrix and parity check matrix are not the exact same matrix described
in theory their differences are simple manipulations that are allowed in linear algebra without
affecting the value of the matrix. For example switching rows is one operation that is allowed to
manipulate matrices with out changing its value. A copy of the code used in this simulation can
be found in Appendix 2. The results of the simulation are as follows:
>> Hamming 7_4
n=

7
k=

G=

1 0 0 0 1 1 1
0 1 0 0 1 1 0
0 0 1 0 1 0 1
0 0 0 1 0 1 1
96
H=

1 1 1 0 1 0 0
1 1 0 1 0 1 0
1 0 1 1 0 0 1

msg =

1 1 1 1

code =

1 1 1 1 1 1 1

recd =

1 0 1 1 1 1 1

syndrome =

1 1 0

Position of error in codeword=2

correctedcode =

1 1 1 1 1 1 1

msg_decoded =

1 1 1 1

97
5.7.2 Observed and Measured Results
The following table are the tabulate results of the test described in Section 5.7.2. Note: In all test
results logic “1” indicates a voltage reading of approximately 5V, while logic “0” indicates a
voltage reading of approximately 0V.

Table 5.7.3: Results of Hamming parity generator hardware test.

Theoretical
D1 D2 D3 D4 P1 P2 P3
P1 P2 P3
0000 0 0 0 000
0001 1 1 1 111
0010 1 1 0 110
0011 0 0 1 001
0100 1 0 1 101
0101 0 1 0 010
0110 0 1 1 011
0111 1 0 0 100
1000 0 1 1 011
1001 1 0 0 100
1010 1 0 1 101
1011 0 1 0 010
1100 1 1 0 110
1101 0 0 1 001
1110 0 0 0 000
1111 1 1 1 111

Table 5.7.4: Error free test results.

D1 D2 D3 D4 CBA Y0 All other Y’s


0000 000 0 1
0001 000 0 1
0010 000 0 1
0011 000 0 1
0100 000 0 1
0101 000 0 1
0110 000 0 1
0111 000 0 1
1000 000 0 1
1001 000 0 1
1010 000 0 1
1011 000 0 1
1100 000 0 1
1101 000 0 1
1110 000 0 1
98
D1 D2 D3 D4 CBA Y0 All other Y’s
1111 000 0 1

Table 5.7.5: Single bit error detection results test case D1-D4 = [0000] => P1-P3 = [000].

Bit Error Location CBA Location of Y = 0


D1 011 Y3
D2 101 Y5
D3 110 Y6
D4 111 Y7
P3 100 Y4
P2 010 Y2
P3 001 Y1

Table 5.7.6: Single bit error detection results test case D1-D4 = [0101] => P1-P3 = [010].

Bit Error Location CBA Location of Y = 0


D1 011 Y3
D2 101 Y5
D3 110 Y6
D4 111 Y7
P3 100 Y4
P2 010 Y2
P3 001 Y1

Table 5.7.7: Single bit error correction results for test case D1-D4 = [0101] => P1-P3 = [010].

[DC1-DC4] [PC1-PC4] Error indicated at


Bit Error Location CBA
output from XNORs Y0?
D1 011 [0101] [010] Yes
D2 101 [0101] [010] Yes
D3 110 [0101] [010] Yes
D4 111 [0101] [010] Yes
P3 100 [0101] [010] Yes
P2 010 [0101] [010] Yes
P3 001 [0101] [010] Yes
No Error 000 [0101] [010] No

Table 5.7.8: Single bit error correction results for test case D1-D4 = [1010] => P1-P3 = [101].

[DC1-DC4] [PC1-PC4] Error indicated at


Bit Error Location CBA
output from XNORs Y0?
D1 011 [1010] [101] Yes
D2 101 [1010] [101] Yes
D3 110 [1010] [101] Yes
99
[DC1-DC4] [PC1-PC4] Error indicated at
Bit Error Location CBA
output from XNORs Y0?
D4 111 [1010] [101] Yes
P3 100 [1010] [101] Yes
P2 010 [1010] [101] Yes
P3 001 [1010] [101] Yes
No Error 000 [1010] [101] No

Table 5.7.9: Single bit error correction results for test case D1-D4 = [1111] => P1-P3 = [111].

[DC1-DC4] [PC1-PC4] Error indicated at


Bit Error Location CBA
output from XNORs Y0?
D1 011 [1111] [111] Yes
D2 101 [1111] [111] Yes
D3 110 [1111] [111] Yes
D4 111 [1111] [111] Yes
P3 100 [1111] [111] Yes
P2 010 [1111] [111] Yes
P3 001 [1111] [111] Yes
No Error 000 [1111] [111] No

5.1 Wireless Transceiver Subsystem


Team members who designed this subsystem: Ryan Ginter and Matt Elder
Team members who wrote this subsection: Ryan Ginter and Matt Elder

The Wireless Transceiver Subsystem consists of two 433 MHz OOK wireless
transceivers from Linx Technologies. For a two-way car alarm responder system the wireless
aspect of the system is an imperative trait. Given limited options for prototyping on a
breadboard, the project’s wireless unit options were fairly limited to OOK transmission.
FSK units available through various electronic component retailers were contained in
surface-mount packages with tiny pins, a tangible issue when breadboard prototyping a
communications system. Wireless BPSK at 433 MHz was considered as well, but lack of
availability of UHF band transmitters to provide stable carrier signals halted application to
the design project. In the end, Linx Technologies TRM-433-LT units were used to establish
an OOK RF link for signal transmission separate from the final design prototype.

100
5.8.1 Theoretical Considerations
The theory involved with wireless communications systems is fairly complex. In a design
project of this scale, using IC transmission units is the most economical option. There are many
options when it comes to modulation scheme and power considerations with readily available
transmission units. A theoretical comparison of modulation schemes is important when deciding
on the appropriate transmission scheme. Three popular digital modulation types that are outlined
below are Frequency Shift Keying (FSK), Phase Shift Keying (PSK), and On-Off Keying
(OOK). The different modulation schemes are compared in areas of theoretical bit error rate
(BER), which should decide which scheme is best for the application.
In all digital modulation schemes, digital data is transported via a carrier signal that meets
Nyquist criterion frequency of at least twice the data frequency or bit-rate. This criterion is used
to prevent aliasing and loss of data during the modulation and demodulation process. In FSK,
the data is modulated so that the frequency of the carrier wave used varies via a voltage
controlled oscillator. In PSK, the phase of the carrier wave is varied to convey data. In OOK the
envelope around the carrier waveform denotes the data sent. Each modulation type is quite
different, down to a signal constellation level. Signal constellations determine the theoretical
rate at which noise can interfere and corrupt the intended data enough to result in incorrect data
at the recovery phase (demodulation). In binary applications, such as this project, the signal
constellation is shown to have a minimum BER for each modulation type.
The following figures show the binary signal constellation of each modulation scheme. In
Fig. 5.8.1, binary FSK signal constellation is presented. BPSK and BOOK are presented in Figs.
5.8.2 and 5.8.3. In terms of transmission power E, BPSK exhibits a 2√E signal separation
between logic high and logic low bit values. BFSK exhibits √(2E) and ASK/OOK exhibits
merely √E constellation separation. In general, the larger the separation between bit values in a
signal constellation of a modulation scheme, the larger immunity to noise the modulation
provides. Given this data, the best option for optimum performance is to use a BPSK modulation
when traversing a wireless channel. Despite these results, the finished units were OOK
modulated. Due to the application and given sufficient transmission power, most of the data
corruption will be secure via error correction and PN sequence spread spectrum subsystems.
Fig. 5.8.1: BFSK signal constellation for a transmitted power E.

Fig. 5.8.2: BPSK signal constellation for a transmitted power E.

101
Fig. 5.8.3: BOOK signal constellation for a transmitted power E.

5.8.2 Design Procedure


While initially it was desired to use FSK or BPSK as the wireless transmission method,
because of hardware limitations in size and availability OOK was used instead. To create this
OOK wireless link the LINX Technologies TRM-433-LT transceiver was used. This part was
chosen because of its simplistic controls and availability. There is one pin that when high makes
the transceiver act in transmit mode, and when low makes the transceiver act in receive mode.
Other than this control pin and power the only other input of concern is the serial data
input/output pin. Some other features of interest of this transceiver are its operating frequency of
433 MHz and transferability of data at rates up to 10 kbps over distances of 3000 feet.

The transmit mode and receive mode input was the reason why the baseband signals ENP
and RLD were tapped of from the Baseband Transmit and Receive Data Subsystems
respectively. ENP is high when transmitting and low when not transmitting. RLD is the opposite,
making the two signals ideal for controlling the transceiver because when the input at pin 6 is
low the transceiver is in receive mode and when high it is in transmit mode.

To acquire this part, previous systems that made use of it were modified to isolate the
transceiver from the rest of the prior system. Once acquired the first test was to make sure that
the data was able to be modulated using OOK. To do this the following test procedure was
performed:

Procedure for OOK transceiver transmit mode test

1. Using an ohmmeter make sure the modified system still has connections from
pins 2 and 10 to ground, pin 1 to the antenna, pins 5, 9, 11, and 12 to power.
2. Use no more than 3 V for powering the transceiver.
3. Connect pin 8 to power to put the transceiver in transmit mode.
4. Connect a 1.3 kHz square wave signal, with amplitude = 3 V and offset = 1.5 V,
to the data input at pin 7 of the transceiver.
5. Power everything on and observe the output of the antenna at pin 1 of the
transceiver on the oscilloscope.

102
This test was successful in producing an OOK modulate signal at 433 MHz. In the Observed
and Measured Results section the OOK output signal can be viewed in Fig. 5.8.8. In this figure
the 1.3 kHz data frequency is also highlighted. In Fig. 5.8.9 a close up is taken of to show the
carrier operating at a frequency of 433 MHz. This test was also performed with a 10 kHz data
input to test the transceiver limit of 10 kbps. The results are shown in Fig. 5.8.10 of the Observed
and Measured Results section. Note that this has a lot more noise affecting the signal. Following
the transmit test the following procedure was performed to made sure a transceiver could receive
the signal that was sent from the transceiver that was transmitting data.

Procedure for OOK transceiver receive mode test


1. Using an ohmmeter make sure the modified system still has connections from
pins 2 and 10 to ground, pin 1 to the antenna, pins 5, 9, 11, and 12 to power.
2. Use no more than 3 V for powering the transceiver.
3. Connect pin 8 to ground to put the transceiver in receive mode.
4. Connect a 10 kHz square wave signal, with amplitude = 3 V and offset = 1.5 V, to
the data input at pin 7 of the transceiver that was previously set up as the
transceiver.
5. Power everything on and observe the output at pin 7 of the transceiver, in receive
mode, on the oscilloscope.
This test was again successful in demonstrating that the modified transceivers could be used
to establish a wireless link. The received data signal can be observed in Fig. 5.8.11 of the
Observed and Measured Results section. Note one issue, while the signal received is indeed a
square wave with a frequency of 10 kHz, the time for which highs and lows are held is
unsymmetrical. More specifically when a one is sent the pulse is much smaller relative to the
pulse that represents a zero being sent. This was realized as a possibly becoming an issue when
trying to use the Baseband Receive Data Subsystem to sample the data. This issue will be
discussed later.
With a wireless link now established integration was attempted between the Baseband
Transmit and Receive Data Subsystems. After several test the integration was concluded to be
implausible with the current baseband systems. The tests that led to this conclusion along with
possible solutions will now be discussed.
At first the transmission output of the Baseband Transmit Data Subsystem was simply input
to pin 7 of the transceiver designated to act as the wireless transmitter. Then the data output from
pin 7 of the transceiver designated to act as the wireless receiver was connected to the received
data input of the Baseband Received Data Subsystem. After everything was powered on, data
was attempted to be sent and received by toggling the switches that were simulating the car
sensors. Instantly problems were evident. At all times the LED indication from the Hamming
Error Detection and Correction subsystem was lit, indicating errors. Not only were errors
indicated, but the data was not able to be corrected either, meaning that there were multiple
errors. After analyzing what the baseband receiver was getting as an input, it was discovered that
when nothing was being sent the baseband receiver input was always low instead of always high.
In an attempt to fix this an inverter was placed between the receive mode transceivers output and
the baseband receivers input. While this did help in making the baseband receiver see stop bits
when noting was sent it did not completely solve the problem.
In order to further analyze what was causing the errors each possible set of data was sent
with the two sensors (00, 01, 10, and 11). Then, using the oscilloscope, what was output by the

103
receive mode transceiver to the inverter was compared with what the baseband receiver saw as
an input from the output of the inverter. It was also recorded what the baseband receiver’s LEDs
indicated that it had received. The results from this test are shown in Figs. 5.8.12 – 5.8.19 of the
Observed and Measured Results section. Note that because of the inverter, the data received and
indicated by the LEDs should be the exact opposite of what was sent.
After analyzing the result it is noted that the main issue is that when the transceiver receives
a consistent logic high it only outputs the high for no more than two periods. The issue of
symmetry mentioned early was not an issue in this test as the data rate was 100 bps and the data
appeared symmetric. This is most clearly seen in Fig. 5.8.14. The main issue instead was that
after holding the output high for two periods it starts to output a low even if a one is still being
consistently sent. While this flaw can be noticed in all the figures because of the stop bit not
being held high consistently, it is most easily demonstrated in Fig. 5.8.18. This figure shows
what the transceiver’s output is when the sensors were set to 11, meaning the overall data sent
would be [ 0 1 1 1 1 1 1 1 1 ] including the start, stop, and parity bits. Note the start bit is a low
then for two periods the data is held high, but does not remain high, so bits D3, D4 and P1-P3 are
all lost along with the stop bit.
The inverter helps in making sure the stop bit will always be on when no data is being sent.
However when data is sent the start bit will not be detected at the correct point. The only
conceivable solution to this problem is to rework the way the bits are framed and how the start
bit detector works. The simplest solution would be to make the start bit a one and the stop bit a
zero. This would also eliminate the need for the inverter. Other than this solution different
transceiver could be researched to try and find an alternative that will integrate with the system
better.

104
5.8.3 Simulation Results
Several MATLAB simulation references were used early on to provide an idea of theoretical
BER calculations. The program found most useful dealt with the comparison of BPSK and ASK
modulation and travel in the presence of a pseudo-random noise interference. The program
outputs a theoretical plot for ASK and BPSK modulated data signals, and shows an asterisk
where the current simulation results are located in proximity. The original code, written by
author J C last updated April 18, 2005, is available for download on the MATLAB File
Exchange website [16]. The code presented here is a slight modification of the original code,
mainly for printing better plots of the data. Below find several distinguishable plots from the
code, which is presented in Appendix 2 as BPSK_ASKsims_elds.m. Figs. 5.8.4 through 5.8.6
show BPSK signal creation from baseband square wave data, the presence of noise that is used to
simulate corruption of a realistic wireless channel, and the power spectral density of the BPSK
modulated signal. Fig. 5.8.7 shows a plot of theoretical estimations of BER between BASK and
BPSK, and where the simulation calculation for BER lands within the range for the simulated
BPSK signal.

105
Fig. 5.8.4: BPSK modulated signal with carrier frequency 200 kHz and data square wave
frequency 20 kHz.

Fig. 5.8.5: BPSK Signal before and after Noise is introduced.

106
Fig. 5.8.6: BPSK Signal -- Power Spectral Density.

Fig. 5.8.7: BER calculations plot.

107
5.8.4 Observed and Measured Results
The follow pages display the observed oscilloscope measurements that were taken to test and
characterize the Wireless Transceivers Subsystem. Figs. 5.8.8-5.8.11 are evidence of the wireless
link between the two transceivers. Figs. 5.8.12-5.8.19 highlight the issues that occurred when
attempting to integrate with the baseband subsystems.

Observed Results Figures:


Fig. 5.8.8: OOK Transceiver Transmit Test with 1.3 kHz data signal and 433 MHz carrier.
Fig. 5.8.9: Close up highlighting the 433 MHz carrier of the transceiver.
Fig. 5.8.10: OOK limitation test with 10 kHz data signal.
Fig. 5.8.11: Data received from Wireless OOK transmission of data at a frequency of 10 kHz.
Fig. 5.8.12: Data output from transceiver in receive mode after 00 sent.
Fig. 5.8.13: Data received at input of baseband receiver after 00 sent. Note LED outputs indicate
11 interpreted.
Fig. 5.8.14: Data output from transceiver in receive mode after 01 sent.
Fig. 5.8.15:Data received at input of baseband receiver after 01 sent. Note LED outputs indicate
10 having been sent.
Fig. 5.8.16: Data output from transceiver in receive mode after 10 sent.
Fig. 5.8.17: Data received at input of baseband receiver after 10 sent. Note LED outputs indicate
that 10 was interpreted.
Fig. 5.8.18: Data output from transceiver in receive mode after 11 sent.
Fig. 5.8.19: Data received at input of baseband receiver after 11 sent. Note that LED outputs
indicate 11 was sent.

108
Fig. 5.8.8: OOK Transceiver Transmit Test with 1.3 kHz data signal and 433 MHz carrier.

109
Fig. 5.8.9: Close up highlighting the 433 MHz carrier of the transceiver.

110
Fig. 5.8.10: OOK limitation test with 10 kHz data signal.

111
Fig. 5.8.11: Data received from Wireless OOK transmission of data at a frequency of 10 kHz.

112
Fig. 5.8.12: Data output from transceiver in receive mode after 00 sent.

113
Fig. 5.8.13: Data received at input of baseband receiver after 00 sent. Note LED outputs indicate
11 interpreted.

114
115

You might also like