HP 29E IR GPS What????

[Geoff Quickfall]

A little teaser of the functions from the labs of Panamatik!

Received my HP 29C upgrade from Bernhards' lab. This can be confusing and I recommend you visit Panamatik of you love LED HP calculators. I grew up with them and have been using an HP 29E IR that I put together using Bernhards ACT replacement chip.

Panamatik download site

The GPS upgrade came after my talk on the Woodstocks in the 21st Century at HHC2015

Woodstocks in the 21st Century

I now am a proud owner and user of the HP 29E IR GPS. Translated that is an enhanced HP 29C with Infrared print capability and a built in GPS which sends dynamic (updated over time) data to the memory registers in the 29C.

Now my 29C ACT was dead but the keyboard was good. I had a 25 with a bad keyboard, good PCA with a bad ACT. Turns out that the 25 ROM has a larger alpha capability then the 29 ROM due to the increased functionality of the 29. However, and this is interesting, by using the 25 PCA with functional ROM, the Panamatik ACT programmed as a 29E in combination with the GPS the functions of the GPS can be displayed in alpha plus data.

So the following video is a 29C shell, 25C board, Panamatik ACT with IR and GPS. In the video the following program is demonstrated:





the really neat thing about this that the GPS will deposit by request, dynamically updated data to the register of your choice (0 - 7) dynamically updated GPS data. This program requires ZULU in real time to be placed into REG 0 for use by the program. Each call for REG 0 in the program results in the GPS depositing the latest (equivalent to the time of the program request) ZULU time. Any of the functions can be sent to the registers once the initial f STO x command in GPS mode is invoked.

Here is the youtube video I created today. It is best viewed in 720 mode.

HP 29E IR GPS 'world real time clock'

enjoy

[Dieter]

(05-24-2017 06:34 AM)Geoff Quickfall Wrote:  Now my 29C ACT was dead but the keyboard was good. I had a 25 with a bad keyboard, good PCA with a bad ACT. Turns out that the 25 ROM has a larger alpha capability then the 29 ROM due to the increased functionality of the 29. However, and this is interesting, by using the 25 PCA with functional ROM, the Panamatik ACT programmed as a 29E in combination with the GPS the functions of the GPS can be displayed in alpha plus data.

Here is a shorter version of the program that frees one label so that you can enter one more timezone/city group. Also the labels now match the register numbers, so that e.g. GSB 1 uses the timezone stored in R 1. I think this is easier to memorize.

Code:

01  LBL 1
02  RCL 1
03  GTO 0
04  LBL 2
05  RCL 2
06  GTO 0
07  LBL 3
08  RCL 3
09  GTO 0
10  LBL 4
11  RCL 4
12  GTO 0
13  LBL 5
14  RCL 5
15  GTO 0
16  LBL 6
17  RCL 6
18  GTO 0
19  LBL 7
20  RCL 7
21  GTO 0
22  LBL 8
23  RCL 8
24  GTO 0
25  LBL 9
26  RCL 9
27  LBL 0
28  RCL 0
29  +
30  2
31  4
32  X<>Y
33  X<0?
34  +
35  2
36  4
37  X>Y?
38  CLX
39  –
40  RTN

You could even use the 29C's indirect register addressing (RCL i), which would require the GPS time in a register other than R 0 ....or maybe just a few more steps: I am not sure how the GPS time function works in detail, but assuming R 0 is still available as a storage register this could be a solution:

Code:

01  LBL 0
02  RCL 0
03  X<>Y
03  STO 0
04  R↓
05  RCL i
06  +
07  2
08  4
09  X<>Y
10  X<0?
11  +
12  2
13  4
14  X>Y?
15  CLX
16  –
17  RTN

Simply enter 1, 2, 3, .... GSB 0 and get the respective local time. This would allow as many timezones / city groups as memory can hold. Since registers up to R ,5 (i.e. 15) are preserved by constant memory, this would mean up to 15 locations. Of course this requires that the content of R 0 is not changed / overwritten by GPS time during the execution of steps 04 and 05. You said "Each call for REG 0 in the program results in the GPS depositing the latest (...) ZULU time" so that I assume that the current time is generated by the RCL 0 command. In this case everything should work fine ...if R 0 can still be used for indirection. Maybe you can give it a try and report here?

