newRPL: [UPDATED April 27-2017] Firmware for testing available for download

[Han]

Out of curiosity, is Qpi the original HP Qpi or are you referring to the QPI program from the HP48 days?

Lastly, are you using the same algorithm from the HP calcs? or did you happen to implement the algorithm that can be found in the "Best rational approximation" here: https://en.wikipedia.org/wiki/Continued_fraction

[Claudio L.]

(03-17-2016 05:41 PM)Han Wrote:  Out of curiosity, is Qpi the original HP Qpi or are you referring to the QPI program from the HP48 days?

I mean the built-in commands in the 50g, →Q and →Qπ, just that I was too lazy to use the proper Unicode characters.

(03-17-2016 05:41 PM)Han Wrote:  Lastly, are you using the same algorithm from the HP calcs? or did you happen to implement the algorithm that can be found in the "Best rational approximation" here: https://en.wikipedia.org/wiki/Continued_fraction

I don't know or looked at the algorithm implemented for HP calcs.
It's essentially the same algorithm as Wikipedia but more streamlined to find rational approximations.
I actually took the simplified algorithm from this description.

[Vtile]

This might be wrong thread, but any idea of implementing a "pickn..m" style copy&move a block from stack to bottom of it? This specifically to "stack menu".

[Claudio L.]

(03-19-2016 06:22 PM)Vtile Wrote:  This might be wrong thread, but any idea of implementing a "pickn..m" style copy&move a block from stack to bottom of it? This specifically to "stack menu".

I think is a good idea. I have to think about it some more to see what could be a good syntax. There should be a "pick" to copy and then a "roll" to move I think, to be consistent with the usual names.
Also, I'm not sure it is needed for many objects, or perhaps just for groups of 2, 3 and perhaps 4 items.
Then for example command PICK2 would be identical to PICK, but copy 2 items. PICK3 for 3 items, etc.
Or should it be a generic "PICKN" taking 2 arguments from the stack?

[Francois Lanciault]

Hi Claudio,

Small bug (latest version):

If you use the function UBASE (in the units/tools menu) with a number without units the calculator give the error "expected an object with units" as it should. But if you use that same function with nothing on the stack, an exception is triggered (data abort) instead of the normal error message "Bad argument count". If I use "cont" on the exception screen the calculator returns to the normal operation screen with the message "expected an object with units".

Sorry, nothing more interesting to report, the latest version is quite stable. I have been using it for a few days at work doing a lot a units conversion without problem.

François

[Visitor]

Hello Claudio,

in dectranscen.c many constants (e.g. decconst_PI() ) are given back with twice the precision as set
due to shift right of only 2

Code:


int nwords=253-((Context.precdigits+7)>>2);

is that intended?

currently a side effect will be that with the default settings (32 digits) if I enter pi0 i get back pi with almost 70 digits (instead of 32)

shouldn't the constant being rounded before pushing it to the display?

if I multiply this longer number by 1 it will be rounded to the system precision.

BTW I'm admiring your work and the time you are putting into this project. I just came recently across this project and am very excited of it.

regards

Martin

[Claudio L.]

(03-29-2016 05:20 PM)Visitor Wrote:  Hello Claudio,

in dectranscen.c many constants (e.g. decconst_PI() ) are given back with twice the precision as set
due to shift right of only 2

Code:


int nwords=253-((Context.precdigits+7)>>2);

is that intended?

currently a side effect will be that with the default settings (32 digits) if I enter pi0 i get back pi with almost 70 digits (instead of 32)

shouldn't the constant being rounded before pushing it to the display?

if I multiply this longer number by 1 it will be rounded to the system precision.

BTW I'm admiring your work and the time you are putting into this project. I just came recently across this project and am very excited of it.

regards

Martin

I'm glad somebody is actually looking at the code. And understanding it despite my bad coding habits too!
Jokes aside, yes, it is intended. Most of those constants are for internal use by the trig and hyperbolic functions, therefore they need some extra precision to guarantee that the final result has enough digits.
Case in point: the PI constant is used for argument reduction among other things. If an angle is exactly the same as PI with 32 digits precision, the angle it represents is not exactly PI, but only the first 32 digits of PI. We need the internal PI to have at least twice the digits, so that when subtracting PI0-angle we get at least 32 significant digits for the angle we'll be using as input to SIN or COS to have any meaning.
For example:
π0 SIN gives a meaningless result, because the input is too close to PI at double precision, and the system fails to produce an accurate result.
EDIT: That result is not totally meaningless, it's actually accurate up to a few guard digits (usually 8). Just do π0 SIN π0 GETPREC 2 * SETPREC π0 - + and you'll get that only the first 8 digits were correct.

