Generating Simultaneous Tones

[MIS42N]

In lost post of mine I was saying that multichannel transmission does not increase information transmission speed, nor improve latency.

Example: OOK/BPSK spectral efficiency is 1bit/Hz, 1600bps transmission requires 1600Hz frequency band of single channel. Transmission of 16 bits will take 1/100 sec. When we split 1600Hz channel into smaller 16 non-interfering 100Hz subchannels and transmit using OOK/BPSK, then those who can do the math will see that latency of 16 bit transmission will be 1/100 sec. In short: 16-tone requirement only adds unnecessary complexity, does improve nothing in terms of speed or latency.

I was wondering about that. To achieve higher bit rates needs each subchannel to have some form of multibit encoding. Old modems (and maybe still do) negotiated by sending tones and working out noise and distortion, encoded as many bits as each subchannel could reliably handle. However, this does nothing to reduce latency, just send more bits in the same time slice. OP seems interested in latency more than bit rate.

Depending on the actual timing of events, maybe event notification would be a better solution. Send a byte with an event and new value. Since the value is only 1 bit (led on or off) could have up to 128 events. An extensible scheme. This has lower latency and given the sort of data involved could be encoded in a narrow bandwidth. Use a carrier under 300Hz and still get 100ms response. Could go along with the audio.

[hamster_nz]

The requirements are not well enough thought out and expressed if it was monitoring the state of 16 subsystems on a deep space probe.

However, the OPs requirements are well enough thought out and expressed for a hobby project, to be made out of stuff on hand, and perform 'well enough' for their needs, which appear to be monitoring 16 things in a semi-remote radio site.

This sounds like an environment where a Raspberry Pi + cell phone +  web cam pointed at battery meters could be a workable solution to monitoring UPS charge. Let's not over-engineer it. 

[MIS42N]

The requirements are not well enough thought out and expressed if it was monitoring the state of 16 subsystems on a deep space probe.

However, the OPs requirements are well enough thought out and expressed for a hobby project, to be made out of stuff on hand, and perform 'well enough' for their needs, which appear to be monitoring 16 things in a semi-remote radio site.

This sounds like an environment where a Raspberry Pi + cell phone +  web cam pointed at battery meters could be a workable solution to monitoring UPS charge. Let's not over-engineer it. 

I understand what you saying. I don't think two $3 boards and a few passives is over engineering. The beauty of microprocessors is how much can be done with very little. Reading 16 inputs, encoding, decoding and create 16 outputs is a simple task. I recently decided I needed a second 9600 baud input to a processor with one UART, implemented one in software, no problem and for good measure would handle 3.3V input without a level translator. On an 8 bit processor worth maybe $1. Is that over engineering or just making best use of what is there?

And maybe the OP had thought out the requirements, but I would contest that they were expressed in any useful format. About all we were told was a certain packet protocol had too much delay, and were given a 'solution' that we were left to flesh out. I think the majority opinion is the solution is not appropriate for the problem. It is interesting that the only demonstration that appears to solve the problem did not use the proposed solution.

It is interesting to see if any of the multitone proposals gets a real world demonstration. And if it works, is it in any way superior to a time slot system. I think it is like clean coal. Feasible but uneconomic.

[gf]

[...] And if it works, is it in any way superior to a time slot system. I think it is like clean coal. Feasible but uneconomic.

One significant disadvantage of the OOK/DMT approach is the huge peak to avarage power ratio. In order not to clip at worst case¹⁾, when the peak values of all tones happen to add-up, each tone needs to be transmitted with a level of only -24dB_FS²⁾. In my simulation, the maximum tolerated noise level turned out to be only about -27dB_FS (where I still got sufficiently clean eye diagrams). That's not much. To me it is still unclear what effect a squelch or dynamic compressor in the transmission path would have on the bit error rate. Data rate in my simulation was 84.375 16-bit-words per second, dividing the 300...3000Hz range into 16 equally spaced bands. Delay is dominated by by pulse shaping on the sender side (necessary to prevent cross-talk into neighbor channels) and the FFT window I used at the receiver side. Makes a delay of about 3-4 symbols in total (about 35-45ms).

