A look at my Symmetricom GPSDO / 10MHz reference (OCXO + Furuno receiver)

[Bryan]

If you look at... https://www.eevblog.com/forum/projects/a-look-at-my-symmetricom-gpsdo-(ocxo-furuno-receiver)/msg896223/#msg896223

You will see the kind of messages sent at start-up

The $PFEC,GPint,... commands are setting the interval the GPSDO wants to see various messages

I seem to remember that the output of the MCU on the GPSDO board is directly wired (presumably a UART) to the GPS receiver so if you are seeing nothing at the MCU then it is well broken.  You could test continuity from the GPS receiver to MCU pins... can't remember exactly and I don't have my notes to hand.

Thanks for that, very helpful , will have a look tomorrow. These multi layered boards don't make I easy to back trace. Just received my new Siglent scope with the serial decode feature, so sure that will  assist me. <g>

[Bryan]

I seem to remember that the output of the MCU on the GPSDO board is directly wired (presumably a UART) to the GPS receiver so if you are seeing nothing at the MCU then it is well broken.  You could test continuity from the GPS receiver to MCU pins... can't remember exactly and I don't have my notes to hand.

I am wondering if the reason I am not seeing anything on the RX pin is the MCU needs to see some activity from the TX pin before it sends anything to the RX on the Furuno.

[PA0PBZ]

I am wondering if the reason I am not seeing anything on the RX pin is the MCU needs to see some activity from the TX pin before it sends anything to the RX on the Furuno.

I was wondering the same, but I didn't want to lift a receiver from a working board. However, I should be able to monitor both TX and RX pins and see what goes first. And maybe just disconnecting the TX pin and see if there is still commands sent to the receiver. I can do some experiments tomorrow.

[NivagSwerdna]

TBH I would expect the GPSDO to talk to the GPS first.

On the Renesas MCU it appears pins 8,9,10 and 11 are UARTs.... thats numbered anti-clockwise from 1 from the cut-off corner...

Might be fun to look there too.

Oh... and I only mentioned bits falling off because it seems bits often fall off in U26, C119 territory.

[Bryan]

Oh... and I only mentioned bits falling off because it seems bits often fall off in U26, C119 territory.

Second time you have mentioned this and I really should have taken your advice the first time . Went over that area with a loupe and voila what do I see...... a cap that ripped off. I am not sure if that happened when I moved the board around to solder off the receiver or it happened during the original soldering that I though fried the unit. Anyone have an idee what the value would be. Hopefully this was the only issue. Keep my fingers crossed

[Bryan]

Popped off the cap below C33 as it appears the same 100nf tested, replaced both , but no luck. The cap was probably broken a long time ago.

[NivagSwerdna]

If you have nothing being sent to the GPS receiver and nothing has fallen off then I would speculate that you have overloaded the output of the MCU and your board is effectively toast.

You could save up some extra $ and buy one of these... eBay auction: #182145209432, looks quite fun.

[PA0PBZ]

I had a look at what the receiver does at startup and it just starts spitting out information about 2 seconds after powering the board.
Yellow trace = RxD, Green trace is TxD. Both go high after power up, and then it starts to send info although it does not get a command in the first 5 seconds.
Bryan, I hope you realized that it is TTL level, not RS232 level? I think if you already removed the receiver you could just apply 3.3V and it should start doing it's thing.

[Bryan]

Thank you very much, I have observed the same in terms of observing both go high but on my board that's it, nothing after that, Yes at TTL, so this has gotten me thinking it's most likely the receiver. Interesting that the receiver starts to transmit and the there is some data received from the MCU. So is the MCU not sending because it doesn't see any data from the receiver or perhaps more going on. The million dollar question

Could be issues with the MCU as well, but I would have thought it would display other messages as well or not respond at all to any serial commands.

[Bryan]

You could save up some extra $ and buy one of these... eBay auction: #182145209432, looks quite fun.

Think if I can't get this thing going again will use the OCXO and a Jupiter-T receiver I have and  and try this http://www.jrmiller.demon.co.uk/projects/ministd/frqstd0.htm

[Bryan]

On the Renesas MCU it appears pins 8,9,10 and 11 are UARTs.... thats numbered anti-clockwise from 1 from the cut-off corner...

I don't see a chip named Renesas?. Assume the MCU you are referring to is the Spartan ie  U18

[Macbeth]

U20 = Renasas H8S/2317

[Bryan]

I had a look at what the receiver does at startup and it just starts spitting out information about 2 seconds after powering the board.
Yellow trace = RxD, Green trace is TxD. Both go high after power up, and then it starts to send info although it does not get a command in the first 5 seconds.
Bryan, I hope you realized that it is TTL level, not RS232 level? I think if you already removed the receiver you could just apply 3.3V and it should start doing it's thing.

I am pretty sure it is the receiver. I unsoldered the receiver off the board again and applied the power lines and the reset line, still no data coming from the receiver. Same as your findings, after two or so seconds the rx and tx lines go high to 3v. But mine does not output any data. I would be surprised if the receiver needed any commands from the MCU before it started communicating, but who knows. Was hoping to see the MCU sending out some data, but maybe it's waiting for some transmission data first. Your scope test seems to show the MCU sends data after the receiver transmits.

