RS232 by Radio

[Ioannis]

It is obvious Melanie that there is no data integrity check of any kind there,

So it is obvious too, that Bill needs a lot of reading and experimenting onthe subject, which is difficult by default.

Bill, these modules needs DC balancing. This is what Melanie is telling you. If you don't know or want to do that then choose any other module that is doing it inside the can box. There are some for treu RS-232 communication.

Otherwise you must have to do that using Manchester encoding-decoding along with some kind of error check code.

Start slowly, searching the forum. All are there. But give some more details on the project.

Ioannis

[Bruce]

A solution would be to:

1. Start TIMER1 and enable interrupts.
2. Wait for a "!" then grab the message then disable interrupts.
3. If TIMER1 overflows and the interrupt occurs - execute the "Lost_Signal" code.

That approach works. I've done this in an old project for a momentary RF decoder.

This is just a small chunk, but it shows enough to get the point across...;o}

ASM
RESET_VT
    movwf  wsave       ; Save W
    swapf  STATUS,W    ; Swap STATUS to W (swap avoids changing STATUS)
    clrf   STATUS      ; Clear STATUS
    movwf  ssave       ; Save swapped STATUS
    movf   PCLATH,W    ; Move PCLATH to W
    movwf  psave       ; Save PCLATH
    movf   FSR,W       ; Move FSR to W
    movwf  fsave       ; Save FSR
    
    ; Do interrupt stuff here
    bcf   T1CON,TMR1ON ; Stop Timer1
    clrf  TMR1L        ; Clear low byte
    clrf  TMR1H        ; Clear high byte
    bcf   PIR1,TMR1IF  ; Clear Timer1 interrupt flag bit
    clrf  GPIO         ; Clear outputs on button release
    clrf  MATCH        ; Clear match variable
    
    ; Restore FSR, PCLATH, STATUS and W registers
    movf  fsave,W      ; retrieve FSR value
    movwf FSR          ; Restore it to FSR
    movf  psave,W      ; Retrieve PCLATH value
    movwf PCLATH       ; Restore it to PCLATH
    swapf ssave,W      ; Get swapped STATUS value (swap to avoid changing STATUS)
    movwf STATUS       ; Restore it to STATUS
    swapf wsave,F      ; Swap the stored W value
    swapf wsave,W      ; Restore it to W (swap to avoid changing STATUS)
    bsf   T1CON,TMR1ON ; Re-enable Timer1 before exiting interrupt handler
    retfie             ; Return from the interrupt
ENDASM
 
MAIN:         
    ' Fire up Timer1 before entry to serial input routine
    T1CON.0 = 1
    
    ' at 4MHz Timer1 overflows in ~65.5mS if no Synch byte
    ' and serial data arrive before over-flow.
    
    ' Wait for Synch byte, then get new inbound data & checksum
    SERIN2 D_IN,BAUD,[WAIT(Synch),DAT_IN1,DAT_IN2,CHK_SUM]
    
    T1CON.0 = 0    ' Stop Timer1 once data has been received
    TMR1L = 0      ' Clear low byte
    TMR1H = 0      ' Clear high byte
    
    ' / **** Begin data validation **** /

You'll want to use an assembly interrupt since on interrupt would hang waiting for the
SERIN2 routine to finish.

[Bill Legge]

Bruce,

Thanks, I've not yet tried out the code but it is exactly what I wanted. I note that you work at Renton - that's the place I get my LINX radio modules from - I am using the 433 MHz Long Range type - easy to use and reliable. Thanks

Melanie & Others

I am obviously not getting my point over. It would be a foolish person who claims an expertise in radio communications but I'm far from a beginner (but I am a relative beginner at PBP and Assembler stuff). I do understand data encoding, modulation, statistical nature of noise, error detection, error correction, CRC, Manchester encoding and lots of other aspects of telecommunication - it has been the area I've worked in for many years.

However, this does not make me right and you wrong but please, if you are interested, have a careful read of the following:

1. When in range my radio link works perfectly.

2. The code is SERIN2 RXPin, 200, Lost_Signal, [Wait(!), My_Data]

3. Now lets assume that the robot goes out of range.

4. The Rx module receives noise that causes the RxPin to leave the idle state.

5. The software now sits there and waits for a '!' and it will only arrive due to the random nature of noise (a very large number of monkeys typing away at random will, after a significant delay, accidentally type a '!'). The software grabs the gibberish that follows and some software can now deduce that it is gibberish and take appropriate action. For example using a Cyclic Redundency Check, look for some transmitted patern '101010' and so on.

6. But what I was looking for is a means of taking action BEFORE the noise makes a '!'

The cause of this difficulty is using the WAIT("!") approach and combinig it with the 200, Lost_Signal.

Lost_Signal is useful when there is a squeltch type noise suppression or the signal is way stronger than the noise and false triggers are not likely to occur.

WAIT("!") is useful to synchronise the Tx with the Rx.

I guess one just has to abandon the business of using WAIT("!") and instead grab everything the receiver gets and use error detection/correction to deal with the noise. Or use the stop-watch approach?

I was looking for anyone with experience in this area.

Regards Bill legge

[Ioannis]

Hi Bruce. In your idea, step 2, I believe he will still have the sam problem, as the Serin2 command waits for he "!" character. If receiver is out of range then this "!" maybe will never come, only static. So, the timer may have overflown but the Serin2 still waits for then never coming character.

Ioannis

[Acetronics2]

Hi, Bill

In some µP PPM R/C decoders, there's only an 8 bit sequence ( a number ) placed just before the data sequence.

If number is the good one, data is considered valid ...if not, the Fail safe sequence is launched.

so, the receiver analyses all incoming data, not being locked on HARDWARE waiting for the "!"

Alain

[Melanie]

Uhhhh... then why not just make the Qualifying character more complex? Instead of just "!" which gives you a 1:256 chance of random 'monkey typo' hitting the jackpot, make it "Coffee!" which now makes it a 1:72057594037927936 chance.

Lets face it... there's ALWAYS going to be junk comming in from the Receiver at the extremes of range. Now you either kill it via additional Hardware, or by Software, or a combination of both.

I personally hate SERIN. It's a command that cuts corners to provide complex functionality for folks who don't know any better. It's not a professional solution (just search this forum to see how many people have posted their woes with it's usage). It's biggest downfall is that it is designed for 'perfect' communications (which only happens in a nice perfect wired environment). As soon as you go into the real world, and go wireless, the deficiencies in SERIN causes it to fall apart (which is what you are experiencing). My recommendation is to use the Hardware USART and read-in byte-by-byte, handling the Qualifier and Data integrity through your own routine. Using the Hardware USART route, your PIC isn't bogged-down with software timing for the arrival of individual bits... leave that to the USART and just pick-up the byte when it's finished and ready in the buffer. If it's junk, and timing and bits are all over the place (like random noise), then the USART won't act on a lot of it, and the gibberish that does come through will be handled by your Data integrity routines.

[Ioannis]

Well with all the respect Melanie, i think his problem is to just get out of the 200msec of waiting for the ! or whatever this string will be.

If there is a continues noise in the receiver output, either Serin or Hserin will be constantly triggered, and never will get this lost_signal flag.

The problem is before the reception of any characters, not after!

Ioannis