The signal has been simplified for now, until I know what is going on. There will be two LEDs for now. These will be turned on and off using OOK modulation. There will be three parts to the signal. The demodulator will use the following sequence;
The starter bits are 1 1 0
A bit of 1 or 0 to select LED 1 or LED 2 respectively
A bit of 1 or 0 to turn the LED on or off respectively
The 'starter bits' are longer than any passable following sequence to help prevent errors.
Here is an example of two cases blue LED 1, on and red LED 2 on.
I haven't applied the leds yet it's just an idea. I first need to demodulate the signal and remove the nose.
To remove the nose I plan on using a exponential smoothing filter, this is by a recommendation of some stranger I ment at swing dancing.
Currently I'm brainstorming methods of initiating the communication. The most likely method I will use is a long pulse followed by a shorter time were nothing will be transmitted. Where the summed time of both the pulse and the blank space will be longer and different than any possible next communication.
This idea will be developed further in the next posts. The following figure came from the previous mentioned idea. A pulse of 1000 milliseconds and a break of 500 milliseconds, this is followed by periodic ones and zeros.
My idea is the pulse and blank then triggers the data sequence of the periodic ones and zeros in this case.
The cheap microphone/demodulator I'm using was purchased from China for next to nothing and I got what I paid for. I can barely tell the difference between the signal in the background noise. You will see in the figures my signal-to-noise ratio is somewhere between three and four. This is with the low powered buzzer just inches from the microphone.
The cheap microphone will work for now, I bypassed the digital output from a comparator. Instead I am using the analog signal. yesterday's post was while I was still attempting to use the digital output.
Here are a couple references with the analog output from the microphone, in figure 1 I clapped three times, figure 2 there are several short pulses from a buzzer followed by a break ending with a long buzz, figure 3 I messed with the wiring a little bit and I think there may have been some improvement using the same procedure used in figure 2, however it may just be less noisy.
figure 1: clapping
figure 2: buzzer from 2 inches away
figure 3, rewired.
Before purchasing some transducers I want to get an idea of the noise environment I will be testing the system in. For now I will work with these cheap Chinese sensors to develop the software while I consider a more permanent transducer.
Today was one of those days that everything goes wrong and everything breaks... including my car.... There was some small progress with the ROV.
The wireless communication is started. I am stepping away from the 8-PSK for a small time and using a for of ASK that is OOK modulation. It looks like a good start.
on the left is my rudimentary modulator and on the right is also a rudimentary demodulator. It almost didn't work and has a LOT of work to be done.
Sofar the demodulator lights up an LED when it hears a tone, it will be some time before it can send and receive live video.
There is a quick update to keep myself honest to my goals for winter break. Here is part of the first step, LT spice for the ROV. The UDOO development board in LTspice.
I've been M.O.A. this last semester I have been working on my senior design project with FSAE - formula society of automotive engineering designing a race car. This has taken up time I would have otherwise spent on the ROV.
I have gained some experience with FSAE that I am going to apply to the submarine. Most notable, logging information better.
For winter break there are three primary goals:
Map the wiring for the UDOO development board on LTspice.
Re-add the ability to do send and test for the vertical access (be able to go up and down)
wirelessly communicate to the ROP using PAM holds amplitude modulation.
There are various complexities for optical encoders,
I will be focusing on the more basic types.
For those of you who like a video see Video 1, this video covers some of the theory behind how an optical encoder works.However it does not cover of the application to the ROV project.
Video 1: Basics and how it works.
Here is a DC motor connected to an optical encoder. A DC motor isn't very accurate however it has the support and is inexpensive.
An optical encoder improvises for the lack of accuracy. There are three basic parts to an optical encoder see figure 1.
In the black rectangle on the left there is a laser or an LED to shine a beam of light.
Also in the black box there is a gap under the LED or laser, and across that gap there is a photo resistor (light receiver).
There is a rotary disk which fits in the gap between the laser or LED and photo resistor. The disc is transparent, there are hundreds or thousands of black lines to interrupt the light beam which is printed on this disc. I used a marker to enlarge these interrupt lines for visual effects see figure 2.
Figure 1: Optical encoder on DC motor
Figure 2: Optical encoder with enlarged interrupts
Not all optical encoders are the same see Figure 3. This is the optical encoder from my ROV. There are 50 black lines on this rotary encoder. since the encoder has low resolution you can see the lines in this figure. the light emitter and receiver's on the left.
Figure 3: Optical encoder from ROP project
In the optics the photo resistor can only see it's on and off state or and logic design a 1 or a 0.
If we wanted our motor to do a full rotation and there are 50 black lines, then we can rotate our motor until the logic of the photoresistor has seen a 1 50 separate times.
For those of you who are observant will notice that this is not the standard DC motor it is a servo, I unfortunately bought a cheap servo without an accurate built-in encoder.
But wait there are more little tricks to encoders, there is a way to get twice the resolution. Yes, that means 100 steps from 50 black lines. we have been saying that that light received is a 1 and that light interrupted is a 0 see Table 1.
To double our resolution we used the rising and falling edge of each black line. One example, the transition from not receiving light to receiving light has a value of one, however both light received an light interrupted as a value of zero see Table 2.
State of Florida resistor
Light receives
Light interrupted
Logic value
1
0
Table 1: logic values first case
If you find the case in Table 2 difficult to understand consider watching Video 1 at time 2:20 (Here).
The attach interrupt has works different on different arduinos. You can fine fore detail on arduino's site (here).
Attach interrupt allows the program to monitor a pin while doing other tasks. The controller could spend all of its time monitoring one pin awaiting a signal that will be so fast that just about any other way the signal would be missed. But there is one other thing we can do, that is an attachInterrupt.
When an event happens while running a different part of the program, this interrupt will make a note of the missed event to run a designated function when it can make time.
this says when there is a "CHANGE" to "digitalPinToInterrupt(servoEncoder)" pin nomater where the program is running go to "AirServoEncoder" program.
The referenced program has to be as simple as possible without any delays or any thing that can act like one. My referenced program is "AirServoEncoder" and the only line of code in it is on line ~52 "encoderCount++;" then my loop will reference the int encoderCount for posichaning. The int encoderCount is a count of how many stamps have been seen.
Here is a side view of the servo, encoder, adapter, and air regulator for my remote-controlled submarine's air system see Figure 4. The cylinder on the top of the picture is the bottom of my air regulator, right under that is my 3-D printed (soon to be cast aluminum) adapter to fit to the top of the servo. It's difficult to see in this picture of the encoder is placed between the servo and of the adapter.
