Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Communication between pics using rf module..

Status
Not open for further replies.

osjovi1

New Member
Hi everyone, I need to communicate two pics using Rf modules, the modules that i'm using are: technology LINX TXM-869-ES and RXM-869-ES, the pic 16f873, the programation that i use is in C, i'd like to know what routine i have to use without the need to use encoders.
Thank you.
 
What speed (baud) do you want to use? Also, pay particular attention to page 9 of the ES receiver module design guide. You will probably need to use the audio section to get squelch, and your speed will possibly be limited to less than the 56 kbps claimed in the spec sheet.

John
 
Last edited:
I reworked 5 baseball scoreboard controllers with ES devices. jp is right: build the squelch, it makes All the Difference. Follow Lynxs' layout rules too.

These units are solid to ~200' and workable to >500'. This was a redesign, previous used the LC series: being A.M. & ~400MHz, interference was problematic.

They run: 9.6k baud, 8/N/1, data block={sync(5), unit address(1), keycode(1), BCC(1)} BCC is (addr+key) inverted, sync is a $55 ("U"). Good Hunting... <<<)))
 
BCC is (addr+key) inverted

Nice. So on the receiving end you just invert BCC again and subtract the address? If the result isn't equal to the key then you know there is something wrong?
 
I've not done it that way, but it seems ok. Block Check Characters are calculated & compared: if not match=bad block. Usually blocks are Much longer, so your method wouldn't apply, but Thanks, I like it & will keep it in mind for short blocks.

Its' big advantage is ease of generating: just add each relevant byte & ignore overflow. At block end, invert & send. On Rx: wait for sync, on seen: throwout following syncs, on 1st non-sync: save to buffer & start BCC calc with its' value.

This requires either fixed length blocks Or one of the initial bytes being block length. Note, I send 5 sync chrs to allow for RF interference/latency <<<)))
 
Status
Not open for further replies.

Latest threads

Back
Top