Karl Reichert wrote: > Karl Reichert wrote: > > Karl Reichert wrote: > > > Karl Reichert wrote: > > > > Jan Kiszka wrote:> > > > > > What I would analyse if I were you: > > > > > - Is the request frame sent in the right slot according to the > > > sender? > > > > > > > > Well, now I have another weird behavior. The slave sends a request > > > > calibration frame in cycle no 45849 and sets Reply Cycle Number to > > > 97655. As I'm > > > > using a cycle length of 5 ms, this means the slave wants the answer > > more > > > > then 4 minutes in the future, which is for sure to far away! > > > > > > > > This behavior and the one observed before points to a problem when > > > > calculating or setting this reply cycle number. How can one > configure > > > how big this > > > > value is set (how big the offset between request and reply should > be). > > > If > > > > this is done automatically, in which function is it done? > > > > > > I digged deeper into the code and here are the results. Please see > > > attached file to see me changes. Every change is marked by /* REK > debug > > */: > > > > > > My first step was to go into module tdma_worker.c, function > > > do_request_cal_job(). I printed the values of tdma->current_cycle and > > job->period. > > > job->period is always 1, in all calls of this function. > > tdma->current_cycle of > > > course changes, but it holds an old value, for example 1521 cycles ago > > with 1 > > > ms cycle length. > > > > > > As a quick hack, my second step was to substitue job->period with an > > > constant value, 2500 in my case. Now the synchronisation works, of > > course > > > slowly, but it does. > > > > > > The error must be the "wrong" value of on of those two variables! > > > > > > This leads to a few questions: > > > 1) Is it right that job->period is always 1? > > > 2a) If yes (what I do not believe), do you have an idea why > > > tdma->current_cycle holds an "old" value? > > > 2b) If not, where is this value calculated and where for? > > > > > > > Hello list! > > > > I did some further testing and this is what I found out: > > > > 1) tdma->current_cycle holds the right value! I set the tdma cycle > length > > to 10s (yes, seconds) and also started wireshark on the master. I > checked > > the value of this variable and when I compare it to what wireshark tells > me > > about the sent sync frames, I see that this value is correct. > > > > 2) The slave is able to sync with this long cycle length. The reason for > > this is that job->period is still always 1, but now there is enough time > > (nearly 10s) to send the req cal frm. > > > > > > This leads me to the following conclusions and questions: > > > > 1) Again ... why is job->period always 1? Is this correct? I still don't > > understand where this variable stands for and why we do not simply add > any > > other constant value (like 1 or sth bigger). > > > > 2) If it is correct that job->period contains always 1, is it > problematic > > to set any higher value there (like I did in my quick hack, see last > mail)? > > If yes, wouldn't it make sense to make this configurable (make > > menuconfig)? > > > > 3) If it has to be always one, running tdma with cycle length 1ms would > > mean, that the slave must be able to send a req cal frm after a sync frm > > within less then 1ms. Is this to much for a high end Core 2 Duo? Don't > think so > > ... > > > > After checking the sourcecode again and playing around with tdmacfg -p > parameter, I see now the meaning of this job->period variable. When one > provides -p 1/2 this variable holds the value 2, so that the frame is sent > only > in every second period. So it makes sense that it normally holds 1 in my > case. > > So, what I see is the following: > Without changing the sources, it isn't possible to set any offset between > received sync frm and sent req cal frm. The TDMA module in slave mode > always sents the req cal frm right after receiving the sync frm (of course in > it's timeslot). It sets the "reply cycle number" field in this frame always > to the next cycle number. This behavior is hard coded and not configurable > via make menuconfig. > > As my slave isn't able to send the req cal frm so fast, it isn't able to > synchronize when a short tdma cycle length is configured (1ms). Is this a > problem only of my station? > > Why is it not possible to configure those offsets? > > Please advice! > Thanks ... Karl
To keep you up-to-date, just in case anyone cares ;) With the dirty hack, after synchornization is finished, sending data frames every 1ms works fine. So my machine isn't to slow at all, just the do_request_cal_job() seems to be problematic. I will dig deeper into this now with I-pipe Tracer and give further information when available. Regards. Karl -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
