Hi Dave, and all.

Oops ... I left myself open for that suggestion, didn't I? Here I
was trying to avoid doing any observing till the next "interesting"
event, and you blew me out the water ... :-)

Actually, there are some occultations coming up in a couple of weeks.
Between now and then I should get some idea how sensitive the setup is,
I guess. Next week when work isn't so busy ... promise.

Steve.

Gerhard beat me to the punch but brings up some valid issues.

before we go forward in trying to locate the problem, we have to
insure all the ducks are in a row.

as far as the pinout on the DIN connector goes, i do not beleive that
there was any mention of using the ones on the DIN as reference. all
the documentation refers to the drawings in the instructions. i
deliberately used the same pinouts of the DIN 5 so there wouldn't be
any confusion with the DIN6. if i had numbered the DIN6 differently,
then someone could have mistakenly used the DIN5 drawing by mistake.
by keeping them the same, the wiring is always the same except for
the extra pin 6, and someone wiring the din5 won't confuse that one!

i have wired up the GPS units wrong myself and haven't "fried" any of
them.

if what Gerhard eludes to (wiring the 12V ) was done correctly, then
i would first assume the GPS is still wired incorrectly.

i do hope that you didn't apply 12V directly from your power source
to any of the gps wires. that is why we include the polyfuse...

when i wire the GPSs here, and i have done many of them, i never
fully finish the connector, i leave the hood off until i'm sure the
wiring is correct. that way it is easy to correct my wiring and i
don't have to cut off a connector.

please check all the suggestions of Gerhard and post your results. i
think this exercise can be a valuable lesson for all.

vince


--- In kiwiosd@yahoogroups.com, "Gerhard Dangl" <gerhard@d...> wrote:
>
> Hello Steve,
>
> this is also a long answer-message :-).
> After reading about your troubles I made a download of the pdf-
manual about
> Garmin GPS16 HVS. There are no great differences to my GPS Garmin
18 LVC.
> But the GPS16 uses an additional power-control-input (original RJ-
45 Pin #3,
> yellow). If this pin is not connected to ground (GND) this GPS will
never
> work. This is only a reminder from me. But this seems not to be
your problem
> at the moment.
>
> My second advice:
> As you correct assumed, your measurement of 30-50 kohms tells you a
wrong
> result. Circuits with semiconductors are not linear resistors and
have a
> very different behaviour connected to a voltage.
>
> You wrote about 800 mW in typical operation. The data sheet tells
about
> 480-600 mW. And as you can see the GPS16 HVS uses an intern
switching
> regulator. A linear regulator would drive always the same current
and so
> would overhaet at high supply voltages.
> 60 mA at 8V
> 40 mA at 12V
> 15 mA at 40V
>
> I assume you did the following power connections to your GPS.
> Beside the Regulator U1 from point "Safe DC out" a wire to the
point "GPS
> DC". So you must not(!) use a wire-Jumper at "Lnk". Your GPS should
be
> connected after the fuse F2 at the point "+DC" beside the 1PPS
signal point.
> GND is in the middle of the five GPS-points on the board. GTxD and
GRCV
> should also be right connected.
>
> An important question:
> Did you measure 2-3V at the point after fuse F2 direct at the GPS
at point
> "+DC". If on the other side of the fuse F2 are 12V then your GPS
seems to be
> the reason of the low voltage. Polyfuse F2 is limiting the current
at 100mA.
> Because of a GPS fail the current consumption can rise to to high
values and
> so this fuse is limiting by decreasing voltage.
>
> You wrote due to your mistake the GPS got +12V from PCB-Board on
the 1PPS
> Output. Unfortunately no intern circuit-sheets of Garmins are
available. So
> I can only assume that there are intern protecting diodes to limit
the
> voltage on a pin. This diodes could have been damaged by to high
> input-current. But in this case I cannot explain the normal
function after
> correcting your mistake. So if you have tested your GPS several
times
> sucessful after the mistake I assume a new error is in your system.
>
> Regards from Austria
> Gerhard Dangl
> gerhard@d...
> www.dangl.at
>

As of November 8th, 2005, PFD Systems will no longer be offering the
KIWI-OSD as a kit.

  Only the KIWI-OSD RTG model will be available. In addition, the KIWI-
OSD will only be offered configured for use with the Garmin 18 LVC
GPS. No other make or models of GPS will be supported.

This decision came about as a result of the many problems that kit
builders and those with GPS units other than the Garmin 18 LVC have
experienced. It takes a lot of additional time and effort to support
the kit builders and other GPS units and we only have a limited
number of hours available each week to devote to the products. We
realize that some of you have successfully built the kits and enjoyed
the experience, but our decision was a business decision, not a
personal one. For those of you who were planning on purchasing a kit
in the near future, we apologize and hope that you will still
consider a KIWI-OSD for your needs.

Thank you for your patience in this matter.

Vince
PFD Systems

Alas, I know where you are coming from and can fully understand
your decision to limit it to completed units.  But I wish I had acted
sooner on getting the kit version because there a few modifications
I would have made to suit my needs a little better.

But thanks for a great unit.

Derald Nye
----- Original Message -----
From: <kiwiosd@yahoogroups.com>
To: <kiwiosd@yahoogroups.com>
Sent: Wednesday, November 09, 2005 12:51 PM
Subject: [kiwiosd] Digest Number 69


