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.
