SparkFun Forums

[Mee_n_Mac]

I was actually wondering if a PICAXE chip can be inserted and programmed with arduino and then put in between the TX and the RF transmitter to convert the baud rates...im skeptical if coding and encoding can get over this baud rate limitation

At the risk of repeating myself ... sure it can. The PICAXE (or any MCU) only need to store the 5 ASCII characters and then retransmit them at the slower 4800 baud rate. It takes about 5msec to read in the 5 characters and will take another ~10 msec to retransmit them. There's plenty of time in the 100 msec in between data bursts to do this. Also time to do other things to improve the probability that the 5 characters will be properly received at the receiver end.

[stevech]

maybe.
But you should just use or adapt one of the many Arduino and other programs for on-off-keying (OOK) cheapie radios.
Better, as a beginner, start with more sophisticated radio. Like a pair of XBee series 1. Maybe an overkill, but your inexperience will lead to lots of frustration trying to use OOK radios and DIY very bit and byte of the MAC and Application layer.

[jeff77789]

Now I am at the point where i can send a digital signal at 4800 baud through these sensors.

The thing is, If it send "123" on the other side, i rarely ever get the "495051" sequence (refer to ASCII table)
(there is no encoding for this signal and i am not quite sure how to "encode" it either.)
the accuracy rate is less than 10% and I have no Idea why the signal is so "noisy"

is there any way i can improve on this?

[jremington]

What you are doing is extremely unlikely to work properly, for reasons already pointed out by various posters in this thread. You can dramatically improve on this result by reading about and implementing something like the VirtualWire project that I linked to previously. It need not be complicated but your method will need to include, in addition to the message, a preamble, a sync signal and some sort of error checking.

[leon_heller]

Or, use something easier to work with like a pair of nRF24L01+ modules.

[stevech]

Beginners often choose the cheapest RF TX, RX modules.
But, versus. starting with a $25 module, the $4 module like trying to learn to fly an airplane by starting with a crude old tail-dragger - and you can't even see the taxi-way.

[CircuitBurner]

Hey now....tail-draggers bounce best!

[leon_heller]

nRF24L01+ modules are less than $3 each.

[Mee_n_Mac]

nRF24L01+ modules are less than $3 each.

The naked IC or a "module" with xtal, antenna, etc, etc ? Because at that price it may be less $$ to link things via RF than to have cabling and connectors !

[leon_heller]

http://www.ebay.co.uk/itm/1X-NRF24L01-2 ... 3536748%26

[Mee_n_Mac]

Wow !

[jremington]

Ha! $1.15 each (qty 10) plus free shipping! (or $3.43/2 plus $1 shipping)

http://www.ebay.com/itm/10PCS-Arduino-N ... 27c59c2557

[languer]

Unless I'm mistaken, both the OOK modules and the nRF24L01+ modules require a uC to process the signals at both the Transmitter and Receiver. The nRF24L01+ (another useful one is the RFM12B) is a much more robust system (and it is a transceiver); but it needs configuration. I do not believe it is easier to use as-is; but I do believe it is a much better solution. Having said that, I would not choose the nRF24L01+ to start out with. A transparent RS232 bridge like the WIXEL's it's an excellent entry-level approach.

My 2cents; the MAXBOTIC sensor sends 5 bytes: "R", four range bytes (ASCII character representing range in millimeters), followed by carriage return (ASCII 13). Only thing you care about is the range isn't it? And you care about the number, not the digit representation. So why would you transmit the whole enchilada? I would strip the R and CR (carriage return); convert the digits to a WORD (since the range can go from 0 to 5000 - according to datasheet); encode this and send. Regardless which module you use (unless you use the WIXEL) just send the data you need. If you use the nRF24L01+ or RFM12B; those already do the encoding for you. If you use the OOK modules; you have to do the encoding.

An example of encoding with OOK modules: JUNK - JUNK - JUNK - SYNC1 - SYNC2 - DATA. Example: 0xAA, 0xAA, 0xAA, 0x2D, 0xD4 0x01F4. The 0xAA balances the OOK receiver; the SYNC1 and SYNC2 are bytes the receiver looks at (look-at-me) to determine the data byte(s) is coming; the 0x01F4 would be the code for 500decimal (for example). You could add a CRC byte (at end of message) to validate message packet. On the receiver you would create a state machine which waits for the SYNC1 byte and then SYNC2 byte; only when both bytes are received sequentially does the receiver accepts the next byte(s) as valid data.

[CircuitBurner]

A long time ago, in a galaxy far far away...
uh, I mean about 12 years ago working in a hotel room while deployed out to USPS mail facilities for automation systems installations, I found my love of micro controllers in the form of a Basic Stamp-1.
I soon had 2 and had built a pair of IR transceivers with them...experimenting with sending ASCII strings from one to the other, and figuring out how to improve ranges and message quality.
I set one TRX as an initiator, and the other TRX as a responder.
The initiator powered up and immediately sent out a string.
The responder powered up and sat there listening for a message before sending its string.
The pair formed a tag-team that played a game of "catch" that would continue on and on until the chain was broken by missing characters in the string transmission, or by simply one unit not getting the message at all
( because I threw a sock over its head to kill the game and make em goto sleep )
I found this pair of matching TRXs highly useful in prototyping or testing algorithms related to IR signalling and stuff.
Some very notable discoveries I made in these experiments was how the more workable data formatting methods and the different schema for TX and RX pairs data formats worked and why.
I also went all they way down (way...on...down...) to 300 baud on TX and RX that made an incredible (i said that in loud baritone) difference in range and readability... it even worked around corners!! im not shittin you.
But the part most applicable here to this thread would be the formatting that boosted reliability of signalling between TX and RX pairs.
Im sure this is prolly encapsulated within some one elses coding formats, but I did this independently of anything anyway, so this might be of help to you or anyone working out a solution by scratch.
If you figure out how many individual control/message signals you might need for your particular application, you can then proceed in coding or at least conjuring up some 'alphabet' or command list to work from.
I originally was sending a complete sentence like "mary had a little lamb", and it didnt take much to break the cycle... a dropped space could terminate the game of 'catch' my little 'stamp-bots' were playing.
Then I discovered stacking or chaining like characters to form redundant command signalling that was much harder to cause to fail. Then, progression lead to the best way of implementing the RX-side decoding methodologies...
like I sent "mmmmaaaarrrryyyy hhhhaaaadddd aaaa lllliiiittttttttlllleeee llllaaaammmmbbbb" and had the RX side perform a "latch" decoding function by only expecting the next character in the series after successfully interpreting the prior symbol.
So, unless RX decoded an "m", it ignored everything else, sitting there waiting on its expected "m' symbol.
In this way, the redundant series of characters were filtered out rapidly, and entire complex sequences could be decoded reliably at impressive distances and orientations (around corners ~wink)
This in effect created the possibility for many many "channels" or commands to be coded into the TRX pairs, essentially making many possible signals that could be sent and used to trigger events on the RX side.
I went as far as using "return acknowledgment signalling" where each time a RX got some characters in a burst, it would send out a simple string of +++++ to let the TX know it got something, and then it would send out +++++ or ------ to let the TX know it had successfully keyed a function or failed to match a key... causing a possible retransmission.
Using these basic fundamental format methods, the TX / RX pairs reached impressive reliability, rivaling any low power RF signalling setups.

Think about this methodology and you can improve your conditions immensely regardless of "noise" or transmission quality.