Generating Simultaneous Tones

[gnuarm]

So can you tell us what you decided to implement other than just saying "KISS" and "Arduino"?  What means of generating the tones, what frequencies, what means of detecting the tones? 

You never even told us what bit rate or symbol rate you are looking for?  Are the 16 channels all just continuous tones with async data on each one, rather like 16 separate Morse code keyers?  Is there some minimum response time to a change in the source of the data? 

I worked at a company once that designed push to talk military radios (never call them walkie talkies).  The old timers had very little sophistication and any time they wanted to say MCU they just said PIC.  I kept thinking they had a serious hard-on for Microchip for some reason.

[ogden]

I found a time slot to refine my simulation. Octave script is attached.

Could you show some more info about your solution for those who don't have Octave installed (yet)? I wonder you still use initial upconverter with FFT16 instead of let's say 16 (middle'ish) bins of FFT64 or even FFT32 w/o upconverter?

So can you tell us what you decided to implement other than just saying "KISS" and "Arduino"?

Right. BTW he said "LPF" and "CMOS" as well

[rfclown]

... I worked at a company once that designed push to talk military radios (never call them walkie talkies).  The old timers had very little sophistication and any time they wanted to say MCU they just said PIC.  I kept thinking they had a serious hard-on for Microchip for some reason.

walkie talkies were push to talk miliary radios, but they weren't hand held; those are handie talkies. HT is still the term used today for hand held PTT radios. We used to use the term "walkie talkies" when we were kids for the AM toy PTT radios, but that wasn't what the term originally meant. I worked for Moto on HTs.

I put an AVR in a product at work last year. Everyone refers to it as "the PIC". I've stopped correcting them; it's no use.

[gnuarm]

... I worked at a company once that designed push to talk military radios (never call them walkie talkies).  The old timers had very little sophistication and any time they wanted to say MCU they just said PIC.  I kept thinking they had a serious hard-on for Microchip for some reason.

walkie talkies were push to talk miliary radios, but they weren't hand held; those are handie talkies. HT is still the term used today for hand held PTT radios. We used to use the term "walkie talkies" when we were kids for the AM toy PTT radios, but that wasn't what the term originally meant. I worked for Moto on HTs.

I put an AVR in a product at work last year. Everyone refers to it as "the PIC". I've stopped correcting them; it's no use.

They still make back pack versions they call man pack which is more powerful with longer range as well as a vehicle mounted version with even more power, I forget the term for that, I think it was just a vehicle adapter with an amplifier.

[rfclown]

..
...Could you show some more info about your solution for those who don't have Octave installed (yet)? ...

I just installed Octave on my Windows 10 machine, and it was painless. Googeled "octave download", clicked link, installed, copied tone16.m.txt file, removed .txt from filename, typed "tone16" and gf's plots all popped up. I've never been a Matlab user, but this was just too easy to try. When I saw the "pkg load signal" at the begining of the file, I was afraid I'd have to learn about finding and loading packages, but it just worked.

[rfclown]

They still make back pack versions they call man pack which is more powerful with longer range as well as a vehicle mounted version with even more power, I forget the term for that, I think it was just a vehicle adapter with an amplifier.

I'm working on some man pack's now. You don't want to be the one who has to carry these things.

[gf]

Could you show some more info about your solution for those who don't have Octave installed (yet)?

It is not the solution, but a simulation of the potential outcome. The simulation assumes that the carriers are generated via (software) DDS and AM-modulated (regular double side-band modulation) with the 16 digital signals (after band-limiting them with a pulse shaping filter). Data streams are supposed to be async, with a (maximum) bit rate of 84.375 bits/s each. Carriers are 384.375, 553.125, 721.875, 890.625, 1059.375, 1228.125, 1396.875, 1565.625, 1734.375, 1903.125, 2071.875, 2240.625, 2409.375, 2578.125, 2746.875, 2915.625 Hz. Hopefully "KISS enough" The most computationaly expensive thing at the sender side is likely the pulse shaping filter.

Receiver side assumes sampling the audio signal at 10.8kSa/s sampling rate, a 384.375Hz quadrature LO (realized as software DDS as well), mixer (one complex multiplication per sample), and overlapping 128-point FFT (112 points overlap -> 8 FFT evaluations per symbol).

EDIT: Prior decimation could reduce the FFT size, but OTOH requires an additional decimation filter. I'm not sure if that were computationally cheaper, after all. And decimation were still limited to 2x, since the transition band of the decimation filter needs to be > 0, and the 2700Hz channel bandwidth is fully occupied by the 16 sub-bands.

Even w/o Octave installed you can still look at the code, of course

I wonder you still use initial upconverter with FFT16 instead of let's say 16 (middle'ish) bins of FFT64 or even FFT32 w/o upconverter?