Dieter

[Paul Dale]

(05-24-2017 08:51 AM)Dieter Wrote:  I am not sure how the GPS time function works in detail, but assuming R 0 is still available as a storage register this could be a solution:

Time is fixed to register 0 unfortunately.

Your first program might even be able to be adapted to the 25E GPS, although likely losing some of the time zones.


Pauli

[Geoff Quickfall]

Dynamic functions can only be stored in registers 0 through 7. Sort of the same idea as the Sigma stat registers being fixed.

The program can be modified using indirect registers for extra zones ,but those are the ones I use at work.

Next will be linking a program originally broken into three 98 line sections. Each program calling the next similar to the merge on the 67.

Geoff

[PANAMATIK]

(05-24-2017 10:13 AM)Paul Dale Wrote:  Time is fixed to register 0 unfortunately.

Pauli

Every register 0-7 can be chosen for the actual time. In general, every register can be randomly chosen for every of the GPS data.
Invoking f STO 1 when GPS time is shown uses register 1 for time.
Of course you can use register 0 as indirect register.

Bernhard

[Paul Dale]

Thanks for the corrections. Seems I misunderstood the manual.


Pauli

[Dieter]

(05-24-2017 09:40 PM)PANAMATIK Wrote:  Every register 0-7 can be chosen for the actual time. In general, every register can be randomly chosen for every of the GPS data.
Invoking f STO 1 when GPS time is shown uses register 1 for time.
Of course you can use register 0 as indirect register.

If I understand this correctly – and after reading the ACT manual p. 60/61 – Geoff's original program assumes that the "dynamic data storage" feature has been enabled before by an initial f STO 0 so that the current time is stored in R 0 and updated every second. Any manual STO 0 during a regular calculation will stop the permanent update of this register. So there is no way of using any of the eight possible registers both for continuously updated GPS data and temporary use in regular calculations. If R 0 is required as the 29C's index register it cannot be used for GPS data without stopping the continuous data update.

Is there a chance that a later 29C GPS version may use more than just R 0 ... R 7?

Dieter

[PANAMATIK]

Sorry, that the manual does not describe everything clear enough.

(05-25-2017 03:04 PM)Dieter Wrote:  If I understand this correctly – and after reading the ACT manual p. 60/61 – Geoff's original program assumes that the "dynamic data storage" feature has been enabled before by an initial f STO 0 so that the current time is stored in R 0 and updated every second.

Yes. But Geoff should use f STO 1 and RCL 1 in the program instead, then R0 is still free to use as index register.

(05-25-2017 03:04 PM)Dieter Wrote:  Any manual STO 0 during a regular calculation will stop the permanent update of this register.

No, this is true only when you are in GPS menu, not during regular calculation mode.

(05-25-2017 03:04 PM)Dieter Wrote:  So there is no way of using any of the eight possible registers both for continuously updated GPS data and temporary use in regular calculations.

Yes, because your temporary value will be overwritten every second. Perhaps you think that f STO n enables continuous update generally to all registers? No, f STO n enables continuous update only for the value, which is actually displayed. You can choose which value will be updated individually.

(05-25-2017 03:04 PM)Dieter Wrote:  If R 0 is required as the 29C's index register it cannot be used for GPS data without stopping the continuous data update.

There are 8 different GPS data available, but you can choose which of them are continuously updated and to which register it is written, the other registers are still available for your calculations.

(05-25-2017 03:04 PM)Dieter Wrote:  Is there a chance that a later 29C GPS version may use more than just R 0 ... R 7?

This would be required only if you want to use all eight GPS values (UTC time, latitude, longitude, Speed, Heading, Elevation, doHP and No of Satellites) to be dynamically updated. But I don't think you need all of them. At least the HP-29E could be extended to use also registers 8-9 in a later version.

Bernhard

[Dieter]

(05-25-2017 04:47 PM)PANAMATIK Wrote:  Yes. But Geoff should use f STO 1 and RCL 1 in the program instead, then R0 is still free to use as index register.