>
> There is 1 message in this issue.
>
> Topics in this digest:
>
>       1. *** IMPORTANT NOTICE ***
>            From: "thevinenator" <thevinenator@...>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 1
>    Date: Tue, 08 Nov 2005 21:53:34 -0000
>    From: "thevinenator" <thevinenator@...>
> Subject: *** IMPORTANT NOTICE ***
>
>
>
> As of November 8th, 2005, PFD Systems will no longer be offering the
> KIWI-OSD as a kit.
>
>  Only the KIWI-OSD RTG model will be available. In addition, the KIWI-
> OSD will only be offered configured for use with the Garmin 18 LVC
> GPS. No other make or models of GPS will be supported.
>
> This decision came about as a result of the many problems that kit
> builders and those with GPS units other than the Garmin 18 LVC have
> experienced. It takes a lot of additional time and effort to support
> the kit builders and other GPS units and we only have a limited
> number of hours available each week to devote to the products. We
> realize that some of you have successfully built the kits and enjoyed
> the experience, but our decision was a business decision, not a
> personal one. For those of you who were planning on purchasing a kit
> in the near future, we apologize and hope that you will still
> consider a KIWI-OSD for your needs.
>
> Thank you for your patience in this matter.
>
> Vince
> PFD Systems
>
>
>
>
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
>
>
> ------------------------------------------------------------------------
> Yahoo! Groups Links
>
>
>
>
> ------------------------------------------------------------------------
>
>
>
>
>

I have made a couple modifications to my kit, Derald, with very
satisfactory results.  I am sure the RTG version has the same box
and board, so it should be no problem to modify that version.

Walt

--- In kiwiosd@yahoogroups.com, <ddnye@a...> wrote:
>
> Alas, I know where you are coming from and can fully understand
> your decision to limit it to completed units.  But I wish I had
acted
> sooner on getting the kit version because there a few modifications
> I would have made to suit my needs a little better.
>
> But thanks for a great unit.
>
> Derald Nye

> >
> > There is 1 message in this issue.
> >
> > Topics in this digest:
> >
> >       1. *** IMPORTANT NOTICE ***
> >            From: "thevinenator" <thevinenator@y...>
> >
> >
> > Message: 1
> >    Date: Tue, 08 Nov 2005 21:53:34 -0000
> >    From: "thevinenator" <thevinenator@y...>
> > Subject: *** IMPORTANT NOTICE ***
> >
> >
> >
> > As of November 8th, 2005, PFD Systems will no longer be offering
the
> > KIWI-OSD as a kit.
> >

Walt, you are correct.

the made up units are exactly like the kits, except that i assemble
them myself. i must add though, that if you do surgery on the RTG
unit, i cannot take responsibility for the outcome.

what kind of mods did you have in mind? perhaps some custom work at a
good price could be had!

let me know,

vince

--- In kiwiosd@yahoogroups.com, "Walt Morgan" <wvmorgan13@s...> wrote:
>
> I have made a couple modifications to my kit, Derald, with very
> satisfactory results.  I am sure the RTG version has the same box
> and board, so it should be no problem to modify that version.
>
> Walt
>
> --- In kiwiosd@yahoogroups.com, <ddnye@a...> wrote:
> >
> > Alas, I know where you are coming from and can fully understand
> > your decision to limit it to completed units.  But I wish I had
> acted
> > sooner on getting the kit version because there a few
modifications
> > I would have made to suit my needs a little better.
> >
> > But thanks for a great unit.
> >
> > Derald Nye
>
> > >
> > > There is 1 message in this issue.
> > >
> > > Topics in this digest:
> > >
> > >       1. *** IMPORTANT NOTICE ***
> > >            From: "thevinenator" <thevinenator@y...>
> > >
> > >
> > > Message: 1
> > >    Date: Tue, 08 Nov 2005 21:53:34 -0000
> > >    From: "thevinenator" <thevinenator@y...>
> > > Subject: *** IMPORTANT NOTICE ***
> > >
> > >
> > >
> > > As of November 8th, 2005, PFD Systems will no longer be
offering
> the
> > > KIWI-OSD as a kit.
> > >
>

Vince,

The 1st thing I would do is replace the computer cable
with a socket in the side of the box.  Then if I ever
did need to plug into a computer, I could then plug in
a cable.

Next, I would remove the power cable and replace it with
a (Radioshack) power plug (type "M" as you have used).
In the field, I will still run the equipment from 110 VAC,
so the DC power cable would plug directly into the box.

Now there are two less dangling cables.  The box now has
only Video in & out and the GPS cables. Even here I might consider
putting a BNC or RCA connector on the box for the Video
(camera) in.  Also I might consider having the GPS plug
mounted directly to the case.

Also I am considering another GPS unit to permanently mount
in the observatory.  But it is slightly over 9 feet from the
dome bottom to the top and I need a longer cable to connect
the GPS to the OSD box.   Any recommendations for the proper
cable type to use, even if I have to put on the proper plugs.

Thanks for your interest.

Sincerely,

Derald Nye






-
-- In kiwiosd@yahoogroups.com, "thevinenator" <thevinenator@y...>
wrote:
>
> Walt, you are correct.
>
> the made up units are exactly like the kits, except that i assemble
> them myself. i must add though, that if you do surgery on the RTG
> unit, i cannot take responsibility for the outcome.
>
> what kind of mods did you have in mind? perhaps some custom work at
a
> good price could be had!
>
> let me know,
>
> vince
>
> --- In kiwiosd@yahoogroups.com, "Walt Morgan" <wvmorgan13@s...>
wrote:
> >
> > I have made a couple modifications to my kit, Derald, with very
> > satisfactory results.  I am sure the RTG version has the same box
> > and board, so it should be no problem to modify that version.
> >
> > Walt
> >
> > --- In kiwiosd@yahoogroups.com, <ddnye@a...> wrote:
> > >
> > > Alas, I know where you are coming from and can fully understand
> > > your decision to limit it to completed units.  But I wish I had
> > acted
> > > sooner on getting the kit version because there a few
> modifications
> > > I would have made to suit my needs a little better.
> > >
> > > But thanks for a great unit.
> > >
> > > Derald Nye
> >
> > > >
> > > > There is 1 message in this issue.
> > > >
> > > > Topics in this digest:
> > > >
> > > >       1. *** IMPORTANT NOTICE ***
> > > >            From: "thevinenator" <thevinenator@y...>
> > > >
> > > >
> > > > Message: 1
> > > >    Date: Tue, 08 Nov 2005 21:53:34 -0000
> > > >    From: "thevinenator" <thevinenator@y...>
> > > > Subject: *** IMPORTANT NOTICE ***
> > > >
> > > >
> > > >
> > > > As of November 8th, 2005, PFD Systems will no longer be
> offering
> > the
> > > > KIWI-OSD as a kit.
> > > >
> >
>

