Close
0%
0%

OpenRPNCalc

Open-source and open-hardware custom scientific RPN calculator

Similar projects worth following
OpenRPNCalc is a scientific calculator based on STM32 microcontroller. Its source code, schematics and 3D-printed case design files are released under open license. The hardware is inspired by the SwissMicros DM42 calculator (which itself mimics the famous HP-42), but designed from scratch. Firmware-wise, however, there is no intention to simulate programmable HP series. Instead, I aim to create a device that fits my everyday needs at work, with a preprogrammed set of functions that are, possibly, rarely or never available in the commercial calculators.

A unique (for hardware calculators) feature that is already implemented here is calculations with uncertainties using error propagation formulas.

The firmware source code and all the design files are at GitHub.

The calculator is based on low-power 32-bit ARM microcontroller STM32L476 running at 8 MHz, which is more than sufficient for the purpose. The display is the famous Sharp memory LCD module LS027B7DH01 (400x240 pixel monochrome). Keyboard uses light-touch tactile switches Panasonic EVQQ2B01W (50g actuation force). All electronics runs off the 3V lithium battery (CR2032) that should be sufficient to provide power for several years of operation.

The case and keyboard is made of four 3D printed parts (top and bottom parts of the case, keypad and switch spacer). The two parts of the case are held together by simple snap fit joints, no screws are needed. For the moment, while the software is under development, the buttons are labeled with a simple laserjet-printable sticker paper. 

Currently, the calculator features:

  • Reverse Polish notation with 4-element stack.
  • Double-precision arithmetics.
  • "Standard" scientific calculator functions (trigonometric, logarithms, exponentiation, square root and power).
  • Error function (erf) and its inverse (erfinv).
  • Fixed, scientific (SCI) and engineering (ENG) display modes (including SI prefixes in ENG mode), variable 3-10 digits precision.
  • Calculations with uncertainties using error-propagation formulas (UNCERT mode). Something that I've never seen in any of the hardware calculators, and very rarely is present in the software ones.
  • Low power consumption (~10 uA in standby mode with LCD display on, 2-3 uA with LCD off).

  • 1 × STM32L476RET Microcontroller
  • 1 × LS027B7DH01 LCD display
  • 1 × TPS61222TCK 5V step-up voltage converter
  • 45 × Panasonic EVQQ2B01W Tactile switch
  • 1 × Hirose FH28-10S-0.5SH(11) Molex-type LCD connector (0.5mm pitch, 10 contacts)

  • Power consumption: solved

    Anton Poluektov4 days ago 0 comments

    I think I've solved all my problems with power consumption being somewhat higher than I hoped. Previously the calculator consumed 40-55 uA of current from the 3V battery, which was to my knowledge a bit on a higher side of what one should expect from STM32L476 in STOP mode. 

    I discovered that in fact the STM32 was put into STOP1 mode, while there is a more economic one, STOP2, which, however, takes longer startup time (does not matter in my case). STOP2 is activated with the extended HAL function 

     HAL_PWREx_EnterSTOP2Mode(PWR_STOPENTRY_WFI);

    That solves my problem. With STOP2, the STM32 itself draws only 2-3 uA, and that increases to 10-12 uA with LCD on. This must be sufficient to run the calculator from a single CR2032 for several years. 

    Another small fix I had to do is to add an electrolytic capacitor of 47 uF in parallel to the battery. This fixes occasional resets of the calculator while waking up. As far as I understand, this could happen when the 3V->5V DC converter is powered up and starts to charge the capacitor C2. With the battery being not fresh enough, this could deplete the voltage for a short time below the minimum needed for STM32 to operate, causing it to reset when the voltage is back to normal. Adding extra capacitor with the value a few times higher than C2 fixed this. 

  • New key stickers and firmware update

    Anton Poluektov05/28/2021 at 19:08 0 comments

    Printed new keyboard stickers: now on a laserjet-printable transparent sticky film (the brand is "Printation Mat Transparent"). Hopefully they will last longer than the paper ones, although with the function set still under development, the longevity is not a real issue. 

    Updates in the firmware: 

    • Added relativistic kinematics functions (uncertainties are not implemented yet for them):
      • Conversion between angle and pseudorapidity (eta <-> theta)
      • Conversion between beta and gamma factors (gamma <-> beta)
      • Center-of-mass momentum for 2-body decay (P(z->xy))
    • Added Gamma and log Gamma functions.
    • Conversion between degrees and radians.
    • Slight reshuffle of function keys.
    • Update with ST-Link is now activated with "SHIFT+Reset" (instead of "ON+Reset"). There was a good reason for that: with the almost-flat battery, the MCU could sometimes go into reset when switching calculator on (due to a sudden increase of current consumption). With ST-link connection activated via ON+Reset, it would immediately send MCU into firmware update mode. 

  • Firmware issues

    Anton Poluektov05/24/2021 at 20:28 0 comments

    • STOP mode and keyboard scan. When the calculator is ON, the STM32 spends most of its life in STOP mode for minimal power consumption. It can wake up on either external interrupt from the keyboard, or, once a second, on the timer interrupt to toggle the EXTCOMIN signal for Sharp LCD. When the key is pressed, STM wakes up, performs a needed operation, and waits for the key to be released. The waiting cycles are, however, done without sending the MCU to STOP. So, while the button is being pressed, the MCU runs on its full 8 MHz and draws around 4 mA from battery. This needs to be fixed eventually. 
    • Switching the calculator ON. When the calculator is OFF, all the columns of the keyboard matrix have external interrupts enabled. So, whenever the button is pressed while in OFF, the MCU wakes up, scans the keyboard, and if the button that is pressed is not ON, goes back to STOP. In principle, a better way would be to only enable the interrupt from the column connected to the ON button. However, the straightforward implementation of this appeared to be buggy (it worked, but for some reason the average current draw in OFF was much higher). I've postponed this for now. 

  • Issues with PCB and enclosure design

    Anton Poluektov05/24/2021 at 19:30 0 comments

    • The case is relatively thick (12.5mm total thickness). This is limited by the chosen CR2032 battery holder which is itself 5.5mm thick, and of course it should be placed on the back of the PCB, so one should add the thickness of LCD/switches to this value. A better solution would be to make the cutout in the PCB for the battery and find a thinner holder, but I failed so far to find the good one. Alternatively, I could use two smaller 1.5V batteries placed on the front side of the PCB. To be investigated for the next iteration of PCB. 

  • Issues with electronics

    Anton Poluektov05/24/2021 at 18:52 0 comments

    Here are few issues related to electronics: 

    • The current PCB lacks a few filter capacitors. Normally, STM32 manual recommends a 100 nF capacitor for each VDD-ground pair entering the chip. I had to solder two capacitors in an "ad-hoc" way, PCB needs to be fixed to add them. Also, they could be placed closer to the STM pins. 
    • 5V booster for the LCD is controller by the 5V_EN signal. The idea was to switch the 5V power to LCD completely when the calculator is OFF. However, it does not work like this due to my wrong understanding of TPS61222 logic. As it is implemented currently, when the calculator goes OFF, LCD receives 3V from the battery instead of 5V (the booster is switched off, but still supplies battery power). This has to be fixed by adding a transistor to decouple the TPS61222 and LCD from the battery. 
    • By the way, it appears that Sharp memory LCD works nicely from 3V instead of nominal 5V as indicated in datasheet. Maybe 5V booster can be removed completely? 
    • The circuitry around TPS61222 does not follow exactly the PCB design pattern from the datasheet (conductors are not thick enough, inductor and capacitors are not close enough to the chip). While it works stably, the PCB should still be improved. 
    • A couple of filter capacitors are missing near the LCD connector as well. To be fixed. 

