Rookie - working through 1st project.

Wireless & IoT
1

I recognize that my knowledge level is way waay below the normal discussions around here, but I’m hoping that by asking the embarrassingly basic questions, I can not only learn a little bit, but maybe help some others who don’t ask for fear of looking foolish… as a married man, I’ve overcome that fear years ago!

As my first project beyond the LED flashing version of “hello world” , I’m trying something a bit ambitious; at least at my level. I’m trying to put together one board with a 16F628A that will take input from a microphone and a couple of switches and then transmit instructions via 434 Mhtz to a second board (also with a 16F628A) that will the trigger one or both of two relays to control a 110 volt appliance. I’ve worked through everything on the first board up to the transmitting part. I have a pushbutton that is polled by the MCU, when it’s pressed, the MCU sends power to the microphone circuit. Then the MCU polls the output from a OP Amp/Comparator circuit until a signal from the microphone is received (think of a “clapper” switch circuit). Once the sound is detected the MCU checks two switches, and then sends a signal via USART to be transmitted to the second board and turn on the 110 v. circuits.

As I said, I have learned a tremendous amout using the try this, fail, try again method to build the circuit up to the USART. Now it’s time to admit that I need the guidance of an experienced hand. I’m hoping that your help with a couple of what may appear simple questions will get me jumpstarted again.

When I set up the MCU to output the signal to be xmitted - do I need to enable both the transmit and receive functions? (ie should I have both TXEN=1 and CREN=1 even though the MCU will only be xmitting?

Also, it seems that as soon as my MCU runs through the program section that initializes the USART, the TX pin (RB2, pin 8) goes high and stays there – an LED connected to the RB2 pin (along with the xmitter data in pin) turns on and stays on even though I have a full 1 second delay after each byte (an ascii character) is put into the TXREG. To make sure the code was correct, I changed it to send output to a different pin with each TXREG operation, and an LED on that pin blinked once per second, just as expected – thus I’m sure that the TX pin is getting a constant high signal… but I don’t know enough about what I’m doing to know if this is SUPPOSED to be this way – it seems like some sort of carrier signal, maybe; but I didn’t think that the USART would have a carrier signal.

Okay, this is supposed to be just a couple of questions, not a thesis - I appologize. The basic questions are:

a) do I need to enable both transmit and receive functions of the USART even if I’m only transmitting from one and receiving with the other? and

b) should the TX pin hold a constant high state once enabled, or do I need to review my initialization settings for a mistake?

I thank you for any help you can offer, and I’m sure others will appreciate your efforts even without acknowledging them.

2

The 16F628A is an obsolete device. Much better chips are available, with on-chip debugging.

3

BushWhacker:
The basic questions are:

a) do I need to enable both transmit and receive functions of the USART even if I’m only transmitting from one and receiving with the other? and

b) should the TX pin hold a constant high state once enabled, or do I need to review my initialization settings for a mistake?

a) I have not seen a UART where you could enable to disable the Tx or RX sections independently. This is not to say your part does not have this function. In general, I would enable the UART and only transmit with it or receive from it. Assuming you are transmitting, then any byte that arrive in the receiver will simply sit there and rot away or get overwritten by other bytes that should not be arriving anyway. If you are receiving, having the transmitter on and just not sending it any bytes to send if fine as well.

b) “Logic level” or “real” RS-232 signals are reverse logic from normal human thinking. If nothing is being transmitted, the signal is held high. When a byte is to be sent, the signal drops low for one bit period (1/baud rate) and then transitions up and down based on the data. The data bits are then followed by one (or more) stop bits that are HIGH, before the next byte gets send. If you want to transmit a 1 bit, the signal goes low for a bit width. A 0 makes it go high. In your case, seeing the TX line high on a quiet bus is a good thing.

4