Derald,

All good ideas, and ones we thought of, but let address them.

Computer cable: this is the tough one. the "socket" on the box would
have to be "non-round". This is very time consuming unless you have a
punch. i could not find one "cheaply" enough to make it worth my
effort.

Power Cable: the cable has an "M" barrel connector that ac adapters
can plug directly into. the extra length of the cable gives users
some flexiblity in where they can place their power source.

Video: yes, there are some box mounts for RCA jacks. I have a couple
in my possession that i might try out.

DIN: for the gps. there are also box mounts for this format as well
and most of them require 3 holes, the main hole and 2 screw/bolt
holes.

so with the exception of the computer cable, the others are possible.
the extra connectors would add around $10 for additional parts but a
lot of time for labor. It would add an additional 30-45 minutes to
the assembly time. time is the real issue here. i would need to
increase the cost of the box significantly if i made the mods you
requested.

GPS cables: others have posted threads indicating that using AT style
keyboard cables (must insure all the pins are wired and wired
straight through) have worked, but it might be difficult to get one
that length. if you want to make your own cable, it would be simply a
DIN5 Male connector on one end and DIN5 Female connector on the other
end. all the pins are wired 1 to 1. a cable that has a shielding
would be more suitable. i would use stranded cable though since it
handles "bends" better. i'll do a product search to see if i can find
a suitable cable. if anyone else has found such a cable already,
please post info about it.

vince

Gerhard and Vince,

Thanks very much for your replies... I'm afraid that I am only
getting to play with this stuff on Sundays at the moment hence the
slow response.

Hopefully below I can answer each of your questions/checks ...

Re the pin numbering ... Vince, there is nothing in the manual that
would justify my making the mistake that I did ... I fully accept
that it was my fault.

Gerhard, I had not looked too closely about the connections from the
"Safe DC Voltage" point to the GPS cable bond points - mine was an
RTG unit that Vince has built so I assumed it was OK.  While I
haven't lifted the PCB out of the case, the behaviour looks
reasonable to me and is consistant with how you have both described
it should be.

The main learning for me out of this was what a 'polyfuse' is.  I
didn't realise the it was a dynamic current limiting device.  When
the OSD is powered up WITHOUT the GPS connected, I see 12V relative
to ground on both legs of the fuse.  When the GPS is connected, the
leg away from the GPS cable remains at 12V while the other drops to 2-
3V ... so yes, it would seem that it is actively limiting the current
draw of the GPS and that is where the problem lies.  Gerhard talks
about the Garmin only requiring 480 to 600 mW.  The manual I
downloaded when I bought the GPS (Garmin part no. 190-00228-20
Revision B - November 2002) talks about 65 mAmps at 12V (780 mW) for
typical operation (page 3).  If the GPS was trying unsuccessfully
(because I am indoors at the time) to get a fix, is it likely to draw
more current than typical???  Should I be testing the polyfuse by
putting a 200 Ohm resistor across the GPS connection pins?

I haven't spent much time yet messing with the GPS cable termination
but will probably have another go at terminating it.  The coloured
cores in the GPS lead are definitely on the right posts and the
colours agree between the Garmin manual and the OSD manual.  I was
about to pay my local Garmin dealer a visit but after Vince's
reassuring words about the robustness of these things, I might just
spend a little more time tinkering.  No, I have not applied straight
12V to the unit - since the DIN plug went on, I don't have any
convenient means of doing that.  Frankly, the little plug pack (240V
AC/12V DC) I have been using is only rated for 500 mAmps while the
Garmin manual recommends a 1 Amp fuse on the power supply, so I have
some doubt if I am actually able to fry it ...

One question that has come up in my mind ... How should I be handling
the GPS cable shield?  I notice that it is in full electrical
connection with the GPS ground(s) cable cores.  Is that how it should
be?  At the moment, I haven't tried connecting the shield to anything
in particular ... just trimming it back from the terminations.

Any thoughts ???

Thanks,
Steve Kerr,
Rockhampton, QLD
Australia.

Hello Steve,

> Gerhard, I had not looked too closely
> about the connections from the
> "Safe DC Voltage" point to the GPS cable
> bond points - mine was an RTG unit that
> Vince has built so I assumed it was OK.

I did not know about this. So I think it will be OK.

> When the OSD is powered up WITHOUT the GPS
> connected, I see 12V relative to ground on
> both legs of the fuse.  When the GPS is
> connected, the leg away from the GPS cable
> remains at 12V while the other drops to 2-3V

It seems your problem is really after polyfuse F2.

> Gerhard talks about the Garmin only requiring
> 480 to 600 mW. The manual I downloaded when I
> bought the GPS (Garmin part no. 190-00228-20
> Revision B - November 2002) talks about 65 mAmps
> at 12V (780 mW) for typical operation (page 3).

In my Nov. 2005 download I got a manual from July 2005. But some mA (mW)
difference are not the problem.

> If the GPS was trying unsuccessfully
> (because I am indoors at the time) to get
> a fix, is it likely to draw more current
> than typical???