The Pi0 constant was exposed to the user for those corner cases. Quite often you need PI at a higher precision than normal so subtractions work well for angles near PI. Notice the 0 in the name, to make it different from the regular PI constant.
As you noticed, operations will round the result to the system precision, and that's the important part: it's the result that's rounded, but never the arguments! The operation will take place using the arguments as given, only the final result will be rounded.

[Claudio L.]

(03-25-2016 08:48 PM)Francois Lanciault Wrote:  Hi Claudio,

Small bug (latest version):

If you use the function UBASE (in the units/tools menu) with a number without units the calculator give the error "expected an object with units" as it should. But if you use that same function with nothing on the stack, an exception is triggered (data abort) instead of the normal error message "Bad argument count". If I use "cont" on the exception screen the calculator returns to the normal operation screen with the message "expected an object with units".

Sorry, nothing more interesting to report, the latest version is quite stable. I have been using it for a few days at work doing a lot a units conversion without problem.

François

Thank you! Another bug fixed.
I'm adding a few more commands and also adding all the menus (that's a lot of work), so in a couple of weeks we'll have a much more usable ROM for everyday calculations. Stay tuned and keep hunting for bugs, it's stable but I know there is quite a few in there, just not easy to find.

[Visitor]

(03-30-2016 04:43 PM)Claudio L. Wrote:  I'm glad somebody is actually looking at the code. And understanding it despite my bad coding habits too!
Jokes aside, yes, it is intended. Most of those constants are for internal use by the trig and hyperbolic functions, therefore they need some extra precision to guarantee that the final result has enough digits.
Case in point: the PI constant is used for argument reduction among other things. If an angle is exactly the same as PI with 32 digits precision, the angle it represents is not exactly PI, but only the first 32 digits of PI. We need the internal PI to have at least twice the digits, so that when subtracting PI0-angle we get at least 32 significant digits for the angle we'll be using as input to SIN or COS to have any meaning.
For example:
π0 SIN gives a meaningless result, because the input is too close to PI at double precision, and the system fails to produce an accurate result.
EDIT: That result is not totally meaningless, it's actually accurate up to a few guard digits (usually 8). Just do π0 SIN π0 GETPREC 2 * SETPREC π0 - + and you'll get that only the first 8 digits were correct.

The Pi0 constant was exposed to the user for those corner cases. Quite often you need PI at a higher precision than normal so subtractions work well for angles near PI. Notice the 0 in the name, to make it different from the regular PI constant.
As you noticed, operations will round the result to the system precision, and that's the important part: it's the result that's rounded, but never the arguments! The operation will take place using the arguments as given, only the final result will be rounded.

Thanks Claudio for taking the time to explain it in detail.

Martin

[Claudio L.]

(03-30-2016 08:16 PM)Visitor Wrote:  Thanks Claudio for taking the time to explain it in detail.

Martin

No problem. By the way, since it seems you understood some hairy parts of the code quite well, please allow me to extend an invitation to join the project. If you feel you can create a library and add commands (really simple right now), let me know as I could use some help. This was supposed to be a community project, not a one-man crazy quest to save RPL from extinction.

Claudio

[Visitor]

(03-31-2016 03:16 PM)Claudio L. Wrote:  

(03-30-2016 08:16 PM)Visitor Wrote:  Thanks Claudio for taking the time to explain it in detail.

Martin

No problem. By the way, since it seems you understood some hairy parts of the code quite well, please allow me to extend an invitation to join the project. If you feel you can create a library and add commands (really simple right now), let me know as I could use some help. This was supposed to be a community project, not a one-man crazy quest to save RPL from extinction.

Claudio

Why not. Lets give it a try.
Currently I'm travelling without Computer equipment until april 9. But that should not be a problem, right?

Saluti

Martin

[Nigel (UK)]

Since flashing my HP-49g+ with newRPL on more than one occasion the machine wouldn't switch on because the batteries were flat. I have blamed myself for leaving it turned on as after all there is no auto-power-off yet.

This evening I decided to measure the current drawn by the calculator. I put two strips of copper separated by an insulator in series with the final positive battery terminal and connected the strips to a meter set to its 200mA range. The calculator switched on when the circuit was complete; the current drawn was 80mA. Switching it off via the keyboard, the current dropped to 10mA. Switching on again, this time via the keyboard, the current drawn was about 40mA. The current drawn when switched off was still about 10mA.