I did not assume FFT on the sender side. OFDM requires the insertion of a guard interval between the symbols (mostly a cyclic prefix -> CP-OFDM), so I guess symbol timing recovery cannot be renounced at the receiver, and the receiver cannot work async? Or can it? The guard interval also reduces symbol rate (which can be compensated OTOH by modulating multiple bits onto one carrier). But likely no longer "KISS enough" for the OP then...

Also did take a brief look at gnuradio docs. Seems that a huge nuber of building blocks are readily avalable, which are suitable to compose various kinds of modems. So Raspberry PI + USB sound card + gnuradio might be an option, too?

[ogden]

Receiver side assumes sampling the audio signal at 10.8kSa/s sampling rate, a 384.375Hz quadrature LO (realized as software DDS as well), mixer (one complex multiplication per sample), and overlapping 128-point FFT (112 points overlap -> 8 FFT evaluations per symbol).

EDIT: Prior decimation could reduce the FFT size, but OTOH requires an additional decimation filter. I'm not sure if that were computationally cheaper, after all. And decimation were still limited to 2x, since the transition band of the decimation filter needs to be > 0, and the 2700Hz channel bandwidth is fully occupied by the 16 sub-bands.

Try 8KHz sample rate, iFFT64 and bins 4 till 20. Unused bins are set to 0, some may be used to transmit FCS btw. Decode accordingly - using 8KHz sample rate and FFT64.

OFDM requires the insertion of a guard interval between the symbols (mostly a cyclic prefix -> CP-OFDM), so I guess symbol timing recovery cannot be renounced at the receiver, and the receiver cannot work async? Or can it?

Cyclic prefix will not hurt - because then prolonged symbol do not need windowing for FFT at the receive end. Sync is needed as well - to avoid inter-symbol interference, thou for particular (OOK of subcarriers) application it can be as simple as brick: transmit some silence (>=1/4 of symbol time) between symbols. On receive end "listen" with AM envelope detector, save received baseband samples in the buffer. As soon as envelope detector finds signal which lasts as long as symbol - try FFT on buffer and consider it done. Well, maybe check FCS.

[gnuarm]

Could you show some more info about your solution for those who don't have Octave installed (yet)?

It is not the solution, but a simulation of the potential outcome. The simulation assumes that the carriers are generated via (software) DDS and AM-modulated (regular double side-band modulation) with the 16 digital signals (after band-limiting them with a pulse shaping filter). Data streams are supposed to be async, with a (maximum) bit rate of 84.375 bits/s each. Carriers are 384.375, 553.125, 721.875, 890.625, 1059.375, 1228.125, 1396.875, 1565.625, 1734.375, 1903.125, 2071.875, 2240.625, 2409.375, 2578.125, 2746.875, 2915.625 Hz. Hopefully "KISS enough" The most computationaly expensive thing at the sender side is likely the pulse shaping filter.

Where did you get the max bit rate?  I'm assuming it was from the frequencies you picked?

Receiver side assumes sampling the audio signal at 10.8kSa/s sampling rate, a 384.375Hz quadrature LO (realized as software DDS as well), mixer (one complex multiplication per sample), and overlapping 128-point FFT (112 points overlap -> 8 FFT evaluations per symbol).

