On Mar 17, 2:45 pm, Henk van Broekhuyzen <[email protected]> wrote: > Hi Matt, > Using without CRC byte is possible. I forsaw this. > Just do not define "const bit spi_rf12b_use_CRC_ see description on > line 53 of spi_RF12B.jal.
I do understand, but crc is not a part of the rf12b module's workings. The only think rf12b is for, is to send data. crc could be a part of a package/protocol library. > The other element (length op payload) or terminating zero (see command > T and R). Must be there > or you have to use the length in SLIP or TCP/IP package. > The FSK transmission mode of the RFM12b requires that the bytes are > send without pause (or you > get a underrun error) and if you do not stop receiving when the > transmitter stops, you get garbage > at the end of your message (zero's if you are lucky). Yes, this payload length does seem to be a part of rf12b. This is fine, but it does not necessarily mean that someones packet will be the same size as one transmission. Someone may want to send a packet that is 1 byte, or 1000000 bytes. One large packet could be sent using more then one transmission. Here's a example: 1. User sends 100 bytes to a packet library 2. packet library encodes the 100 bytes of data into a packet (encodes crc, length, etc), then sends this packet to rf12b library. 3. rf12b splits and transmits 10 bytes at a time (10 times), for a total of 100 bytes. 4. receive rf12b picks up 10 bytes at a time and sends this to the packet library. 5. packet library puts each received back together (decodes crc, length, etc), until it gets the entire packet. 6. receive user now has one packet that is 100 bytes. rf12b can deal with acks/nacks if the user chooses and re-transmit if necessary. I do agree with this, however TCP/IP also has this feature, so someone may want to turn the feature off. A feature like this could also be done in a packet library. I know you didn't implement this yet. > As far as I know, my protocol is an incomplete SLIP. > I did not finish SLIP because of 3 reasons: > a) Code filled already up my 16F73. > b) As state on the end of the .doc file: a RFM70 might be a beter > alternative and it has a protocol build in the modules. > c) The RFM12B.s did not have a turn-around time that is stable enough > for a project I discuss with Joep Suijs. The RFM70 might. > > But if you want to implement SLIP pakages and forget about mine: The > basic routines you need are available and > if you do not use my packet functions, the compiler will remove these > functions as unreacheble code. Yes, the compiler would remove these functions, but someone may not want to read through the extra code. Again, how can I use your protocol on another wireless device? Again, these are only suggestions. It is great the way it is. Matt. -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
