3
$\begingroup$

I'm working on improving the modem communication speed that can be achieved over a 10km cable. The current modem achieves a speed of 9600 bps via hardware (phase locked loop) and I'm looking for ways to at least double this, and do it all in firmware. Here are some specs for the project.

Cable characteristics

  • Length: 10,000m
  • Capacitance: 1.48μF (148pF/M)
  • Resistance: 320 Ω (32 Ω/km)

Driver signal

  • 10 Vpp (+10 V to -10 V) @ 250 mA
  • Can be used for Amplitude and Frequency modulation
  • Currently cannot perform phase modulation

Available bandwidth on cable

  • 30 KHz to 100 KHz
  • Attenuation: 100KHz signal results in a third of the amplitude of the 30KHz signal

Current method of modem communications (want to improve)

  • A hardware implemented Phase Locked Loop (PLL)
  • Achieves a speed of 9600 bps

The aim is to improve the 9600 bps speed and also to implement the modem in firmware. The firmware target is an ARM based 32-bit microcontroller - Infineon's XMC4500 with onboard ADC (firmware to be written in C). I have a working prototype, but the best I can achieve so far is 10,500 bps which is only a small improvement over the current system. The method used was to implement FSK demodulation using the Goertzel algorithm. I was detecting 4 frequencies in the range of 40KHz to 80Khz, which gives 2 bits per signalling period. On the microcontroller performance, I've found that 4 frequencies is the maximum number that can be attempted using the Goertzel method. Also the microcontroller ADC's practical maximum sampling rate is 700 KHz.

Does anyone have a suggestion how to achieve a decent speed improvement using frequency and/or amplitude modulation with such limitations as these? I'm new to DSP so I've likely missed some other better techniques that could be used.

Many thanks in advance.

PROGRESS UPDATE (10/10/2013)

Since posting this question and after some simulation and testing, the communications scheme has been changed to be asymmetrical since only the downlink side actually needed to be upgraded. The uplink speed remains as is - a PLL running at 9600 bps, but the downlink speed ends up being a faster ~64,000 bps, with the downlink demodulator hardware running on something equivalent to PC level.

This hardware upgrade enables the use of an FFT and an 8-bit symbol using 8 frequencies. The FFT parameters being used are a sample rate of 512,000 SPS and a number of bins of 64. The frequencies being detected are in the range of 32,000 Hz and upwards, with a spacing of 8,000 Hz. The ADC is 12-bit. I've also implemented Reed-Solomon forward error correction, which may be used to reduce error rates.

Improve this question
$\endgroup$
3
  • $\begingroup$ What is the noise level (or SNR) ? $\endgroup$
    – Paul R
    Aug 13, 2013 at 8:53
  • $\begingroup$ @PaulR sorry don't know the exact figure - will find out tomorrow, but I know its reasonably noisy. Having said that I believe the Goertzel algorithm that is used in the prototype seems to be really noise immune. $\endgroup$
    – dodgy_coder
    Aug 13, 2013 at 12:43
  • 4
    $\begingroup$ You probably already know this but the theoretical upper bound on bit rate is determined by bandwidth and SNR, so once you know the SNR you can quickly put a theoretical limit on what might be possible, given the right encoding scheme. See: Wikpedia entry for Shannon-Hartley $\endgroup$
    – Paul R
    Aug 13, 2013 at 13:49

1 Answer 1

Reset to default
2
$\begingroup$

It seems your hardware is limited. If you can't detect more finite frequencies and you can't implement another method of modulation you might have reached your maximum in physical bits with your hardware.

May I suggest a bit of coding theory? Implement LZW compression. The data rate will vary and it might not give you double the speed but will definitely increase the data rate.

Its already produced in c, try it out.

http://marknelson.us/attachments/1989/lzw-data-compression/lzw.c

Improve this answer
$\endgroup$
1
  • $\begingroup$ Thanks for the suggestion, which is a good one. I did previously investigate some compression schemes a while ago but with the data being fairly random and smallish (<200 bytes per frame, 5 frames per second) it didn't show much gain when using compression. A better technique turned out to be differential compression (only frame diffs encoded) but this raised its own issue of when an error occurs - the need to 'reset' the sender back to an uncompressed frame. Basically the current preference is for the transmitter to be 'stateless' i.e. always transmitting the full frame. $\endgroup$
    – dodgy_coder
    Oct 10, 2013 at 7:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.