I don't understand the need for the down conversion.  Your spectral results don't seem to be any different, just different frequencies.  Were your graphs not from the 128 point FFT, but rather higher resolution processing?

EDIT: Prior decimation could reduce the FFT size, but OTOH requires an additional decimation filter. I'm not sure if that were computationally cheaper, after all. And decimation were still limited to 2x, since the transition band of the decimation filter needs to be > 0, and the 2700Hz channel bandwidth is fully occupied by the 16 sub-bands.

[gf]

Where did you get the max bit rate?  I'm assuming it was from the frequencies you picked?

I have divided the 300-3000Hz voice channel evenly into 16 sub-channels, and the carriers are in the center of each sub-channel. Each sub-channel therefore has a total bandwidth of 168.75Hz and the upper and lower sideband of each sub-channel have a width of 84.375Hz. Since the 16 digital signals are AM-modulated onto their carriers, the bandwidth of each digital signal must not exceed 84.375Hz in order to avoid channel crosstalk. The spetrum of a digital NRZ signal has a main lobe with a width of 1HZ per bits/s. If only the main lobe is retained and the side lobes are eliminated by pulse shaping (low-pass filtering), then the 16 digital signals can have a bitrate of max. 84.375 bits/s each, w/o cross-talking into the neighbor channels. In the previously attached spectrum plot you can see the upper/lower sideband of each sub-channel.

I don't understand the need for the down conversion. Your spectral results don't seem to be any different, just different frequencies.  Were your graphs not from the 128 point FFT, but rather higher resolution processing?

Mixing with a sinusodial quadrature LO does exactly that -> shifting the frequency spectrum.
Reason for the down-coversion is that the carriers are not aligned with frequency bins of the 128 point FFT.
After down-conversion the carriers are exactly aligned with FFT bins (N*168.75Hz, where N is an integer).

The spectrum plots are high-resolution (16k points FFT) of ~1.5s data stream. They are not limited to a single symbol. They are supposed to show how the overall spectrum is utilized by the modulated signal. Limiting it to one symbol would only show a subset.

Note this is eventuall just AM+FDM, it is not OFDM.
Neither are the carriers orthogonal, nor does any symbol synchronization occur at the receiver.
EDIT: Not exactly true. While the actual carriers are not orthogonal, the down-converted carriers happen to be. Since the timedomain signal of the symbol was not generated by IFFT (circular convolution), and since there is also no symbol synchronization, the benefit of orthogonality alone is limited, and there is still a window function required for the FFT.
The FFT on the receiver side (in conjunction with the window function) is just "abused" as filter bank.

[gf]

Receiver side assumes sampling the audio signal at 10.8kSa/s sampling rate, a 384.375Hz quadrature LO (realized as software DDS as well), mixer (one complex multiplication per sample), and overlapping 128-point FFT (112 points overlap -> 8 FFT evaluations per symbol).

EDIT: Prior decimation could reduce the FFT size, but OTOH requires an additional decimation filter. I'm not sure if that were computationally cheaper, after all. And decimation were still limited to 2x, since the transition band of the decimation filter needs to be > 0, and the 2700Hz channel bandwidth is fully occupied by the 16 sub-bands.

Try 8KHz sample rate, iFFT64 and bins 4 till 20. Unused bins are set to 0, some may be used to transmit FCS btw. Decode accordingly - using 8KHz sample rate and FFT64.

OFDM requires the insertion of a guard interval between the symbols (mostly a cyclic prefix -> CP-OFDM), so I guess symbol timing recovery cannot be renounced at the receiver, and the receiver cannot work async? Or can it?

Cyclic prefix will not hurt - because prolonged symbol do not need windowing for FFT at the receive end. Sync is needed as well - to avoid inter-symbol interference, thou for particular (OOK of subcarriers) application it can be as simple as brick: transmit some silence (>=1/4 of symbol time) between symbols. On receive end "listen" with AM envelope detector, save received baseband samples in the buffer. As soon as envelope detector finds signal which lasts as long as symbol - try FFT on buffer and consider it done. Well, maybe check FCS.

