We need to integrate a microphone into the RC, but I have no idea how or what I should use. We really don’t need to hear clearly all we need to hear is morse code. Does anyone have any Idea how?
I was hoping to use the IFI dashboard.
John,
What you might want is a mic preamp. It is fairly easy to build one with parts from Radio Shack. An LM324 is a quad opamp optimized for a single ended power supply. What you might want to add to this arrangment is a DTMF emitter with a DTMF decoder following the preamp. This will give you a digital type output where you can use one of 10 switch closures. Morse code is OK but it is difficult to decode unless the code is generated through an electronic device that has controlled timing. Morse readers are available but are fairly complex devices as you problably know. DTMF decoders have built in filtering that will help in noisey environments. Several vendors sell kits for this. Ramsey I think has a few different kits. They are the ones that make some nice little devices for hams and they have an internet site. You also might want to check out MCM.
Au contraire! If you have a clean signal with no significant “bounce” on the leading or trailing edge of the dits and dahs, reading hand-generated Morse code is remarkably simple.
One of my first programming projects as a youngster was a speed-adaptive Morse decoder. It usually took about three characters to figure out the difference between e.g. C and TETE, and then kept perfect sync through up to a 2:1 speed change between characters. PM me for the algorithm if you’re interested, and I’ll try to remember it well enough to explain it.
My point exactly. Noisey accoustic environment, excited Morse sender, and non standard and non repeatable timing all add up to unreliable Morse decoding. To send three characters to get the decoder to track and then recognize what is sent would take most or all of the auto period at the send rate of an inexperienced operator.
There is some pretty good free CW decoder software out there on the Internet. One that I’ve used is CWGet. Look in some old issues of QST (If you know of a ham radio operator that is a member of ARRL) as I seem to remember a article comparing several programs about two years ago.
I think the source for the Morse code request is from FIRST students who will be entering the underwater robot contest, NURC, in June. One of the tasks is to decode a repeating 5 words per minute, 3 letter airport code (eg PHX PHX PHX…). The speaker is approximately 12 feet underwater, at night, and is one of many taks that the teams can earn points.
- You must activate the origin beacon button which will be lighted due to the system being armed and waterproof. The button will also be labeled to aid in finding it. Once the button is pressed, a Morse code tone will begin repeating a three letter airport set of initials to indicate the airport of origin. An underwater speaker will be located on the dashboard of the cockpit near the activation button of the origin beacon.
There are many strategies to “hear” and decode 5 wpm Morse underwater. It will be interesting.
John and Allan,
This will bring into play a new set of problems. There are a variety of waterproof and water resistant mics available. You are going to have to search. The military has been using mics that can be used in all kinds of harsh environments. Mil surplus dealers may have some in stock that you can pick up cheap. The kind of code that you describe (three letter groups at five words per minute, machine generated) will lend itself fairly well to the techniques that Alan described above with a caveat. The pool environment will likely give some fairly strong reflections of the original signal and a variety of other sounds as well. This will require some filtering so that the morse decoder will not be fooled. Since it is a repeating code, it shouldn’t be too difficult. Good luck.
We’re planning on entering this competition again, and probably would just have the robot operator listening to the signal and trying to decode it. This would just have a mic and amp in the robot, and send the audio signal to the surface over a twisted pair or coax cable in the tether, and the driver would listen to the sound using the speaker built into the TV being used to watch the video signal from the robot.
I think the original poster is mainly trying to figure out how to send an audio signal from an analog input on the IFI RC back to the IFI OI, then use the Dashboard to hear it. I know nothing about the Dashboard…so I can’t help…but maybe this will clarify the problem better for those trying to help?
I’m assuming the OP is planning on tethering the IFI OI and RC.
Jim,
With a little thinnking that might be possible. The dashboard as I understand it just ports all the data that is streaming between the RC and OI out the dashboard port. Dave Flowerday might be able to lend a hand there. If you use the microphone to pick up audio that is filtered and then rectified you could use it to set a bit in OI stream. At the OI you could then use the bit to set an LED output that could fire an audio oscillator that would be a representation of the original audio and the code spacing. You wouldn’t need the dashboard for that.
I don’t believe the dashboard data would be fast enough to give you a digitized audio signal. Most code is between 500 and 1000 HZ with most operators comfortable at 700Hz. To be able to digitize in a simple fashion, you would want to be able to have data at about twice that rate to allow simple recovery (D to A) at the OI.
The IFI RC’s A/Ds have a 10 bit resolution. That should be plenty for the quality of audio you are looking to use. After the RC has values from the A/D, it could conceivably transmit them as a byte and a couple bits on another byte, which you could write a LabView app to decode back into audio. I once wrote a fairly simple assembly program for a pair of 68HC11’s to do exactly this. One chip used an A/D to get input from a mic, stored it to a memory system that I designed, and then transmitted it to the other processor, which used an R-2R ladder that I built to output out to a speaker. The amount of data required is very minimal, and I think that the system would be able to keep up, seeing as a good part of a kilobyte is sent per packet. Theres plenty of room to snag 10 bits. (as many as you want, really.)
Again, the question would be speed. If it’s too slow, then you could have the RC keep track of two generations of data, and send them both at once (again, using twice as much bandwidth per cycle, but who cares? Theres plenty of room.)
You could even do that more than twice if the resolution isn’t high enough. Play around with it.
Jacob
There’s nowhere near enough bandwidth in the RC-OI data stream to pass general audio through the IFI radio modem. You could perhaps get sufficient processing power to do a chunky spectrum analysis and send a dozen or so samples per second, enough to make it possible to recognize a Morse code signal at the other end.
If the frequency of the signal is known in advance, I’d suggest detecting it in hardware and just relaying the output of the detector to the operator.
Jacob and Alan,
What is the sample time of an analog input on the RC? If it is faster than 2kHz it might be doable. Might require some filters but it is only a tone, not full audio.
The data rate is barely a kilobyte per second.
Each complete set of data from the RC requires three packets. That’s where my “a dozen or so samples per second” comment comes from.
It’s not unreasonable to take 6400 analog measurements per second, though at that rate you might need to worry about how many CPU cycles the rest of the code needs in order to function.
Well Jim, it would seem that some experimenting might be in order but it appears that it might just work. I leave the digital part up to the software guys and Alan is one of the best or one or more of our software guys might help also. It might require some manipulating at the OI end to get enough data to make audio but the bandwidth is so limited you might just be able to do it. If you are going to Atlanta, you might want to set up a time where you can brainstorm with these guys.
As to the RC end, a mic preamp with some filtering should be easy to come up with using the LM324 quad opamp I mentioned earlier. You will need at least 50-60 dB of preamp gain since you are trying to get the audio up to at least 4 volts p-p. The 324 should be able to easily give that swing on 12 volts of power supply. Of course with the input signal being just one frequency, you might even consider using even higher gain, then limit the peaks and send it to a zero cross detector and feed that to a digital input. You could then port that to the OI and feed it to a low pass filter (2kHz) and speaker amp and still be able to decode the morse.