If we like transmitting digital data [0,1] thru a voice channel (as 300 to 3300 Hz), could the bit rate be made close to the bandwidth upper limit?
I am working on it by using ATmega8A with relatively simple hardware (opamp and gates).
I am asking this to avoid, perhaps, re-inventing the wheel.
Thank you.
I think the particular wheel you are re-inventing is called a modem...
Remember "56K" ... ?
Do you mean 56 Kbit/sec?
Added: thru 3300KHz bandwidth?
Added: But thank you, awneil. Now I am searching if the topology used is as simple and low-cost as the one I am working on.
@KerimF said:
Do you mean 56 Kbit/sec?
Added: thru 3300KHz bandwidth?
https://en.wikipedia.org/wiki/List_of_modem_standards says:
V.90: The fastest transmissions standard available for analog transmission, it is capable of 56,000 bit/s.
If a narrow channel (as 3K2) can pass 64,000 bit/s [56K data + 8K control], I wonder why this narrow channel cannot also pass more than 64,000 bit/s!
Added: I guess it is all about "the Shannon capacity of a narrowband line".
Added: Therefore, the trade off here is: simple hardware (software) for 3,000 bit/sec and complex one (using specialized ICs) for higher bit rates (assuming P_signal/P_noise > 1 ).
V.90 was a "special case" which relied upon the fact that the PSTN is mostly digital.
IIRC, it also required special equipment in the network.
The 56k was down-link only; 33k uplink.
https://en.wikipedia.org/wiki/Li...
Channel bandwidth is not the center frequency of the band, it is the width of the passband. Thus, a 56KHz channel that is 10Hz wide cannot pass 56Kbaud data. Its the same situation as with a radio receiver. You tune the receiver to, lets say, 5MHz, but the passband is only a few hundred hertz. You can barely get high speed morse code through.
Jim
You can send data at any speed on a voice channel. It's the signal to noise that really give the speed, and how the channel works (true analog or is it digital some of the way)
I have decoded AIS 9600 baud, received from normal audio (true audio from a VHF radio 300-3000Hz).
And it's actually possible for a AVR to do it in real time, (a long waiting project of mine).
And don't think about just modulating the frequencies. There's also the phase to play with (eg QPSK). And also multiple frequencies (eg DTMF).
For example, with a simple DTMF scheme you can transmit 4 bits at once.
An extreme case for AVR :
E5's XCL doing 2Mbps(!!!) FSK, appnote to follow
https://www.avrfreaks.net/forum/e5s-xcl-doing-2mbps-fsk-appnote-follow
Here is my story 
With my humble hardware and software tools, I was designing, updating and producing various 1-line outdoor moving message signs for Arabic and English (as a first step) before year 2011.
The user wrote his message (up to 2000 characters) on Notepad. By an exe file (I made for DOS, since I have BORLANDC 3.1 only), the text is translated to binary which could be saved in 24C32 (actually in half of it, usually embedded on a homemade 8-pin plastic card). The user had 2 ways to update the message displayed on his sign. First, by a simple homemade card (SEEP) reader, the memory bytes could be read automatically by the sign at boot if connected to it via 4-line phone cable. The second way, the card could be inserted in a homemade RF transmitter (powered by 4 small batteries and in which there is a small RF TX module imported from China). By detecting the card, the raw data were transmitted in order to be received by the RF RX module placed in the sign. The sign MCU did the rest. At that time, the best MCU I was able to get was SST89E58RDA (before it, I was using AT89S8253, AT89S8252...).
If my business in producing LED signs will be revived (I had to work on other projects during the last 6 years), I am looking to use the raised cosine square wave (which needs a rather simple hardware that I developed lately to eliminate the higher harmonics without the need of a low pass filter) to transmit binary data (small amounts) between two mobiles (of the user and the one placed in the sign) using the voice channel. Well, may I add that you are lucky out there. It happens I was born and live in a region in which I have to build things almost from scratch always while my products have to be innovative or compete, in a way or another, similar ones imported from abroad. So I used to think for my designs what could be close to the optimum solution for a situation I live; leaving the global, if not perfect, solutions for others to find out
Wow
If my business in producing LED signs will be revived ...
I am looking to use the raised cosine square wave ... using the [mobile] voice channel.
Reason: my electrical engineering information theory course was 30+ years ago
Well, may I add that you are lucky out there.
Could add some EDC and/or ECC to the data to increase the link's reliability.
... my products have to be innovative or compete, in a way or another, similar ones imported from abroad.
An advantage of being local and/or regional versus an importer.
leaving the global, if not perfect, solutions for others to find out
If the point of the data channel is to update the sign's data for display, then why does speed matter?
Who cares if it takes 0.1 Seconds or 10 seconds for the data to upload to the sign, as long as you are not trying to stream real time messages.
Pick a slow baud rate, e.g. 300 baud or maybe 1200 baud and then make it work, reliably, and move on.
If your customers have smart phones these days, then an App to enter the new message on the smart phone and use Bluetooth to link to the message board would be another, wireless option.
JC
If we like transmitting digital data [0,1] thru a voice channel (as 300 to 3300 Hz), could the bit rate be made close to the bandwidth upper limit?
Most of the answers so far have been based on the common telephony standards, which have a 56k or 64k digital channel at their cores. The bandwidth of telco voice calls is generally spec'ed at 4kHz, but that's end-to-end including losses in the microphones and etc. If you really have a channel with 3300Hz of bandwidth, then that would probably be the upper limit of data transmission as well. You can look at the old "acoustic coupler" MODEMS - 300bps was common, some people achieved close to 600bps, and I think other designs could do 1200bps by reducing the reverse-direction channel to a lower speed. Various new modem technologies for phone lines cut out more and more of limiting factors (first eliminating the microphone/speaker with a direct electrical connection), incorporating various fancy signal processing, and eventually relying on the digital nature of the "central" site to achieve essentially the theoretical max of 56k.
I don't know if you can still buy modems, now that dialup is not popular. (https://www.newegg.com/Product/P... ? Might still be included on some laoptops.) I don't know how compatible they are with phone systems in an international context.
For Home Brew data-over-audio at relatively low speeds (300bps?), you might want to look at the "Kansas City Standard" developed for storing computer data on audio cassette tapes.
IIRC, there were some relatively simple circuits that could implement this, and reliability was limited more by tape quality than actual bandwidth.
https://en.wikipedia.org/wiki/Ka... - I bet you could implement it in SW on a modern AVR.
The Kansas City Standard.
Boy, that's a trip down memory lane.
The Wiki article was interesting, lots of old names in the industry mentioned:
Bill Gates, of Microsoft fame
Les Solomon, Popular Electronics
Wayne Green, Byte Magazine
And old micro systems mentioned:
Kim-1
MITs Altair
Ohio Scientific
BBC Micro
Acorn
Heathkit H8
and others
I can recall using a cassette tape recorder for storing programs for several systems.
JC
There are a few projects for the AVR kicking around which use audio to transfer data. Even one which implements a bootloader.
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
 |
