Wireless problem

[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?

[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.