These "off" currents seem far too high (and the "on" currents as well, although I'm less certain about those). Can anyone else confirm them? In particular, does the HP-50g when flashed with newRPL suffer from the same problem?

Nigel (UK)

(In case you are wondering - I definitely mean mA, not microamps!)

[Claudio L.]

(04-11-2016 07:36 PM)Nigel (UK) Wrote:  Since flashing my HP-49g+ with newRPL on more than one occasion the machine wouldn't switch on because the batteries were flat. I have blamed myself for leaving it turned on as after all there is no auto-power-off yet.

This evening I decided to measure the current drawn by the calculator. I put two strips of copper separated by an insulator in series with the final positive battery terminal and connected the strips to a meter set to its 200mA range. The calculator switched on when the circuit was complete; the current drawn was 80mA. Switching it off via the keyboard, the current dropped to 10mA. Switching on again, this time via the keyboard, the current drawn was about 40mA. The current drawn when switched off was still about 10mA.

These "off" currents seem far too high (and the "on" currents as well, although I'm less certain about those). Can anyone else confirm them? In particular, does the HP-50g when flashed with newRPL suffer from the same problem?

Nigel (UK)

(In case you are wondering - I definitely mean mA, not microamps!)

If the IO pins are not properly setup there can be currents when off, and that's something I need to investigate and correct. I didn't notice any problems on my 50g, batteries last quite long now that I have enabled auto-power off I'd say about the same as my other 50g with stock firmware.
10 mA is a lot of current, there might be something setup incorrectly, I just need to figure out what it is.
There's virtually no difference in hardware between a 50g and 49g+, except for an extra battery and the circuitry to power the calculator from the USB port. That's where I should start looking.

[Nigel (UK)]

(04-12-2016 02:41 AM)Claudio L. Wrote:  If the IO pins are not properly setup there can be currents when off, and that's something I need to investigate and correct. I didn't notice any problems on my 50g, batteries last quite long now that I have enabled auto-power off I'd say about the same as my other 50g with stock firmware.
10 mA is a lot of current, there might be something setup incorrectly, I just need to figure out what it is.
There's virtually no difference in hardware between a 50g and 49g+, except for an extra battery and the circuitry to power the calculator from the USB port. That's where I should start looking.

Just to confirm my readings (this time with a proper power supply and crocodile clips):

• Current when power is first applied - 82.4 mA
• Current when switched off: 4.2 mA
• Current when switched on from the keyboard: 42.4 mA
• Current when switched off again from the keyboard - 6.8 mA
  

Subsequent currents are all close to 42mA (on) and between 5mA and 10mA (off).

Nigel (UK)

[Nigel (UK)]

(04-12-2016 08:10 AM)Nigel (UK) Wrote:  Just to confirm my readings (this time with a proper power supply and crocodile clips):

• Current when power is first applied - 82.4 mA
• Current when switched off: 4.2 mA
• Current when switched on from the keyboard: 42.4 mA
• Current when switched off again from the keyboard - 6.8 mA
  

Subsequent currents are all close to 42mA (on) and between 5mA and 10mA (off).

Nigel (UK)

One extra piece of information that might give a clue: I've left the calculator turned off for about 2 hours and the current settled at about 4 mA. Removing the SD card causes the current to jump up to 10 mA. Re-inserting the card causes the current to drop back to 4 mA again, even before the card is properly seated. Simply having the card mostly in without pushing causes the current to drop.

Nigel (UK)

[Claudio L.]

(04-12-2016 10:09 AM)Nigel (UK) Wrote:  

(04-12-2016 08:10 AM)Nigel (UK) Wrote:  Just to confirm my readings (this time with a proper power supply and crocodile clips):

• Current when power is first applied - 82.4 mA
• Current when switched off: 4.2 mA
• Current when switched on from the keyboard: 42.4 mA
• Current when switched off again from the keyboard - 6.8 mA
  

Subsequent currents are all close to 42mA (on) and between 5mA and 10mA (off).

Nigel (UK)

One extra piece of information that might give a clue: I've left the calculator turned off for about 2 hours and the current settled at about 4 mA. Removing the SD card causes the current to jump up to 10 mA. Re-inserting the card causes the current to drop back to 4 mA again, even before the card is properly seated. Simply having the card mostly in without pushing causes the current to drop.

Nigel (UK)

Good info, thanks. I'll look into the SD card pins.
However, I haven't changed batteries in several weeks, and 4mA with 800 mAh rechargeable batteries should last 200 hrs, or 8 days and change. Add normal daily usage at work and I should've been replacing batteries every week or more often.
That tells me my unit doesn't leak current like yours, but I have no idea why. Han reported big power consumption too, I'd like to hear if he still has that problem.

[Francois Lanciault]

(04-12-2016 01:17 PM)Claudio L. Wrote:  

(04-12-2016 10:09 AM)Nigel (UK) Wrote:  One extra piece of information that might give a clue: I've left the calculator turned off for about 2 hours and the current settled at about 4 mA. Removing the SD card causes the current to jump up to 10 mA. Re-inserting the card causes the current to drop back to 4 mA again, even before the card is properly seated. Simply having the card mostly in without pushing causes the current to drop.

Nigel (UK)

Good info, thanks. I'll look into the SD card pins.
However, I haven't changed batteries in several weeks, and 4mA with 800 mAh rechargeable batteries should last 200 hrs, or 8 days and change. Add normal daily usage at work and I should've been replacing batteries every week or more often.
That tells me my unit doesn't leak current like yours, but I have no idea why. Han reported big power consumption too, I'd like to hear if he still has that problem.

I will check power consumption on mine tonight and report.

Edit...

Here is what I get on a HP-50G with Newrpl hooked to a 6 volts regulated power supply

Calculator ON : 42.3 milliAmps
Calculator OFF: 21.7 microAmps (2000 times less than ON state)

Same values with or without the SD card installed

François

[Nigel (UK)]

(04-12-2016 10:09 AM)Nigel (UK) Wrote:  

(04-12-2016 08:10 AM)Nigel (UK) Wrote:  Just to confirm my readings (this time with a proper power supply and crocodile clips):

• Current when power is first applied - 82.4 mA
• Current when switched off: 4.2 mA
• Current when switched on from the keyboard: 42.4 mA
• Current when switched off again from the keyboard - 6.8 mA
  

Subsequent currents are all close to 42mA (on) and between 5mA and 10mA (off).

Nigel (UK)

One extra piece of information that might give a clue: I've left the calculator turned off for about 2 hours and the current settled at about 4 mA. Removing the SD card causes the current to jump up to 10 mA. Re-inserting the card causes the current to drop back to 4 mA again, even before the card is properly seated. Simply having the card mostly in without pushing causes the current to drop.

Nigel (UK)

One further piece of information: I've re-flashed my HP-49g+ with the HP ROM 2.15. Current when turned on is 12 mA (with big pulses when keys are pressed); current when turned off is 18 microamps.

Edit: to be clear, I didn't notice the current pulses when pressing keys with the newRPL firmware installed. The current was high all the time.

Nigel (UK)

[Vtile]

Are everyone measuring the currents with precise enough equipment, if the measuring device have too much burden voltage (which is suprisingly big even in many high end benchmeters HPs/Agilents incluted) it might effect suprisingly to your device.

[Claudio L.]

(04-12-2016 01:24 PM)Francois Lanciault Wrote:  Here is what I get on a HP-50G with Newrpl hooked to a 6 volts regulated power supply

Calculator ON : 42.3 milliAmps
Calculator OFF: 21.7 microAmps (2000 times less than ON state)

Same values with or without the SD card installed

François

(04-13-2016 11:59 AM)Nigel (UK) Wrote:  One further piece of information: I've re-flashed my HP-49g+ with the HP ROM 2.15. Current when turned on is 12 mA (with big pulses when keys are pressed); current when turned off is 18 microamps.

Edit: to be clear, I didn't notice the current pulses when pressing keys with the newRPL firmware installed. The current was high all the time.

Nigel (UK)

Some notes:
a) The calculator running at 12 MHz (stock ROM idling) consumes 12 mA. This is consistent with some old measurements posted in this forum.
b) The calculator 'spikes' when pressing a key because the stock rom changes the clock to 75 MHz and then back to 12 MHz.
c) newRPL uses 6MHz clock when idling, so current should be around 12 mA or lower, if it's 42 mA something isn't right, something must be mis-configured.
d) Why some calculators would not drain current and some others will is a mystery to me. Perhaps some hidden hardware revision that happened over the years. The configurations of pins are identical on power-up, and are not retained when power is lost, so all calcs should be good or all bad, unless something is different in the hardware.

I'll see if I can investigate more this weekend.