[PA0PBZ]

Bryan,

The green line is the output from the receiver, it starts without getting any commands from the MCU (yellow line).
Tonight I will remove the receiver from one of my donor boards and power it up. If it starts transmitting it's yours 

[Bryan]

Bryan,

The green line is the output from the receiver, it starts without getting any commands from the MCU (yellow line).
Tonight I will remove the receiver from one of my donor boards and power it up. If it starts transmitting it's yours 

Thanks very much, will contact you by PM. Fingers crossed that the MCU requires output from the Furuno before it sends commands. If not well then it's game over. The C33 that was broken didn't seem to make  a change, I note there appears to be space for a unpopulated IC on the reverse side and I suspect the cap was just some supporting components that is not needed for the operation of the GPSDO, maybe for another revision or model number?

[PA0PBZ]

Well, this turns out to be interesting - in a bad way.

I removed the receiver and powered it up. It looks like you also have to power the backup voltage and that you have to apply a reset -after- applying the power.
Even then all output I get is what seems to be the software version... in 38400 Baud! No matter how long I wait nothing else is happening.

So either:

 - it needs to be initialized, but my scope shows nothing when looking at the power up of a working pcb.
 - It's broken, but I find that unlikely.
 - I forgot a pin, but I measured a working one and the only difference is that I didn't apply the antenna voltage, again unlikely.
 - Something else I can't think of, likely because it's over 30^oC in my lab and after tinkering for an hour I ran away.

It's almost like it is in some kind of test mode, but even then why 38K4 when it normally does 9K6? and the test & flash pins are low as it is in the normal mode.
So for the moment I'm out of ideas, I can't find anything about initializing this thing and it's too warm anyway. I need to think this over and have another go tomorrow.

[Bryan]

Well, this turns out to be interesting - in a bad way.

I removed the receiver and powered it up. It looks like you also have to power the backup voltage and that you have to apply a reset -after- applying the power.
Even then all output I get is what seems to be the software version... in 38400 Baud! No matter how long I wait nothing else is happening.

So either:

 - it needs to be initialized, but my scope shows nothing when looking at the power up of a working pcb.
 - It's broken, but I find that unlikely.
 - I forgot a pin, but I measured a working one and the only difference is that I didn't apply the antenna voltage, again unlikely.
 - Something else I can't think of, likely because it's over 30^oC in my lab and after tinkering for an hour I ran away.

It's almost like it is in some kind of test mode, but even then why 38K4 when it normally does 9K6? and the test & flash pins are low as it is in the normal mode.
So for the moment I'm out of ideas, I can't find anything about initializing this thing and it's too warm anyway. I need to think this over and have another go tomorrow.

Hmm that's interesting and yes in a  bad way as if it requires some type of initialization then likely my board is bad and not the receiver. I have a manual for the Furuno at home and will look it up. I believe pin 7? the Reset needs to be HIGH, but if I recall there is some timing that may be required, seem to recall from memory, something like 1ms. I just assumed the receiver would more or less "freewheel" when it starts and send out NMEA statments.

[NivagSwerdna]

You may have multiple issues but if you take a divide and conquer approach....

According to...

http://www.ko4bb.com/manuals/80.229.235.197/Furuno_GT8031_Protocol_Specification_Rev1.pdf

the defaults are such that if you get the receiver powered and in satellite site it should eventually send out some info.

[uncle_bob]

You may have multiple issues but if you take a divide and conquer approach....

According to...

http://www.ko4bb.com/manuals/80.229.235.197/Furuno_GT8031_Protocol_Specification_Rev1.pdf

the defaults are such that if you get the receiver powered and in satellite site it should eventually send out some info.

Hi

There are a very small number of GPS module designs that "boot dead" and then need to be initialized. The problem is that vendors are quite happy to supply modules with non-standard firmware. If you are buying enough parts, the module can do almost anything. If the original design was for a unit that did indeed "boot dead", you can get your new module to do the same.

Bob

[Bryan]

Hi

There are a very small number of GPS module designs that "boot dead" and then need to be initialized. The problem is that vendors are quite happy to supply modules with non-standard firmware. If you are buying enough parts, the module can do almost anything. If the original design was for a unit that did indeed "boot dead", you can get your new module to do the same.

Bob

Yes, I was wondering about some type of custom firmware for the Furuno, which in my case probably means the issue could be the MCU as it is not initializing the receiver, but PA0PBZ  tests show nothing is sent from the MCU to the receiver until after the receiver responds.

PA0PBZ , could it be that during your off board test you had the reset held low when it should be high as per the manual?

[PA0PBZ]

PA0PBZ , could it be that during your off board test you had the reset held low when it should be high as per the manual?

No, I made the reset go high after applying power to the receiver, I found that when the reset is held high during power up nothing happens al all. Maybe the reset needs to go high within a certain time after power up but according to the timing diagram it doesn't matter. I will hook up a LA to a working board this evening, find out what the timing is and try to reproduce that.

