Page 2 of 2

Re: GPS project

PostPosted: Mon Jun 08, 2020 5:37 pm
by Brutman
I tried to read that post on my laptop and it got really warm and then started emitting smoke. Google Translate also couldn't tell what language that was in. However, that sounds like a really neat project. Is there a Python program or a pre-compiled binary for Windows 10 available?

Re: GPS project

PostPosted: Mon Jun 08, 2020 6:05 pm
by alanh
What part of 'dead on balls accurate' is hard to understand? :)

The cliff notes version is no local oscillator is 100.00000% accurate to the frequency printed on the can. You know this, hence the problem you are trying to solve with GPS.

So get an oscillator with a +/- fine frequency adjustment. Count the number of ticks between GPS pulses per second. If the tick count is smaller than the desired frequency, turn up the fine adjustment knob. If it's higher, turn down the fine adjustment knob. Create a PID loop to do this automatically every second. Bingo, you have a local oscillator that averages to 100.00000000% accuracy (or however accurate GPS is at least). Let the frequency you choose be 14.318 MHz (the crystal frequency of a 4.77 MHZ 8088 like the PCjr) and use your shinny dead on balls accurate oscillator as the system clock reference. Now you don't have to write any Python, run any Windows 10, or any of that Satan-worshiping software stuff!!!

Re: GPS project

PostPosted: Mon Jun 08, 2020 6:29 pm
by Brutman
So you causally throw in a control system and you talk about the rest of us being Satan worshippers? :-)

Re: GPS project

PostPosted: Tue Jun 09, 2020 11:09 am
by alanh
alanh wrote:For example, 5% duty would be 14318181 - (75 * .05) Hz, where a 95% duty would be 14318181 + (75 * .95) Hz.


Just correcting my math:

5% duty would be 14318181 - (75 * 14.31 * .95) Hz (, where a 95% duty would be 14318181 + (75 * 14.31 * .95) Hz.

So 14317161 MHz (5%) to 14319212 MHz (95%)

Re: GPS project

PostPosted: Sun Jul 05, 2020 12:34 pm
by Brutman
So I got back to this project and I decided to try mode 2 of the 8253 timer out. Short story, it works ...

This code is better because it doesn't change the interrupt interval from the 8253 like the previous code, so that interrupt is firing back at the normal 18.2 times per second. I had it firing 64x faster before which is slightly noticeable on the machine, and also raises the chances than an interrupt will be missed. The biggest challenge was doing the math correctly without doing floating point. I'm using 32 bit integers to keep things faster than using emulated floating point, and it is slightly sloppy but it works.

I think my timing resolution is comfortably under 1ms now where before it was in the 1 to 2ms range. When the GPS 1PPS causes an interrupt I increment my own "seconds since the epoch" counter, the BIOS ticks and the 8253 counter are read and squirreled away. The interrupt gets handled, my code resumes, and it sees that the interrupt has recently fired. It then snapshots the BIOS ticks and 8253 counter again, does the math, and computes the current timestamp. This is taking on the order of 600 to 700 microseconds to do. (Screen access time is not counted; it's just the time to finish the interrupt handler, get back to the main program loop, figure out the time needs to be displayed, and then compute the current time.)

Assuming 650 microseconds and machine running at 4.77Mhz that works out to 3100 clock cycles. I actually have a V20 which is slightly better than the stock 8088 but the machine is running C code that isn't highly optimized and it's still doing integer division on the math. This doesn't seem unreasonable, and if I can knock off a few division instructions I can save a lot of clock cycles. (Shifting 10 bits right instead of dividing by 1000 would save a lot of cycles at the expense of some accuracy.)


Mike