A GPS receiver also includes a little computer system. So due to dynamic
operations there may be always a little variation of current consumption.
But I think there is no reason to draw much more current without a fix
generally.

> Should I be testing the polyfuse by
> putting a 200 Ohm resistor across the
> GPS connection pins?

Yes, a good idea. But you have to use existing resistor values. Typical
R-values (e.g. row E12) are 1.0, 1.2, 1.5, 1.8, 2.2, 2.7, 3.3, 3.9, 4.7,
5.6, 6.8 and 8.2. From this numbers several powers of ten are existing. Some
examples: ..., 68, 82, 100, 120, 150, ...

But instead of only one resistor you should use two ore more resistors
connected serial. R=R1+R2. The reason is the heating power caused by a
current in a range of 60-80mA at 12volts. P=60-80mA x 12V = 720-960 mW.
Normal PCB-resistors are built for maximum values in a range of 250-600mW.
Only one resistor in use would overheat. After some seconds you can burn
your fingers on it! So if you use e.g. two 82 ohms (current= 73mA), each of
them will be charged with 440mW. But if you have only very small resistors
you can use 3 or more of them serial to get a current in the designated
range and to split the power.

> Frankly, the little plug pack (240V
> AC/12V DC) I have been using is only
> rated for 500 mAmps while the Garmin
> manual recommends a 1 Amp fuse on the
> power supply, so I have some doubt if
> I am actually able to fry it ...

No problem. Your system is consuming much less than 200 mA in a functioning
condition.

> How should I be handling the GPS cable
> shield? I notice that it is in full
> electrical connection with the GPS
> ground(s) cable cores.  Is that how it
> should be? At the moment, I haven't tried
> connecting the shield to anything
> in particular ... just trimming it back
> from the terminations.

My Garmin GPS18 LVC was delivered with 3 meter cable. For inhouse testing I
can add a selfmade 7 meter cable. In this cable the shield is electrically
not in use. As you can see at the bottom of this page the signal is OK.
http://www.dangl.at/ausruest/ausrt06e.htm
But I did not make tests near strong power lines or other strong disturb
sources. My house is in a little village of only 25 houses without
factories.

Regards
Gerhard
www.dangl.at

Hello Steve,

> Gerhard, I had not looked too closely about the connections from the
> "Safe DC Voltage" point to the GPS cable bond points - mine was an
> RTG unit that Vince has built so I assumed it was OK.  While I
> haven't lifted the PCB out of the case, the behaviour looks
> reasonable to me and is consistant with how you have both described
> it should be.

Yes, I wouldn't remove the OSD pcb at this stage. I think it is behaving as
it should. Vince tests each RTG before he ships, so your pcb has been
connected to a Garmin 16 and tested to give the time on video, so at time of
shipping to Australia, it was operating as designed.

> The main learning for me out of this was what a 'polyfuse' is.  I
> didn't realise the it was a dynamic current limiting device.

They are interesting devices, and for those not familiar with this new
technology, here is a PDF document that describes how they work.

http://www.circuitprotection.com/techpapers/notafuse3.pdf

However like any device, they have their limitations, and I think they can
only handle about one thousand fault conditions. So there is a slight chance
that your F2 is faulty, however I suspect it is the GPS that is now drawing
more current than it should. F2 is a 100mA device, which means that it can
supply 100mA continuous, however if the current gets up to about 200mA it
'trips' and goes high resistance (as you have measured).

Steve, at this stage, I think it would be best to put the OSD box to one
side (and not stress its protection anymore) and test the Garmin 16 (with a
1 Amp fuse) on your old power supply (used for KIWI PC).

Connect up the Garmin 16 with a normal 1 Amp fuse in series. Don't connect
any other wires apart from the power leads to the Garmin 16 and see if you
can connect your 12 volt DC supply to the GPS without blowing the 1 Amp
fuse. You can do this inside the house, because although it will not lock
onto a satellite, it will prove if the switch mode power supply on the
Garmin 16 is working correctly. If you can connect the 12 volt supply then
you can see if you can get the Garmin to work on the laptop as you have had
going  in the past.

> One question that has come up in my mind ... How should I be handling
> the GPS cable shield?  I notice that it is in full electrical
> connection with the GPS ground(s) cable cores.  Is that how it should
> be?  At the moment, I haven't tried connecting the shield to anything
> in particular ... just trimming it back from the terminations.

The shield should be connected to the GND connection of the power supply,
that is, the most negative lead of the 12 volt supply.

Many thanks to Gerhard for his (very good ) advice on this matter so far.

Speaking of the OSD. On Saturday night I took my OSD out to a graze event.
It was used to video time insert the PC164 of Larry Field. We also
had one of Pauline's bleepers beeping away (that had previously been synced
to GPS time by Brian Loader). So it was very nice to see the OSD time
ticking away in sync to the bleeper. This was done only about 100 metres
away from a high voltage transmission line (which would have swamped WWVH).

A very nice graze was recorded even though it was so close to the sunlit
part of the moon.

