Close
0%
0%

OpenRPNCalc

Open-source and open-hardware custom scientific RPN calculator

Similar projects worth following
OpenRPNCalc is a scientific calculator based on the 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 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 on GitHub.

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

In the present design, the front panel and keys are made of PCB with labels printed as silkscreen. The rest of the enclosure is 3D printed. All the parts are kept together with six M2 standoffs and 12 flat-head screws. The size of the enclosure is 139x72x9 mm.

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), gamma function and its log, number of combinations and permutations, and several special functions related to probability and high-energy physics
  • 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 (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 (~15 uA in standby mode with LCD display on, 1.5 uA with LCD off).

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

  • New keyboard design

    Anton Poluektov20 hours ago 0 comments

    So, the major change in the current design is the keyboard. My aim was to make something that would look not too ugly, last long, could be made relatively cheaply and would be reproducible. I guess PCB silkscreen is the only option that satisfies all that.

    My original idea was to make the button of two layers of PCB of different thicknesses, thicker top part (say, 1.6 mm) and thinner bottom (0.8 mm), such that the button would stick over the thin front panel (0.8 mm). I thought it would be a good idea to have the button pivoted to limit its free movement, and for that I planned to use a couple of standard through-hole header pins on the main PCB and matching holes in the bottom button PCB.

    The plastic part of the pins exactly matches the height of the tactile switches that I used (2.5 mm). Skipping forward, it appeared that the keyboard works better without the pins, but possibly my mistake was that I left too tight a gap between the front panel and the top PCB of the keys (around 0.2mm).

    The top and bottom PCBs for each key can, of course, be glued together, but a more reliable connection is done by soldering one to another (we have PCBs after all!). For that purpose I left copper pads on the reverse side of the top PCB and tented vias in the bottom part.

    I don't think any PCB house would be happy to work with 10x6 mm PCBs, so one has to panelise both key parts. Here's the panelised top PCB:


    and its reverse side with copper pads: 

    and the bottom PCB with tented vias for soldering both parts together and simple holes for "pin suspension": 


    I made the PCBs such that they could be soldered precisely before cutting it into pieces, after connecting them with four screws.



    However, later I found out that it's in fact much more convenient to cut the board first, and solder the buttons later: cutting the top part of the keys is quite tedious with Dremel since they have a smaller outline than the bottom. One can still solder the cut parts pretty precisely with a simple jig to position them.

    Buttons after soldering and cutting: 



    (the buttons made in the opposite order, cut and then soldered, look much better).

    This is the closeup how the buttons look like inserted into the front panel: 


    As I said, finally I've decided that the pins are not needed, so the through holes in the main PCB are left unoccupied: 


    That's it for the keyboard part. The rest is coming soon...

  • OpenRPNCalc, season 2

    Anton Poluektov5 days ago 0 comments

    If you were wondering what happened to this project: yes, it was on hold for a while for various reasons, but now it's back! 

    The first version of the calculator is still alive, but predictably the stickers have worn out quite quickly, so for revision 2 I decided to try a different approach: the front panel and keys both made of PCB material, with labels printed as a silkscreen. And I think it worked out quite well as a proof of concept, see the photo here.

    This version has improvements in both the firmware and (especially) in hardware and enclosure design. I consider it a transitional revision and already see some further improvements to be made for rev. 3. However, I'm going to document this design here anyway, including some pitfalls that I came across.

  • v2 of the PCB

    Anton Poluektov07/21/2021 at 20:00 1 comment

    Based on my experience with the first version, I've made an update of the schematics and the v2 of the PCB is now ordered. Here is the list of changes: 

    • Additional filtering capacitors for STM (one per each pair of VSS/VDD(A) inputs as per datasheet) and for the LCD (according to LS027B7DH01 datasheet). 
    • Tantalum capacitor (220 uF) in parallel to the battery to avoid voltage drops during heavy processor activity when the battery is weak. 
    • Power pin on ST-Link header to power the calculator while flashing or to measure current consumption. Two Schottky diodes as a protection when both ST-Link and battery power is on, and to protect from reverse battery polarity. 
    • New battery holder (Keystone 1057) which sits in the cutout of the PCB to reduce thickness of the enclosure. 
    • Improved PCB layout for TPS61222 voltage booster (following datasheet)
    • More compact PCB (126x64 mm) with screw holes and cutout for LCD flat cable. 

    New schematics

    New PCB: 

  • Power consumption: solved

    Anton Poluektov06/19/2021 at 18:10 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 8 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

Javier Cardona wrote 4 days ago point

I'm so happy this is coming back to life!  Some thoughts/comments/questions:

1. (Ab)using PCB silkscreens to generate key labels is brilliant! Also gives users the option to use other PCB colors for customize looks (I'm rooting for black).  How do you plan to attach the (PCB) labels to the buttons?

2. You might want to consider swapping the 220 uF tantalum cap for 2-3 regular ceramic capacitors (https://jlcpcb.com/partdetail/15681-CL31A107MQHNNNE/C15008).  They are slightly cheaper, and JLCPCB has those as basic parts, so there is no feeding fee.  This can shave ~$5 from an economic 5-board PCBA order.  Yes, you use a bit more PCB space, but you avoid rare earth metals...

3. This MCU and display are well supported in Rust, my favorite language (https://github.com/stm32-rs/stm32l4xx-hal, https://crates.io/crates/sharp-memory-display).  I'm looking forward to try to try it on your cool calculator!

4. You might want to consider a protective layer of laser-cut acrylic.  I use it on my designs (for instance https://www.amazon.com/dp/B0CYHGFRJS) and protects well the display while giving it a polished look.  It is also cheap and easy to source.

Thank you for sharing with the world!


  Are you sure? yes | no

Anton Poluektov wrote 4 days ago point

Thanks for your comments, Javier! 

1. Yes, I'll post the keyboard design shortly. It's quite trivial, the most tedious part is cutting the panelised PCB as it comes from the factory.

2. Good point about caps. I didn't realise there were ceramic caps of ~100 uF, but apparently, you can even find 220 uF in a 1206 package.

3. Yeah, I think it would be great to ultimately have a hardware platform that's cheap to order at JLCPCB and the likes and easy to assemble, and which wouldn't look too ugly as well. There are a few custom calculator firmware projects out there which could probably be ported.

4. Right, bare LCD doesn't feel safe. Problem is, acrylic adds quite a bit to the overall thickness. Maybe a mobile-style gorilla glass screen protector could do, if you can have it cut to a custom size.

  Are you sure? yes | no

Javier Cardona wrote 3 days ago point

Thanks for the additional info.  I will monitor the project and when you post the gerber files for the keys and new enclosure, I'll try to build one and share feedback.  Cheers!

  Are you sure? yes | no

Anton Poluektov wrote 15 hours ago point

All the design files for KiCAD and gerbers are now on GitHub. Feel free to try them, or maybe wait for the next iteration, when I'll correct this revision's omissions.
Are you going to make your own version of the firmware in Rust?

  Are you sure? yes | no

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