I will have to take a look at it. I appreciate you bringing this method up. I wonder what the computational expense is compared to a typical FFT. I may have also found another solution, but I need to check into it more.
I hope you don't honestly intend to operate on 75 MHz exactly. That's the same frequency the air transport industry uses for marker beacons, and having both the FAA and FCC to answer to doesn't seem like a very good idea.
Are you perhaps proposing to operate in the 72 MHz R/C band?
There is a 75MHz band that the FCC has designated for RC surface use. 72MHz is designated for air use. In that 75MHz band, they have also authorized other communication items (I think that it is pagers if I remember correctly).
I checked 47 CFR 2.106 (the FCC Table of Allocations), and found the following note:
NG56 In the bands 72–73 and 75.4–76 MHz, the use of mobile radio remote control of models is on a secondary basis to all other fixed and mobile operations. Such operations are subject to the condition that interference will not be caused to common carrier domestic public stations, to remote control of industrial equipment operating in the band 72–76 MHz, or to the reception of television signals on channels 4 (66–72 MHz) or 5 (76–82 MHz). Television interference shall be considered to occur whenever reception of regularly used television signals is impaired or destroyed, regardless of the strength of the television signal or the distance to the television station.
Sooo...you can certainly operate an R/C transmitter in 75.4-76.0 MHz. Not sure about type approval or any of the other legal angles associated with rolling your own, though.
Yeah. As to rolling your own, there is no issue, it is not an intentional transmitter. I already consulted with the FCC on this. Even for transmitters, as I understand the rules, I can build up to 5 of a design for personal use as long as the follow good engineering practice.
In practical terms for transmitters, this means that as long as I do a good job, and I do not cause complaints because I have a lot of spurrious signals interfering with other licensed band users, I am most likely ok. This by far is not to be considered an official legal interpretations of that for transmitters, though.
When I played around with Görtzel vs Fourier on an stm32f4 for vowel detection it was about four times faster than a classic FFT. Also, the code was less complex. Again, it all depends on the application but it seems to me you could benefit from it.
What's the attenuation of the 75MHz signal in water? I would think the signal would fall off really quickly, even for such a relatively low frequency. Is there a long antenna that stays near the surface? I guess an easy experiment would be to put an FM radio in a ziploc bag and dive to the bottom of a pool and see if you can still hear the radio station.
75MHz actually does pretty well as long as it is not in brackish water. This project is not so much to do something completely new, just to provide a new supply of 75MHz receivers because the current supply is dwindling. I have a paper that I am trying to find for another individual. Once I find it, I will see if I can post a link to it. It gives the attenuation factors over a range of frequencies.
At least as far as losing the boat to depth is concerned, I would think that one could employ a pressure sensor of some sort, for depth detection, that would initiate a local override command to automatically actuate an ascent. That would be a snap for a Senior Mechanical Engineer, no?
Now, as for losing the boat to distance that get's bit trickier. Perhaps if it doesn't receive a viable command after x seconds/minutes a more sophisticated local overide command goes into effect: ascend and circle.
Then after you've nailed down das but's mechanical behavior, you can start working on how that nifty littel radio chip could transmit real-time video from the little camera you'll be mounting to the bow. Much fun will be had by all.
Yeah, those are some good ideas, but it does get a bit easier than that. You can actually set ut up so that the receiver looks at each frame of data and determins if it is good or not. If you have a certain period of time where you do not get good data, you have an automatice action programmed into the receiver that commands the boat to the surface. This is what you are getting at with your second idea. I do like though, the concept of initiating not only a surfacing command, but also to circle. That is an interesting idea. I will have to think about that one.
The only problem with the video is that it requires a lot of bandwidth and the frequencies that might be used (900MHz or 2.4GHz) all attenuate too significantly to use. The only other option might to be see if I can transmit in an amature frequency band in the 50MHz region (I forget exactly what the band limits are), but I am not sure how much bandwidth would be needed for an ok sized picture.
I'm glad I could contribute. As for the video idea, I am aware of the BW limitations. I was just kidding around. That's why I quipped about fun being had by all, because it wouldn't be had by you as you were trying to clime that little Mt. Everest of a problem.
I don't think you need to do an FFT. There are a couple of much simpler ways to do things. You can do an arctan (or approximation) of the IF or baseband to find phase and then take the derivative of that (i.e., the difference between the last two samples) to get the frequency. Another, possibly easier, method is to center two bandpass (or a highpass/lowpass) FIRs around the two FSK frequencies and then measure the ratio of the average power output of each (finding the power would require a squarer or square approximation and another lowpass to average).
There are a lot of other problems to deal with, though, if you need to do an AGC loop, carrier recovery, etc. I'm not sure how much your chip is already doing for you. This might be a huge task.
Edit: I just looked up the datasheet of that part. It's pretty nice, and no, it looks like you don't have to worry about AGC or carrier recovery. The output is not quadrature, so forget what I said about finding the arctan (which only works for complex signals). You'll just have two audio tones to discriminate, so I'd just use the two FIR filters. It's audio so the processing requirements are really low. I see now you already suggested the FIR filters (actually, for audio, IIR would be fine) but worried about the latency. I don't think you need to worry about that. We are talking about steering a boat, where 100ms of latency is probably nothing, and the IIR latency would be more like a couple of ms at the most.
Kevin, I appreciate your thoughts. Even your initial ideas are valuable as it helps me understand more about some ideas when dealing with a signal in which you have both the I and Q. This is an area that I am really trying to dig into and learn more. It takes a bit longer when you do not have a local expert to help, but little by little I am coming to a better understanding of RF and DSP concepts.
One of the next projects that I would like to do is to create a full receiver. Front end and all. Potentially use it as a learning project for FPGA's. I would do it as a directo conversion receiver with a delta sigma converter, and target a frequency range in the 100-200kHz range. It is just a concept right now.
For your digital receiver (which is too much for your application) the only issue is that the standard frequency deviation for an FM receiver is 50khz (old school). 5khz could be too small. (The bigger the frequency deviation the better coverage). Otherwise, you should get the data that you need.
The below data refers to an analog FM receiver.
In some conditions a simple comparator at the frequency detector output could be enough.
But if your transmitter should transmitt long zeros, and long 1s, than the receiver should be able to output them. This means that the receiver should be able to output DC. Otherwise, before generating the FSK, you have to process your digital signal, to be able to transmit only zero's or only 1's. For example, a Manchester coder/decoder should be used.
or, the 3rd sollution is to use an analogue IC FSK receiver (Motorola), or just to buy a FSK receiver module for 75Mhz band.
I do not know anything about 75Mhz propagation under the water. Is it possible?
Thanks for your thoughts. First, 75MHz does propagate well under water. Though, it has to be fresh water and not salt water.
As to the method of post processing the data, it is looking like a comparator may be the way to go. I have found some more information lately that seems to show that this may work. I have a post that should go live here in a day or so on this.
When I saw hat you were going to use 5kHz frequency shift, I was immediately concerned, since the broadcast FM deviation is 75kHz, so you will get a very small output signal. Also, it sounded like you plan to transmit a 10 or 15kHz tone frequency-modulated on a 75MHz carrier. This will not give you signals at 75.010 and 75.015 (FSK), except at very particular Modulation Indexes. Single- or double-sideband suppressed-carrier modulation will do that, but is more complex. If you are just detecting the received 10 and 15kHz tones, however, you should FM modulate them at a 50 to 75kHz deviation, for best received signal level.
As for antenna matching: while I am not volunteering to donate the necessary equipment for that, antenna analyzers are available for the Ham Radio market, from MFJ and others. Prices are in the $280 range.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.