I'm indeed tempted to try (simulate) that OFDM stuff, too. It seems to have a couple of nice properties

[ogden]

Note this is eventuall just AM+FDM, it is not OFDM.
Neither are the carriers orthogonal, nor does any symbol synchronization occur at the receiver.
EDIT: Not exactly true. While the actual carriers are not orthogonal, the down-converted carriers happen to be. W/o symbol synchronization, the benefit of orthogonality is limited, though.
The FFT on the receiver side (in conjunction with the window function) is just "abused" as filter bank.

It is OFDM indeed, just obfuscated with up/down-conversions I wonder about as well. OFDM does not actually define range of FFT bins to be used, nor modulation of subcarriers which can be any, even OOK/AM. iFFT64 @8KSPS can generate frequencies in range of 125 to 4000Hz for bins 1 to 32. We pick only those bins which fall into our band of interest, set others to 0 for iFFT and ignore in FFT receive end. In case of my example bin 4..20 will give 500Hz..2500Hz subchannels. Decoding is as simple as generation of symbol waveform - do FFT instead of iFFT making sure you point your FFT at symbol waveform (more or less).

I'm indeed tempted to try (simulate) that OFDM stuff, too. It seems to have a couple of nice properties

Would be nice to see what you make out of it.

[gf]

It is OFDM indeed, just obfuscated [...]

Isn't the "circular" property missing for the symbol's time domain samples, when they were not generated via IFFT, but as 16 independent AM streams, and without considering dedicated symbol borders?

Would be nice to see what you make out of it.

Sorry, not today

[ogden]

It is OFDM indeed, just obfuscated [...]

Isn't the "circular" property missing for the symbol's time domain samples, when they were not generated via IFFT, but as 16 independent AM streams, and without considering dedicated symbol borders?

Exact frequency of each subcarrier, not phase defines - "symbol" has circular property or not. OFDM symbol (output from iFFT) contains integer periods of each subcarrier sine. So if you generate correct subcarrrier waveforms using other than iFFT math, result shall be still valid. You did kinda prove it yourself Other argument - OFDM mostly uses nPSK modulations for subcarriers meaning their phase can vary, yet it does not impact circular properties of symbol, allows cyclic prefix.

[rfclown]

I assume though that for the OP's application he's sending "whatever" through an FM system. So if we want to use OFDM, it's not really OFDM on the RF carrier. Put regular OFDM through preemphasis and a fully compressed PA on the Tx, then a limiter and deemphasis on the Rx, and you have a mess. When I was thinking OFMD, I was just pondering the use of an IFFT to generate the tones and FFT to extract tones. OP didn't seem interested in the discussion anyway. What I got out of it was just having some thoughts... and downloading Octave.

[gf]

Exact frequency of each subcarrier, not phase defines - "symbol" has circular property or not. OFDM symbol (output from iFFT) contains integer periods of each subcarrier sine. So if you generate correct subcarrrier waveforms using other than iFFT math, result shall be still valid. You did kinda prove it yourself Other argument - OFDM mostly uses nPSK modulations for subcarriers meaning their phase can vary, yet it does not impact circular properties of symbol, allows cyclic prefix.

Generating the subcarrrier waveform for a symbol via IFFT implies that sub-carrier amplitude and phase is constant for the symbol duration. OTOH, the sine wave, AM-modulated with the low-pass-filtered NRZ signal, does not have a constant amplitude for the symbol duration. Still equivalent?

[ogden]

Generating the subcarrrier waveform for a symbol via IFFT implies that sub-carrier amplitude and phase is constant for the symbol duration. OTOH, the sine wave, AM-modulated with the low-pass-filtered NRZ signal, does not have a constant amplitude for the symbol duration. Still equivalent?

No. Unless precisely timed, amplitude change of subcarrier *during* OFDM symbol may break cyclic properties of it indeed.

[gf]

Would be nice to see what you make out of it.

Found a time slot to try, see attachent. Sorry, too late (in the night) now to describe details and findings. There are some comments in the code, though. There is still some debuging stuff left and commented-out. Pleas ignore.

