raw rf, hope lost?

curseofthedonkey · 2010-03-19 19:08

I've been messing around with this almost every spare moment I could manage to get to my workroom.
Objective: Transmit a decimal. That's it, just one stinkin' number consistently. I'm getting noise, and the value of x IS changing with that noise. Should I just pack up these cheapo raw RF modules and go ahead with XBee or can I confidently say I've done everything I can? I posted before, and Dr_Acula and Mike Green were very helpful with some great tips (feel free to give more

) . I've simplified the code and started using the bs2 library to TRY to get this working. No luck. The headphones are a great help in "audio debugging".
I've attached a terrible drawing of the schematic, but I'm using two pins from the same prop on the same breadboard.
Here's the code. Notes below.

CON

_clkmode = xtal1 + pll16x                        ' 5 MHz crystal &#61627; 80 MHz system clock
_xinfreq = 5_000_000

VAR

long stack[noparse][[/noparse]20]
long stack2[noparse][[/noparse]20]
byte x

OBJ

bs2 : "BS2_Functions"
debug: "FullDuplexSerial"


PUB transmit
dira~~
outa:=1



cognew(receive, @stack)                              'start receiving
cognew(print, @stack2)                               'start printing

debug.start(31,30, 0, 2400)                         'start full duplex serial

repeat
  bs2.SEROUT_DEC(1, 24, 2400, BS2#Inv, 8)          ' send dec(24) on pin @2400Baud, mode 0, 8 bits
              
  
  
PUB receive



repeat
   x:= bs2.SERIN_DEC(2, 2400, BS2#NInv, 8)          'receive char "A" on pin, mode 1
   'waitcnt(clkfreq + cnt)                          'uncommenting this line allows a tone to come through, yet displays nothing.

PUB print

repeat
  debug.dec(x)                                       'print 
 waitcnt(clkfreq +cnt)

If I change the DEC value (it's 24 here) I get different reactions on the Parallax Serial Terminal. All nonsense, but different characters on the terminal, sometimes tones, and sometimes nothing at all. I found that strange. Antennas help with the static, but I get the same results as if I weren't using them.

Anyway, I have every thing running separately to keep it as simple as possible. If anyone has any insight to this it would be very helpful. If these RF modules just aren't doing what they're supposed to do, that would be nice to know too.

Toby Seckshund · 2010-03-19 19:28

I wonder if the two modules are just too close together, and the Tx is blowing the socks off the Rx.

Could you extend the wiring to one and get a few yards between them.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point

Post Edited (Toby Seckshund) : 3/19/2010 7:39:30 PM GMT

Leon · 2010-03-19 19:36

You need something like Manchester code to transmit data between two of those modules.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM

Toby Seckshund · 2010-03-19 19:41

I have two of those cheap modules and they quote 2400 Baud maximum, and I bet that is as Leon says, using NRZ such as Manchester coding. Just for a test drop the rate down to 300 or so and find out if and when the data becomes solid.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point

curseofthedonkey · 2010-03-19 20:03

Something is odd. The value transmitted (was 24 @2400baud) seems to create no apparent display of nonsense static characters at 300baud. I messed around with a few numbers and 80,000 doesn't display, but four digit numbers appear to create the same effect of noise on the terminal at 300 as 24 did at 2800.
Thanks for the tips. It's research time. I'll report back after a few more configurations.

Toby Seckshund · 2010-03-19 20:59

I just drew out the highs and lows of 24(dec)

the component bits of that number are 16 + 8 which are next to each other. So you have a simple waveform of low, low, low, high, high, low, low, low (or it's inverse) MSB first.

This presents a low bandwidth to be transmitted/received. 170(dec) would give high, low, high, low .....and present a worse case.

Do you have access to a 'scope ?

EDIT

Also, the Prop might be chucking out all sorts of interferance, if you were to extend the wiring to one of the modules then I would get the Rx away from the Tx and the Prop. The cheaper ones are regenerative and open as a barn door.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point

Post Edited (Toby Seckshund) : 3/19/2010 9:10:18 PM GMT

curseofthedonkey · 2010-03-19 21:22

Sadly, no scope. After all of this, I'll be placing an order for one soon.
It may be a couple days before I get the opportunity, but at first chance I'm going to try getting the receiver away from the whole board. I'll repost then.
In the mean time I will be reading on up Manchester code and decoding. There has already been a few discussions about it.
About 6 hours ago I was just happy to see something showing up on the terminal...on to the next.
Thanks again. I'll be sure to provide an update as soon as I have one.

Toby Seckshund · 2010-03-19 21:34

Always try to scounge any test equipment. When something better comes along upgrade and pass on the old stuff to somebody else.

Good luck

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point

Dr_Acula · 2010-03-19 23:18

I've built a lot of RF things with picaxes and raw RF modules. I gave up in the end with raw RF - the ranges are poor, the sensitivities of the Rx units are not good, and you need all sorts of filtering. I'm using transceiver modules and having no problems at all sending big files between propellers - including .jpg pictures. They cost more - $25 or so, but they work so much better as they are true replacements for wires. I've just picked up a couple from Sure electronics for $30 a pair so I'll see how they compare with the ones I have.

First - on that schematic, I see 5V on the Rx and that is going directly into the prop. ? needs a 1k series there.

Also - I'm presuming the Tx is ok with 3V3 as high. It probably is, but you can't really be sure unless you send a tone into the Tx and see a nice squarewave on a scope on the Rx. Speaking of scopes, they are very handy, but if you spent the same money on transceiver modules you could buy quite a few and you wouldn't need the scope!

What is the antenna length?

And yes, any closer than 1 metre and these modules interfere.

Any chance of a photo of the setup - the schematic shows the important bits, but it is sometimes the unexciting bits like bypass capacitors that make the difference between failure and success.

I have to confess, despite being able to transfer files between propellers I still don't understand Spin. When you say

repeat
  bs2.SEROUT_DEC(1, 24, 2400, BS2#Inv, 8)          ' send dec(24) on pin @2400Baud, mode 0, 8 bits

does that not repeat endlessly and never get to the next line, which is the receive part?

After two years of discussions on the picaxe forum, I think I can state categorically that sending single bytes does not work. You need a wakeup packet of at least six ascii U (which is 01010101 in binary). Then a start preamble, eg ABC. Then the bytes. And then a checksum at the end.

This is where the transceiver modules are so much better, because you can send one byte in and one byte comes out the other end. With raw RF, everything has to be wrapped up in a packet.

The serin part needs to be polling round and round looking for A, then if that comes in, B and C and only then does it go off and get the rest of the bytes. Otherwise it goes back to polling looking for an A.

And you might need a timeout.

I've used manchester coding but it hasn't been necessary to get this working and it only added a tiny (5%) distance to the maximum range. But it halved the data rate.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller

curseofthedonkey · 2010-03-20 00:56

Hey Dr_Acula.
Thanks for the reply. There must be a very good reason I'm not seeing a simplified raw rf txrx object. I can only assume this is because it is not simple at all. This began as a simple plan to connect serially via rf with some cheap modules. As you can see it's become a complex task to transmit even a byte of data accurately, or at all. This is mainly an exploratory project, a proof of concept, as I have had no prior experience with wireless ventures.
My circuit building could use a little work too. I'll try and get you a good pic soon, I have more access to computers than I do my board.

TX 3.3 volt high: I get a tone on the headphones, however I have not been able to accurately measure anything at all due to the lack of a scope. Again, I've learned my lesson.

Antenna: 1 foot each. Just some hookup wire.

repeat code: YES. The constant repeat of the transmission is an attempt to net a valid return value. I don't know if this is effective, but it was the best I had to go on. The following code is meant to receive this information as var x. I have them running on separate cogs:

 x:= bs2.SERIN_DEC(2, 2400, BS2#NInv, 8)

I did this so I might have a better chance of at least returning the correct decimal. Even once out of 100 would be a major accomplishment, then I had hoped to narrow down the actions for error checking. If this was a ludicrous thought process to someone who may know more about this stuff I understand. It was the most obvious method to attempt, but without any usable return value at all, it proves greatly inadequate.

Dr_Acula · 2010-03-20 02:05

I very much appreciate your frustration. I've been there and I have a shed full of half completed experiments.

If you look at the dracblade thread on the last post is a screen grab of two propellers talking to each other wirelessly. This has taken 2 years to get to this point.

One day I'd like to get the raw modules into the network - if only because
a) I think the prop has enough onboard smarts to handle them and
b) they are so much cheaper.

What I'm not sure is how the serial object code works at the assembly level. I think they will work properly, but it isn't how they work, it is how they fail. So if somehow there is what is called a framing error, and you are sending a start bit and then 8 data bits and then a stop bit and then a tiny delay, but somehow the serial port object has decided to start reading in the middle of the byte, it will still (I think) read out bytes as if they are valid bytes.

I think this is what might be happening with the raw rf modules - they start off listening to static, along comes a byte but they probably start reading in the middle of the byte rather than the beginning. So you will then get a series of repeating data but it wont be the right data.

The ABC header on picaxes exploits some internal code inside a picaxe that captures those header bytes reliably and also synchronises things for the next bytes. I'm not sure such a thing has been written for the propeller.

So - a general question - how do you detect and get out of framing errors?

The picaxe solution has been to add small delays of definite zero - ie zero.... then UUUUUU then ABC then the data

And some people on that forum feel very strongly about adding a delay between UUU and ABC as well.

What I'm not sure about is whether to plug raw rf modules into existing serial objects, or whether to go back to basics with the bell modem obex (which I don't think will work, as the bell obex uses sine waves and the raw rf modules work with square waves). I think the answer is some smarter ways to talk to the serial objects - and I think it might involve delays
eg delay - send UUUUU delay send ABC etc

The delays need to be just the right length. Too long and the centrepoint for the Rf Rx will drift. Too short and framing errors can't be detected. I am guessing the right delay is about one and a half byte lengths. eg about 15 bit lengths. So if you are 2400 baud, 15/2400th of a second. I'd be hoping that would allow a framing error to be detected.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller

Toby Seckshund · 2010-03-20 09:36

I have just twiged that the "raw rf" items are actually a maker's name. The only units I have ever used (but not on a Prop, yet ) are cheaper, about £8 for the pair. I only had 1200 Baud going through them at a range of 10-20 yards. They are just sat in a drawer now but I had intended to try another pair in a packet system.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point

curseofthedonkey · 2010-03-20 11:46

Here are the modules I'm using:
http://www.sparkfun.com/commerce/product_info.php?products_id=8946
http://www.sparkfun.com/commerce/product_info.php?products_id=8950

First order of business will be to separate the modules by at least a couple meters.
I'll be sure to post an update.

Leon · 2010-03-20 12:05

I had a look at the comments on the SFE web page, no one seems to have been able to get them to work! I've never had any problems with the Nordic nRF24L01 modules, FWIW.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM

Post Edited (Leon) : 3/20/2010 12:10:33 PM GMT

Dr_Acula · 2010-03-20 12:59

Re "I have just twiged that the "raw rf" items are actually a maker's name. "

No, raw rf is a way of describing a range of modules. They are generally under $5, the Tx and Rx are seperate (not a 'transceiver'), they have Rx sensitivies around -93 to 103db, they don't have antennas included (you have to add the wire), and, most importantly they output random white noise if nothing is transmitting nearby. There are many different brands and manufacturers. Some are only $2, hence the motivation to get them working!

They are much more complicated to interface than 'transceiver' modules. Transceiver modules generally are $15 to $25 each, have an onboard micro, can do TTL or RS232 signal levels or both, when there is no data being transmitted the output is zero or 5V, they are a lot more sensitive (around 100 to 1000 times more), they have a screw connection for an antenna, and they are generally a drop-in replacement for a wired connection.

Raw RF modules are harder to get working. I think they are going to need some spin code that couples with existing serial code. I am not surprised at the comments on the sparkfun page, as these modules are often advertised as "data in = data out" and that is precisely what they do not do. However, I have managed to send data over 500 metres with modules very similar to these using picaxe chips.

I think what is needed is another layer of code that interprets data coming in. It is in a loop looking for valid U characters, then if that arrives it looks for a header, and if that arrives it looks for a data byte(s), and if that equals a checksum then, and only then, does it output to a circular buffer. From the users point of view, you want an object where you ask if a byte is in the buffer, just like with serial data objects. You might also want some data statistics saying 'I'm getting the header bytes ok but only half the checksums are correct".

I really do think this is just a combination of delays and existing serial code. But I need to understand something more fundamental first - how can you run background spin code? I understand running cog code independently, and I understand running the 'main' cog which is interpreting the main spin program. I'd like to know if you can run other spin code in parallel? OR - is it going to be necessary to build a brand new pasm object to do this - an object based around the serial object but with some code doing the above data checking and necessary delays.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller

Leon · 2010-03-20 13:14

Messing about with delays etc. isn't the right approach, Manchester code is the only reliable way to get them working. These low cost modules have Manchester encoding and decoding built-in:

www.rfsolutions.co.uk/acatalog/Smart_Radio_433_Transceiver_Module.html

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM

Toby Seckshund · 2010-03-20 15:28

So when I thought that the term "raw rf" was just some cheap little modules, I was right. I put "raw rf" into Google and it threw up some cute looking ones at $40 each. It did get me wondering when Dr_A said that they were cheaper than the ones he uses.

I had put a crude form of squelch on the one I used to shut it up on no carrier

And another thing ... The antenna for 433 should be about 7" (17cm) long.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point

CannibalRobotics · 2010-03-20 15:44

Are they Lynx modules? If so I think I can dig up some code for them. I basically re-wrote fullduplexserial to accomidate the idiosyncracies of RF. I think good money is now on something like an Xbee module that handles all that encoding/decoding stuff.

RF is·an unpredictable environment - I can't imagine trying to make it work without a scope. I'm impressed!

Jim-

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Signature space for rent!
Send $1 to CannibalRobotics.com.

Dr_Acula · 2010-03-21 00:49

I guess I should say for the record that I do have a reliable network of propellers talking wirelessly up to 3km and that I haven't used these raw rf modules. But I have used raw RF modules to go 500metres with picaxe chips.

I have been pondering Leon's comment about Manchester encoding and I think this has a lot of merit. Consider - 6 U characters, one or two pauses, a unique wakeup byte combination (2 or 3) and a checksum, all to send one data byte.

I think Leon is right about Manchester coding.

Thinking about this more, it really needs to be pasm and to behave like the existing objects - ie complicated behind the scenes but easy to use.

I think there will always be a need to synchronise somehow, even with Manchester coding. So the Rx is receiving white noise and a tone appears which is the wakeup byte at clock frequency f (eg 4800hz) transmitted as the translated byte 0x00 to a Manchester code. en.wikipedia.org/wiki/Manchester_code Then you might send 0x55 as the next byte and this ends up being a tone of f/2 and the receiver is expecting this transition so it can use that to synchronise the start of the bytes. Then just send the packet.

One of the things about the picaxe system with lots of U bytes and only a few data bytes is that the picaxe can only handle a maximum of 14 byte packets. So you can get away with a few data bytes being 0x00 0x00 0x00 and it won't shift the balance too much. But with longer packets (which the prop can handle) then it makes a lot more sense to send via Manchester encoding. (with the picaxe and long packets some have used a 'poor amn's' Manchester, ie send bytes in pairs and if you send 0x01 then send 0xFE straight afterwards (255-n).

So - this needs to be a pasm object. It uses one pin for Rx and one for Tx. Asynchronous. Buffered (? up to 256 bytes if possible). Maybe even add the fancy system used in the transceiver modules where if you send one byte it waits for more bytes and IF (buffer full OR >30 milliseconds) THEN clear buffer. That way the bytes end up in packets.

On the Rx end take the packets and translate back to bytes and put them in the rx buffer ready for spin to collect them.

Hmm. Complicated to write. Big benefits down the track as RF comms for under $5.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller

curseofthedonkey · 2010-03-21 01:57

@CannibalRobotics
Nope. Not Lynx. Generic rx tx modules that were under five bucks from sparkfun (rx module: MO-RX3400-A from Holy Stone Enterprise Co and corresponding tx module). No scope either, but that wasn't an intent to make it even more challenging. Just plain unpreparedness on my part. Frustrating to say the least, but it does make me chuckle a little to know that my first week of delving into wireless transmission has already provided me with a worthy nemesis.

This has turned into a rather interesting and much more challenging project than I had thought. This was a small piece to a larger project, and while I may just move forward with an XBee for the main one, I now have two main projects I'll be working on that will keep me busy for a while.

I'll continue to work on this and will post updates. Thanks to everyone for the helpful advice!

raw rf, hope lost?

Comments