Wireless problem

[supersonic]

Hello everybody.

I've been looking a lot your forum which gave me a lot of help without the need of ask questions... all my problems where solved using 'Search'...

Now I think I need some guru help to solve my little problem.

I am trying to build a remote trasmitter wich will send SHT11 sensor data to my wireless station.

The modules I am using are this(TX):http://elmarpeters123.googlepages.com/TM1000-1.pdf
and this for RX (RM1SGS):http://e-madeincn.com/Product/Product-RXModule.htm

I've found them on ebay. They are very cheap. I paid 12€ for 3 pairs of them, shipping included!

I am writing some simple code to test them. The transmitter is a 12F683. Power pin is used to power up the transmitter via a transistor, will send data and then will be powered off for a minute to save battery.Here is the TX section:



INCLUDE "modedefs.bas"

ANSEL=0
CMCON0=%00000111
define osc 4
txpin var gpio.4
led var gpio.5
power var gpio.2
i var byte

low power

loop:
for i=0 to 9
high power
serout txpin,n2400,[$55,$55,$66,#i]
high led
pause 30
low led
pause 1000
low power
pause 1000
next i
goto loop

Then there is the RX section, the pic used is a 16F876:



INCLUDE "modedefs.bas"

define osc 20
Define LCD_LINES 4 ' Settings for a 4x20 LCD
Define LCD_DREG PORTB ' 4bit mode
Define LCD_DBIT 4 '
Define LCD_RSREG PORTB
Define LCD_RSBIT 3
Define LCD_EREG PORTB'
Define LCD_EBIT 2

'LCD Lines constants
row4 con $d4
row3 con $94
row2 con $c0
row1 con $80
rxpin var portb.0
rx_data var byte

TRISC=255
intcon=0

pause 500
lcdout $fe,1
lcdout $fe, row1, "** RX TEST **"
pause 300

loop:
serin rxpin,n2400,1000,loop,[$66],#rx_data
lcdout $fe, row3,dec1 rx_data
goto loop


The TX/RX modules work fine, If I monitor the rx pin of the receiver I get exactly what I send, with no garbage at all.

Still on the rxpin set on the pic I get the same clean data.

Can somebody explain me why the PIC does not always print the correct data?
The amount of correct numbers recieved is about 60%.
I've tried with and without preambles, serin, serin2,hserin, but I always get the same results.
I repeat, connecting the rxpin to an rs232 everyhing's perfect. It seems the pic is not fast enough the get data! It has a 20Mhz clock with proper capacitors.
One more thing: The pic has all the sensors(18b20, SHT11, pressure, RTC) soldered around.
I'am trying to expand the initial project, adding a receiver.
Anyway, the code uses just the rxpin to catch data.
Thank you for your attention
Francesco

[skimask]

all my problems where solved using 'Search'...
You're in the minority...good for you...

Looks to me like you're using the internal oscillator on the 12F683 (i.e. GPIO4 & GPIO 5 are used). The internal clock is probably off the nominal 4MHZ by a bit on one side of the other (i.e. might be 4.1mhz, might be 3.9mhz, whatever). Jist of the story, you're 2400 baud is based off the oscillator...if the oscillator's off, the 2400 baud is off.
Write yourself a quicky program to generate a square wave of a known frequency, use a 'scope or freq. counter to count that square wave, and tweak the OSCTUNE to get 4mhz exactly.
Or try slowing down to 300 baud and see what happens. Slower baud rates are generally more tolerant of being out of tolerance.

[supersonic]

Looks to me like you're using the internal oscillator on the 12F683 (i.e. GPIO4 & GPIO 5 are used). The internal clock is probably off the nominal 4MHZ by a bit on one side of the other (i.e. might be 4.1mhz, might be 3.9mhz, whatever). Jist of the story, you're 2400 baud is based off the oscillator...if the oscillator's off, the 2400 baud is off.

Yes, I am using the internal oscillator at 4Mhz.


Write yourself a quicky program to generate a square wave of a known frequency, use a 'scope or freq. counter to count that square wave, and tweak the OSCTUNE to get 4mhz exactly.
Or try slowing down to 300 baud and see what happens. Slower baud rates are generally more tolerant of being out of tolerance.

Unfortunately I have no scope.... but the problem is that attaching the rxpin on a pc and monitoring with a serial port monitor, the receiver gets exactly what I send. So I guess the problem is somewhere in the PIC code, maybe some registers to be correctly configured or wrong code somewhere.
Is 2400 8N1 too fast for a 20Mhz powered PIC? I will try to slow down to 1200...

Thanks skimask

[mister_e]

Another way to teak the internal OSC is to program your PIC with _INTRC_OSC_CLKOUT set. The just grab the signal of the internal OSC.

Problem could be because of the latency SERIN/LCDOUT combination... well i know it's a slow baudrate... but on the other side there's that Timeout thingy that may timeout somewhere in a middle of a byte.... I would suggest to remove the Timeout... and my obvious suggestion... use HSERIN.. yeah a real USART + it's nice input buffer :D

HEY You have it for free on your 16F876... why not using it?

[skimask]

How does it at if you just continuously send that '$55-$55-$66-#data' string without any pauses at the transmitter? And get rid of that timeout in the RX code like mister_e said?

Also, if you plan on powering this thing up just once a minute, I wouldn't send the data just once. I'd send it 3, 4, 5, maybe more times in a row and do some comparison checking at the RX end.
You get 3 data in a row that are the same, you got good data, otherwise you throw it out. Or you receive 5 data chunks, 3 match, the other 2 don't, the 3 that match are what you take from it.
Whatever works...in the end, it turns out to be 'Supersonic Protocol version 1.0'.

As far as tuning your OSC...a far out idea that worked for me once a few years ago...(and I was bored and I was thinking back to a lesson my physics teacher taught many many moons ago with a water tank and two egg beaters)...
I generated a 1khz tone with my PC and put it on speaker... I set up the PIC to generate a 1khz tone thru another speaker... Then I listened to both of them at the same time.
If the tones are both at 1khz, they 'beat', and what I hear is constant...
If the tones are 1hz off from each other, I hear an increase/decrease about once per second as they beat and unbeat on each other.
If they're out in the weeds somewhere, it just sounds wierd.
Tweak the OSCTUNE and retried it until they were dead on...took a few days, but I got it...
Then I bought an o'scope... :)

[mister_e]

mmm, or use a Guitar tuner :D

[Ioannis]

Hi Steve. I don't think that the timout of the Serin could be of a problem since it gets reset as long as data are arriving. It times out only if there is more than the t defined idle input.

If the connection is made directly from the serial output of txer to the serial input of rxer, is the communication 100% succesful?

If it is, then I am guessing that the problem is caused by the modules. Maybe they loose sync when data that is not encoded properly are transmitted. Try to encode data like manchester or similar.

You are using a good preamble of $55, which is the best to stabilize the data slicer but your payload is not. And follows $66 that is pulling the data slicer a little.

Ioannis

[mister_e]

I based my assumption on the previous statement...

but the problem is that attaching the rxpin on a pc and monitoring with a serial port monitor, the receiver gets exactly what I send. So I guess the problem is somewhere in the PIC code,
now, what happen if you receive a sucessful $66 + 1 byte, you show it on the LCD, if the next byte is delayed enough, there shouldn't be much of a problem... but let's say it's sent in middle of LCDOUT or Timeout goto loop(which is barely possible.. slow baudrate, preamble sent, and wait for a synch.... ), there's still no input buffer, and maybe this could be part of the problem.... but yeah, i admit... chances are really slim seeing the TX Code.

No config fuses at all, no schematic... hard to tell what's wrong. Could be the usual noisy PSU...

[Jerson]

There are a couple of things I can think of.

Try increasing the preamble bytes $55. So, you send $55,$55,$55,$55,$55,$66,[data]
Try flagging the capture of qualifier in receive module to the LCD. So, you know if it is being captured correctly.
Perhaps the most important to me. Try keeping the transmitter on continuously till you get the receive part working correctly. Maybe the switching on/off of the transmitter is causing the receiver to go crazy.

[mister_e]

all good point, but this doesn't explain why the PC comm always works.

EDIT: have to be a paste error, but DEFINE OSC have to be in capital letter, unless... well i guess nothing would even works anyways...

[Ioannis]

The next bunch of data will come 2 seconds (at least) after. So I doubt that LCD stuf is a problem. It should work. Of course it could loose the data the moment that timout occurs, so it will grab the next data arriving. Is this happening Francesco?

How is the PC part connected? PC RS232 pin is connected to the Receivers output?

Ioannis

[supersonic]

Thank you guys for all your replies.

I added the preamble and qualifiers data after reading other posts regarding wireless communications, but it makes no difference if I use control bytes or not.

@Ioannis:
the receveir output is connected on portb.0. The same output goes to the pc through a rs232 level converter(sniff!!). Monitoring the output with the PC I don't loose a single byte.

@Mister_E:
I've tried using the HSERIN instruction, configuring the USART with your great pic multicalc, but results are even worst... I checked on the datasheet, usart rx should be pin 18(portc.7), I will triple check.
Of course :( removing timeout from serin gave no results
and sorry for the schematics, but it's very simple, just the display and the rx as in the code for the receiver side, external 20MHz clock with capacitors and pullup on MCLR, powered at 4.5V from a lab PSU(0-30V 0-5A). Could power be the problem? I'm not working at 5V because receiver datasheet says that max VCC shoud be 4.5V
I can't check the fuses now, they should be the default define for a 16f876a in pbp, just changed osc to hs

@skimask:
I send 4 bytes (2 preambles+1 qualifier +1 data)at least every 2 seconds(there are 2 pause 1000 in the loop) so it should be ok. And of course, when everything will work fine(at least better than this!!!) I will send data 3 or 4 times, as I need to send just 3 bytes I was thinking of calculating a checksum. Sum the 3 bytes, send a word with the sum. The receiver will get the data , sum them and compare the sum with the checksum word sent. Could it be a way of verifying data?

@jerson
Could the tx power switching be a problem even if a rx module alone(just powered and connected to the pc) works fine?

I also reduced serial speed to 1200. same problems.
Maybe I should first try to bypass the lcd and monitor on the pc a serout pin.

I think I went too far for my first picbasic project: a weather station with RTC, pressure bargraph and remote wireless sensor... but everything works fine apart this damn receiver...

[skimask]

I just noticed that your code has you powering up the TX and then sending straight away.
I don't think I've ever had good luck doing it like that. I've always given my TX module a solid 5ms to stabilize before sending out the preamble.
But that's just me, and that's the only way I've tried it. It might or might not be alright to transmit right after power is turned on.
And based on what you are saying about changing the baud rate numbers according to Mr.E's calculator and the problem getting worse, I'd still be inclined to think that your oscillator is off. Yes, your PC can receive it, but maybe it's able to receive 'sloppier' serial than the receiving PIC can.

[dhouston]

I've even used the data signal to simultaneously supply power to the transmitter and it works just fine.

Also, I see many people here saying the internal oscillator isn't stable enough but X-10 has used the internal oscillator in a 12C508A (in their MR26A & E) with a 9600bps TTL RS232 link for a few years now with no problems. Nor have I had any problems using a 12F629 @9600 using the internal oscillator.

[skimask]

I've even used the data signal to simultaneously supply power to the transmitter and it works just fine.
Good info for me then. I see an increase in data rates in the near future with my modules...


Also, I see many people here saying the internal oscillator isn't stable enough but X-10 has used the internal oscillator in a 12C508A (in their MR26A & E) with a 9600bps TTL RS232 link for a few years now with no problems. Nor have I had any problems using a 12F629 @9600 using the internal oscillator.
Do you use OSCTUNE as applicable and tweak it as required or have they just plain ol' been good enough in your experience?

[supersonic]

There are a couple of things I can think of.

Try increasing the preamble bytes $55. So, you send $55,$55,$55,$55,$55,$66,[data]
Try flagging the capture of qualifier in receive module to the LCD. So, you know if it is being captured correctly.


2 more preamble bytes!!!! Now I send $55,$55,$55,$55,$66,data and the amount of correct data received(and displayed on lcd) is more than 90%

I've also made a few changes: there is now a 5msec pause after the txer is switched on. 2400bps now works fine.

On the monitoring side I chenaged the hardware/software tools used. At first I tried a software called serial port monitor and the hardware was a max232 ttl<->rs232 transceiver.

Now I use a 2 resistor based rs232 adapter and the serial communicator software built into MicroCode Studio.
What I found is that now I can see the noise!!! There is a lot of junk along with correct data. Maybe the other software/hardware configuration were filtering that noise so I could only see correct data...

So I thought that adding more preamble could be an initial solution... it worked!
I will try the reliability of the communcation at longer distance to see if I need to add manchester routines...

[Ioannis]

That test results clearly show that the turn-on delay is absolutely necessary. Why not give your Txer more time to wake-up?? Say 100ms and test how it goes. Then you can decrease this wake-up time gradually.

Also if you send a long stream of preamps and only 1 or 2 data bytes, that is OK. No manchester is really necessary. But more than this... don't think whether to or not to. Just add it.

More, I would suggest for 100% reliable communication to add checksum or even better a CRC check.

Almost every receiver will output noise that could lead to false data reception when no transmission takes place. There is no mute function available on these cheap devices.

Ioannis

[supersonic]

Now that I solved(or going to solve...) reliability problems, I find that serin/serout work fine while hserin/hserout seem to have more problem...

Usart has been configured used pic multicalc.

I noticed that Mister_E adds the comment "Enable serial port & continuous receive" setting rcsta receiver.
Does it mean that hserin does not have to be in a loop? maybe something like:


hserin [#txpin]

main:
lcdout $fe,row1,dec txpin
goto main

could work?

[Ioannis]

If you use the example you post, then you will display only the first byte and continue to display that exact byte endlessly.

If you send serial data then the buffer of the 2-byte long USART will overflow and depending on the setup will stop with error flag raised or replace old bytes with the new ones.

Please refer to your Data sheet of the PIC you are using for more infos about the USART and its associated flags and control bits.

If serin/serout work then I am sure that USART will work better and without having PIC to deal with the data untill they are available to process. You must have something wrong with your setup.

As Steve stated without the whole picture we can only guess.

Here in Greece we had the ancient times the oracle at Delphi and Pythia making guesses and prophecies but nowadays I suppose it is better to see, measure calculate and then conclude. So if you want real help post all you got (schematics, cablings, software, defines etc).

Ioannis

[supersonic]

If you use the example you post, then you will display only the first byte and continue to display that exact byte endlessly.

As the define comment says "continous receive" I guessed it could've be continuos receive in background while pic runs the program, as hpwm.


If you send serial data then the buffer of the 2-byte long USART will overflow and depending on the setup will stop with error flag raised or replace old bytes with the new ones.

I included DEFINE CLROERR 1 to clear overflow automatically.
And surely I still have to study a lot....

[dhouston]

Do you use OSCTUNE as applicable and tweak it as required or have they just plain ol' been good enough in your experience?
I've never found the need to tweak it beyond the factory calibration. I programmed the 12F629 as an enhanced replacement for the 12C508A in the MR26. I've never had a complaint from hundreds of users. I'm sure there are many thousands using the original and I've never seen any complaints about it either.

My use of the data line for Vcc is with the NEC protocol where the shortest pulse/space is 500µS. (I've given examples in the Code Examples forum). Faster protocols might have problems but I have seen none.

[supersonic]

Finally!

At last I've been able to use USART!
On the tx side I changed serout from N2400 to T2400 and the rx started to display correct data! Data is sent 10ms after powering the txer.

99% of data is correctly showed on the display.

Now I have to mount the sensor and send acquired data along with a sort of checksum.

I could stay hours watching the display:0...1...2...3...4..... to see if some of my numbers gets lost. Watching it for a minute, no problems!
So here is the working code for the TX:


INCLUDE "modedefs.bas"

ANSEL=0
CMCON0=%00000111

define osc 4
txpin var gpio.4
led var gpio.5
power var gpio.2
i var byte

low power

loop:
for i=0 to 9
high power
pause 10
serout txpin,t2400,[$55,$55,$55,$55,$66,#i]
low power
high led
pause 30
low led
pause 1000
next i
goto loop

And, of course RX:


define OSC 20
Define LCD_LINES 4 ' Settings for a 4x20 LCD
Define LCD_DREG PORTB ' 4bit mode
Define LCD_DBIT 4 '
Define LCD_RSREG PORTB
Define LCD_RSBIT 3
Define LCD_EREG PORTB'
Define LCD_EBIT 2

DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 20h ' Enable transmit, BRGH = 0
DEFine HSER_BAUD 2400
DEFINE HSER_CLROERR 1 ' Clear overflow automatically

'LCD Lines constants
row4 con $d4
row3 con $94
row2 con $c0
row1 con $80
hser var byte

intcon=0

pause 500
lcdout $fe,1
lcdout $fe, row1, "** RX TEST **"

loop:
hserin [wait($66),hser]
hserout [#hser]
lcdout $fe, row3," hser: ",dec1 hser
goto loop

[Ioannis]

Congratulations!

Ioannis

[cdmiwa]

Supersonic,

I got a couple of the same wireless boards you got (Great price), except I got the RM1SGS2. I got some at at 433mhz and some at 315mhz. I can get the 433 to work, mostly, but I haven't been able to get the 315 to work (They seem plug compatible). Do you have a reference layout or anything I can try to get them to work?

Right now I've got them hooked up directly to the pic.

Thanks,