So my OSD (one of Vince's first kits) has one graze under it's belt now!

Regards, Kiwi Geoff.

Vince,

Would you be interested in putting one together if
I built the 'box' with all connectors etc installed?
I think it would be a metal box with the LED mounted
on the box close to the switch.  If I could get the switch,
I would also mount it.

I have a Bridgeport mill and can make just about any
size and shape hole that would be needed.

Any thoughts?

Cheers,

Derald Nye

-
-- In kiwiosd@yahoogroups.com, "thevinenator" <thevinenator@y...>
wrote:
>
> Derald,
>
> All good ideas, and ones we thought of, but let address them.
>
> Computer cable: this is the tough one. the "socket" on the box
would
> have to be "non-round". This is very time consuming unless you have
a
> punch. i could not find one "cheaply" enough to make it worth my
> effort.
>
> Power Cable: the cable has an "M" barrel connector that ac adapters
> can plug directly into. the extra length of the cable gives users
> some flexiblity in where they can place their power source.
>
> Video: yes, there are some box mounts for RCA jacks. I have a
couple
> in my possession that i might try out.
>
> DIN: for the gps. there are also box mounts for this format as well
> and most of them require 3 holes, the main hole and 2 screw/bolt
> holes.
>
> so with the exception of the computer cable, the others are
possible.
> the extra connectors would add around $10 for additional parts but
a
> lot of time for labor. It would add an additional 30-45 minutes to
> the assembly time. time is the real issue here. i would need to
> increase the cost of the box significantly if i made the mods you
> requested.
>
> GPS cables: others have posted threads indicating that using AT
style
> keyboard cables (must insure all the pins are wired and wired
> straight through) have worked, but it might be difficult to get one
> that length. if you want to make your own cable, it would be simply
a
> DIN5 Male connector on one end and DIN5 Female connector on the
other
> end. all the pins are wired 1 to 1. a cable that has a shielding
> would be more suitable. i would use stranded cable though since it
> handles "bends" better. i'll do a product search to see if i can
find
> a suitable cable. if anyone else has found such a cable already,
> please post info about it.
>
> vince
>

Derald Nye wrote:
> I have a Bridgeport mill and can make just about any
> size and shape hole that would be needed.

To overcome my jealousy of your Bridgeport, I thought I would just
make a few comments about a metal box and your planned extension
cable Derald.

The OSD pcb itself generates a low level 'birdie' at 16MHz which
would be suppressed by your planned metal box, however the main RF
generator is the GPS's serial transmission at 4800 baud. The Garmin
18 has obviously fast switching transistors on the serial port that
can generate harmonics way up into the shortwave band. I found this
out when I made a quick extension cord for the GPS without grounding
the shield (braid) of the multi-cable.

About 10 - 20 milliseconds after the UTC reference second, the Garmin
18 squirts out the NMEA information. The RMC and GGA sentences take
about 325mS to be transmitted. So if you don't ground the shield of
the cable, you can get a squirt of #hash# for a 1/3 of a second just
after each 1PPS, especially at 10MHz (WWV). Moving the radio receiver
a few feet away from the unshielded cable stopped the interference.
If you are going to run a long cable Derald (to the top of your dome)
I suggest you carefully connect the cable shield system to the GND
pin at the OSD.

To see this NMEA squirt of noise, Gerhard Dangl has made a nice
oscillogram of the 1PPS and NMEA data, check out the 3rd and 2nd last
images on Gerhard's page at:

http://www.dangl.at/ausruest/ausrt06e.htm

So apart from grounding the shield or braid of the extension cable,
any multi cable can be used really. If we were timing to
microseconds (rather than milliseconds) then the cable would be very
critical and allowance would need to be made, but for the OSD we
don't need to worry.

Regards, Geoff.

Hi all.

Having owned my KOSD now for a few weeks, I've been looking
forward to trying it out. As I reported earlier, my attempts to
record a graze were thwarted by a week of cloudy weather,
which started a few hours after I turned the gear on for
the first time, and ended a few hours after the event.

Dave G suggested I do some straight occultations to test
out gear and technique. Good suggestion. Checked the predictions
and decided that recording Wednesday evening's Pleiades occultations
would be a good way to find limiting magnitudes, the
effect of a bright moon, etc.

So, I set up the gear Tuesday lunchtime to check all was
well. (To be honest, I needed to check, because I managed to
drop my C5. Nasty ding on the tube, but no other damage. Needed
recollimation though. Not surprising.) Within a couple of hours,
a violent storm moved through Sydney, uprooting trees, unroofing
houses, etc. Needless to say, Tuesday night was cloudy.

Ever the optimist, though, I rescheduled a meeting for today to
make sure I got home in time to catch the occultations. Alas,
the day was very overcast. I joked at the meeting that it would be
cloudy until an hour after the events finished.

I was right. It's clearing up nicely outside.

Geoff, I think your device should come with a warning: "Causes
clouds, storms, tempests, and floods". Luckily, no plague
of locusts ... yet.

Cheers,
Steve.

Warning: initial excitment of using your OSD for the first time will
give way to total frustrations due to cloud cover. For those of you
who suffer from this condition, there is a cure. Before hauling out
all the equipment, driving forever, hooking up all the
equipment....pause, take a deep breath, and turn the Tele to the
weather channel.

--- In kiwiosd@yahoogroups.com, Dave Gee <davegee_inoz@y...> wrote:
>
> Hi Steve,
>
> > Nasty ding on the tube, but no other damage.
>
>   Sorry to hear about that... but good on ya for trying to use the
gear.
>
>   Remember... Bozo the Occultation Gemigod has a law that states
that you have to observe X number of occultations before you get a
good minor planet event served up in good weather and a favourable
moon.  So you may as well make them total lunars...  :-)
>
>   Regards
>
>   DaveGee
>
>
>
>
> ---------------------------------
> Do you Yahoo!?
>   Find a local business fast with Yahoo! Local Search
>

Geoff or whomever:

My Kiwi OSD worked great right out of the box, I'm very happy with the
purchase.

