Hi Matt, You asked: " Again, how can I use your protocol on another wireless device?" My answer: This depends on what other device and what driver software is available. Mark that the pre-amble characters (to lock the data-rate timing) is defined by the module. I do not think that it was ever the intension of the manufacturer that it could communicate with modules of other brands, or to comply to international standards. They aimed for the low-cost applications where the dominant bluetooth is to expensive.
It was never my intension to define a protocol. The project was only started to investigate: "what is possible with this low-cost modules". Well, now I know that on short distances they are rather OK, but for longer distances there must be a layer on top that re-transmits when no ACK is received (like SLIP). They are also appilicable when it is not critical that a currupted message is ignoired On the other hand: Why sould one combine different brands, as these modules are so cheap. I paid less that E10,- for the RFM12B with connector, and half of this for RFM70's I am investigating now. Henk. On 17 mrt, 22:51, mattschinkel <[email protected]> wrote: > 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.
