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.
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.
Oh... and I only mentioned bits falling off because it seems bits often fall off in U26, C119 territory.
You could save up some extra $ and buy one of these... eBay auction: #182145209432, looks quite fun.
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 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,
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
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 30oC 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.
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
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?
%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
isn't that unexpected and confirms the the Furuno sends first.