Without going into too many details about the wireless side of things, I want to obtain the highest possible data rate using audio modulation techniques. This is pretty straight forward using FSK or Manchester encoding over a single audio channel (of say, 50Hz-10Khz bandwidth) but how best to make use of a ‘stereo’ configuration? You could easily get twice the data rate by using independent microcontrollers and modems on each channel but could there be more direct way to use stereo to obtain higher data rates? Please let me know if you have any ideas.
High data rates via stereo?
- Thread starter xstamp
- Start date
BeanieBots
Moderator
I don't think so. Data rate is data rate. As soon as you start adding channels the data rate drops simply because you need to add extra data to the stream to identify which channel it belongs to.
The only way to increase the rate above what the hardware can do is to use a second set of hardware.
The only way to increase the rate above what the hardware can do is to use a second set of hardware.
Jeremy Leach
Senior Member
Are you saying you've got twice the hardware - ie two wires instead of one? I'd guess this is a very tricky area.
Perhaps data compression is an idea to increase you're transmission throughput - but the processor time to encode and decode might be counter-productive overall !
Perhaps data compression is an idea to increase you're transmission throughput - but the processor time to encode and decode might be counter-productive overall !
If the bandwidth of the two channels overlapped (eg.50Hz-10kHz and 9kHz-19KHz) I think it would be possible to simply send the same modem signal to both channels and sum their outputs at the receiver end. But two stereo channels should of course have identical bandwidth characteristics.
If we take the multiple hardware route, maybe it would be possible to send a common serial data packet (at say, 4.8kbps) to two PICAXE chips that each simultaneously re-transmitted half the packet at 2.4kbps via their own encoders. At the receiver end, two more decoders and PICAXE chips would combine the two halves of the packet and present it to a PC as a single 4.8kbps data stream.
Although four PICAXE chips would be required, they could be low cost 8-pin versions and the software MAY not be too complex. This could be a relatively cheap approach but I still have a nagging feeling that there may be a more elegant solution.
If we take the multiple hardware route, maybe it would be possible to send a common serial data packet (at say, 4.8kbps) to two PICAXE chips that each simultaneously re-transmitted half the packet at 2.4kbps via their own encoders. At the receiver end, two more decoders and PICAXE chips would combine the two halves of the packet and present it to a PC as a single 4.8kbps data stream.
Although four PICAXE chips would be required, they could be low cost 8-pin versions and the software MAY not be too complex. This could be a relatively cheap approach but I still have a nagging feeling that there may be a more elegant solution.
Jeremy Leach
Senior Member
I'm confused over this. A datastream will have a typical frequency spectrum. So what are the channels? Are they the radio side of things?
I can see that a signal's frequency spectrum can (in theory)be chopped in half by two separate bandpass filters whose band's touch, then the resulting two signals recombined. But this is theory and I doubt it would work well in practice (phase issues, sharpness of the band edges etc)
I can also see that if you have two independant signal paths (one for each L and R of the stereo) you could have dual hardware:
IF the data you want to transmit is in a common memory store then you could have a PICAXE for each L&R signal and they would each loop around fetching data, transmitting data. At the receiving end you could have receiving PICAXEs, and the PC itself could strip off the received data at twice the data rate of any single PICAXE.
Synchronisation of the L and R signals could be an issue, and making the data store accessible to two PICAXEs.
Edited by - Jeremy Leach on 08/11/2006 17:17:27
I can see that a signal's frequency spectrum can (in theory)be chopped in half by two separate bandpass filters whose band's touch, then the resulting two signals recombined. But this is theory and I doubt it would work well in practice (phase issues, sharpness of the band edges etc)
I can also see that if you have two independant signal paths (one for each L and R of the stereo) you could have dual hardware:
IF the data you want to transmit is in a common memory store then you could have a PICAXE for each L&R signal and they would each loop around fetching data, transmitting data. At the receiving end you could have receiving PICAXEs, and the PC itself could strip off the received data at twice the data rate of any single PICAXE.
Synchronisation of the L and R signals could be an issue, and making the data store accessible to two PICAXEs.
Edited by - Jeremy Leach on 08/11/2006 17:17:27
Jeremy ....Your multiple PICAXE approach is pretty much along the lines that I was thinking but could there be a simpler way? For example, in the days of digital cassette storage one track was used for storing ‘1’ and the other for ‘0’. With a pulse arriving at the same time from both tracks being used for synchronisation. I know this is not directly relevant to splitting data between two audio channels, to increase the rate, but it might help to start thinking along another approach route.
Jeremy Leach
Senior Member
Hmmm ... one idea: I think one of the transmitter PICAXEs could be a master and the other a slave. The Master would generate a regular interrupt to the slave at a point in it's read/transmit cycle - and the interrupt generated in the slave would ensure that the two were synchronised.
But it's the shared data store I'm not sure about - and what sort of data you'd want to put there in the first place - have you got any particular idea of data?
Also although I say the PC can strip off the received data, there's quite a few details to fill in, with possibly some register ICs etc!
But it's the shared data store I'm not sure about - and what sort of data you'd want to put there in the first place - have you got any particular idea of data?
Also although I say the PC can strip off the received data, there's quite a few details to fill in, with possibly some register ICs etc!
May thanks for your comments.
The data would be from ADC channels. For example, a 08M could scan three analog signals and send the data at 2.4kbpsover a stereo channel via a FSK modulator. Whilst a second 08M would also do this simultaneously over the other stereo channel. As you suggest, some form of synchronisation would be required between the two transmitting PICAXE chips. In order to help merge the six channels of data into a single 4.8kbps stream at the PC end of the telemetry link.
This is probably the best development route to follow and I’ll post any useful techniques that MAY result from the project.
The data would be from ADC channels. For example, a 08M could scan three analog signals and send the data at 2.4kbpsover a stereo channel via a FSK modulator. Whilst a second 08M would also do this simultaneously over the other stereo channel. As you suggest, some form of synchronisation would be required between the two transmitting PICAXE chips. In order to help merge the six channels of data into a single 4.8kbps stream at the PC end of the telemetry link.
This is probably the best development route to follow and I’ll post any useful techniques that MAY result from the project.
Jeremy Leach
Senior Member
I expect there are lots of possibilities. I guess with FSK you could have a modulator per transmitting PICAXE and arrange the frequencies so that the two modulated signals could be combined on one wire/link - then have two bandpass filters at the receiving end separating the signals out again before demodulation! Could all get quite complicated though !
BeanieBots
Moderator
I've been looking at some kit that uses no less than 16 phone lines to transmit real time high quality video data so I guess the principle exists and is possible to multiplex a data stream over several channels in real time. However, I would be very surprised if a PICAXE could process the data (including multi/de-multiplex overhead) at a rate higher than that which would be possible with a single channel. This being because the bandwidth of the PICAXE itself is nto much better than the transmission bandwidth. If the transmission bandwidth was a lot worse then it might be more feasable.
An interesting project none the less and please come back if you have any success with it. Good luck.
An interesting project none the less and please come back if you have any success with it. Good luck.