Channel bandwidth is not the center frequency of the band, it is the width of the passband. Thus, a 56KHz channel that is 10Hz wide cannot pass 56Kbaud data. Its the same situation as with a radio receiver. You tune the receiver to, lets say, 5MHz, but the passband is only a few hundred hertz. You can barely get high speed morse code through.
Jim
Hi Jim
I agree with you because when I needed to build private RF voice links in the past (in 80's) I had to consider this point (though the transmitted signals were of voice not digital).
So, do you think now that, in case of RF, the Shannon capacity of a narrowband line, C=BW*log2(1+P_signal/P_noise), doesn't apply?
In other words, in case of radio channels, P_signal/P_noise cannot be made greater than 1.
Kerim
Although no one commented yet the expression "raised cosine square wave" that I wrote earlier, I picked a picture of a work I did about a year ago to give you a closer idea of it.
Since I can't access all scientific sites, mainly the professional ones, I am not sure if this idea is new or not.
To my knowledge it doesn't have a copyright and it cannot get one from where I live :) So if you will find out it is new, feel free to use it the way you like :)
google GMSK
And you should just do everything in SW
google GMSK
And you should just do everything in SW
You are totally right. It is indeed a phase shift modulation (180 deg.)
But I am afraid that the known ways to implement GMSK, even at low frequencies as it is the case here, are not as simple as the way I did.
As you know, a Gaussian filter and VCO are used in the analogue solution (which is usually not recommended).
In case of the reliable digital solution, one special IC (perhaps more) would be needed to let the modulator be practical.
But, on the other hand, these solutions are good to those who have the privilege of being serviced by any source of electronic components they may hear of.
During the last 6 years (and likely for many years to come) I had to depend on what is available at the local retailers only. The last time I was allowed to import goods directly from USA (Jameco for example) was in early 80's. Later, when many young Chinese started to communicate in English (about 20 years ago), it became possible for me (since around 2005) to go on designing better controllers. My designs which were provided as detailed schematics were converted to professional assembled/tested boards by the Chinese engineers. On these boards, it was possible for me to use any component I saw suitable. But my happy days had to end in year 2011. And although, via China, I was able getting any component, the tools I had (still have) for the design processes were rather old; for example, BORLANDC 3.1 to write PC programs and the DOS assembler, TASM.EXE, to run C51 family. Fortunately, I was able to download KICAD. Also, thanks to Atmel and its free AS6, I was able to shift to AVR. For instance, downloading AS7 from here is against the law now (after Atmel was acquired by Microchip). But it happens that AS6 is more than enough for me since I write in assembly only and I have to use a conventional parallel programmer (I also wrote a small PC program to insert automatically the fuses and locks, suitable for the project of interest, in the hex file generated by the assembler).
About SW, the carrier frequency (as 3KHz) is relatively not high for the MCU I have (ATmega8A). Therefore, the code for generating the GMSK signal, in this case, is not hard to write.
Since you know the signal only 1 and 0 , it's easy to "can" the value, and if you don't push it to hard (like a BT of 0.5 as AIS), it's ok no to have any memory between bits, (with BT of 0.3 as a cellphone the bit's start to mingle).
And if you don't need to push it to high there are no problems to make both the coder (you need a DAC but a R2R would be fine) and decoder in SW on an AVR.
Depending is the channel it can be a problem that the signal don't have a average value of 0 (or even close), and there can be long sequence without any shifts, this is normaly solved by preprocess the data.
Which speed do you need ? (your def. of upperlimit.)
and what is the quality of your audio? (is it 2m VHF, AM or ?). (and what is the BW of each channel ? )
Since you know the signal only 1 and 0 , it's easy to "can" the value, and if you don't push it to hard (like a BT of 0.5 as AIS), it's ok no to have any memory between bits, (with BT of 0.3 as a cellphone the bit's start to mingle).
And if you don't need to push it to high there are no problems to make both the coder (you need a DAC but a R2R would be fine) and decoder in SW on an AVR.
Depending is the channel it can be a problem that the signal don't have a average value of 0 (or even close), and there can be long sequence without any shifts, this is normaly solved by preprocess the data.
Which speed do you need ? (your def. of upperlimit.)
and what is the quality of your audio? (is it 2m VHF, AM or ?). (and what is the BW of each channel ? )
Although I didn't get very well your point, I will try to answer parts of it.
The average value of the signal is 0. If all bits are 0's or 1's, the stream would be a pure sinusoidal wave of frequency F . If the data bits alternate, the stream would be a raised cosine square wave of frequency F/2. If the bits are random, the stream would be a mix of the two. And since the edges follow the cosine function (upwards and downwards) the high harmonics of F are attenuated without the need of a low-pass filter.
As I mentioned earlier, the channel of interest is of the ordinary phones and mobiles. Therefore, the upper limit of its bandwidth is around 3,200 Hz.
But when Jim raised [#7] the subject of Channel bandwidth in RF communications, I just wondered if the Shannon capacity of a narrowband line, C=BW*log2(1+P_signal/P_noise) is also valid for RF transmissions, as it is the case for modems.
As I mentioned earlier, the channel of interest is of the ordinary phones and mobiles. Therefore, the upper limit of its bandwidth is around 3,200 Hz.
Mobiles today aren't don't use a simple analog channel for voice. They use a fairly heavily compressed digital channel. You likely can't use the same equations you would normally use to compute capacity based on the apparent passband.
However, I'm sure you could manage something like Bell 103. It might be only 30 characters per second, so if you've got 2000 characters to transfer, that will take a bit more than a minute to send the whole message. Perhaps a bit annoying but how often do your clients need to update the text on a sign? Bell 202 will quadruple that speed, so about 15 seconds for 2000 characters.
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
You can't use anything there have been through a cellphone, it don't send the "sound" but a model of it, and the tones are not send in correct phase, (the human ear don't care).
I have tried on a voice only satellite connection and could only get about 100 baud (200-300 would be possible ) and that was with something like DTMF but with more than 2 tones.
Thank you 'joeymorin' and 'sparrow2' for your interesting remark about the difference that exists between mobile and phone line concerning their voice channels.
I think I will have to test the mobile voice channel carefully before deciding on the optimum protocol (and its bit rate) by which a couple of Kbytes could be sent to update a sign message in a practical time.
But why don't you use a cellphone modem. It looks like you have all the normal nets 2G (and edge )3G (with the high speeds HSPA(+) ) and 4G(LTS).
You will have big problems using the voice faster than 200-300 BAUD, and the only way I can see that is something like 4 or even 5 DTMF tones for about 2 packets lengths (30ms) to make sure that they change.
But why don't you use a cellphone modem. It looks like you have all the normal nets 2G (and edge )3G (with the high speeds HSPA(+) ) and 4G(LTS).
You will have big problems using the voice faster than 200-300 BAUD, and the only way I can see that is something like 4 or even 5 DTMF tones for about 2 packets lengths (30ms) to make sure that they change.
Thank you again.
I am not familiar yet with cellphone modems in general.
I just had a wireless USB modem to connect to internet when the ADSL service (via phone line) was out of service for about a couple of years.
So I am not sure if certain models of such modem can connect directly two cellphones; the user's one and the sign's one.
If your signs are or will be equipped with a cellular link, then consider a simple GSM/GPRS module like the SIM800.
https://www.google.ca/search?q=sim800
Hopefully you can get such in your location...?
Would be fairly simple to set up a system whereby you update the sign with something as basic as a series of SMS text messages. Security and authentication might be a bit challenging, but perhaps that's not important?
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
If your customers have smart phones these days, then an App to enter the new message on the smart phone and use Bluetooth to link to the message board would be another, wireless option.
USB device is in AOA with USB host in later Android
Problem is Android may be a no-go in this case.
https://source.android.com/devices/accessories/custom#connecting-over-bluetooth
embedded.com
The basics of USB device development using the Android framework
Rajaram Regupathy
November 19, 2014
Edit: Android version
all new smart phones (need bluetooth 4.0+LE) will work fine, and I have used bluegiga (112 and the long range 121) and programmed them so the AVR just used the UART.
Thank you for your valuable suggestions and notes.
By the way, during the last 6 years, I used producing various inverter/charger sets.
Now, after returning the mains power (though about 15/24 only), I started producing various mains regulators instead (for the local market).
