Wireless problem

[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

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

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

[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

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