Looking for the cheapest method to commincate in 433MHz

[bes]

There are so many RF modules in the **broken link removed** . Maybe you can get find your favorable modules.

 

[rogerynt]

USe super-regen. transmitter and receiver.

 

[Kulkarnitejas]

Re: transmitter bfr93

CAN WE CONNECT TWS 434 Or Some Module of 433Mhz (without the Holtek Encoder Decoder) To PIC18F4520' TX Pin Directly....
And Can WE Receive It With RWS434 Or Similar Module On Another PIC18F4520

 

[ctownsend]

Re: transmitter bfr93

CAN WE CONNECT TWS 434 Or Some Module of 433Mhz (without the Holtek Encoder Decoder) To PIC18F4520' TX Pin Directly....
And Can WE Receive It With RWS434 Or Similar Module On Another PIC18F4520

the holtek encoder/decoder pairs encode the data in a specific way to overcome the noise present on the data line of the module. If you just try to send data directly to the TWS 434, it will be unreliable at best.

You need to devise an encoding/decoding scheme of your own. Do some google searches for manchester encoding.

 

[chrismicro]

All data receiver and transmitter modules in the 433.92MHz band has a data input or output respectively and can be connected to any I/O pin of any PIC MCU,
Static and noise interference have no effect on it because of the modulation type, it is almost like FM, in other words no amplitude modulation, the data signal is switching the carrier on and off, on for a one and off for a zero and visa versa depending on your transmission mode.
When using PIC Basic programming a simple

---

Code Basic4GL - [expand]
1
serout I/O pin, N2400(Mode T2400) or serin

---

is used to send or receive data.

 

[ctownsend]

Static and noise interference have no effect on it because of the modulation type

I don't think we are talking about the same thing here. The cheap 433MHz RF modules are not immune to noise.

Hook it up as you say, and display the data received from the receiver to a terminal or LCD. YOU WILL SEE that the receiver is ALWAYS picking up garbage even if the transmitter is off and not sending.

Even if the baud rate is correct, the start/stop bits are sometimes not synchronized correctly due to noise. Some guys may be able to make it work BUT IT will NEVER be 100% reliable unless a good encoding/decoding method is used. Why do you think there are hundreds of posts about this problem?

It is a great deal of trouble to do this, therefore an encoder/decoder will work 100% and will save a great deal of hair pulling.

 

[chrismicro]

I agree, if your circuit is poorly designed you might have problems with garbage, if you are using a MCU smoothing of your supply is very important, I use a 10mF cap directly between Vdd and Vss a small tant. SMD cap on the solder side of the board and thats it, I do it daily and have no garbage problem at all, I'm using my own designed 433.92MHz on board transmitter and a cheap receiver module (not so cheap $24 per module) with PICBASIC programing and I will bet my life on it that you will never receive garbage. I design projects that is used underground in mines and it essential that it is reliable.

 

[Nick C.]

Re: transmitter bfr93

CAN WE CONNECT TWS 434 Or Some Module of 433Mhz (without the Holtek Encoder Decoder) To PIC18F4520' TX Pin Directly....
And Can WE Receive It With RWS434 Or Similar Module On Another PIC18F4520

Yes, I've done this with these Wenshing parts (I think that these are now made by multiple manufacturers, so YMMV), but as others have said, noise can be an issue. It's been several years, so the details are a bit foggy, but I remember having to send a throw-away byte to 'warm up' the receiver, followed by a unique synchronization byte (ie, 255), and once that was detected by the receiving uC, it was ready to receive the string of data. This just took two or three lines of code in Picbasic Pro. Be prepared for glitches and errors.

If a single value was being transmitted, you could have the transmitter send it three times in a row. So if the byte to transmit was '127' and the receiving uC received '127,5,127', it knew that there was an error and ignored that last transmission.

It was clumsy and crude, but it worked well enough for my non-critical hobbyist application. I ran this at 2400 baud, IIRC. I don't remember if I ever tried anything faster.

Manchester encoding would be better, of course. Or simply adding checksums to your data (like used at the end of every NMEA183 sentence) couldn't hurt.

 

[ctownsend]

I do it daily and have no garbage problem at all, I'm using my own designed 433.92MHz on board transmitter and a cheap receiver module (not so cheap $24 per module) with PICBASIC programing and I will bet my life on it that you will never receive garbage. I design projects that is used underground in mines and it essential that it is reliable.

ok, so you are not using a genuine cheap TWS434 or TLP433 module after all, which is what Kulkarnitejas (post 23) is asking about. I would be willing to bet my life that you are using some sort of encoding in your code as well, not just sending data out of an IO pin @ 2400 baud.

If a system is to be 100% reliable, not 90%, 95%, or whatever, truly 100% reliability is dependent on some sort of encoding whether it be hardware based or software based.

If you still insist, prove it. Post your code here. Many others have made this claim and have never posted one line of code. (no offense intended, of course)

 

[chrismicro]

ok, so you are not using a genuine cheap TWS434 or TLP433 module after all, which is what Kulkarnitejas (post 23) is asking about. I would be willing to bet my life that you are using some sort of encoding in your code as well, not just sending data out of an IO pin @ 2400 baud.

If a system is to be 100% reliable, not 90%, 95%, or whatever, truly 100% reliability is dependent on some sort of encoding whether it be hardware based or software based.