[NivagSwerdna]

OK... this is completely over the top but this is the dialog I see between the Renesas and the Furuno...

I have swapped $ for % to indicate a message from Furuno to Renesas...

Code: [Select]

%GPGGA,000002,3444.0000,N,13521.0000,E,0,00,00.00,000000.0,M,0036.7,M,,
%GPZDA,000002,01,01,2002,+00,00
%GPGSV,1,1,00
%GPVTG,,T,,M,,N,,K,N
%PFEC,GPtps,020101000002,1,0,1,000000000000,00,00,000000000000,1147,172802
%GPGGA,000003,3444.0000,N,13521.0000,E,0,00,00.00,000000.0,M,0036.7,M,,
%GPZDA,000003,01,01,2002,+00,00
%GPGSV,1,1,00
%GPVTG,,T,,M,,N,,K,N
%PFEC,GPtps,020101000003,1,0,1,000000000000,00,00,000000000000,1147,172803
%GPGGA,000004,3444.0000,N,13521.0000,E,0,00,00.00,000000.0,M,0036.7,M,,
%GPZDA,000004,01,01,2002,+00,00
%GPGSV,1,1,00
%GPVTG,,T,,M,,N,,K,N
%PFEC,GPtps,020101000004,1,0,1,000000000000,00,00,000000000000,1147,172804
%GPGGA,000005,3444.0000,N,13521.0000,E,0,00,00.00,000000.0,M,0036.7,M,,
%GPZDA,000005,01,01,2002,+00,00
%GPGSV,1,1,00
%GPVTG,,T,,M,,N,,K,N
%PFEC,GPtps,020101000005,1,0,1,000000000000,00,00,000000000000,1147,172805
$PFEC,GPint,GSV00
%GPGGA,000006,3444.0000,N,13521.0000,E,0,00,00.00,000000.0,M,0036.7,M,,
%GPZDA,000006,01,01,2002,+00,00
$PFEC,GPint,VT|%GPGSV,1,1,00
%GVTG,,T,,M,,N,,K,N
%PFEC,GPtps,020101000006,1,0,1,000000000000,00,00,000000000000,1147,172806
$PFEC,GPint,GSV00
%GPGGA,000007,3444.0000,N,13521.0000,E,0,00,00.00,000000.0,M,0036.7,M,,
%GPZDA,000007,01,01,2002,+00,00
%GPGSV,1,1,00
%GPVTG,,T,,M,,N,,K,N
%PFEC,GPtps,020101000007,1,0,1,000000000000,00,00,000000000000,1147,172807
$PFEC,GPint,GSV00
%GPGGA,000008,3444.0000,N,13521.0000,E,0,00,00.00,000000.0,M,0036.7,M,,
%GPZDA,000008,01,01,2002,+00,00
$PFEC,GPint,ZD|%GPGSV,1,1,00
%GVTG,,T,,M,,N,,K,N
%PFEC,GPtps,020101000008,1,0,1,000000000000,00,00,000000000000,1147,172808
$PFEC,GPint,GSV00

So at startup the Furuno sends quite a few messages, unsolicited. Then it gets a series of commands from the Renesas and then after a while things start generally interleaving and getting more confusing!


If you look at Section 1.5 in the receiver software spec you will see values like... "N34deg.44.0000 min. E135deg.21.0000 min." as default values following restart without battery back-up, so

%GPGGA,000002,3444.0000,N,13521.0000,E,0,00,00.00,000000.0,M,0036.7,M,,

isn't that unexpected and confirms the the Furuno sends first.

Share and Enjoy

[PA0PBZ]

isn't that unexpected and confirms the the Furuno sends first.

Yes, I fully agree and I can see the same on a working unit, it's just that I can't get the receiver running on its own.
I grabbed the signals from the working unit and this is the result:



Also as expected, reset goes high about 200 ms after power up. (TEST and MODE both stay low)
So I hooked up the spare receiver in parallel, that is to say GND, VCC, VBCK and RST_N (and later also RD and VANT when it first didn't work), but it keeps doing what it does: spitting out the firmware version in 38K4. The only logical explanation I have is that it's broken, but how that happened I have no idea. I have 2 more donor boards so I can take off another receiver but it's a bit of a fight and I didn't feel like it this evening. If anyone has a suggestion other than a broken receiver I'd love to hear it. 

[NivagSwerdna]

RST_N should presumeably be wired HI when operating stand-alone?


Is it sending $PFEC,GPtrq ?  That suggests it is in Self-Test mode

[Bryan]

Thanks everyone for taking the time to test out their boards, for me it looks like it's the Furuno for sure with the possibility of the MCU as collateral damage. I suspect the Furuno is receiving some type of initialization from the MCU after it "handshakes" in some fashion. This would probably explain while you can't send anything from the RXD pin or was it very limited commands that the Furuno would respond to?. If it was  fully "unlocked" it should accept all the commands in the operating guide and send back the corresponding NMEA response. Or maybe a custom firmware on the Furuno from the get go.

Can anyone confirm which pins the on the Renasas is sending and receiving data for the Furuno. Is it 8,9,10 and 11