On Fri, Mar 18, 2011 at 9:14 AM, mattschinkel <[email protected]>wrote:
> 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. > http://focus.ti.com/docs/prod/folders/print/cc2500.html about $2. Vasile > > 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. > > -- 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.