I've played around with GPS in the past, using the fantastic utility
SAWatch (google it with "I'm feeling lucky".  To enable all the SAWatch
features requires quite a number of the Garmin sentences to be turned
on, and I gather the kiwi can't keep up with, say, a 19,200 baud
connection.  Thus, by re-configuring the GPS repeatedly, I can use
either SAWatch (to average position information) or KiwiOSD (time).
With sensor set up as delivered (WAAS off, etc.) SAWatch can still be
used with only (two) Kiwi GPS sentences on, with plot position
information, HDOP, etc., but no details as to satellites in view,
etc.   I'm seeing the output positions clump tightly in one location,
then jump 2-5 meters and clump tightly in another location, and so
forth.  I'd like to learn what's happening (i'm assuming that the
location jumps correlate with switching satellites) so I plan to study
it with Garmin in high baud rate mode.  I have a clear view of the
southern horizon, and the ketector moutned on my roof with no
immediately adjacent trees, etc.

But it makes me wonder: why 4800 Baud limit for the Kiwi?   This is not
a complaint,  as a video time inserter it's tops.

Second question: are there any Integral Technologies FlashBus MV Lite
or MV Pro users out there?  Perhaps you could email me off-group with
advice on software compatible with this(these) video capture card(s) to
permit view of individual fields (17 ms apart for US standard, or 20ms
for PAL).

Thank you.

Chris

Hi Chris,

Welcome aboard, and sorry for my belated reply - I have just returned
from an enjoyable kayak/hiking holiday (southern hemisphere summer).

> But it makes me wonder: why 4800 Baud limit for the Kiwi?

The 16F628A microcontroller

http://tinyurl.com/6lnas

used in KIWI OSD, has a nice hardware serial decoder, so it can work
at quite high baud rates. However the foreground software must be
able to cope with the resultant interrupts (as each byte is decoded).
Because the OSD generates the video text itself, each video field the
microcontroller has to disable all interrupts while it works at full
speed (16MHz) to generates the dots (video text) - this takes just
under 1 millisecond. Because the 16F628A has only a two byte buffer
on its serial receiver, this limits the baudrate to something like
19.2K in theory. However because I have made the serial interrupt
service routine the lowest priority (timing and integrity checks have
a higher priority) at 19.2K the software could possibly miss the odd
character at times when everything happened at once. I ran tests for
a week at 9600 without detecting any data overruns, so by making the
serial rate at 4800 baud, we can be confident that the OSD does not
miss "any" characters from the serial stream.

4800 is also the 'default' rate for the Garmin 18, and is the rate
that is found on many older GPS units.

> I'm seeing the output positions clump tightly in one location,
> then jump 2-5 meters and clump tightly in another location, and so
> I'd like to learn what's happening (i'm assuming that the
> location jumps correlate with switching satellites) so I plan to
> study it with Garmin in high baud rate mode.

Because the default config (for KIWI OSD) has "averaging" enabled, I
think the effect you are seeing Chris, is the short term averaging
(boxcar average) dropping old history values.

Chris it sounds like you have good experience using GPS technology
with SAWatch etc - so will look forward to any insights you may
discover regarding GPS and timing issues.

Regards, Geoff (New Zealand)

In a recent thread DaveG (Australia) wrote
> About a year ago and prompted by Geoff I ran some frame rate tests to
> determine if my PC164C camera could be used as a backup device as
> described here...
>  http://www.geocities.com/kiwi_36_nz/kiwi_osd/example.htm#determine
> I am confident my NTSC camera's rate is within 7 parts per million of the
> specification of  29.97 frames per second.

Because there are a lot of people now using KIWI OSD, I thought it would be
useful to devise a test procedure - so folks could test that they can
do ppm (part per million) tests as DaveG described above.

Rather than measure a camera, we can use someone else's atomic clock and
use that to see if indeed the video time inserter (VTI) can give precision
timestamps.

In New Zealand, TVNZ use a rubidium oscillator to generate their video sync
signals - the rest of the network, genlock off this standard. I believe the
ABC do the same in Australia.

I connected my TV aerial (large yagi mounted under my concrete roofing
tiles) to a high quality Sony VCR (acting purely as a tuner), the output of
this was connected to KIWI OSD which in turn was connected to another VCR
that I had programmed to record - as every 100,000th field rolled over.

The following is a summary of what I recorded:

06:59:50  021  001  # 2    (start of test)
09:46:30  021  001  # 500,002   (end of test)

We can see that after half a million video fields, the phase relationship
between the rubidium based atomic generator and the atomic clocks in the GPS
satellites had not changed at the millisecond level. This is to be expected
for a rubidium standard,  however what we are really testing here is the
actual VTI abilities.

The test lasted 10,000 seconds (02:46:40) and shows the complex VTI software
can make a measurement to one part in 10 million (0.1 ppm) in this case.

Indeed the VTI can be used to monitor the stability of the rubidium standard
over an extended period (for PAL systems only). Notice in the above example
the millisecond counter unit digit is "stuck" on 1 (as were all the
time-stamps) - as they all have been over the last few days. Back in August
(when I last did a quick test) the unit millisecond was 'stuck' on 8. This
stuck digit is the phase relationship between the rubidium oscillator ( I
think it is in Auckland) and the GPS atomic clocks - which are not allowed
to drift as the TVNZ rubidium standard does.

So although the TVNZ signal does not give the time, it is a very stable
clock signal (short term) that can be used to show if a VTI is able to time
stamp video with precision.

I'm not sure what TV stations can be used in the USA for similar tests,
however because I was using version 3 of the KIWI OSD software, users can be
confident that their VTI's are able to carry out prolonged precision
timing - at the millisecond level.

Regards, Kiwi Geoff

I have an story I usually only get to tell to uber-geeks that answers
the question posed below by Geoff.  I guess we're all geeks on this
bus, eh? ;-) :

On Dec 1, 2005, at 6:33 PM, Geoff wrote:

> So although the TVNZ signal does not give the time, it is a very
> stable
> clock signal (short term) that can be used to show if a VTI is able
> to time
> stamp video with precision.
>
> I'm not sure what TV stations can be used in the USA for similar
> tests,
> however because I was using version 3 of the KIWI OSD software,
> users can be
> confident that their VTI's are able to carry out prolonged precision
> timing - at the millisecond level.
>
> Regards, Kiwi Geoff