EDIT:

I used the proposed baseband frequency plan (renouncing a mixer). This also gives some extra channels in the 500...3000 Hz range (which I used for e.g. sync and pilot tone). As subchannel modulation I used 2-PSK, i.e. using only real +1 and -1 constellations. My aim was to send plain bit streams, w/o dedicated frames, so I can't used use preamble for sync. Instead I used channel 16 (=> fs/4) to send a continuous sync pattern (alternating +1 and -1 constellation).

Since OFDM symbols are well-isolated in time domain, but the sub-channels have significant out of band leakage in the frequency domain, there is significant cross talk from the data channels to the sync channel. This (in conjunction with renouncing frames and preamble and the short symbol size) complicates detection of the symbol position in the time domain signal. Nevertheless correlating a long enough sequence of the sync pattern (20+ symbols) with the received data stream still did enable symbol position detection with a standard deviation of ~1.5 samples. That's close enough to do further phase synchronization via channel estimation.

For a poor man's channel estimation I used a 500 Hz pilot tone (so that a phase shift of +/-pi corresponds to an adjustment range of +/-8 samples, leaving some room to correct the  imperfectly detected initial symbol position). At the assumed noise level, the phase estimate from the pilot tone was still not robust enough, so I'm smoothing it over time. Consequence is that the first few symbols after initial synchronization still have a higher BER, which decays, however, when the smoothed time offset stabilizes. A simple single-pilot-tone EQ needs to rely on linear phase in the 500...3000 Hz band, which is certainly not granted in practice. So rather a larger number of pilot tones would be needed eventually, leading to even more complex EQ processing, doing some interpolation.

While it seems certainly feasible to implement all this stuff, I'd no longer consider it "KISS". So I think, for a low-effort and robust implementation I'd rather tend to go the gnuradio route, which already includes ready-to-use modules for all this stuff, and much more. Requires of course a processor/system where gnuradio is runnable (a Raspberry PI and an USB sound stick are not so expesive either, though). Nevertheless, evaluating various of aspects was an interesting experience.

[OldVolts]

These signals are audio.  There is no reason to use 16 different DDS generators.  A single  generator with 16 sets of registers (easily implemented in LUT memory) will run many times faster than required.  As others have pointed out this can easily be done in nearly any MCU you can think of.  It is the decoding that is a bit more difficult.  Some are suggesting an FFT is the way to go, but the devil is in the details and so far I have not seen any details from the OP.  In fact, this "project" may just be a prank.   He seems to be responding to serious questions with sarcasm. 

Yeah, it seems like it's time to ignore this thread.  Am I wrong?

Sorry but not a prank.  Really looking to generate 16 different audio tones simultaneously with the ability to control each individual tone.
My biggest issue was the number of I/O pins on any conventional MCU but I now believe any of the Propeller chips will solve that problem; 2 chips - 8 cores each - 16 tones.
If / When I get something making reasonable output I'll post.
Thanks All

[OldVolts]

Warning - LONG
To address the noise about need for more information:
I am responsible for the maintenance and improvement of a local amateur radio group's repeater systems.  One of those systems has 7 remote receivers distributed about the county and tied back to the "control" site by UHF radio links.  There is also "local" receiver bringing the total to 8 receivers.
The COR and audio output of each receiver is fed to a voter (LDG-RVS-8) then to a controller (SCOM 7k) and then to the transmitter (CDM750) and finally to the amplifier (Henry 500 BA).
The control site is a 30 minute drive and in a location having TIGHTLY controlled access.  Pure PITA!  By the time I get there the problem has usually gone "poof".
So . . .  To ease my troubleshooting pain I decided to undertake a means to remotely observe various diagnostic indicators, which initially lead to an attempt to use a packet-based protocol (AX.25) to transmit the diagnostic stuff.
Issue 1 - Data occurs in real time - packet is NOT.  A mobile can vote between 3 or 4 receivers in ONE second -NO packet system is that fast.
2 - Besides being data "shy" it is delayed so what I'm seeing is historical - not what I'm currently hearing.
3 - Uneconomical - requires a second radio dedicated to a TNC and some sort of display - $$
I want to watch 8 radio activity (COR) indications simultaneously - 8 "bits" and the voter's voted selection (one of 0 to .  I can encode the voted as 8 into 4 - requiring only 4 tones leaving tones 13, 14, 15 and 16 for environmental and other alarm indications.
The decoder is a slight modification to https://create.arduino.cc/projecthub/shajeeb/32-band-audio-spectrum-visualizer-analyzer-902f51
The tones I have chosen are non harmonically related through 5th order and are based on prime numbers so the FFT decoder should have an easy time keeping the tone display "clean".
So - to sum:  Looking at using 2 Propeller chips.  8 Cores each, 80 MHz clock, simple programming and SCADS of I/O pins.
As before - If I get it to work to my satisfaction I'll share what I can.
Thanks for those of you who were actually willing to help,
Bill

