Man, this can be a good article ... On Dec 15, 12:38 am, "funlw65(Vasi)" <[email protected]> wrote: > Personally, I can solve this in a quick way: > - putting "maximum_CRC_errors" as a parameter and let users define > what is the maximum. > But which will be that number? 5, 10, 15? What number a newbie will > chose? Based on what? > This is why I'm asking experts :) . > > This is how I understand the thing: > I suppose a cable in a normal environment, will behave as in case > number one, described by Marchaudon. The worse environment will be, > the more and frequent failures you will have. So, choosing the right > number of maximum failures in line (one after another) depends on > environment and you can judge the environment only making tests in > that environment. So, I propose that this variable to be a parameter > to those last procedures inside library. > > It is right? It is good to have such functions inside the library, or > their place is inside user application? If is inside a library, then > is handy for everyone. If not, then it must be in an included sample > program to avoid reinventing the wheel. > > Vasi > > On Dec 15, 12:15 am, "funlw65(Vasi)" <[email protected]> wrote: > > > Hi Kiste, > > > Both things you request are in library. The readable temperature > > (Celsius) and a global flag about the status of CRC. > > > The problem is inside those procedures which gives you the readable > > temperature. Is there a loop where you read the temperature with CRC. > > You can leave that loop only if a good CRC happened. So, you need a > > protection against freezing your program. > > > Now, we have two notable cases here: > > > 1. The case of Marchaudon. He used 5 temp. sensors on a 20meters three > > wire cable 10 years without a single problem. In this case, a bad CRC > > can happen at every 5 readings so, you will not be stuck inside > > library. > > > 2. The case of Vasile where the cable had an increased electrical > > resistance because of heat. There problems were solved only rerouting > > the cable (so, you can get stuck inside that loop in library). > > > Now, my question was, what is the maximum acceptable number of cycles? > > How many bad CRC's we can receive in line (one after another) before > > we can declare that the cable (or sensor) have problems? So, you must > > be secured against such a case because you also must take care of > > other sensors and tasks. > > > Vasi > > > On Dec 14, 10:14 pm, Oliver Seitz <[email protected]> wrote: > > > > > But, again, how many cycles to > > > > consider as maximum? > > > > I haven't had a look at the lib yet, perhaps this fits badly... But how > > > about giving the read temperature, abd a flag if the CRC was ok? The lib > > > user can then decide in his program what to do with that. > > > > Greets, > > > Kiste
-- 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.
