Transmit and receive parallel data through radio link

[Anon_LG]

The information you want to transmit is digital, right? Seven digital signals?

Yes the signals are digital. The more bits of data I can transmit the better. At first I will be only transmitting a few but eventually I hope to get more information from sensors outside.

I am using a 433/315 Mhz transmitter and receiver, I believe the transmitter broadcasts both frequencies and the receiver has a removable core in the form of a screw within the inductor for tuning.

As Kris said, I do not want to use microcontrollers, I not only want a working transmitter/receiver pair I also want a project not just to connect 2 IC's together. Yes, brief disturbances should be alright.

Does anyone know whether the circuit I have designed would work?

 

[BobK]

Yes, it would not work.

Bob

 

[KrisBlueNZ]

Yep, that's a good one Bob. Looks like it will do what he wants. I think 6 bits is enough.

BTW do you know whether those "Princeton Technology" devices are actually microcontrollers in disguise? I don't recognise the pinout. I'm interested to know whether it's a custom device or just a customised standard device.

 

[Anon_LG]

So is what BobK saying the schematic drawn by me is not going to work. Could I have a bit more detail? Do I need a clock generator instead of an oscillator, if so can anyone tell me how to build a crystal oscillator clock generator without using capacitors, is this what I need: http://www.ti.com/lit/ds/scas868/scas868.pdf

Thanks

 

[BobK]

I did not analyze your schematic in detail, but I think this is what you are doing:

A signal called <scan> starts the scanning of the (up to 8) input channels and outputting their value to the data input of the transmitter.

The problem with this is that there is no way to sync the receiver to the transmitter. Say, for instance that the first 3 bits to be transmitted are zero. With your scheme, the first time the receiver sees anything, it is bit 4. How does the receiver know this?

And, as I said before, even if you solve the synchronization problem (it is not that difficult, really, you just need a start bit), noise is almost certainly going to be a problem. One false start bit, and all of your bits become randomly wrong.

As I said before, you need a protocol with redundancy. The very simplest is serial protocol which has a start bit and one or more stop bits and often parity.

Do some reading about communication protocols and you will understand that this is not trivial.

Edit: If I were you, I would get the transmitters and receivers that already have encoding and decoding built in. The sell on Ebay very cheap:

http://www.ebay.com/itm/433MHz-Ardu...pt=Vintage_Electronics_R2&hash=item3f1f4ddf4b

Bob

 

[Anon_LG]