[gnuarm]

I thought you said it was going to be an Arduino???  KISS, no?

If you need to use two propeller chips,  you must need a data rate of around a Mbps.  That makes no sense because the tones are just AUDIO rates.  If you need much lower data rates you can generate the audio tones with pretty much any MCU, even a simple 8 bit Arduino processor. 

There may be 16 tones, but each tone generator only takes a few instructions.  So the tones can all be generated by the same code running sequentially on the same processor.  A DDS requires one word in memory for the phase increment which corresponds to the frequency and one word in memory for the phase accumulator.  In each case pick your data width to suit your frequency resolution and sample rate.  So that would be 32 words for 16 DDS. 

Assume a sample rate of 8 ksps that gives 128 k DDS updates per second or 156 clock cycles per DDS update with a 20 MHz processor.  That should be a piece of cake.  Use 16 bit data samples and you can achieve approximately 90 dB of SNR and similar harmonic distortion with any of many available 16+ bit stereo CODECs for $3.  All 16 DDS outputs can be summed into a single output for the CODEC. 

I literally can't think how it will be easier in any way to spread the tasks across 16 threads having then to coordinate them with a 17th process.  I suppose you could create each thread to sum data input from say the "LEFT" and pass data out to the "RIGHT" with the right of the last processor being the CODEC perhaps.  Otherwise the threads will have to be different.  Yeah, it's kinda goofy to try to take a single process and turn it into 16 threads.

[oPossum]

The tones I have chosen are non harmonically related through 5th order and are based on prime numbers so the FFT decoder should have an easy time keeping the tone display "clean".

You've got that backwards. An FFT can only give a 'clean' output for tones that are periodic within the sample set. Everything else will spill in to other bins.

[hamster_nz]

Depending on how crufty you want to go...

If I was doing this with parts on hand, it would be an ESP32 with an I2S DAC for encoding, and an ESP32 with an I2S ADC on the decoding.

I would also think of adding a pilot tone, so the receiver can 'anchor' onto something.

[MIS42N]

Talk about a steamroller to crack a nut. The OP distinctly stated in post #1 "Can use a (reasonable) number of processors (16 is NOT reasonable)" then proposes to use two propeller chips containing (....dada....) 16 processors.
If the 'explanation' of the problem by the OP is described as LONG, but answers few of the questions, I'd like to see the REALLY LONG description. I cannot see why this can't be dealt with as a parallel to serial conversion, simple transmission, serial to parallel at the other end. These are decades old techniques with simple, cheap and well proven technology.
It will be interesting to see the final solution.

[voltsandjolts]

I would also think of adding a pilot tone, so the receiver can 'anchor' onto something.

Pilots are definetly required for calculation (compensation) of symbol phase and amplitudes.
The more the transmission medium properties vary over the frequency range of interest, the more pilots that are required.

Symbol alignment is crucial but a neat trick is to copy, say, last 2% of time domain signal (for a symbol) to the beginning of the symbol. Similarly, 2% of the beginning copied to the end.
Thanks to the circular nature of FFT, symbol alignment can then be out by 2% and still get the same result.