If you still insist, prove it. Post your code here. Many others have made this claim and have never posted one line of code. (no offense intended, of course)

You asked for it,
First line: Is to include the mode procedures, a standard include file that come with PICBasicPro
Second line: first a qualifier is send in the form of an Cap. “A” to tell the receiver PIC to read the following variables(data)
Third line: used in the receiving PIC the program will wait 300 ms. for the string “A” then go to the Loop2 label, “300,Loop2” can be omitted then the program will wait infinitely for the string “A” as soon as it see the “A” it will read the following data into the variables Code, Zone and Key.
And that’s it
Note you can’t call the qualifier a filter or coding because it is 8 bits long and if there is garbage, then your receiver will never be able to read the “A”

INCLUDE "Modedefs.Bas"
SerOut PORTA.1,N2400,["A",Code,Zone,Key]
SerIn PORTA.2,N2400,300,Loop2,["A"],Code,Zone,Key

---------- Post added at 14:53 ---------- Previous post was at 14:20 ----------

Yes, I've done this with these Wenshing parts (I think that these are now made by multiple manufacturers, so YMMV), but as others have said, noise can be an issue. It's been several years, so the details are a bit foggy, but I remember having to send a throw-away byte to 'warm up' the receiver, followed by a unique synchronization byte (ie, 255), and once that was detected by the receiving uC, it was ready to receive the string of data. This just took two or three lines of code in Picbasic Pro. Be prepared for glitches and errors.

If a single value was being transmitted, you could have the transmitter send it three times in a row. So if the byte to transmit was '127' and the receiving uC received '127,5,127', it knew that there was an error and ignored that last transmission.

It was clumsy and crude, but it worked well enough for my non-critical hobbyist application. I ran this at 2400 baud, IIRC. I don't remember if I ever tried anything faster.

Manchester encoding would be better, of course. Or simply adding checksums to your data (like used at the end of every NMEA183 sentence) couldn't hurt.

You can go up to 9600 baud provided your PIC run at 20MHz, if you communicate from PIC to PC change the mode from N9600 to T9600

INCLUDE "Modedefs.Bas"
SerOut PORTA.1,N2400,["A",Code,Zone,Key]
SerIn PORTA.2,N2400,300,Loop2,["A"],Code,Zone,Key

 

[zuzu]

I'd evaluate cheapest method against all possible factors involved, not only chipset:

- need MCU for encoding/decoding? If so, why not MCU with transmitter inside? See SilliconLabs, Texas, Adi, Microchip and others
- need one way or two ways. If one way, the cheapest is transmitter + receiver, other ways use transceivers.
- if transceiver, has all RF parts inside eg. LNA, POWER and most important antenna switch & match options?
- need no freq. tuning? use absolute cheep and dirty transmitter: some transistor and saw resonator or use more elevate PLL method, see Micrel which has the smallest part count transmitter in the world (in SOT-23 package)
- one expensive component is quartz crystal involved. Many manufacturers doesn't understand that and made chipsets with absolute idiot frequencies that can be ordered only in 1000+ qty. For this reason, search crystal availability before thinking use that chipset. At least for some can be found that special values on market, for others is absolute impossible to test unless order samples.
- is your product exposed to temp range? If so, you probably need a chipset with AFC or use your own compensation with temp sensor or a TCXO
- finally I'd advice you to read carefully the datasheets and test for final choose. Since is a huge market here, manufacturers often exaggerate their performances. The cheapest is the lower component count (as Micrel or Sillicon Labs) since PCB size is also involved

Cheers,

 

[chrismicro]

I'd evaluate cheapest method against all possible factors involved, not only chipset:

- need MCU for encoding/decoding? If so, why not MCU with transmitter inside? See SilliconLabs, Texas, Adi, Microchip and others
- need one way or two ways. If one way, the cheapest is transmitter + receiver, other ways use transceivers.
- if transceiver, has all RF parts inside eg. LNA, POWER and most important antenna switch & match options?
- need no freq. tuning? use absolute cheep and dirty transmitter: some transistor and saw resonator or use more elevate PLL method, see Micrel which has the smallest part count transmitter in the world (in SOT-23 package)
- one expensive component is quartz crystal involved. Many manufacturers doesn't understand that and made chipsets with absolute idiot frequencies that can be ordered only in 1000+ qty. For this reason, search crystal availability before thinking use that chipset. At least for some can be found that special values on market, for others is absolute impossible to test unless order samples.
- is your product exposed to temp range? If so, you probably need a chipset with AFC or use your own compensation with temp sensor or a TCXO
- finally I'd advice you to read carefully the datasheets and test for final choose. Since is a huge market here, manufacturers often exaggerate their performances. The cheapest is the lower component count (as Micrel or Sillicon Labs) since PCB size is also involved

Cheers,

ZUZu my transmitter is using 6 components, all SMD's a BFR92A, 2 caps, 2 resistors, saw resonator and a printed loop antenna, I think that is cheap enough, what do you think? for receiver I use a dirt cheap module $7 for reliable work I use a more expensive module $24 USD.
PS. For coding and decoding I use a PIC12F629 in a 8pin SOP and on my panic button ring transmitter I use a PIC10F206 SOT23 10X10mm PCB.