Positron BASIC Community

Hi everyone,

I'm working on a project where I need to transmit a few bytes (ten at most) and receive a confirmation. So far, so good.

The challenge is that I only have access to a bidirectional intercom audio channel. I'm currently at a crossroads: should I use a dedicated modem chip from the 90s (like the CMX469A) to handle the data, or can I rely solely on a microcontroller to modulate and demodulate the bits as audio signals?

While FSK transmission is straightforward, I'm unsure about the best way to handle reception using only a MCU. I'm aiming for at least 300/600 bps, or ideally 1200/2400 bps.

Has anyone experimented with this type of transmission using a PIC?

Are you starting with an audio signal that you want to digitize and then transmit at a standard bit rate such as 9600 or 19200 bps?  What is the bandwidth of the audio signal?  And are you transmitting in real time or is it a batch mode transmission?

These are commands for managing Pelco cameras.
The standard Pelco communication speed is 2400 bps, but I can transmit much slower, store the bytes, and send them to the camera at the correct bitrate.
As previously mentioned, transmitting at 300 bps is fine.

The audio channel - is it analog or digital? An old modem might not work if it is a digital audio stream with compression.

You can look at the old HAM radio Packet modems, they use the "TCM 3105", "XR2206", "XR2211" chips . Obsolete but you got the idea.

Trastikata
The audio input is analog, the transmission is digital. If you have had experience with old modem chips not working, I'd leave this route and try only with Pics.

Gods
Yes, I have see old HAM radio Packet modems


I can try to decode with the PulseIn function and in the meantime I try to understand the best way forward

If the transmission path is digital, it is most likely lossy compressed audio and optimized for human speech (mid tones), so a classic modem probably won't work.

You can try the much slower DTMF coding if it is only for few bytes, but still might have problems since frequency is probably cut in the audio compression.

Only I can say is best to test the transmission line for frequency response, before you decide on hardware. Generate some sound with different frequencies. Then play it from the one side and directly record the received sound on the other, then compare the two recordings using some audio software to see the received vs sent histogram. But run the same test few times just to be sure.

right, that's definitely the first thing I'll do

Perhaps not the most elegant solution but there is plenty of PIC code available to code and decode morse.  If the data is too slow to be used at receive end just buffer the received code.

What is the cable medium/length (coax, twisted pair)? Is this a point-to-point or a point-to-multipoint application?

See_Mos
The transmission speed can't be too low; for example, if I want to correct the camera's aperture, I need to see the image change within 1 or 2 seconds at most.

JonW
The communication is point-to-point; the signal travels via VPN over the internet.

Ah, so your transmission is transported directly to the camera, but you want a system to coexist in the audio channel that can be encoded/decoded and also remain in the BW of the digitised signal.  I have used diseqc in the past, its an ook modulated tone at a 1/3 bit time, it's primarily at 22kHz and is modulated at a much lower data rate, but it can be at any frequency/rate that you choose.  It could be a high audio frequency just outside the band; a simple diplexer could be used to seperate and combine the tone and audi stream, this way you don't need a wide bandwidth for FSK and no fancy modem ICs, etc.  Use PWM or NCO to generate the tone easily.  To decode the tone/data, I would use a low-pass/band-pass or high-pass diplexer and feed the data into an amplifier, then simply peak-detect and shape ready for the MCU. 4 transistors and a few R & C can do this, and then you can run at a much lower modulation rate, with the peak detectors demodulating the bits for you and keeping the code simple.  The metrics of Disecq can be easily altered to suit the coexisting data application. The beauty is that you can use the same frequency and it will be well controlled so can filter it easily simplifying the electronics and make the whole system very low-cost, and you don't need fancy ICs.

Am I correct in thinking that the audio channel is digitised and pushed over the internet and vice versa, if so, then this should work.

Thanks for the idea, JonW.


A clarification: I have this interface that transmits video and audio over the internet, but I can't connect directly to the internet. It's a closed system and uses four SIM cards for transmission.
If I could send data directly to the internet, it would have been very simple.

You have access to the data at each end, regardless of the medium. The single OOK tone should work as long as it's at the band edge.  Most digital modulated systems are quite tolerant of low-level tones, if it's at the edge and within the Nyquist BW of the digital side, it should be easy to diplex.