[Tinyos-help] DTN on tinyos
Hello, I am intent on testing DTN protocls on sensor network nodes operating under tinyos. I would like to know if anybody knows any implementation for these motes. Thanks in advance for your attention Regards Patsali Konstantinia ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] ZigBit Amp (ATZB-A24-UFL) sleep issue
Thank you, I will check Iris mote tomorrow and see whether it is as high as zigbit amp or not. I found the following sentence on the REB231FE2 application note (radio extender board always from atmel and with the same frontend as the zigbit amp): The SE2431L operating mode is determined by control lines CTX, CPS and CSD. The default configuration connects CPS pin to EVDD via R31. This means that in receive mode the LNA will always be enabled for maximum sensitivity. Enabling low power RX bypass mode requires removing R31 and R32 populated with 0R resistor Maybe they made something similar with the zigbit amp? It sounds strange, but never knows... Ugo On 09/29/2012 06:46 PM, András Bíró wrote: Hi Ugo, Sorry, I took that picture a long time ago, I don't remember the avg. The measurement wasn't quite accurate eighter, I just wanted to show you what to except from an atmega128/1281 mote. Andris On Sat, Sep 29, 2012 at 11:19 AM, Ugo Colesanti colesa...@dis.uniroma1.it wrote: Hi, I've used a cheap multimeter, I can check with my oscilloscope if I get these spikes too. BTW, with the multimeter I have an avg value that shows 1-2uA with telosb and, if I remember well, with Iris too (but I should recheck next monday). In any case it was not as high as the zigbit amp that steadily shows 160uA. Just to know, in your figure, what is the avg current? Ugo On 09/28/2012 10:01 PM, András Bíró wrote: Hi Guys, 160uA doesn't seems so much. I don't think it's the amplifier, I suspect the timer stack is running on your mote. As far as I remember the timer stack is always running on atmega128(1) based motes, and it consumes quite a lot of power (it's only an 8 bit counter, and the overflow interrupt is inaccurate, so the MCU wakes up for resetting the counter about 5 times in a second) How do you measure the power consumption? You can clearly see the spikes on an oscilloscope, for example this is the power consumption of the timer stack on iris: https://www.dropbox.com/s/cmidjtple52jvv5/uresj.png Andris On Tue, Sep 25, 2012 at 6:05 PM, Ugo Colesanti colesa...@dis.uniroma1.it wrote: Thanks Janos, I already tried to change this pin but the power consumption increases to approx. 5.5mA (I suppose because the amplifier is activated). In particular here is what I made: 1) I first modified MotePlatformP adding: DDRC = 0x02 ; PORTC = 0x02 ; - power consumption 5.5mA DDRC = 0x02 ; PORTC = 0x00 ; - power consumption 160uA 2) Then I restored the MotePlatformP component and modified NullC by adding the same lines in Boot.booted with same results. 3) I replace those lines with GeneralO interface (it should be the same, but just to be sure) and adding GeneralIO.makeOutput; GeneralIO.set() / clr() , again, with same results. No luck :( Ugo On 09/25/2012 04:55 PM, Janos Sallai wrote: Ugo: I think I had the same issue at one point. Try setting HplAtm128GeneralIOC.PortC1 to high. Make sure that you set it as an output pin first. Janos On Tue, Sep 25, 2012 at 3:58 AM, Ugo Colesanti colesa...@dis.uniroma1.it wrote: Hi all, I'm using two zigbit amp with tinyos based on the latest eth code found on the old tinyos-contrib cvs. Everything seems to work fine (I receive and send packets even in LPL) except for one test that I'm used to perform on new platforms: I burned the Null application (including the ActiveMessageC component as it should be done for IRIS platforms) and measured the current draw of the node. Based on the datasheet, the expected current draw should be lower than 6uA but in my case I'm not able to reach values below 160uA. I forced MCUSleep to return ATM128_POWER_DOWN as lowest state and disabled the amplifier pulling low the PC1 port of the cpu but nothing changed. I noticed that the CPS pin of the SE2413l (the front-end) stays high which avoids the fron-end to go in sleep mode and I think that this is the main reason of the unexpected power consumption. Unfortunately Atmel does not give the schematics of the ZigBit Amp and I have not been able to pull this pin low (nor I've been able to understand how bitcloud manages it). Does anybody have worked on it and could help me? Ugo p.s. Janos: I've seen an old post where you say that you've worked on that module, have you experienced the same issue? -- Ugo Maria Colesanti Dipartimento di Ingegneria Informatica, Automatica e Gestionale Antonio Ruberti Sapienza Universita' di Roma Via Ariosto 25, I floor, room B112 00185, Rome http://wiserver.dis.uniroma1.it/cms/index.php/contacts/13-postdoc/4-ugo-colesanti Phone: +39 06 77274119 Fax:+39 06 77274002 ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Ugo Maria Colesanti Dipartimento di Ingegneria Informatica, Automatica e Gestionale Antonio Ruberti Sapienza
Re: [Tinyos-help] How to run the example EasyCollection (of Collection) in part Network Protocol (http://docs.tinyos.net/tinywiki/index.php/Network_Protocols)?
Dear Omprakash Gnawali, For the example EasyCollection, inside the file* EasyCollectionC.nc*, the root will be set ID = 1. Then, I try to do as follow: 1. *make telosb* for the folder EasyCollection. 2. For compiling the node and root, I type: For root node: *make telosb install,1* For non-root node: *make telosb install, x* (with x is sensor ID 1) However, when I use the command Listen for listening from non-root sensors to root node, nothing happen!!! (the command: *java net.tinyos.tools.Listen -comm serial@/dev/ttyUSB17:telosb*) Then, I try to compile the root by using the BaseStation (inside *apps*folder), and I can see the packet when I turn on the sensors (by using the above command *Listen*)!! I do not know which case is right, and where is the wrong thing?!!! Could you please tell me how to get and display the packet in right way? Best regards, Huy. On Sun, Sep 30, 2012 at 3:51 AM, Omprakash Gnawali gnaw...@cs.uh.eduwrote: We can identify the problem as one of networking or rest of the system. Could you first run apps/tests/TestNetwork? If the root receives the packets, then we know networking is working and the problem might be somewhere else. - om_p On Sat, Sep 29, 2012 at 1:49 PM, Nhuanthong nhuanth...@gmail.com wrote: Dear Helps, I try to form a CPT (Collection Protocol Tree) WSN by the example EasyCollection in the part Network Protocol (http://docs.tinyos.net/tinywiki/index.php/Network_Protocols). However, when I run the application, the base station sensor (root) can not receive any packet from other sensors even though the led lights of the these sensors work! Could you please teach me how to receive the packet from the children sensor and display on the PC? Thank you so much for your help. Best regards! ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] How to run the example EasyCollection (of Collection) in part Network Protocol (http://docs.tinyos.net/tinywiki/index.php/Network_Protocols)?
We can identify the problem as one of networking or rest of the system. Could you first run apps/tests/TestNetwork? If the root receives the packets, then we know networking is working and the problem might be somewhere else. - om_p On Sun, Sep 30, 2012 at 8:04 AM, Nhuanthong nhuanth...@gmail.com wrote: Dear Omprakash Gnawali, For the example EasyCollection, inside the file EasyCollectionC.nc, the root will be set ID = 1. Then, I try to do as follow: 1. make telosb for the folder EasyCollection. 2. For compiling the node and root, I type: For root node: make telosb install,1 For non-root node: make telosb install, x (with x is sensor ID 1) However, when I use the command Listen for listening from non-root sensors to root node, nothing happen!!! (the command: java net.tinyos.tools.Listen -comm serial@/dev/ttyUSB17:telosb) Then, I try to compile the root by using the BaseStation (inside apps folder), and I can see the packet when I turn on the sensors (by using the above command Listen)!! I do not know which case is right, and where is the wrong thing?!!! Could you please tell me how to get and display the packet in right way? Best regards, Huy. On Sun, Sep 30, 2012 at 3:51 AM, Omprakash Gnawali gnaw...@cs.uh.edu wrote: We can identify the problem as one of networking or rest of the system. Could you first run apps/tests/TestNetwork? If the root receives the packets, then we know networking is working and the problem might be somewhere else. - om_p On Sat, Sep 29, 2012 at 1:49 PM, Nhuanthong nhuanth...@gmail.com wrote: Dear Helps, I try to form a CPT (Collection Protocol Tree) WSN by the example EasyCollection in the part Network Protocol (http://docs.tinyos.net/tinywiki/index.php/Network_Protocols). However, when I run the application, the base station sensor (root) can not receive any packet from other sensors even though the led lights of the these sensors work! Could you please teach me how to receive the packet from the children sensor and display on the PC? Thank you so much for your help. Best regards! ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Timer Granularity on Telosb
Dear Eric, I am experiencing a very strange behavior which, in my opinion, is not possible. I am using this AlarmMicro16C component and I am observing that it almost take around 6000 ticks each time the call goes from my Application component into the AlarmMicro16C component, when measured using Alarm.getNow() command, now some delay is most likely since I am using printf commands, but a delay of around 6000 ticks just passed between the calls when followed from the application component, where the AlarmMicro16C component is delcared to the AlarmMicro16C itself. I really need some experienced advice here coz I am deep stucked in the problems now I never anticipated! On Sun, Sep 30, 2012 at 6:00 AM, Eric Decker cire...@gmail.com wrote: I strongly suspect none of the implementations have been tested for corner cases. On Sat, Sep 29, 2012 at 8:43 AM, wasif masood rwmas...@gmail.com wrote: Dear Janos, There is a strange behaviour I am experiencing with AlarmMicro16C. From the tinyos general documentation, it is pretty clear that start command starts the timer from current time to dt, now since we know that AlarmMicro16C can has a maximum 65535 value so if one intend to give this value i.e. start(65535), logically it should run uptil 65535 ticks, but the catch I saw in the implementation is something different, there it is something like call Msp430Compare.setEvent( now+remaining ); which means that if now is even 1, now+remaining time will overshot the uint16_t limit so it will reset the timer to 1. This all means that dt can not be greater than 65535-now, otherwise now+remaining will become greater than 65535 limit and the new alarm value would be the overflow value rather the remaining value. So According to my understanding, dt should mean that how long you want the timer/alarm should run, it should not have any dependency over the current time. Is my understanding correct, and if soo, how this current implementation can be changed to compensate for the desire behaviour? Regards, Wasif! On Tue, Sep 25, 2012 at 5:05 PM, Janos Sallai sal...@isis.vanderbilt.edu wrote: Wasif: tos/chips/msp430/timer/AlarmMicro16C.nc is what you're looking for. Please note that the us counter is driven by the DCO, which stops when the MCU goes to sleep. You will have to prevent the MCU from sleeping by implementing McuPowerOverride.lowestState(). Janos On Tue, Sep 25, 2012 at 2:37 AM, wasif masood rwmas...@gmail.com wrote: Thanks Eric, I have been through a alot of these posts. So far, I think, the solution I am looking for, is not answered in any of them. Either there isTMicro packet timestamping being discussed or the TMicro counters are explained just to track the time elasped between two events. But I am interested in an Alarm, of TMicro, cable of signaling interrupts periodically, with the granurality of 1 us. So far, the closet I got is Alarm32Khz, where I tick ~ 30us, is there any way to wire the Alarm to get a granurality of 1us per Tick FOR TELOSB only? On Tue, Sep 25, 2012 at 12:53 AM, Eric Decker cire...@gmail.com wrote: You want Tmicro. Search via http://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/ for tmicro. This topic has been discussed previously. On Mon, Sep 24, 2012 at 5:39 AM, wasif masood rwmas...@gmail.com wrote: Hi All, A quick question, is there a timer with granularity of 1us. more than AlarmT32khz, uint32_t, where I tick~30us? for Telosb. VG, Wasif Masood ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Eric B. Decker Senior (over 50 :-) Researcher -- Wasif Masood ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Wasif Masood -- Eric B. Decker Senior (over 50 :-) Researcher -- Wasif Masood ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] low power, good range, sub GHz transceivers with tinyos
I'm going to be making some tinyos nodes for field biologists using the old telosb design slightly modified, but after that batch, I'd like to make something better for frequencies like the CC1101 transceivers use: 315, 433, 868, and 915 MHz. A few years ago David Moss emailed this list often with talk about using those frequencies, but I don't see him talking lately, is anyone else using 433 or 915 MHz bands for tinyos? I'd like to know if so. I'm wondering how difficult the testing and all for a folded dipole for 433 or 915 MHz is and what is out there already. In reading about antennas, I like the folded dipole as used on CC2500 reference designs since it is matched to the transceiver output impedance so you don't need a balun circuit and have fewer parts and inherent good coupling to the antenna for true low power. So, another question I have is, Is there an open platform based on the cc2500, and if so, it probably uses a MSP430 for the tinyos code rather than the internal 8051 MCU of the CC2500, and if so, which one? The msp430f5438A platform mm5t, (https://github.com/MamMark/mm.git), mentions using the CC2420, which costs 2X as much as a CC2500, and doesn't have a folded dipole ref design, so not as desirable... John Griessen -- Ecosensory ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Timer Granularity on Telosb
Here is how I would approach the problem I've been doing industry development for 30+ years. Equally split between old (mini-computer days) cpu bring up, design, system software and embedded systems (early router development at cisco, essentially embedded systems). First, I would instrument in some way. I currently use the TI JTAG FET pod connected to gdb and I use that for all my main debugging. That gives me internal visibility of the machine state. mspdebug continues to get better. They've recently added watch points but I haven't used them yet. For your problem, I would add a simple trace mechanism that writes to a circular buffer in memory. This of course assumes that you have access to machine state through the above. This trace mechanism then logs arriving at certain points in the code and at what time. I use the uSec ticker (which assumes the machine doesn't go to sleep). There is no substitue in my opinion in being able to see what is actually going on. for example, a bunch of i2c drivers have been written but to my knowledge (expect perhaps for what Steve Ayers has done) no one has actually observed what the i2c bus has actually behaved like. So I've rewritten the i2c driver and have hooked up to the i2c bus a logic analyzer so I can actually see what the bus is doing. That is how I would approach the problem On Sun, Sep 30, 2012 at 11:47 AM, wasif masood rwmas...@gmail.com wrote: Dear Eric, I am experiencing a very strange behavior which, in my opinion, is not possible. I am using this AlarmMicro16C component and I am observing that it almost take around 6000 ticks each time the call goes from my Application component into the AlarmMicro16C component, when measured using Alarm.getNow() command, now some delay is most likely since I am using printf commands, but a delay of around 6000 ticks just passed between the calls when followed from the application component, where the AlarmMicro16C component is delcared to the AlarmMicro16C itself. I really need some experienced advice here coz I am deep stucked in the problems now I never anticipated! On Sun, Sep 30, 2012 at 6:00 AM, Eric Decker cire...@gmail.com wrote: I strongly suspect none of the implementations have been tested for corner cases. On Sat, Sep 29, 2012 at 8:43 AM, wasif masood rwmas...@gmail.com wrote: Dear Janos, There is a strange behaviour I am experiencing with AlarmMicro16C. From the tinyos general documentation, it is pretty clear that start command starts the timer from current time to dt, now since we know that AlarmMicro16C can has a maximum 65535 value so if one intend to give this value i.e. start(65535), logically it should run uptil 65535 ticks, but the catch I saw in the implementation is something different, there it is something like call Msp430Compare.setEvent( now+remaining ); which means that if now is even 1, now+remaining time will overshot the uint16_t limit so it will reset the timer to 1. This all means that dt can not be greater than 65535-now, otherwise now+remaining will become greater than 65535 limit and the new alarm value would be the overflow value rather the remaining value. So According to my understanding, dt should mean that how long you want the timer/alarm should run, it should not have any dependency over the current time. Is my understanding correct, and if soo, how this current implementation can be changed to compensate for the desire behaviour? Regards, Wasif! On Tue, Sep 25, 2012 at 5:05 PM, Janos Sallai sal...@isis.vanderbilt.edu wrote: Wasif: tos/chips/msp430/timer/AlarmMicro16C.nc is what you're looking for. Please note that the us counter is driven by the DCO, which stops when the MCU goes to sleep. You will have to prevent the MCU from sleeping by implementing McuPowerOverride.lowestState(). Janos On Tue, Sep 25, 2012 at 2:37 AM, wasif masood rwmas...@gmail.com wrote: Thanks Eric, I have been through a alot of these posts. So far, I think, the solution I am looking for, is not answered in any of them. Either there isTMicro packet timestamping being discussed or the TMicro counters are explained just to track the time elasped between two events. But I am interested in an Alarm, of TMicro, cable of signaling interrupts periodically, with the granurality of 1 us. So far, the closet I got is Alarm32Khz, where I tick ~ 30us, is there any way to wire the Alarm to get a granurality of 1us per Tick FOR TELOSB only? On Tue, Sep 25, 2012 at 12:53 AM, Eric Decker cire...@gmail.com wrote: You want Tmicro. Search via http://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/for tmicro. This topic has been discussed previously. On Mon, Sep 24, 2012 at 5:39 AM, wasif masood rwmas...@gmail.com wrote: Hi All, A quick question, is there a timer with granularity of 1us. more than AlarmT32khz, uint32_t, where I tick~30us?
Re: [Tinyos-help] platform development choices for field biology use
On 09/17/12 02:08, Eric Decker wrote: The other platform the mm5t (for test) also runs on the experimenter board but has custom configurations for various sensors we are developing drivers for. The mm5t platform lives in a seperate repository, https://github.com/MamMark/mm. You want the mm5t branch. Have the Mammark project folks built a platform mm5 as was discussed? In progress. We have a design and the h/w is routed but we are waiting for GPS verification before fabbng. I just found the 2006 article on the mammark hardware not even mentioning a radio...do you use one now? Does mm5t have the tinyos2.1 radio code in it? What hardware platforms use David Moss's contrib tmote1100 and tmote2500 for its CC1101 radio? The CC2500 seems to be able to send at 500kbits/sec and XE1205 can do 125kbits/sec, so I like the CC2500... What others are there to consider in the 1 GHz frequency range? When I look in the latest tinyos-2.x.svn there's no cc2500 in chips, and likewise for tinyprod. CC1100/CC2500 Recent Updates stops in 2008. It seemed to be by David Moss. Any idea how easy it would be to pick up and reuse his cc2500 work for biologist researchers, in case he's not allowed to offer help since his company is in the business of providing WSNs? Thanks, John Griessen -- Ecosensory ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] [SOLVED] FTSP fails apps/tests/TestFtsp/Ftsp (both 2.1.2 and 2.x) - msp430-gcc version issue
Dear All,
Again, thanks to those who replied to me.
I have investigated the issue further and narrowed down the problem. The
issue was related to the calculation of the skew in TimeSyncP (so it's the
slope of the linear regression). While the computation of the linear
regression was perfectly fine (from the C point of view), the actual value
of the skew was incorrect. You might recall that this has been already
raised in the past (
https://www.millennium.berkeley.edu/pipermail/tinyos-help/2010-November/048878.html)
and pretty much the problem was ignored.
However, while the previous symptoms suggested that floating point division
might be the issue, on TinyOS's google code repo, in Issue 10: Floating
Point Arithmetic and FTSP, Philip has explained why this should not be the
case - which makes sense. In any case, the issue has persisted (
https://www.millennium.berkeley.edu/pipermail/tinyos-help/2012-July/055155.html),
the skew was incorrect and it was not the floating division.
Please take a look at the following code from TimeSyncP.nc file, in
calculateConversion() function:
for(i = 0; i MAX_ENTRIES; ++i)
if( table[i].state == ENTRY_FULL ) {
int32_t a = table[i].localTime - newLocalAverage;
// a is (xi - x)
int32_t b = table[i].timeOffset - newOffsetAverage;
// b is (yi - y)
localSum += (int64_t)a * a; //
Sum of (xi -x)^2
offsetSum += (int64_t)a * b;//
Sum of (xi - x)(yi - y)
}
Everything looks good in the code and the regression is computed as
expected. However, while investigating the code further I've noticed that
the localSum does not equal to the sum that one would compute offline by
summing squares of a. Trying couple of tricks and making more tests I've
found no point in digging around this code further as I was always getting
incorrect sum. The point was clear: the C code is perfectly valid, the
compiled results is not.
So I checked my msp430-gcc version which was gcc version 4.5.3 (GCC). I
upgraded msp430-gcc to msp430-gcc-4.6.3 from tinyprod and now everything
works fine.
Bottom line, FTSP does not work with msp430-gcc-4.5.3. With this
observation in mind, I would like to ask developers to maybe add a
warning/error in FTSP that would inform/prevent others from getting into
the same issue and spend time in potential problem investigation.
Best,
Marcin
On Tue, Sep 25, 2012 at 7:25 PM, Marcin Szczodrak mar...@ieee.org wrote:
Hi Han Bin,
Please take a look at the log from one of the tests. This code is printed
from void addNewEntry(TimeSyncMsg *msg) function. As you can see, every
time the number of the table entries (numEntries) is = 4, the timeError of
new TimeSync message is checked, and it never fits between the limits
of ENTRY_THROWOUT_LIMIT (500).
The logs are from experiment with 2 motes, each within a distance of ~4
inches from each other.
msg-localTime:657714 msg-globalTime:750209 timeError:-92495
offsetAverage:0 localAverage:0
msg-localTime:767248 msg-globalTime:767367 timeError:92376
offsetAverage:92495 localAverage:657714
msg-localTime:876782 msg-globalTime:876903 timeError:90192
offsetAverage:46307 localAverage:712481
msg-localTime:986316 msg-globalTime:986439 timeError:-283317
offsetAverage:30912 localAverage:767249
msg-localTime:1095850 msg-globalTime:1095975 timeError:-99916
offsetAverage:23215 localAverage:822017
timeError too big
msg-localTime:1205384 msg-globalTime:1205511 timeError:-149120
offsetAverage:23215 localAverage:822017
timeError too big
msg-localTime:1314918 msg-globalTime:1315047 timeError:-198325
offsetAverage:23215 localAverage:822017
timeError too big
msg-localTime:1424452 msg-globalTime:1424583 timeError:-247530
offsetAverage:23215 localAverage:822017
timeError too big - cleanTable
msg-localTime:1533986 msg-globalTime:1534119 timeError:-296735
offsetAverage:23215 localAverage:822017
msg-localTime:1643520 msg-globalTime:1643655 timeError:-49204
offsetAverage:133 localAverage:1533986
msg-localTime:1753055 msg-globalTime:1753191 timeError:197128
offsetAverage:134 localAverage:1588753
msg-localTime:1862589 msg-globalTime:1862727 timeError:-7293
offsetAverage:135 localAverage:1643522
msg-localTime:1972123 msg-globalTime:1972263 timeError:-1510611
offsetAverage:136 localAverage:1698290
timeError too big
msg-localTime:2081657 msg-globalTime:2081799 timeError:-2114860
offsetAverage:136 localAverage:1698290
timeError too big
msg-localTime:2191191 msg-globalTime:2191335 timeError:-2719110
offsetAverage:136 localAverage:1698290
timeError too big
msg-localTime:2300725 msg-globalTime:2300871 timeError:-3323359
offsetAverage:136 localAverage:1698290
timeError too big - cleanTable
msg-localTime:2410259 msg-globalTime:2410407 timeError:-3927609
offsetAverage:136 localAverage:1698290
Best,
Marcin
On Tue, Sep
