Wireless problem

[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

[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

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