Then why would you want to generate harmonics and then attempt to filter them out??? But then I suppose you still have the filter problem with a mixer.
Ok, sending data over networks messes with timing. That's why my product interleaves an IRIG-B signal with a digital stream when transported across an IP network. At the other end the two signals are then separated and presented time aligned.
My point was that the two methods have similar complexities and issues to be dealt with.
Indeed. Harmonics are easier to filter because they are further away from the carrier.
I guess that is another way to do the same thing. Putting time information in the header can be called interleaving as well. I don't use complicated formats, just a 64-bit offset from a fixed epoch expressed in nanoseconds. This can be easily retrieved in a Linux system.
Maybe I can use an existing module like an Arduino as a building block to do the control and interfacing. My time adjustment code is in C and uses a resampling library, I don't know yet how to port it to a raw FPGA as opposed to a general-purpose processor.
FM by DSP can be tricky. I think the trick has to do with the fact that the sampling rate needs to be sufficiently high that Nyquist is met, not just for the audio BW, but for the Bessel sideband BW as well.
Distance is not the only criteria. The harmonics are typically lower in amplitude at higher frequencies. If you are using say the third harmonic, you have to filter the fundamental which might be 3 times or more higher in amplitude.
How exactly would you generate the harmonics?
I didn't get to choose this aspect of the design. Range Commanders Council did. I just had to design the details and make it work. There are always many ways to skin a cat.
If you can make it work on an MCU, that is not a bad way to go. Working in FPGAs removes many complications that come from sharing a single CPU between multiple processes. If the CPU can be dedicated then no worries, but few are the systems that don't use interrupts, etc.
Someone already wrote that it is better to upsample the audio to the frequency of the NCO. Of course this is true as it removes components that are based on the audio sampling frequency (12 kHz in my system) that would be impossible to filter after modulation.
So I need to find out how I can upsample a signal in an FPGA. Once it is upsampled, it is also a lot easier to lock it to the timing input with sufficient accuracy.
This is all standard RF circuit design. No need to discuss it in this context. What matters is that it is easier to triple a 143 MHz signal to 430 MHz and then get rid of the 143, 286 and 573 MHz components than it is to generate the 430 by mixing a 10.7 MHz modulated carrier with a 419.3 MHz fixed carrer and then get rid of the 419.3 and 408.6 MHz components. Because they are closer to the wanted frequency.
My current design runs on a PC (typically a 4-core Intel processor) and uses the sample clock of a soundcard as its fixed timebase. Audio samples are queued for output on the soundcard (taken up by DMA as usual) and the timing is derived from the interrupts the soundcard sends to the processor when it is ready for a new chunk of samples. This way the timing of the main program CPU instructions does not really matter, the only thing that matters is the response time to the interrupt, whose first task is to read the current time. Once that is done, all other handling can be done at leisure.
Same thing for the PPS input: the state change of the PPS triggers an interrupt, it reads the current time, and stores that for later processing.
It would be great when the entire audio processing (upsampling from
12 kHz to the rate at which the NCO is fed and aligning the result to the PPS pulses) could be done in a hardwired FPGA statemachine, but I am not experienced in that and I am a bit sceptical about the feasibility of that. Of course I can just put an ARM core in the FPGA and run the existing software on that.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.