I was in Vail, Colorado, on a sunny cool day in 1990, August 2nd.  On
this day, unrelated to my trip, President Bush the First was meeting
with Margaret Thatcher in this beautiful Colorado mountain town
(noted for its population of super-rich and famous people).

I was there with a Suburban Van full of video equipment to provide a
"scientific looking background" on a bank of video monitors for my
Boss's boss of my day job at that time at the National Center for
Atmospheric Research.  The project was titled something like "100
Years in the future of science", Speilburg Productions", and I was
told that Speilburg was working on a documentary about the future of
science and he wanted to record interviews with a bunch of famous and
semi-famous scientists.  Sounded like fun gig, although I forget why
they had to do it in Vail, rather than in my video studio, where the
backdrop would have been easy.  They put me and my family up in a
posh hotel in Vail, all expenses paid, and paid me a good penny to
boot.  Not bad!

We were told to get to the hotel where the makeshift film studio was
going to be set up early to avoid the Presidential and Prime Minister
traffic and security.  The film crew came in from New York, and was
shooting on Super 16, and they were able to sync to a video signal
that I was to supply.  I got everything hooked up, and ready to rock
and roll--4 monitors, three Betacam video decks, but I didn't have a
house sync generator.  No problem, I had a little TV with video out,
and I tuned it to a local TV station and fed its output into my first
BetaCam Deck, and then took the sync out from the BeteCam Deck to
feed the rest of the chain, and also give to the 16mm camera.

We're rolling along on the first reel when Thatcher's jet or maybe
Air Force One lands at the Vail Airport, which is close enough to the
hotel that they have to stop shooting for a few minutes for the
audio.  We start up again, and about two minutes into the take, the
camera guy yells "Cut!, The monitors are showing bars!"  Everyone
looks at me, gulp!.  They are paying me good money to be the expert,
here, and I have no idea what broke...  So, I act confident and say,
"Just a second, we must have lost sync..." I look over at the TV, and
the local station has cut into the network soap opera for a CNN feed
of Thatcher and/or Bush stepping off the plane.  They apparently
broke sync to do it!  Never did find out if it was because we were up
in the mountains, and it was a podunk TV station, or what.

The talent (my boss's boss, remember) had to give a luncheon talk (I
guess he was at a scientific conference in Vail, and that is why we
were there, I forget), so after a long lunch break (where, we had
some very interesting and enlightening conversations with the line
producer of the project who was on the internal White House Press
detail during the Reagan Administration, some great stories there!),
we got back to work.  On the second reel, the cameraman yelled,
"There's the bars again!", but I was prepared for this and resynced
and told them to hold off for a few minutes so they could go back to
the soaps, and I could resync again.  I looked over at the TV that
was my master sync generator, and the break-in this time was not
related to Bush or Thatcher--Iraq had just invaded Kuwait!  August
2nd, 1990.

So, that's my story about US TV station master sync. In 1990, in an
isolated mountain community, you couldn't count on a stable sync from
a network broadcast TV station, at least not on a Big News Day. ;-)

St

Sam Herchak wrote:
> left the OSD running for a while before actual occultation. twice
> when i reset the unit for position fixes (after "runs" of 10-15
> minutes), i got the "times not valid - use field count" messages.
> what's your experience with these? is there a certain length
> of "run time" when these begin to crop up? every position fix i
> looked at had 7 to 10 satellites used, so i can't imagine there
> wasn't valid time info available from the GPS at the moment the
> runs were ended.

Sam, you are correct, it is unlikely the GPS system had invalid time
information in the above case. The "integrity test" that you invoke
(by pressing the info switch) compares the GPS time to that of KIWI
OSD. The reason it would have said "Error" would be because you would
have had the camera not powered for more than 4 minutes (to save
battery power once you had initially tested everything was working).

You did the right thing leaving the OSD system running (the longer
the GPS is left powered the better it operates) however without a
video signal into KIWI OSD, after 2^8 (= 256) seconds without video,
the OSD can no longer 'hold its breath' - so it loses time.

To operate correctly KIWI OSD needs the video (camera) to be working.

