rf rx/tx noob
curseofthedonkey
Posts: 11
Hello,
This is my first post, but have been working with the prop for about six months now. I have searched the forum and found some discussion on radio transmission. Prior to reading these posts I was under the impression it would be rather easy, as the modules are purported to 'set and forget'. 'Just like sending serial data'.
So far, after numerous attempts I have not been able to display a single digit on the pst, and this is a last resort.
I'm currently using these:
http://www.sparkfun.com/commerce/product_info.php?products_id=8946
http://www.sparkfun.com/commerce/product_info.php?products_id=8950
I don't want to waste anyone's time with a lengthy instructional on how to set everything up, I'd just like to know if I can use an obj like simple serial to send and receive without reworking the packets, parity, inversion or checksum.
The goal is to use conditional statements to simply move a servo.
I would appreciate ANY help.
This is my first post, but have been working with the prop for about six months now. I have searched the forum and found some discussion on radio transmission. Prior to reading these posts I was under the impression it would be rather easy, as the modules are purported to 'set and forget'. 'Just like sending serial data'.
So far, after numerous attempts I have not been able to display a single digit on the pst, and this is a last resort.
I'm currently using these:
http://www.sparkfun.com/commerce/product_info.php?products_id=8946
http://www.sparkfun.com/commerce/product_info.php?products_id=8950
I don't want to waste anyone's time with a lengthy instructional on how to set everything up, I'd just like to know if I can use an obj like simple serial to send and receive without reworking the packets, parity, inversion or checksum.
The goal is to use conditional statements to simply move a servo.
I would appreciate ANY help.
Comments
1) Don't try to communicate faster than 2400 Baud. These devices are not designed for it.
2) If you've got an RF noisy environment, they may not work, but you should still see noisy data.
3) If you want reliable transmission, you need at least error checking. That can be done lots of ways. The easiest is to send the same data 2 or 3 times and reject the whole thing if any copies don't match. You can also use checksums or CRCs.
It's impossible to give you specific advice without schematics and source code listings. Use the Attachment Manager to attach files to a message. You get the Attachment Manager by clicking on the Post Reply button.
I have the modules hooked up the breadboard on the ppdb in accordance to their data sheets. The rx pin is 2 and the tx pin is 1. I assumed I would at least see gibberish if I had the door open on the rx.
The getc was a shot in the dark.
con _clkmode = xtal1 + pll16x ' 5 MHz crystal  80 MHz system clock _xinfreq = 5_000_000 OBJ uart : "FullDuplexSerial" pub rftest startx(2,1,2400) repeat getc waitcnt(clkfreq +cnt) PUB startx(rxpin, txpin, baud) : okay '' Starts uart object (at baud specified) in a cog '' -- uses specified rx and tx pins '' -- returns false if no cog available okay := uart.start(rxpin, txpin, 0, baud) PUB getc : rxbyte '' Get a character '' -- will block until something in uart buffer rxbyte := uart.rxIt's generally a bad idea to quote a datasheet or an example as how you've hooked things up. Perhaps you made a mistake. Perhaps there's an error in the datasheet diagram or example documentation. The number of times people have hooked things up wrong is legion. There's nothing wrong with mentioning what you used for a reference, but describe what you actually have.
For prototyping reasons, I have a 434MHz transmitter and a receiver hooked up to the same breadboard, same prop.
What I'm trying to do is send a signal generated by the prop to itself. Pin 1=out to tx, Pin 2=in from receiver.
The receiver has eight pins:
ANT
GND
GND (redundant)
VCC
VCC(redundant)
DATA
DATA (redundant)
GND
The transmitter, four:
ANT
VCC
DATA
GND
I will attach a pic so you have an idea of what's going on, and I apologize if it's not clear. Green are data leads and jumpers, red VCC, black ground. I'm running them both +5v. Neither ANT is connected. The redundant lines are jumpered.
UPDATE:
I have reworked all the wiring, multiple times. I added antennas and made the redundant lines their own lines (except for DATA, which I tried all combinations), even moved the entire module, used different pins on the prop...Still, not even a trace of noise. At this point I was just working on the receiver. I'll worry about sending data when I can hear it.
Post Edited (curseofthedonkey) : 3/12/2010 9:36:33 PM GMT
First, get it working with a wired connection. If it won't work with wires, it won't work with RF
Start bit, stop bit, parity don't matter. Everyone uses the same standard on those.
Polarity does matter. There are three standards
1) RS232. Resting voltage is minus 12V. Data is plus 12V
2) TTL. Resting voltage is 5V. Data is 0V
3) Propeller TTL. Resting voltage is 3V3. Data is 0V
There are fudges to simplify things but it helps to know what the fudge is. RS232 does not allow voltages between minus 3V and plus 3V. So a voltage of 0V on an RS232 cable is 'invalid'. But most receivers do allow 0V and it counts the same as minus 12V. So, if you put 0V on an RS232 line and count that as resting, and put 3V3 and count that as data, then the 3.3V is 0.3V greater than the threshold for a data pulse. The fudge is you need to reverse the polarity in software if you do this.
I presume you have a terminal program running on a PC to receive the data? I don't have the exact code for the serial port driver (I use a 4 port in one cog one) but there will be a setting that reverses the polarity. You can check it with a voltmeter and when no data is going through, it should be 0V. Put a 1k resister in series with that line for protection because...
This isn't really a fudge I'd recommend though, and I've gone for proper RS232 signals on everthing. Even though this adds more chips (mainly max232 chips), RS232 has the nice ability to be shorted, you can join +12V to -12V lines, you can join transmitters to transmitters, you can swap lines in any random combination you like, even muddling the ground line with a transmitter line, and nothing will happen. But try doing that to a propeller and there is a very real chance of putting minus 12V on a prop pin and destroying the chip.
So - if you set up the polarity right, and match the baud rates hopefully you can get a character to appear on a terminal screen.
Only then is it time to change to wireless. I need to check the volts on those modules as I suspect they run on 5V, not 3V. So the Rx might need a 1k to the propeller, and I'm not 100% if the Tx will recognise 3v3 as high but it probably will.
Do you have a CRO? if so, it will help a lot to see the signals going through. If not, an alternative is a 1k resistor from the Rx to a headphone earpiece and you should hear white noise on the Rx most of the time, and a tone when the data goes through. It is this white noise that is the problem. It is supposed to be the leftover noise from the big bang (I think some Nobel prizes were won for working that out) and the serial in code cannot distinguish between white noise and data. Over on the picaxe forum this has been actively discussed for four years now. Solutions include sending about ten ascii "U" characters (binary 01010101) to bias the midpoint and then a preamble ABC and then the data. Not easy, because the Rx serial code needs to be constantly checking to see if "ABC" has arrived (most of the time it is random data), and so you need to be constantly discarding that random data.
Even though these "raw RF" modules work, they are not as sensitive as you would like, and there are ones that are a bit more expensive but are true "set and forget" modules. They go by various names - RF modem, RF Transceiver and there are many brands around. I use these ones www.yishi.net.cn/rf/ProductShow.asp?ID=99 because they are the only ones with a big enough buffer for file transfers using xmodem.
I think sparkfun sell transceievers too. They cost more, but they are a true drop in replacement for an RS232 wire, as all that noise filtering above is being done by a microprocessor on board. Also, they tend to up to 1000 times more sensitive than "raw RF" modules. And for some strange reason, no matter what the brand, they all come with that little red plastic thingy over the antenna connector.
Having said all that, I'm sure there is a simple 'walk through' for these raw RF modules. Something that explains it all on one page like this www.picaxe.orconhosting.net.nz/all3.jpg (re the code, 85 is ascii 'U'). The equivalent setup using transceiver modules is www.picaxe.orconhosting.net.nz/txrxconf.jpg
I'm building hybrid wireless networks using propeller and picaxe at the moment. Each platform has its strengths - the propeller has heaps of code space and can handle things like "store and forward" for data packets. Picaxe is dirt cheap and the code is extremely simple and they are perfect for things like translating an analog voltage into a serial wireless packet for only a few dollars.
Don't despair. This is all doable and probably with the hardware you have. First step would be to see all the code you have and a photo of all the hardware.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Thank you for the excellent information. I'll need a little time to form an appropriate response, however will try as many of the methods you outline prior to doing so and will let you know the result.
Here are a few notes:
-I do not have a CRO or even a digital one. I find myself needing one more every day.
-I'm using the PST and simple duplex to try and get something (anything) to show up on the screen as received. I tried transmitting the string "hello" via the wired connection with the same propeller chip (pins 30 and 31) on repeat at 1 second intervals. Then I had the wireless modules hooked up and simply tried using the data pins from the transmitter and receiver(pins 1 and 2).
-The setting most frequently used (I'm gathering) is the inverted receive signal or "0" in pst.start(31,30,0,2400)
Baby steps. I will make it to my workroom, hopefully, sometime this weekend and give you a more thorough outline of what's going on. I know there is very little useful information here however I wanted to thank you for the response and I have a few more leads to go on.
I'd need to know more about your setup. I've never tried this before, but I would guess that if you put a wireless Rx output into the correct pin on a serial port going to a PC (measure first, because it will be either pin 2 or 3, and if you put it on the one with -12V on it you zap the receiver), but pick the one that has no volts on it, and send data to a terminal. I very much suspect you will get random characters on the terminal coming through continuously. If not, something is wrong with the Rx (zapped already?) or the signal levels (0-5V should be enough to trigger RS232). Raw RF modules can be used for propeller to propeller comms but you need more signal processing. There is even a brilliant piece of code in the obex that does a software modem with sinewave matching, and that would be perfect for using CB radios to transmit data. But it won't work for the Raw RF modules because if you put a sine wave into the Tx you get a square wave out the Rx (experiments like this are where a CRO is handy).
If you are building radio comms, you need some way of seeing the data. So somewhere along the line the terminal is very handy. I've even used picaxes as "raw RF to serial" translaters but it is a roundabout solution. Of course a propeller could also do that, but how do you test it??
Without a CRO, do you have any sort of audio amplifier? You could always connect the Rx output to the input of an audio amp and listen to what is happening. Perhaps use a 10k pot as a volume control, as most audio amps use 1V peak to peak and the Rx will be outputting 5V so it needs dividing by 5 at the least and problably more. I had an old crystal earpiece (these are high impedence so don't load the circuit) and connected that via a 1k resistor to the Rx output and that worked just fine for debugging.
Having said all that, the Transceiver modules for $25 each are a lot easier as data in = data out. eg www.microzed.com.au/Rf433.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 3/14/2010 12:54:11 AM GMT
I actually had a reply ready to go until I started messing around a little more. That headphone idea was great. I verified that I am indeed transmitting AND receiving something at the intervals I specified (1 second repeat). I have a parallel data line that I put a 1k resistor prior to the headphone connection on my ppdb. I can actually hear it, which is nice.
Here is the objective: I have two raw rf modules that I want to talk together on the same breadboard with the wiring hooked up to the same power source, the same prop chip, different pins for rx and tx than what's stated to have the prop normally communicate serially.
What I'm trying to do is literally send a byte or small piece of info I can use in a conditional statement later. I expected something like the following code to work:
con _clkmode = xtal1 + pll16x ' 5 MHz crystal  80 MHz system clock _xinfreq = 5_000_000 OBJ uart : "FullDuplexSerial" pub rftest uart.start(23,1,0,2400) 'rx pin=23, tx pin=1, mode bit 0 = invert rx, 2400 baud repeat uart.str(string("Hello")) 'tx "Hello" every second waitcnt(clkfreq + cnt)It, of course, doesn't. The headphones indicate I am indeed receiving something however I cannot get anything to display.
The following works, but only because I changed the pins for tx and rx to their 'in chip' allocations and am bypassing the rf modules (work as expected):
con _clkmode = xtal1 + pll16x ' 5 MHz crystal  80 MHz system clock _xinfreq = 5_000_000 OBJ uart : "FullDuplexSerial" pub rftest uart.start(31,30,0,2400) 'rx pin=31, tx pin=30, mode bit 0 = invert rx, 2400 baud repeat uart.str(string("Hello")) 'send "Hello" and repeat every 1 second. waitcnt(clkfreq +cnt)At this point, I would be happy with just noise on the receiver showing up in the terminal. I do not believe I am able to switch those pins that easily, and if so, something is not right.
I initially thought this would be the easy part and writing the verification and error catching code would be the more involved process. The point of this setup was to provide a prototyping area for the verification code. I had my doubts initially about how I wired everything, however just listening to the receiver, it's picking something up 'tap...tap...tap...tap'.
I will most definitely go with something easier later, but at this point I must know what's going on for my own understanding.