[time-nuts] Specifications of the older PicoSync GPS Engine communication protocol on the RS232 port?

[Juha Honkanen]

Hi all

I have a couple of the older PicoSync GPS Engines: http://www.trinstruments.cz/data/files/picosync-gps-engine-604.pdf

They are working fine and producing good stable freq ref for my instruments. Please note that these are the first version and not the newer one PicoSync II.

Is there any one here on the time-nuts list that has been able to reverse engineer the binary protocol that the PicoSync seems to be using on the RS232 port?

It seems to be some proprietary protocol by FEI Inc (Frequency Electronics Inc) that I have not seen before.

I see that the internal GPS receiver being used by PicoSync is a standard Trimble Resolution T (http://www.trimble.com/timing/resolution-t.aspx ) and when I connect to the GPS card directly I am able to communicate with the card via Trimble software and the TSIP protocol using 9600-O-8-1 comm parameters. I used the pretty good Trimble GPS Studio software (http://trl.trimble.com/dscgi/ds.py/Get/File-484972/TrimbleStudio.exe)

However, when I connect via the RS232 port on the PicoSync I receive something that looks like a binary proprietary protocol that is not TSIP. I have been able to verify that the PicoSync also switches from from 9600-O-8-1 comm parameters from the internal Trimble Resolution T card to use 9600-N-8-1 on the RS232 output.

I have used both oscilloscope connected directly to the Resolution T card via an TTL to RS232 converter as well as to the RS232 output and the signals looks ok with proper levels.

It definitely looks like PicoSync is massaging the data in some way.

This is how some of the HEX TSIP protocol data looks like coming out from the Trimble Resolution T card:
Some of the Packet from the GPS receiver Trimble Resolution
10 8F AB 00 06 5C 93 06 D5 00 10 00 23 30 13 12 07 07 DD 10 03
10 6D 9C 3F F4 1C 23 3F 76 BF 16 3F D2 A3 88 3F 81 26 B2 1B 13 06 01 03 12 16 1C 0E 10 03
10 5C 1B 00 01 01 40 D9 99 9A 48 CB 92 66 3F 51 45 76 40 3E 6E D8 00 00 00 01 10 03
10 5C 13 08 01 01 40 A6 66 66 48 CB 92 66 3F 9A 88 DD 40 77 0A 03 00 00 00 01 10 03

So that above looks like familiar TSIP packets with 0x10 as the starting byte and 0x10 and 0x03 as the ending bytes.

At the same time the PicoSync outputs following packets on the RS232 output:
02 04 00 00 00 42 6C B4 87 41 90 F6 5D 00 53 09 07 BC 3F 13 08 70 10 00 09 07 02 0D 06 05 01 00 FA 00 00 00 00 00 00 00 00 31

02 04 00 00 00 42 6C B4 8A 41 90 F6 6B 00 50 09 07 BC 3F 13 09 E2 10 00 09 07 02 0D 06 05 01 00 FA 00 00 00 00 00 00 00 00 B2

02 04 00 00 00 42 6C B4 8A 41 90 F6 6A 00 50 08 07 BC 3F 13 09 EE 10 00 09 07 02 0D 06 05 01 00 FA 00 00 00 00 00 00 00 00 BC

02 04 00 00 00 42 6C B4 89 41 90 F6 69 00 51 09 07 BC 3F 13 0A 02 10 00 09 07 02 0D 06 05 01 00 FA 00 00 00 00 00 00 00 00 D1

02 04 00 00 00 42 6C B4 89 41 90 F6 69 00 51 09 07 BC 3F 13 0A 04 10 00 09 07 02 0D 06 05 01 00 FA 00 00 00 00 00 00 00 00 D3

Note that quite many initial bytes looks exactly similar between the transmissions and that the ending packets are also long and identical between the transmissions except for the final byte that seems to be some kind of counter counting up 0x02 on each transmission?

I am pretty stuck now with trying to figure this out since I guess Fei-Zyfer Inc as well as Gillam-Fei in Belgium and Frequency Electronics Inc will probably not release any specs on the protocol being used. :(

/Juha