If you want to see "time fly" you can disconnect (or power down) the
camera for about 4 minutes (but not longer than 4' 16") then
reconnect. If you then observe the HH:MM:SS on the OSD - you will see
the seconds whiz round (as the OSD plays catch-up) - and then tick
over at the normal rate. If you then compare the OSD with WWV you
will see the time is correct because the OSD has realigned itself
with UTC.

However if the input video signal is absent for more than 256 seconds
the OSD loses track of time! (although it can still be derived
because it will be out by a constant modulo 256 seconds).

When you start an actual video recording (for a timed event) you
should "always" use the info switch to get the OSD to give your
position, date etc. This procedure also clears any previous errors,
and sets up the integrity system to function correctly. Also in this
situation the video input (camera) is always running - so the OSD is
able to work as designed and give millisecond accurate timestamps to
each video field.

Regards, Geoff.

i'm asking this question for on of our KIWI users since i guess he
hasn't had time to post it.

he is looking for an app that can take the serial data from the OSD and
use it to set the time on his PC. i think they have another app that
needs an accurate (not sure how accurate) time but want to insure that
the PC is close enough. the program could remain running and monitor
the two times and refresh the PC as needed.

i told him i could indeed write a program that reads the serial port,
parse out the time and then use that to call the API function to set
the time, but some testing would need to be done to see what the delay
would be coming from the serial port, etc. not unsurmountable, but not
something i can throw together in an evening probably either.

so, my question to the group is, does anybody know of a program that
might be able to do this already so i don't have ot reinvent the wheel?

also, what other issues, and i'm sure there will be some, might their
be.

thanks,

vince

Vince wrote:
> my question to the group is, does anybody know of a program that
> might be able to do this already so i don't have ot reinvent the
> wheel?

Assuming the OS is Windows.

I use the freeware Satk (Satellite Assisted Time Keeper)

http://www7.ocn.ne.jp/~set/SatkE.zip

this works fine with KIWI OSD.

Another (but has a slight cost) is NMEATime:

http://www.visualgps.net/NMEATime/default.htm

> also, what other issues, and i'm sure there will be some, might
> their be.

Having Windows deliver accurate timestamps is non trivial. It depends
on what sort of precision they are after. Also the NMEA sentences
vary a little in the time they are sent.

Regards, Geoff.

Hi,

I have a quick question: Is there a way to lower the time display
closer to the bottom of the screen?

Thanks!

Michael


Michael F. Vasseur
Galaxy Blues Observatory (IAU code H89)
Gatineau, Quebec, CANADA

Michael Vasseur wrote:
> I have a quick question: Is there a way to lower the time display
> closer to the bottom of the screen?

The first prototype I made Michael, had the OSD text where you are
wanting it (on the very bottom scan lines). It was not until I took
it out to Brian Loader's observatory that it became apparent that
when the video was viewed with a normal TV (which wraps the very top
and bottom scan lines out of sight) that we could not read the time -
half of the text was not visible.

I then ran a number of tests on different TV's to work out the
position I needed to set the text to display correctly on NTSC and
PAL TV sets.

So the position the text is displayed is a compromise between a TV
display and a digitised display. To enable the user to adjust the OSD
text position, would mean a larger (more expensive) microcontroller
to be used. So it was something that I felt was not worth the extra
expense to do Michael.

Sorry my reply has taken a while, I have been out of town over the
Christmas/holiday period.

Oh, and we are getting near the first "leap second" that the Garmin
18 has experienced (and KIWI OSD), so hopefully what I predicted in

http://finance.groups.yahoo.com/group/kiwiosd/message/15

will come true, I will be monitoring at the time.

Best wishes and Happy New Year to everyone.

Regards, Geoff.

Happy New Year everyone,

I made a video of the change to 2006 and to see the
effects of the leap second by recording the screen of
my KIWI PC and VTI the KIWI OSD.  Alas the video is
too big to upload but I have made a log of the
happenings and have uploaded it to the files section.

Back to the Hair-of-the-Dog remedy....

Regerds

DaveGee

Send instant messages to your online friends http://au.messenger.yahoo.com

Dave Gee wrote:
> I made a video of the change to 2006 and to see the
> effects of the leap second by recording the screen of
> my KIWI PC and VTI the KIWI OSD.

Across the Tasman Sea, I was monitoring the change too Dave!

I had 3 PC's recording the NMEA data stream from 3 GPS's.

In hindsight I should have had my Trimble SV6 in TAIP mode and
logged the "integrity function" in the KIWI PC version, and noted how
the changeover to the new UTC reference occurred (this had never been
tested, because the last leap-second was in 1999). So glad to hear it
worked Dave. I was more focused on testing KIWI OSD.

Dave, I ran KIWI OSD on batteries to minimise electrical
interference - so KIWI OSD behaved as predicted, post 23:59:60 it was
exactly 1 second FAST until I reset it. Upon resetting, KIWI OSD was
then in perfect sync with the 'new' UTC standard.

The following log of the Garmin 18 LVC, shows it performed exactly as
predicted in the Garmin 18 manual for the leap-second.

I have grouped each second to a paragraph, note how $PGRMF relates
GPS time and UTC time!

So KIWI OSD survived the leap-second, I can now doze in the corner
for another 5 years or so - until the next leap-second!

Regards, Kiwi Geoff.

----------------------------------------------
Garmin 18 LVC, edited NMEA data from Leap Second 2005->2006
Geoff Hitchcox, Christchurch, New Zealand.
http://www.geocities.com/kiwi_36_nz/

$GPRMC,235955,,,,,,,,311205,,
$GPGGA,235955
$PGRMF,332,8,311205,235955,13,

$GPRMC,235956,,,,,,,,311205,,
$GPGGA,235956
$PGRMF,332,9,311205,235956,13,

$GPRMC,235957,,,,,,,,311205,,
$GPGGA,235957
$PGRMF,332,10,311205,235957,13,

$GPRMC,235958,,,,,,,,311205,,
$GPGGA,235958
$PGRMF,332,11,311205,235958,13,

$GPRMC,235959,,,,,,,,311205,,
$GPGGA,235959
$PGRMF,332,12,311205,235959,13,

/**** The LEAP Second ****/
$GPRMC,000000,,,,,,,,311205,,
$GPGGA,235959
$PGRMF,332,13,311205,235959,14,
/**** The LEAP Second ****/

/* First second of 2006 */
$GPRMC,000000,,,,,,,,010106,,
$GPGGA,000000
$PGRMF,332,14,010106,000000,14,
/* First second of 2006 */

$GPRMC,000001,,,,,,,,010106,,
$GPGGA,000001
$PGRMF,332,15,010106,000001,14,

$GPRMC,000002,,,,,,,,010106,,
$GPGGA,000002
$PGRMF,332,16,010106,000002,14,

$GPRMC,000003,,,,,,,,010106,,
$GPGGA,000003
$PGRMF,332,17,010106,000003,14,

$GPRMC,000004,,,,,,,,010106,,
$GPGGA,000004
$PGRMF,332,18,010106,000004,14,

$GPRMC,000005,,,,,,,,010106,,
$GPGGA,000005
$PGRMF,332,19,010106,000005,14,
----------------------------------------------