For comparison, the good old Bell 202 FSK signal @1200bits/s has constant amplitude and thus a very good peak to average power ratio. It is pretty robust/tolerant to amplitude change and even some clipping. Due to constant amplitude I would not expect problems with squelch or dynamic compressor. I have simulated FSK as well, and even after adding -6dB_FS of noise I've still seen bit error rates as low as 10^-4...10^-3. So the noise tolerance is ~20dB better (factor 10 in terms of voltage) than the OOK/DMT approach. Both, modulator and demodulator are computationally cheaper than for OOK/DMT. If I assume 20-bit frames (start, 16x data, parity, 2x stop) then the net data rate is 60 16-bit-words per second. Delay (excluding the radio) is about 18ms (16.667ms for the frame transmission, and ~1ms for a digital low-pass filter at the reciver). If any DAC/ADC buffering and/or analog audio signal filters are required, they add on top of that (but this applies to both approaches).

Who of them is my winner?

¹⁾ Since the worst case happens rarely, it may be possible to overcommit amplitude, say by a factor of ~2. Still gains only 3dB 6dB SNR, while intruducing additional bit errors OTOH.
²⁾ With dB_FS I mean dB relative to a full scale sine wave

[fourfathom]

Delay is dominated by by pulse shaping on the sender side (necessary to prevent cross-talk into neighbor channels) and the FFT window I used at the receiver side. Makes a delay of about 3-4 symbols in total (about 35-45ms).

I think from your numbers that you are modulating the individual tones at twice the channel spacing (in Hz)?  If you cut the modulation rate in half (baud rate = tone spacing) then the modulation spectral nulls will have the same spacing as the channel-spacing, reducing neighbor crosstalk and your filter requirements.  Of course that halves your data rate...

[gf]

I think from your numbers that you are modulating the individual tones at twice the channel spacing (in Hz)?  If you cut the modulation rate in half (baud rate = tone spacing) then the modulation spectral nulls will have the same spacing as the channel-spacing, reducing neighbor crosstalk and your filter requirements.  Of course that halves your data rate...

I tried to avoid channel overlap completely at the transmitter side.
It is only 0.5 baud per Hz channel spacing, i.e. the main lobes of adjacent channels don't overlap (first zero in the middle between adjacent carriers).
And the side lobes are significantly reduced by doing pulse shaping prior to the AM modulation onto the carriers.
See attached figure2.png here https://www.eevblog.com/forum/projects/generating-simultaneous-tones/msg3552741/#msg3552741

[oPossum]

Nice, very nice.

A little outside of the voice 300 -> 3k bandwidth requirement, but that's just selecting the right range of primes and sample rate...

Thanks.

The OP mentioned using "Arduino audio analyzer" as a basis for decoding. That may be a reference to this: https://create.arduino.cc/projecthub/shajeeb/32-band-audio-spectrum-visualizer-analyzer-902f51
The code for that project has 32 bands from 601 Hz to 19.23 kHz. With a few simple changes described in the writeup it can cover 150 Hz to 4.8 kHz. So I wrote code that has a DDS phase increment value that matches the bin number of the FFT. The frequencies where chosen to have no 2nd or 3rd harmonics of each other. The result is 16 tones from 301 Hz to 4.357 kHz that match the FFT bins of the audio analyzer.

[gf]

The OP mentioned using "Arduino audio analyzer" as a basis for decoding. That may be a reference to this: https://create.arduino.cc/projecthub/shajeeb/32-band-audio-spectrum-visualizer-analyzer-902f51

One issue with this gadget is obviously leakage from the left and right neighbor channel, which can be also seen in the screenshots. Looking at the code at Github basically clarifies why this happens. Hamming window has a suppression of 40+ dB for the side lobes, but that comes at the cost that the main lobe has a width of +/-2 bins, i.e. the two immediately adjacent neighbor channels still fall into the main lobe. I see two potential solutions:

• Keep the Hamming window, but double the FFT size and discard every 2nd frequency bin (leads to higher computational cost for the longer FFT)
• Replace the Hamming window with a rectangular one, accepting some leakage when tones are turned on or off in a fast sequence
  (carriers which are continuously on, are still not supposed to leak, since the fall onto the zeros of the window's frequency response, but the modulation sidebands can leak)

Another potential issue is that the code caputures 64 samples, and then it does the whole processing for these samples before capturing the next samples. So the audio stream is obviously not sampled continuously, without gaps. For the intended use case this may be still OK. I have no idea, though, how long the processing takes and how log the gaps are.

BTW, just wondering, are the supported sampling rates really limited to "odd" values of 16MHz/13/2^n?