Hi guys,

Got a small problem when trying to test what data has been received by the PIC. What i am doing is sending out data, when the receiving end processes the data, it sends "ok" back allowing the PIC to know when it is clear to send more data. I am having trouble reading in and testing the "ok"
The way i am testing the incomming message is by moving the contents of RCREG into a file called store. From here i subract d'79' which is "o" in ascii and test the zero flag bit i.e. if it is "o" then the zero flag will be set. Then i go on to test the "k" part of the message.
This is where the program gets held up, it sends out the required data perfectly, but then stops when testing for "ok" Heres a snippet of code where i test the zeroflag bit:

UART MOVF RCREG, W ;
MOVWF STORE ;
GOTO MODE ;

MODE
BCF STATUS, Z
MOVF STORE, W ;
SUBLW D'79' ;
BTFSC STATUS, Z ;
GOTO SENSOR2 ;

Any pointers would be greatly appreciated thanks

hi,
Can you say what the 'receiving end' is, example PC ??

If you are using a MAX232 on the PIC uart i/o and its talking to say a PC, the PC program could control the CTS line, which the PIC could read.

If not, why are using 'ok' as ok to send, why not a single used ascii control code or one of the ascii commands for clear to send?

Eric

It would be a lot simpler if you used the assembler to convert from ascii to decimal.

Use,
sublw "o"

Doing this ensures that you compare with 111 which is "o" and not 79 which is "O".

Mike.

sorry i should have said,

I am using two telegesis wireless modules, one connected to my sensor circuit via MAX232 and PIC16F74, and the other connected to the PC where the telegesis terminal software is running. I am sending out the at+bcast:00,"data" from the sensor circuit, which broadcasts the message to the network. This part works since the pc end is recieving the data but for a limited time i.e. the sensor circuit is sending out too much for the node to handle. When the sending node completes the transmit it confirms by sending "OK" which is what i am trying to read with the PIC. So that the PIC is synchronised with the wireless node.

Hope this clears up what i am trying to do

Thanks again guys

Originally Posted by imhereithink

sorry i should have said,

I am using two telegesis wireless modules, one connected to my sensor circuit via MAX232 and PIC16F74, and the other connected to the PC where the telegesis terminal software is running. I am sending out the at+bcast:00,"data" from the sensor circuit, which broadcasts the message to the network. This part works since the pc end is recieving the data but for a limited time i.e. the sensor circuit is sending out too much for the node to handle. When the sending node completes the transmit it confirms by sending "OK" which is what i am trying to read with the PIC. So that the PIC is synchronised with the wireless node.

Hope this clears up what i am trying to do

Thanks again guys

hi,
I follow your description.
Have looked over the telegesis site, for some reason at the moment my downloads from that site hang up, I'll try later.

As Mike points out the 'AT' protocols are upper case "OK".

Software control of 'clear to send' can be source of problems in a asychronous TX/RX serial system.
Problem is, by the time the transmitter gets/decodes the 'acknowledge' its transmitting.

Is it possible you can modify the receiving program in the PC, so that it forms a data string when it detects the 'at+bcast' identifier,, any partial unsynched string would be dumped?

Can you post your full code as an attachment, I'll run it thru my simulator to see if I can find any obvious bugs.?

Does your system work ok, if the PIC and PC serial ports are connected by a cable,,, hardwired?

Eric

Hi eric,

Thanks for the help, iv attached the asm file for you to have a look at. When i dont check for the received "OK" The program works perfectly, but the wireless node cant cope with the amount of data being sent out. When i check for the "OK" it only transmits the first set and hangs up when testing for "OK".

Tnaks again, greatly appreciate this

Thanks for the code eric,

That is some piece of code you have written there I havnt tested it yet, i am just reading through it all, making sure i understand what is going on with all the new sub routines. I will let you know how it goes. You deserve a beer or two for this

Many thanks

Just tested the program,

It manages to send out the first set of data, this is what the receiving node displays: "BCAST:000D6F0000063D1C=AA106" but it hen does nothing, it seems as if the program isnt receiving the OK from the node. I tried looking for LF/ OK/ CR/ to no avail

Originally Posted by imhereithink

Just tested the program,

It manages to send out the first set of data, this is what the receiving node displays: "BCAST:000D6F0000063D1C=AA106" but it hen does nothing, it seems as if the program isnt receiving the OK from the node. I tried looking for LF/ OK/ CR/ to no avail

hi,
Is there any way you can confirm that the PC is sending the "OK" back to the PIC??

I would test it by using a second PC/Laptop and using a cable connection between the PIC and PC's serial port.

If you have upgraded the asm, post a copy and I will re-run it for you.

Eric

What i reckon is happening, is the sending nodes buffer is getting over run with data, so even if the "OK" is being sent back it wont be able to continue sending. I was thinking of implementing the xon xoff handshaking, but unsure how to set this up. Any ideas?
This is from the telegesis data sheet:

"When using a channel there are no limitations to the payload, so a buffer overflow can occur when sending too much data at once or where the recipient is temporarily out of reach. To avoid a buffer overflow XON/XOFF handshaking is used"

The only changes i did to the program was to change the receive characters to D'13' and D'10' looking for LF and CR.

Thanks again

I will go and find the PROCOMM and try that out. The module is the ETRX1. Im posting from work in the uk