Geoff does not want to use any indirect register calls, it's me who suggested this way of extending the number of possible locations.

(05-25-2017 04:47 PM)PANAMATIK Wrote:  

(05-25-2017 03:04 PM)Dieter Wrote:  Any manual STO 0 during a regular calculation will stop the permanent update of this register.

No, this is true only when you are in GPS menu, not during regular calculation mode.
(...)
...your temporary value will be overwritten every second.

OK. Now please take a look at the second program version I suggested earlier in this thread:

Code:

01  LBL 0
02  RCL 0
03  X<>Y
03  STO 0
04  R↓
05  RCL i
06  +
..  ...

Here R0 is recalled, then an index number (1, 2, 3, ...) is stored there and the indexed register containing the timezone is recalled and added. This should take not more than about 0,1...0,2 seconds. Would this mean that the proposed program should work in, say, 4 out of 5 cases, but sometimes the GPS data update happens during these first steps before the RCL i, thus overwrites R0 so that RCL i recalls the wrong register?

Anyway, according to the above information this version should work once the GPS time is assigned to R 1:

Code:

01  LBL 0
02  STO 0  ; store index
03  ISZ    ; increment index to get register number for timezone
04  RCL 1  ; recall GPS time
05  RCL i  ; add local timezone
06  +
07  2
08  4
09  X<>Y
10  X<0?
11  +
12  2
13  4
14  X>Y?
15  CLX
16  –
17  RTN

This version uses R0 as index register while R1 holds the current GPS time (f STO 1). The timezone table is stored in R2 and up, so timezone no. (i) is returned by RCL (i+1). That's why I'd prefer GPS data to be stored in higher registers so that R1...R14 could be used for the timezone table.

(05-25-2017 04:47 PM)PANAMATIK Wrote:  

(05-25-2017 03:04 PM)Dieter Wrote:  Is there a chance that a later 29C GPS version may use more than just R 0 ... R 7?

This would be required only if you want to use all eight GPS values (UTC time, latitude, longitude, Speed, Heading, Elevation, doHP and No of Satellites) to be dynamically updated. But I don't think you need all of them. At least the HP-29E could be extended to use also registers 8-9 in a later version.

If would be a nice feature even if you only need one or two of the GPS values because it may free up the lower registers for general use. So an f STO ,5 would leave R 0...14 unchanged.

Dieter

[PANAMATIK]

(05-25-2017 06:11 PM)Dieter Wrote:  ... Would this mean that the proposed program should work in, say, 4 out of 5 cases, but sometimes the GPS data update happens during these first steps before the RCL i, thus overwrites R0 so that RCL i recalls the wrong register?

Any register, which is assigned to dynamic GPS data, should to be used as read only value, because it could be updated any time. Just use any other register for indexing or calculations.

(05-25-2017 06:11 PM)Dieter Wrote:  If would be a nice feature even if you only need one or two of the GPS values because it may free up the lower registers for general use. So an f STO .5 would leave R 0...14 unchanged.

For compatibility with HP-25E GPS I will not implement the upper registers for dynamic data. I see no disadvantage to use the upper registers in your program for calculations instead.

Bernhard

[Geoff Quickfall]

Yes,

I was lazy and did not use REG 0 for indexing, in fact I forgot about indexing and REG 00! Time to get the 29c manual out again. My initial program used manual input for GMT and this was an extremely minor change. Also, OCD caused me to change the GMT dynamic data to REG 0 :-)

Indexing with REG 1 would increase the zones for a more complete world time clock.

The YouTube video, (turn on hi def and captions), explains and demonstrates the active update of REG 0 and the ability to disable this update; not by manual input to the REG but by switching to GPS mode and pushing the CLX button.

------------------

You will see in the above coding that there is a second data register 3 with the time zones reversed (page 2). The GPS update of REG 0 must be disabled for this to routine to work. I have a pocket alarm set to GMT. It is a wonderful loud and vibrating alarm:

Invisible clock

This clock is awkward to change time zones so instead I use the second set of data to set the correct local alarm converted to GMT to the GMT alarm clock.

Geoff