View all 5 project logs

  • 1
    3D printing the enclosure
    Here are a few more-or-less random notes about 3D printing the calculator enclosure. 

    • I've printed it with the Creality Ender 3 V2 printer using PETG plastic, and the case went really well I think. Contrary to what's written in many websites, I've had no issues with PETG not sticking or sticking too strongly to the heated bed. My settings were: 235 C extruder, 80 C bed temp (85 C for the 1st layer). 
    • The top and bottom parts of the enclosure were printed without raft, directly on the glass bed, which made the nice and smooth surface. I've made a 4mm brim around them however, because I've had an issue with warping. 
    • The keypad and spacer were printed with a 4 layers, 4mm width raft, and I had to add dummy 1x1x1 mm cubes at the edges to simulate "mouse ears" to avoid warping (Cura slicer does not have "mouse ears" option). Since both parts are rather thin (the spacer has 0.2 mm, only one-layer-thick, springs) detaching them from the raft is tricky, but doable with a thin knife. 
    • I had an issue that the X and Y axes of my printer were not exactly perpendicular (about 1/2 degree off), which resulted in the top and bottom halves to be not exactly rectangular. And since the top was printed upside down, once the enclosure is assembled, it caused it to be bent in a propeller-like shape. I had to adjust the frame of my printer really well to make the case perfectly rectangular. 

View all instructions

Enjoy this project?

Share

Discussions

John Hind wrote 06/10/2021 at 09:52 point

Been thinking about doing one of these myself. Nice to see someone else gets the importance of indefinite battery life. If you put a color TFT on a calculator you may as well just use an app on your phone!

Button labelling is the key (sorry) issue to solve. Two ideas:

1. Put a column of four or maybe even five keys adjacent to the left and/or right edge of the display. Then you can have dynamic 'soft labels' on the screen to support vastly more functions with fewer keys. An overall landscape design might then be attractive with all the keys to the left  and right of the display.

2. I've never seen it done, but it should be possible to 3-D print double-shot keys using a two-filament extruder. Failing this, would it be possible to print the top part of your existing key design in clear plastic and stick printed labels on the back of this so the clear plastic protects the label?

  Are you sure? yes | no

Anton Poluektov wrote 06/11/2021 at 07:46 point

Thank you for your feedback John! Indeed, battery life is something I'm going to work on further, I believe the current ~40 uA in standby mode could be reduced (for example, but completely turning off LCD power). 

Two-filament printer is hard to find. I tried printing the keys with embossed labels with my Ender, you can kind of recognise what's written there, but that was far from perfect. I have not tried transparent plastic, and suspect that it's in fact not transparent enough to see the labels through it. My best bet would be to cover the keys with the layer of clear lacquer or epoxy after the keyboard layout is finalised. 

  Are you sure? yes | no

indigoredster wrote 06/06/2021 at 01:43 point

This is useful! Years ago my physics 102 class had a teaching assistant who's pet specialty was error propagation. Bastard tripled the time it took for homework compared to the other professors for the same class. Could barely understand him.  Those were the days ;-)

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates