Radio transmission question
max72
Posts: 1,155
I'm trying to use the quasar QMA RX4 and TX1 modules.
I'm doing a minimal set-up on a single demoboard.
I tested the serial protocol directly connecting (with a 1k resistor) the two pins of the propeller, and the simple program here attached works.
Nonetheless when I connect the radio modules I only get gibberish from the terminal.
Am I missing somethiing obvious? Are they too close?
Thanks in advance,
Massimo
I'm doing a minimal set-up on a single demoboard.
I tested the serial protocol directly connecting (with a 1k resistor) the two pins of the propeller, and the simple program here attached works.
Nonetheless when I connect the radio modules I only get gibberish from the terminal.
Am I missing somethiing obvious? Are they too close?
Thanks in advance,
Massimo
Comments
Is it possible that the 5v input into the 3.3v prop is messin something up?
(or if your running the RX4 at 3.3 that might explain your problems.)
I see you are running at 600 baud, so that doesn't seem to be the issue. Try other baud rates after you fix the 5v issue.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
I'll check for the Manchester code.
Thanks,
Massimo
Uhh, this dosen't mean the prop will be protected or operate properly.
You can try a voltage divider circuit to be sure its not the issue. A voltage divider is simple and easy to figure out. Just look up voltage divider calculator on the net, and it will tell ya what resistor values to use to get from 5v to 3.3.
But I do not know for sure if this is really your issue, but I do know that a series resistor will NOT protect a device from too high voltages. (the prop might be different, but generally most devices NEED the proper voltages)
I once had to control a 3.3v lcd with a 5v BS2. I did it by putting a voltage divider on all the lines between the lcd and BS2. It worked fine.
A 1K series resistor is quite adequate for handling a 5V logic signal. You don't need a voltage divider with the Propeller and with many current microcontrollers. Most CMOS logic devices have diodes connected between the I/O pins and the power rails so they will conduct any input voltage more than one diode drop above Vdd to the Vdd rail or any input voltage less than one diode drop below Vss to the Vss rail. On the Propeller, these diodes are rated at 500uA, but can transiently handle more, hence the 1K resistor ((5V - 0.3V) - (3.3V + 0.6V) = 0.8V = 1K x 800uA).
Oh. I have always followed the datasheets when it comes to chips.
My downfall in life is apparently following the rules, as I am beginning to realize this in more than one way.
I think Leon is right: as you can see in the typical application they use the RF600D/E chipset which, beside encrypting the data because of security reasons, uses manchester encoding to enforce reliability. Using manchester code the signal is selfclocking thus you have two transitions per each bit and you lose half of the RF bandwidth, but the communication is much more reliable.
Try a forum search for prop transmitting directly on ethernet (IIRC you will find Hippy's manchester encoding code)
As per wiring I also suggest to respect datasheet so for receiver (powered @5V)·R=(5v-3.9V)/500uA so 2K2/2K7 ohm.
For the transmitter you can power it with 3.3V and go directly without any resistor (or with 5V power using a open-collector/5Vpull-up scheme): depending on how it is internally build, sometimes having a higher Vpp incoming signal means a deeper modulation and so a higher S/N ratio
Because of the raw RX/TX data transceiver set you will need also to implement a software error correction/check in your communication protocol.
Dario
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates)
I'll check the forum for the encoding.
Ciao,
Massimo
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
You need to design a message-based protocol that begins with a sync header. I started a message with a series of $F0 bytes to allow the receiver to sync on the start bit. Then I sent a couple of fixed bytes to identify the message, followed by a byte indicating the message length (fixed-length messages obviate the length byte). Then I send the payload of one or more bytes, followed by a checksum.
The receiver would look for $F0 to start a message and then throw away all subsequent $F0 bytes. I would send several in case it didn't sync on the first one. Once something other than $F0 is received, the message is clocked in per the protocol. If the two fixed bytes are not what they're supposed to be, or the checksum doesn't add up, then the message is rejected. In the system I implemented, I also sent each message twice.
Using $FF for a sync byte may work well too. It seems the receiver might lock onto it sooner, but might not be as noise immune as $F0. I didn't really do a lot of analysis to determine an optimum sync byte.
Hope this gives you some ideas.
Ken
Post Edited (Ken Peterson) : 9/3/2009 2:36:33 PM GMT
I'm trying to do same approach. A couple of throw away bytes to wake up the receiver, a start character and then the data.
Did you use the manchester encoding?
Thanks for the help.
Massimo
I think the important thing about the sync byte is that it must only have one space / mark transition per byte so that there's no question which transition is a start bit. It can be any of the following: $FF, FE, FC, F8, F0, E0, C0, 80, 00. Experiment with the different values to see which one gives you the best results.
Regards,
Ken
Post Edited (Ken Peterson) : 9/3/2009 5:15:29 PM GMT
So I'm not so far away.
I'm probably missing something obvious...
Thanks again,
Massimo
Regards,
Ken
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
- Bjarne Stroustrup
cheers,
Massimo
The modules use ASK (Amplitude Shift Keying) to modulate the bits. This much is in the data sheet. This a fancy way of saying that it turns the carrier on and off based on what's on the state of the input pin. This means that if there's 0V on the input pin, there's no carrier being transmitted at all. Or perhaps a 1 turns off the carrier and a 0 turns it on. Can't remember for sure now. It's important to note that if your application is battery powered, a space should result in no carrier so adjust your polarity accordingly.
On the receiving end, the receiver outputs a 1 or 0 based on whether or not it detects the presence of the carrier. I believe it also has an automatic gain circuit in it, because while you're transmitting a series of bytes it comes through fairly clean, but soon after you stop transmitting it starts producing garbage on the output pin. I think that is because after some time without a carrier it bumps up the sensitivity and picks up a bunch of noise.
So your first few sync bytes give the receiver the opportunity to re-adjust the gain back to a level that gives you accurate data without all that background noise.
That's just my theory based on my oscilloscope observations and my attempts to explain them.
Regards,
Ken
Post Edited (Ken Peterson) : 9/3/2009 5:34:43 PM GMT
Do you think if the two modules are too close it will cause too much noise?
Massimo
Start with a simple test. Switch the input of the transmitter on and off and put your scope or voltmeter on the output of the receiver and see what happens. Then put a steady series of pulses into the transmitter and see if you get pulses on the output of the receiver.
Thanks again for the suggestions.
Massimo
then I find that it's more reliable to leave the radio transmitter on when it's not sending data
(assuming that otherwise it doesn't transmit RF for both bit states). Static almost never creates false data
in the receiver when it is within practical range of the transmitter if it's always transmitting.
That is the results I got when I made my own simple serial radio link using a CW or AM serial digital signal.
I'm not sure but it seems to me that any radio link which receives static then outputs bad data must be that primitive.
My link probably consisted of only a shortwave ISM-Frequency crystal, two common quad NAND logic chips mainly used
like op amps, a basic variable-coil-and-capacitor-tuner, and a few resistors, for all of the transmitter and the receiver.
CHEAP!
The project that I did with the TX1 and RX4 units (or something similar) was battery powered temperature monitor and I wanted to minimize power use. I cut power to the transmitter with a transistor controlled by the microcontroller, which would awaken from sleep periodically to send a packet of data and go back to sleep. In my case I was intentionally shutting off the transmitter so I had to deal with the static on the receiving end.
Ken
Post Edited (Ken Peterson) : 9/4/2009 11:20:03 AM GMT