The ripple counter, and the second ripple counter made of dual JK flip flops on each end both start on 0000 and so the default channel can broadcast when not cycling through the other channels. The start bit (scan?) feeds into the encoder on the default channel, the output of the corresponding decoder on the default channel on the receiving end outputs to the "set" on the bistable. The bistable one both ends then start at the same time (almost exactly) triggering the ripple counter (by use of the Q output feeding into an AND gate) to cycle through the channels twice (notice the control bits are only connected up to the 3 l.s.b's not all 4) each then U7 and U6 at both end each reach 1111 so triggering the U1 AND gate to reset the bistable, stopping the cycle. Is there a part in this sequence which would not happen as I described? The 3 bits on each channel can read each other without any communication except the one way transmission, each input/output is paired on each encoder/decoder pair manually before they are put into use in the circuit. The circuits should be synced so long as the clock generators are accurate enough.

 

[BobK]

So the transmitter is constantly transmitting bit 0 until scan is started, right?

So, suppose bit's 1, 2 and 3 have the same value as bit 0. How does the receiver know that the scan has started, it sees no change until bit 4?

Bob

 

[Anon_LG]

Yes, channel 0 is the default channel. I could plug one of those encoders into the transmitter and one decoder into the receiver, it would do exactly the same thing as the circuit I have designed when not scanning, the "scan?" input requires a pulse to begin a scan, a single scan is a double run through of the other main channels.

Do you you mean the bits outputting from the ripple counter constructed from the JK's? in which case bit 4 is used to stop the scan, I did not see another simple solution to stopping scan, having only a 3 bit ripple counter with a 3 input AND gate would stop the scan immediately and having a 3 input NOR gate with a 3 bit ripple counter would mean channel 7 would be unusable. When the bistable is in reset mode all 4 are 0 so this leaves it possible for the bistable to be set, when the channels have been cycled through twice all 4 are 1 and so the 4 input AND gate is activated stopping the scan, I only need the scans to run periodically, not continuously and so the outputs will be fed into bistables to store the data.

Thankyou for all your replies, I appreciate the help a lot.

 

[BobK]

I think you and I are not speaking a different language (though both look suspiciously like English.)

No, I mean the bits output from the encoder. Your circuit will sequentially link each input bit to the output bit for one clock cycle.

I.e. first clock cycle: bit 0 input of encoder appear on the output and this goes to the transmitter data bit.
second clock cycle: bit 1 input of the encoder appear on the output and goes to the transmitter data bit.

The receiver will see a zero if the bit on the transmitter data is 0 and a 1 if the bit on the transmitter is 1.

So, assume the eight bits you want to transfer are:

0, 0, 0, 0, 1, 1, 1, 1

What does the receiver see?

Bit 0, which is zero is being transmitted between scans. So the receiver is sitting there seeing a zero.

You start your scan.

First clock cycle, receiver sees 0, nothing has changed.
Second clock cycle, receiver sees 0, nothing has changed.
Third clock cycle, receiver sees 0, nothing has changed.
Fourth clock cycle, receiver sees 0, nothing has changed.
Fifth clock cycle, receiver sees 1.

How does the receiver know this is bit 5?

Do you see the problem? If not, can you describe to me exactly what you expect the receiver to see, and how it mirrors the bits being transmitted?

Bob

 

[BobK]

The solution to this is called a start bit. When not scanning, you should always transmit 0 (or 1, which is actually what is sued for RS-232.)

Then then it is time to start transmitting data, you transmit the opposite for 1 cycle. The awakens the receiver and readies it to receiver the data. Finally, you send the data bits at a know rate that is matched by the receiver.

The receiver, seeing the start bit, will then start sampling the data starting at 1 1/2 clock cycles after it sees the start bit. This puts it in the middle of the next bit, which is where you want it to be so that the bit is stable and not changing. It then shifts in 8 (or some other agreed upon number) of bits at the middle of each subsequent clock cycle.

This is the simplest possible protocol for transmitting serial data.

Bob

 

[KrisBlueNZ]

In case you're still interested in a discrete solution, here's mine.



It's designed around 74HC devices. Three ICs in the transmitter; four in the receiver.

I don't have time to describe it in detail now and I haven't finished the timing diagram either. I'm going to be busy over the next few days so there will be a delay.

The circuit is more of a thought exercise than a practical recommendation. It requires a fairly reliable transmission medium; disturbances could confuse the receiver but it will recover quickly when the received data becomes correct again.

In practice something like this would be done with a simple message-based protocol with at least a checksum, if not a CRC, and the receiver would have a timeout so loss of communication could be flagged. Any small microcontroller would be suitable for this, and this would drastically simplify the hardware at both ends.

 

[Anon_LG]

In reply to BobK
OK, I think I had better go with the last option:



I am going to be decreasing the frequency of the oscillator to 32 Khz, after the ripple counter used as a divider the frequency will only be 4 Khz and so the multiplexer cycles between the channels slow enough that all the outputs from the encoder on that channel are broadcast in that time. Are you assuming the encoders and decoders are using the crystal clock? there are no input pins on either for a clock.

The receiver has the clock pulses outputting to the ripple counter in sync, so e.g. channel 5 will be activated at the same time either end.

 

[Anon_LG]

In reply to KrisBlueNZ

Thankyou for your reply KrisBlueNZ, I am absolutely and only interested in a discrete solution as I have begun to learn the wrong programming language: C++ when I should have started to learn C. Luckily I have found a C++ IDE for ARM M based micro-controllers, however I do not have access to these at the moment.

 

[BobK]

The receiver has the clock pulses outputting to the ripple counter in sync, so e.g. channel 5 will be activated at the same time either end.

I don't know why you think the clocks at the transmitter and receiver would be in sync. Please explain. The protocol I describe is called asynchronous serial for a reason.

I cannot follow at all the table you have posted. Please just tell me what you would expect the xmit data to be starting from 10 clocks before you start scan, given that the input data is 00001111.


Bob

 

[BobK]

In reply to KrisBlueNZ

Thankyou for your reply KrisBlueNZ, I am absolutely and only interested in a discrete solution as I have begun to learn the wrong programming language: C++ when I should have started to learn C. Luckily I have found a C++ IDE for ARM M based micro-controllers, however I do not have access to these at the moment.

If you know C++ you also know C. C is a subset, you just have to know which parts of C++ are not included.

Bob

 

[Anon_LG]

The clock pulses will be in sync because the scan pulse is sent from the transmitter to the receiver activating exactly the same circuitry at almost exactly the same time, each time before this happens the divider and counter are reset at both ends. The "scan?" as you can see is attached to the input of an encoder on the first channel, of which the decoder on the other end, both the original signal and the signal on the receiving end activate the bistable. the clocks do not need to be in perfect sync as it takes 8 pulses from the crystal to activate 1 on the ripple counter being used as a divider.

 

[BobK]

Okay, that is not what is shown on your diagram.

So the scan signal acts as a start bit.

That could possibly work, but the receiver should wait 1/2 a clock before latching the first data bit.

Bob

 

[Anon_LG]

I need to put this circuit in a thread in the appropriate section with an appropriate title. The thread is not resolved, I would prefer it to be resolved in the new thread.

 

[KrisBlueNZ]

I've renamed the thread. The original title was not very useful. Is that what you want? If not, can you be more specific?

 

[BobK]

Kris's circuit looked pretty complete to me. I eagerly await his explanation.

Bob