Ik ben al een tijdje bezig met een project waarbij ik 2 pics met elkaar wil laten communiceren. Alles lijkt prima te werken, ik gebruik serin en serout, dat vind ikzelf prettig werken en bovendien heb ik de timeout functie nodig. Ik heb serin/serout beide hun eigen pin toegewezen omdat ik wireless wil werken en mij dat wel zo handig leek.
Probleem is dat als ik de draden vervang door rf modules, in mijn geval de bekende Velleman RX433N en Tx433N er helemaal niets meer gebeurt. Ik heb zelf geen scope meer dus kan niet zien wat er mis is. Ik lees hier en daar iets over Manchester codering waarbij clock en data samengevoegd worden, maar ik lees hier en daar ook dat het sommigen kennelijk wel lukt om gewoon domweg serout pin aan de input zender te hangen en serinpin van andere pic aan transmitter en vice versa. Hoe zit het nou ? Wat doe ik fout ? Kan iemand die het wel gelukt is mij misschien een beetje verder helpen??????
Het is mij destijds wel gewoon gelukt. Met een datacontrole in de software.
Ik heb de code van Mr Chaos gebruikt uit dit topic http://www.circuitsonline.net/forum/view/61410. Verder heb ik inderdaad gewoon de rx en tx gebruikt en die aan de ontvanger respectievelijk de zender gehangen.
Maakt het wat uit dat hij HRSin en HRsout gebruikt terwijl ik gewoon Serin/Srout gebruik ?
Baudrate staat op 9600 met parity
SerIn PORTC.7 , 24660 , Main , RNR , BFRec , [Str FTDAT]
Mijn anternne is gewoon stukje draad 1mm kern en 17,2 cm lang. Dat is toch ok ? Heeft het wellicht iets met timing te maken ? Echt frustrerend zo iets grrrrrrrrrr.
Ik geloof dat het 2400 moet zijn. Maar m'n project met 'n 433Mhz zender ontvanger is nog niet zo ver gevorderd dat ik dit zelf heb kunnen uittesten 
Dit is mss ook handig http://www.uploadarchief.net/files/download/433mhz%20tutorial.pdf
24660 klopt wel staat voor 7 bits met neg parity op 9600 baud. werk ook prima met draadjes, Het gaat echt mis via de ether. Het lijkt wel of ik compleet niks ontvang. Ik had het probleem eerst ook met draadjes, maar toen bleek dat ik de serin pinnen gewoon met een pulldownweerstandje naar massa moest leggen, dat werk nu perfect. Ik ben allen niet zo thuis in die modules, lijkt me simpel maar er gebeurt niets:S
Veelste hoge snelheid.
Er staat een maximumsnelheid in de datasheet van de zender en ontvanger neem ik aan?
Bij mij ging het op 1200/2400. Wel met een setje uit China.
baud rate moet 2400 zijn 
Met welke code dat overeenkomt ga je even moeten opzoeken, staat 'n voorbeeld in pdf overigens in picbasic.
Ah, das interessant, dat wist ik niet, als dat echt zo is dan snap ik het wel, goh, 9600 lijkt tegenwoordig al zo slow 
Hey bedankt ik ga proberen stapje terug
BaudRate 8-bit no-parity inverted 8-bit no-parity true 7-bit even-parity inverted 7-bit even-parity true
In de datasheet van die zender staat een datarate van 4800bps:
http://www.velleman.be/downloads/7/rx433_datasheet.pdf
Succes .
Ik ben inmiddels terug naar 1200 Baud, maar ik ontvang soms niets en soms alleen maar vreemde bagger en als ik de zender uitzet merk ik niet echt veel verschil. Heeft het iets met synchronisatie te maken misschien, moet ik "wait" XYZ whatever gebruiken, of werkt het alleen met hrsout en mist serin stop/start bits.Hoe lang mogen de Srings zijn die ik wil verzenden ?
Adhy
Probeer niet jezelf te zijn, je bent ut al...
Hoe voedt je de tx-module? Uit de PIC? Weet je zeker dat de 'ie genoeg krijgt? Zakt hij tijdens het zenden niet teveel in? Eventueel een elco toevoegen om de inzakking te verminderen..
[edit] Je hebt geen scoop beschikbaar..
Ik denk dat de voeding wel ok is, ik gebruik altijd de 5V spanning uit de USB-poort van mijn notebook, en hebben die modules bijna niets nodig als ik de specs bekijk.
Ik had ook veel moeite om mn eerste connectie met 433Mhz op te starten: http://www.circuitsonline.net/forum/view/67968 . Bij mij was de truc om heel veel te zenden: je moet een verbinding in stand houden. Ik zou zeggen dat je je verzend chip eerst constant a's laat zenden om te kijken of je iets van een verbinding tot stand kan krijgen zonder manchester coderingen e.d..
Ik ga dat proberen, ik snap alleen niet dat ik zoveel verschillende dingen lees, de een werkt het kennelijk direct zonder poespas, de ander heeft het over Manchester of over 50/50 characters sturen. Dit is ook iets...
When the transmitter is activated, the receiver "syncs" with the transmitter and much of the noise disappears. So far so good. The problem is that we don't want the transmitter powered up all the time - it would use far too much power. So when we power it down the garbage returns. Our little tidbits of data get lost in a sea of noise. This situation also exists when doing two way commuication. The PC must, therefore, filter out the noise. The VBasic software reads every byte that is received, looking for a valid packet. The "Mailbox" protocol is designed to be simple yet robust enough that only valid data gets through. Each packet is formatted as "UUUUU ::AaDdDdDdDdDd...Xx". The "U"s are 1010 characters that aid the receiver in synchronizing. The "::" are the start bytes. Until "::" is read, no data is passed. The receiver must know the length of the incoming packet. Once a valid packet is identified bytes are read until this length is reached, then a checksum byte is compared.
Another issue arising from the need to stay synchronized is that characters with long periods without changes, like 0 or 0xFF, can cause the receiver to lose sync. Radiometrics recommends using "5050" characters only - characters with a balance of ones and zeroes. This pretty well kills an 8 bit protocol. Instead I convert to ASCII Hex, then to 5050. ASCII Hex converts the transmitted byte to two characters, i.e. the number 168, which is equivalent to 0xA8 hex, is converted to "A" followed by "8". "A" and "8" are in turn converted to 5050 before transmission and converted back at the other end. The PC software abandons any packet that contains non-5050 characters.
Maar dat klinkt allemaal beetje omslachtig, hoe kan het dat het bij de een wel wil en bij anderen niet ? Hoe zit het nou echt ??
Beetje te snel was ik nu misschien hier, ik las net je link
http://www.circuitsonline.net/forum/view/67968 .
Ik ga hier maar eens mee expirimenteren en dan zie ik wel weer, voorlopig weer genoeg dingen om uit te proberen, bedankt !
Bart Hiddink
Bart Hiddink is Ideetron; electronics and projects, http://www.ideetron.nl. LoRaWAN Nutcase.
De meeste modules kakken overigens bij 3kHz al in.
3600 bps is wel het maximale.
2400 bits/s is een mooie waarde.
Een paar keer 0xAA zenden en dan een SOH (0x2D en 0xD4) is voldoende.
Daarna kun je de data goed oversturen.
De Hamming codering is trouwens geen overbodige luxe als je wat afstand wilt overbruggen.
Dat is ook goed te gebruiken als je veel data stuurt waarin veel '0'-en of veel '1'-en achter elkaar zitten.
Dat vindt de UART niet zo leuk.
De Hamming code halveert wel je data rate..
Ben mij momenteel idd in de Hamming code aan het verdiepen, ik wil namelijk behoorlijk lange data strings gaan verzenden. Hamming code lijkt me dan idd wel een must, ben nu over 2 bit error correctie aan het lezen. Wel leuk trouwens