Speaking about legacy T-Bolt devices and modern development: Here is
paragraph from Trimble Thunderbolt User guide:
Week Number: This field represents the current GPS week number. GPS week
number 0
started on January 6, 1980. Unfortunately, the GPS system has allotted
only 10-bits of
information to carry the GPS week number and therefore it rolls-over to
0 in just 1024
weeks (19.6 years,) and there is no mechanism built into GPS to tell the
user to which
1024 week epoch the week number refers. The first week number roll-over
will occur as
August 21, 1999 (GPS) transitions to August 22, 1999 (GPS). The
ThunderBolt adjusts for
this week rollover by adding 1024 to any week number reported by GPS
which is less that
week number 936 which began on December 14, 1997. With this technique,
the
ThunderBolt will provide an accurate translation of GPS week number and
TOW to time
and date until July 30, 2017.
How that "week number" will affect the functionality of whole device ?
Its probably time to think to put some workaround to the code or even
eliminate to use that time information received from T-Bolt. I already
met that challenge when I was working with BC637PCI card. The work
around was quite simple then - just to add 619315200 seconds to the
current value [1024*7*24*60*60]. I would like to be little proactive
here. ;-)
Also, does anybody knows if new Trimble Thunderbolt "E" is backward
compatible with legacy HW ? I mean the replacement will still works on
most of existed setups. For example, I did compare the packet definition
for 8F-AC and looks like Thunderbolt "E" has some extensions, but its
backward compatible.
Regards,
V.P.
On 2014-03-26 08:38, Didier Juges wrote:
You can play with my Thunderbolt Simulator:
http://www.ko4bb.com/Timing/GPSMonitor/TBoltSim.php [2]
(Windows only, sorry...)
It lets you create arbitrary packets (including setting fault
conditions and arbitrary GPS time or coordinates) and properly escapes
the embedded DLEs. The actual string that is sent is displayed in Hex
at the bottom of the screen.
(Warning: It is work in progress, so not all menu selections actually
work)
On Tue, Mar 25, 2014 at 7:11 PM, d0ct0r <t...@patoka.org> wrote:
Much thanks Tom and Mike ! I missed that point. In another word,
T-Bolt sending DLE data "wrapped" by another byte ! Now I know !
On 2014-03-25 19:55, mike cook wrote:
Le 25 mars 2014 à 22:43, d0ct0r a écrit :
Today I spent good part of my time to figure out that my version of
Thunderbolt has some issue with the TSIP protocol definition. I am
using following document: "ThunderBolt GPS Disciplined Clock User
Guide, Version 5.0, Part Number: 35326-30, November 2003"
In that particular PDF file, there is definition for 0x8F-AB TSIP
packet [section A.10.30 Report Packet 0x8F-AB Primary Timing
Packet].
Here is the structure of 8F-AB, translated to plain C-code:
typedef struct tb_8f_ab {
uint8_t sub; //0 : 1
uint32_t tow; //1-4 : 4
uint16_t wn; //5-6 : 2
int16_t ls; //7-8 : 2
uint8_t tflag; //9 : 1
uint8_t sec; //10 : 1
uint8_t min; //11 : 1
uint8_t hr; //12 : 1
uint8_t day; //13 : 1
uint8_t month; //14 : 1
uint16_t year; //15-16 : 2
} mytb_8f_ab;
Here is the dump I get from my MCU:
//0x10 0x8F 0xAB 0x0 0x3 0x92 0x88 0x6 0xF9 0x0 0x10 0x10 0x3 0x2C
0x1 0x11 0x19 0x3 0x7 0xDE 0x10 0x3
//0x10 0x8F 0xAB 0x0 0x3 0xCC 0x16 0x6 0xF9 0x0 0x10 0x10 0x3 0x12
0x7 0x15 0x19 0x3 0x7 0xDE 0x10 0x3
____________
how are you dumping this?
you have an imbedded (stuffed)DLE, which is sent as DLE/DLE but the
second is to be ignored.
Which is conform to TSIP standard packet definition:
TSIP packet structure is the same for both commands and reports.
The
packet format is:
<DLE> <id> <data string bytes> <DLE> <ETX>
Where:
* <DLE> is the byte 0x10
* <ETX> is the byte 0x03
* <id> is a packet identifier byte, which can have any value
excepting
<ETX> and <DLE>.
Ex: In the tsip developer tool kit , from TsipParser.c
case TSIP_IN_PARTIAL:
// The parser is in this state if a previous character was
// a part of the TSIP data. As noted above, a DLE character
// can be a part of the TSIP data in which case another DLE
// character is present in the data stream. So, here we look
// at the next character in the stream (currently loaded in
// ucByte). If it is a DLE character, we just encountered
// a stuffed DLE byte. In that case, we ignore this byte
// and go back to the TSIP_DLE state. That way, we will log
// only one DLE byte which was a part of the TSIP data.
//
// All other non-DLE characters are placed in the TSIP packet
// buffere.
if (ucByte == DLE)
{
nParseState = TSIP_DLE;
}
else
{
ucPkt[nPktLen++] = ucByte;
}
break;
However, its appeared that my T-Bolt throwing one "extra" byte for
the so-called "Timing Flags".
There is 19 bytes coming from my T-Bolt, instead of expected 18. I
found that actual length of TFLAG is 16 bit - not 8. Interesting
enough, that Lady Heather works perfectly fine with that T-Bolt !
Can somebody confirm that there is different version of T-Bolt on
the market ? If so, where I need to look for the documentation for
my version ?
--
WBW,
V.P.
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts [1] [1]
and follow the instructions there.
Links:
------
[1] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts [1]
--
WBW,
V.P.
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts [1]
and follow the instructions there.
Links:
------
[1] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
[2] http://www.ko4bb.com/Timing/GPSMonitor/TBoltSim.php
--
WBW,
V.P.
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
