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 -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser ------------------------------------------------------------------------- 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
