Yet another DIY RPN calculator

[apoluekt]

Hi all,

I've been reading this forum for quite a long time, but did not bother to register until recently. I've used RPM calculators back in school, mostly to fly to the Moon, then I've switched to algebraic ones, then I didn't own any hardware calculators: was either using a Python prompt or cell phone apps.

Recently it occurred to me that I needed a hardware calculator. Not that I desperately needed one, but it would just have been convenient to have something lying on a table which I could use for some back-of-the-envelope style estimates, without the need to start apps, open terminals, etc. Ideally, it would need to have some specific functions that I often need (I'm doing high-energy physics).

I hate to admit this on this forum, but I don't see a use case for programmable calculator for me. If I need to program something relatively complicated, I'd better do it on a computer. Instead, I'd like to have a set of rather specific functions which would only be one-two clicks away (of course I could have programmed them on DM42 or whatever, but running a program is by far not equivalent to pressing a button).

Thankfully, modern MCUs make building custom calculators relatively easy. So I ended up make my own one (I'll resist citing Futurama here). Here's what comes out so far: https://github.com/apoluekt/OpenRPNCalc



The design is kind of inspired by DM42, at least it's using the same Sharp LCD and STM32L476 (good choice, SwissMicros!). The schematics is of course much simpler, as I did not intend to implement any fancy stuff. I've tried to make the keyboard as soft as possible by using 50g actuation force switches. The case and keypad are 3D printed, and key labels are made using laser printable sticky film.

Firmware-wise, it is of course in a constant development. but I think now it largely has most of what I wanted to have in my custom calculator. One notable feature which I think was not implemented in any hardware calcs so far is calculations with uncertainties using error propagation.

I'm publishing all the design files in github under free license, hopefully it could be useful for somebody to make their own machine.

[mfleming]

(05-28-2021 08:48 PM)apoluekt Wrote:  I hate to admit this on this forum, but I don't see a use case for programmable calculator for me. If I need to program something relatively complicated, I'd better do it on a computer.

A point made often in discussions about the future of calculators. In the rare instances where I need to repetitively calculate variants on a theme I just use the solver on a 27S or 200LX.

Inclusion of uncertainty in calculation is certainly unique. How do you manage entry & display of SI units in Eng mode?

Some very "out of the box" thought put into this project. Thanks for making the design files available. Perhaps Swiss Micros should produce a 'blanknut' handheld for experimental models like this?

~Mark

[apoluekt]

Thanks of the feedback!

(05-29-2021 02:43 PM)mfleming Wrote:  Inclusion of uncertainty in calculation is certainly unique. How do you manage entry & display of SI units in Eng mode?

I don't display units, only prefixes (like "m" for 10^-3, "mu" for 10^-6 etc.). You can see them displayed under the exponent figures in the photo above. It only affects the display, entering values is done as usual.

Implementation of uncertainties needs some further thought. For the moment, I've done it in a most dumb way, everything is considered uncorrelated. Even that is useful in many practical cases, but there are packages (like "uncertainties" module in Python) that do it smarter and keep track of correlations internally.

[ttw]

If you have access to a modern floating-point CPU, you may consider implementing interval arithmetic to handle errors. It's fairly hard in software though. It's also important to implement some things like the interval Newton method which can shrink intervals faster than one might think. (One calculates upper and lower bounds on the putative answer and then takes the intersection of this interval with the previous; because of the interval intersection part, one can get really nice contractions, still no better than quadratic.)

There are some other interval things but I haven't kept up.

[mpark]

So awesome--kudos!

What does the /-/ key do? And the G key?

My Ender 3 has the same x-not-quite-perpendicular-to-y problem. How did you adjust the frame to compensate? What I've been doing when my upside-down tops don't fit is to rotate them 90 degrees in Z to cancel out the error, but an actual fix to the printer would be better!

[tcab]

Amazing work!

I wonder if it’s possible to integrate micro-python into it - presumably it’s just more C code to compile...

[apoluekt]

(05-30-2021 05:57 AM)mpark Wrote:  What does the /-/ key do? And the G key?

I was expecting this question. Because of introduction of UNCERT mode, the usual change of sign notation as "+/-" became ambiguous. "/-/" is the "normal" change of sign (maybe would've been better to use "(-)" in TI style). "+/-" next to "Enter" is used to switch between entering the value and its uncertainty.

"G" is the second Shift key (in addition to "F"). Not used much for the moment, only for a couple of functions which are not even reflected on the stickers (change of direction for eta<->theta and gamma<->beta conversion).

(05-30-2021 05:57 AM)mpark Wrote:  My Ender 3 has the same x-not-quite-perpendicular-to-y problem. How did you adjust the frame to compensate? What I've been doing when my upside-down tops don't fit is to rotate them 90 degrees in Z to cancel out the error, but an actual fix to the printer would be better!

Yes, I really wanted to have both sides of the case printed with outside surface lying on the bed, such that it looks nice and flat. This required adjusting the printer.

That was easy. I could notice by eye that the X beam was not exactly parallel to the edge of the bed (if you move the bed towards you such that its edge is right under the X beam, look from the top and close one of your eyes , it becomes apparent). I've loosened the four bottom screws that hold the Z axes. These's a bit of play in them, so you can adjust the frame such that X beam becomes parallel to the edge of the bed with the one-eye trick, tighten them back and you're done.

I guess it's possible that the play in bottom screws won't be enough to fix this, then I'd look carefully at the pulleys that move along Z beams, maybe e.g. placing thin washers in the wheels could help. By in my case this was not needed.

I've seen in reddit posts that some slicers can make a software correction for this, but apparently Cura does not support it.

[apoluekt]

(05-30-2021 07:50 AM)tcab Wrote:  I wonder if it’s possible to integrate micro-python into it - presumably it’s just more C code to compile...

Yes, I'm sure it's possible, STM32L476 seems powerful enough (1M flash, 128k RAM). I don't have any experience with micropython though, and I have no idea how power-hungry it will be.

[tcab]

(05-30-2021 05:19 PM)apoluekt Wrote:  Yes, I'm sure it's possible, STM32L476 seems powerful enough (1M flash, 128k RAM). I don't have any experience with micropython though, and I have no idea how power-hungry it will be.

Seems there is support for quite a few variants of STM32L476 https://www.st.com/en/embedded-software/...l#overview. Interesting.

[Ren]

From the photo I thought...
"Wow! He built a calculator that uses an epaper (e-ink, whatever) display!"
Only later did I read that it was LCD.

(aside) After being active on these fora the past few months,
I no longer think...
"Wow! He built a calculator!"
B^)
(This last comment was in no way intended as an insult to your accomplishment (I'm getting used to seeing the brilliance of some of the folks here))

[rawi]

apoluekt wrote:

Quote:I hate to admit this on this forum, but I don't see a use case for programmable calculator for me. If I need to program something relatively complicated, I'd better do it on a computer. Instead, I'd like to have a set of rather specific functions which would only be one-two clicks away (of course I could have programmed them on DM42 or whatever, but running a program is by far not equivalent to pressing a button).

In quite a number of calculators (e.g. DM41X) you can assign a program to a button. Then you can press the button to run the program. (Btw: This is essentially the same as if you press a "cos" button on a calculator: It makes the calculator run a program). This is much much easier than to build a new calculator. So I do not understand your motivation to build yet another calculator.

Best

Raimund

[agarza]

(05-28-2021 08:48 PM)apoluekt Wrote:  One notable feature which I think was not implemented in any hardware calcs so far is calculations with uncertainties using error propagation.

'Uncertainties"? Great Idea. Never had thought of that.

[apoluekt]

(05-31-2021 04:10 AM)Ren Wrote:  From the photo I thought...
"Wow! He built a calculator that uses an epaper (e-ink, whatever) display!"
Only later did I read that it was LCD.

Yep, Sharp LCD is by far not e-paper, it has amazing contrast (compared to other matrix LCD displays), but only if you watch it under the correct angle.

I did experiment with e-paper on a Raspberry Pi (Waveshare 2.7" display, basically the same size), but it's way too slow, not usable for a calculator.

[apoluekt]

(05-31-2021 04:47 AM)rawi Wrote:  In quite a number of calculators (e.g. DM41X) you can assign a program to a button. Then you can press the button to run the program. (Btw: This is essentially the same as if you press a "cos" button on a calculator: It makes the calculator run a program). This is much much easier than to build a new calculator. So I do not understand your motivation to build yet another calculator.

Sure it's easier, but still by far not as flexible as a custom firmware. E.g. I doubt it is possible to completely redefine the whole context to enable all functions to operate the values with uncertainties and to customize the display output such as to conveniently display such values.

Possibly a way to go would be to buy the SwissMicros machine and make a custom firmware from scratch, but then I also wanted to attempt to make a better keyboard. Not sure it ended up being any closer to the original HP, but at least it's soft and not clicky (I've used the softest tactile buttons I could find in the catalogs).

Finally, and maybe most importantly, I believe you understand that the motivation does not need to be completely rational

[Dwight Sturrock]

Very nice work!

[nuts4calcs]

(05-28-2021 08:48 PM)apoluekt Wrote:  Hi all,

I've been reading this forum for quite a long time, but did not bother to register until recently. I've used RPM calculators back in school, mostly to fly to the Moon, then I've switched to algebraic ones, then I didn't own any hardware calculators: was either using a Python prompt or cell phone apps.

Recently it occurred to me that I needed a hardware calculator. Not that I desperately needed one, but it would just have been convenient to have something lying on a table which I could use for some back-of-the-envelope style estimates, without the need to start apps, open terminals, etc. Ideally, it would need to have some specific functions that I often need (I'm doing high-energy physics).

I hate to admit this on this forum, but I don't see a use case for programmable calculator for me. If I need to program something relatively complicated, I'd better do it on a computer. Instead, I'd like to have a set of rather specific functions which would only be one-two clicks away (of course I could have programmed them on DM42 or whatever, but running a program is by far not equivalent to pressing a button).

Thankfully, modern MCUs make building custom calculators relatively easy. So I ended up make my own one (I'll resist citing Futurama here). Here's what comes out so far: https://github.com/apoluekt/OpenRPNCalc



The design is kind of inspired by DM42, at least it's using the same Sharp LCD and STM32L476 (good choice, SwissMicros!). The schematics is of course much simpler, as I did not intend to implement any fancy stuff. I've tried to make the keyboard as soft as possible by using 50g actuation force switches. The case and keypad are 3D printed, and key labels are made using laser printable sticky film.

Firmware-wise, it is of course in a constant development. but I think now it largely has most of what I wanted to have in my custom calculator. One notable feature which I think was not implemented in any hardware calcs so far is calculations with uncertainties using error propagation.

I'm publishing all the design files in github under free license, hopefully it could be useful for somebody to make their own machine.

Awesome post!!!
I have been thinking of making a similar project for quite some time, the only part where I was clueless was on how to label the case and keys.
Would you share the film and printer you used? I may not find the same ones but would know what to look for.

Thanks!!

[apoluekt]

(06-01-2021 03:05 AM)nuts4calcs Wrote:  I have been thinking of making a similar project for quite some time, the only part where I was clueless was on how to label the case and keys.
Would you share the film and printer you used? I may not find the same ones but would know what to look for.

Here's the link to the exact item that I used: Printation mat transparent. Perhaps there are better ones, this is the first one with the decent responses that I've tried. It's designed to be printable with the laser printer (not inkjet!), the exact model does not matter I believe.

It might make sense to experiment with the plastic for 3D printing. PETG I've used is not the best choice to stick film to, it's possible that PLA or ABS will be better. But then again, I don't want the labels to be glued dead-on because the firmware is still evolving. Once the layout is stable, maybe it will make sense to treat the keys with some lacquer on top of the sticker labels for better results.

[rawi]

apoluekt wrote:

Quote:Finally, and maybe most importantly, I believe you understand that the motivation does not need to be completely rational

OK, that's a good reason i understand. Maybe this whole forum (including myself of course) is not 100% rational. But to have fun with an intellectual challenge is not the worst thing to spend time :-)

I wish your project will be a success!

Best

Raimund

[Albert Chan]

erfinv code had a hidden gem
With minor changes, adding a tail = 1 - |x|, we get *accurate* inverse erfc for free.

Code:

static double erfinv(double x, double tail) {
  
  if (x + tail != 1) tail = 1-x;    // assume x >= 0
  if (tail <= 0) return tail ? NAN : INFINITY;
  ...
  double r = sqrt(M_LN2 - log(tail));
  ...

Calling C from Lua, code is trivial

Code:

static int Lierf(lua_State *L)
{
  double x = luaL_checknumber(L,1);
  double tail = lua_tonumber(L,2);
  lua_pushnumber(L, copysign(erfinv(fabs(x), tail), x));
  return 1;
}

Note that tail is suggestive, throw away if x + tail ≠ 1
This make ierfc(x) easy to implement, even if x > 1

lua> for k, v in pairs(require'mathx') do _G[k]=v end -- get erf, erfc, ierf
lua> ierfc = function(x) return ierf(1-x, x) end

lua> x = erfc(5)
lua> x, ierfc(x)
1.5374597944280351e-012     4.999999999999999

lua> x = erfc(10)
lua> x, ierfc(x)
2.088487583762545e-045      10

lua> x = erfc(15)
lua> x, ierfc(x)
7.212994172451206e-100      15

lua> x = erfc(20)
lua> x, ierfc(x)
5.3958656116079005e-176    20

[Gene]

Written up on HackADay today.

Link