433 MHz RF Transceiver

SEL

I need an Object for the 433 MHz RF Transceiver.

I would appreciate any help.

Zap-o

The least you could do is provide a spec sheet or a model number. I have no solid count but but there has to be over 50 different types of transceivers.

Mike Green

I'm not aware of any 433 MHz RF Transceiver object, but most of the functionality you'd need you'd get from one of the existing serial I/O objects in the Object Exchange. If you look at the documentation for the Transceiver and the examples for the Stamps, you'll see that the only special handling is that of producing a "sync" pulse before transmitting. Consider using either the Simple_Serial object or the BS2_Functions object, both of which can do the serial I/O. You can also use the BS2_Functions routine for PULSOUT to produce the "sync" pulse just like the Stamp routines do. With Simple_Serial, you'd have to do the same thing easily and directly in Spin.

Dr_Acula

I have a shed full of homemade and commercial RF modules, and I've experimented with RF bands from under 1Mhz to 2.4Ghz.

The modules I like the best are these sort http://cgi.ebay.com.au/2-pcs-Wireless-RF-Transceiver-433MHz-FSK-Data-Transfer-/350415172483?pt=LH_DefaultDomain_0&hash=item51965f3383

There are many different variants, and you can get modules with higher receiver sensitivity (these are 109db, and I've got ones up to 123db).

These have a long range, they are very stable, and best of all, you don't need any special software objects. You can add a max232 and talk to a PC port, or you can connect these directly to the propeller (just needs a stable 3V 100mA supply). Then use the standard serial port objects.

What is particularly useful is the way you can connect propellers with a wired link first, test it all out, then replace the wires with these wireless modules.

They work out at $13 each. There are many cheaper modules, especially the "raw RF" modules but those ones need more software smarts to get them working.

SEL

Zap-o wrote: »

The least you could do is provide a spec sheet or a model number. I have no solid count but but there has to be over 50 different types of transceivers.

I should have said: I need an object for the Parallax 433 MHz RF Transceiver.

SEL

Mike Green wrote: »

I'm not aware of any 433 MHz RF Transceiver object, but most of the functionality you'd need you'd get from one of the existing serial I/O objects in the Object Exchange. If you look at the documentation for the Transceiver and the examples for the Stamps, you'll see that the only special handling is that of producing a "sync" pulse before transmitting. Consider using either the Simple_Serial object or the BS2_Functions object, both of which can do the serial I/O. You can also use the BS2_Functions routine for PULSOUT to produce the "sync" pulse just like the Stamp routines do. With Simple_Serial, you'd have to do the same thing easily and directly in Spin.

Mike: The 433 Mhz RF Transceiver is the one that Parallax sales.
Do you know of any Bs2 code that would work with this Transceiver?

Thanks.

Mike Green

There are several examples of BS2 code for the 433 MHz Transceiver. Links to all examples are on the webstore page for the product involved. In this case, there are two examples. There are also some simple examples in the documentation, also with a link from the product page.

Ravenkallen

Thanks for the link Dr_Acula... those RF modules look a lot better than some of the ones i am using. I might buy a couple

obrienm

Sel,
Beau Schwabe from Parallax has an excellent driver and setup validated in this post from exactly 1 year ago - to the day - for the Parallax 433 MHz Transceiver that I verified back then.

http://forums.parallaxinc.com/forums/default.aspx?f=25&p=4&m=397284

thank you
/michael

brian.lloyd

I have not worked with these particular modules before but have used low-cost 433MHz, on-off-keyed (OOK) modules with the BS2. (I was helping one of my students build a data link for his BoEbot.)

While they use plain old async serial, we ran into problems with received noise with no signal present. (No squelch -- maybe these have it.) This required some kind of preamble to let the slicer in the receiver synch up on mark and space. After that we sent two 0x00 which creates a start bit and nothing else. That allows the receiving UART to achieve character sync. After that comes a unique frame-delimiter character (FLAG). (All this is probably overkill but it works really well for SLIP and PPP.) The rest of your frame must not contain the FLAG character. If you want to send the FLAG character as data then you must prefix it with the control-escape (CESC) character.

Basically you look for content between two FLAG characters. By having the FLAG characters and a reasonable error-check (CRC or checksum) even if noise generates a FLAG and your receiver starts to accumulate characters for a frame, as soon as you start to receive a real frame, the first FLAG character closes the noise frame and starts reception of the new, good frame. The noise frame will almost assuredly not pass the CRC check and is silently discarded.

If you want a good way to frame data on an async line, you should probably take a look at the RFC for PPP framing -- RFC1662. You don't need the entire HDLC frame (including unnecessary address byte -- kept it to keep the ISO people quiet) but the rest of it is quite useful. You can use the protocol field for doing multiplexing if you need to. Or you can go to the trouble of implementing the whole PPP LCP and NCP with its concomitant state machine. That might go well with the work on the Spinneret.

Brian