Ok, so let's try to get it in to jallib the way it is, but with a few small changes so it complies with jallib style guide.
By the way, it is a real possibility that someone may want to use this for networking some day. It is a cheap alternative to other wireless devices. I was thinking of trying MRF24WB0MA, but it may be too expensive for some people. Matt. On Mar 18, 8:36 am, Henk van Broekhuyzen <[email protected]> wrote: > 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.