fll-freak… thanks SO MUCH!!! Your explanation was exactly what I was needing. Using your info, plus a great Microchip document (for any other newbies, see: http://www.eti.pg.gda.pl/katedry/ksg/dy … /usart.pdf) on USART, I fiddled with my code, and am confident that I am using the USART correctly. To test my code I ran a direct line from the TX pin on one MCU to the RC pin on the other (using a single board with 5 volt Vdd and a common ground). The data I sent from the xmitter was recieved perfectly by the receiver. (I simply alternated between sending an “A” and a “B” and having the receiving MCU light a different LED for each letter… worked perfectly. Then I tried using the 434 Mhtz RF transmitter/reciever pair that I purchased from sparkfun. For some reason, the reciever lit up to tell me that it received the first character, but then went cold and did not indicte that it received any bytes after the first one… any thoughts on what might cause this? The LED on the xmitting MCU indicates that it’s still sending data, but nothing from the receiving MCU. How could the reciever (hardware) receive only the first byte and then nothing after that? (I know that the program on the receiving MCU is good as it worked when they were directly connected, the only change was replacing a direct wire between the ports with the transmit/rec pair.

I greatly appreciate your efforts to help me, and hope that others will learn from this thread as well.

5

Welcome. We aim to please. Someday you will have the knowledge to help the next generation.

6

You didn’t say which 434 MHz receiver/transmitter pair you have, but the cheap ones are not a replacement for a wire connecting two MCU boards.

In general, a fair bit of sophisticated firmware is required to make sense of a radio signal. Such firmware is packaged into more expensive R/T units like Xbee, which can act as a “virtual wire”. Or, you can use various implementations of virtual wire software on the MCU boards, together with the really cheap R/T units. There are a number of posts on Sparkfun forums discussing this.

Here’s a link discussing one implementation of Mike McCauley’s virtual wire software for AVR and really cheap R/T units: http://www.pjrc.com/teensy/td_libs_VirtualWire.html

7

On most (I say most, not all) of the PICs, the UART TX and RX sections can be individually “enabled” by changing the TRIS for the particular pin to the opposite state and using it in that manner. For instance, using the RX pin set up and used as an output and/or using the TX pin being set up and used as an input.

Most of the 433/434 Mhz Tx/Rx pairs need to use what amounts to “Manchester” (I think bi-phase encoding might be the correct term here) encoding/decoding. You can’t just send serial data across them. Just doesn’t work that way. You have to “train” the receiver before sending it relevant data or it may or may not receive anything at all. Once I got over that “Manchester” hump, those cheap little modules worked good enough for me.

8

Again… thanks to all of you for your help and insights. I’ve finally got the USARTs working, but I was indeed trying to use my $8 Tx/Rx pair to essentially act as a virtual wire between the two units by simply sending serial data from one to the other. Hopefully another newbie will see this post and bypass all of the frustration of trying to do it this way. The good news is that I’ve got everything working, the bad news is that the data being received is pretty routinely currupted, and a lot of trash that I didn’t send is being received. Guess I’ve got a new research project - “Manchester encoding”.

9

I’ve been able to send a couple of bytes, with error correction and 99.99% reliability, up to 1000 feet in the open air using the $5 type 434 MHz modules. I don’t use Manchester encoding, but it is absolutely necessary to send a preamble, that is, a dozen or so ones and zeros, to train the receiver to recognize the signal level, before a synchronization byte, a message and check bytes are sent. Needless to say you can’t use the UART for this, but only one port pin on each MCU is required.

Reynolds Electronics has implemented just this system using extremely simple code on a Basic Stamp http://www.rentron.com/Stamp_RF.htm and also used it to create cheap 8-pin PIC modules that encode up to four on/off functions via RF signals. See http://www.rentron.com/PicBasic/RemoteControl.htm

(I don’t work for Rentron).

10

Outstanding, jremington…Thank you. One or two reliable bytes is perfect; really all I want is to get the recvr to recognize a single byte (for that matter, I could use a single bit) for each transmission. All it need is "if you receive an “A”, send power to pin x, for a “B” send power to pin y, and for a “C”, light 'em both up. I’ll definitely look at the links you provided; the funny thing is I started by playing with a BS2, but decided to go whole hog into electronics and PICs because I didn’t think I could do RF with a BS since it didn’t have a USART. Every day… hell, every hour … I’m learning something new and cooler.

I know this shouldn’t be rocket science, but I feel like I’m doing some extra-cool high-tech stuff here! It’s just so awesome to take a bunch of cheap wires and chips and make them do something cool. Learning this stuff is seriously fun, and I’m very impressed to find a community like this of folks who know what they’re doing, are willing to help, and haven’t yet pointed out my naivete’ – thanks to all of you!

11

jremington:
I’ve been able to send a couple of bytes, with error correction and 99.99% reliability, up to 1000 feet in the open air using the $5 type 434 MHz modules. I don’t use Manchester encoding, but it is absolutely necessary to send a preamble, that is, a dozen or so ones and zeros, to train the receiver to recognize the signal level, before a synchronization byte, a message and check bytes are sent. Needless to say you can’t use the UART for this, but only one port pin on each MCU is required.

Yep, that's my experience as well. A few bytes at a time, no problem as long as you send out a preamble.

I was firing off whole strings, ~32 bytes at a time, 1200 effective bps, with maybe 75% reliability at long ranges, >500ft, using the Manchester encoding method.

Shorten the strings, decrease the range, etc.etc.etc…and like you, I suppose I could’ve had close to 100%. meh…75% worked good enough for that particular project.