▼
Posts: 1,092
Threads: 57
Joined: May 2007
So what happened to the OpenRPN website (www.openrpn.org)?
Last update I can find in the web archives is Aug 28th, 2005.
I'm curious to see all the details people have been talking about but can't find anything.
Also, from what details of the proposed hardware I could find, it seems not that dissimilar to the 50G (e.g ARM processor, graphic screen (colour?  why??), AAA batteries etc)
Has anyone given any thought to simply writing custom firmware for the 50G? (probably possible given that it has FLASH memory). Or does the 50G hardware suck so much that the point is for the project to be just as much a hardware project as a software project?
Dave.
▼
Posts: 727
Threads: 43
Joined: Jul 2005
Quote:
So what happened to the OpenRPN website (www.openrpn.org)?
You should probably try the OpenRPN SourceForge site instead.
 Thomas
Edited: 27 May 2007, 1:18 a.m.
▼
Posts: 1,092
Threads: 57
Joined: May 2007
Quote:
You should probably try the OpenRPN SourceForge site instead.
I have, and all I can see is some C code, a screen shot, and a link to the nonfunctioning documentation site at doc.openrpn.org
Dave.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
IIRC, Hugh Evans will reopen an OpenRPN site soon, i.e. within some weeks.
What I remember being published in the old site:
 Dimensional specs for housings, keys, LCDs including CAD drawings (or sketches, since no dimensions were given there)
 Electronic specs for LCDs, processors, I/O interfaces
 Keyboard layouts (some published also in this forum)
 Function sets
 Software specs and sets as Paul mentioned
plus a lot of discussions about these topics.
Being a project initiated in the USA, an elaborated vision and mission statement and more marketing stuff seemed to be inevitable, though not supporting the progress too much. IMHO, however, the specs were neither complete nor completely consistent at the time I last looked at them. Maintaining the project documentation was a topic with space for improvement, though not the only one. Nobody is perfect.
I've got some of the specs copied and all of the layouts, but Hugh is the project head, so your request should be addressed to his attention.
Edited: 27 May 2007, 3:09 a.m.
Posts: 302
Threads: 34
Joined: Aug 2007
OpenRPN.org will be coming back online. I'm back in touch with my old cohort Chad regarding this.
In response to your question, I have considered porting *fix to the 49G+/50g although I have determined that it is too much work and too far from our actual goals.
Ummm... Graphical FSTN reflective LCD, but not color. Just the best grayscale available.
The overall point is that people want something close a voyager or pioneer, they already have the 50g for graphing. As I said in an earlier post, people would like classic calculators with improved modern electronics.
Send me an email for any more discussion on this. The people around here have heard far too much of it already.
▼
Posts: 1,092
Threads: 57
Joined: May 2007
Quote:
OpenRPN.org will be coming back online. I'm back in touch with my old cohort Chad regarding this.
In response to your question, I have considered porting *fix to the 49G+/50g although I have determined that it is too much work and too far from our actual goals.
Ummm... Graphical FSTN reflective LCD, but not color. Just the best grayscale available.
The overall point is that people want something close a voyager or pioneer, they already have the 50g for graphing. As I said in an earlier post, people would like classic calculators with improved modern electronics.
That's what I thought. It's just that I stumbled across and old post of yours that mentioned a colour graphics screen as being one of the goals.
I believe you would be right to stick with the classic model.
I believe many people would even be happy with a nonprogrammable model.
Dave.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Quote: I believe many people would even be happy with a nonprogrammable model.
I'm leaning more to this view over time.
I've come to the conclusion that an RPL based device is overkill and probably unwarranted. RPN is good enough for most purposes even if it lacks the elegance of an RPL model. Internally, I've no objection to RPL/*fix, that is a different matter entirely.
What is important is a rich enough function set (whatever that means) and numerical stability and accuracy (i.e. all functions accurate to at worst 1 ULP).
 Pauli
Edited: 27 May 2007, 9:20 p.m.
▼
Posts: 308
Threads: 26
Joined: Jul 2007
Another 48/49 clone with RPL and non4level stack will not be warmly received. At least going back and doing Woodstock or Pioneers will address a replacement market for the fervently loyal.
Why buy such a 48/49like product when there's new & used ones available? Who (other than starving students) really uses a CAS system when they have PC software available? It's overkill.
This "project" has grown into creeping featurism  heavyduty ARM CPU, etc.
If someone gave me a 48/49 calc, I might use it for a wheel chock for my truck. I've given away two 48s  they're useless too me: too much in too small of a box.
Many others here probably feel the same  48/49 is overkill, if we need that much functionality we can go use Matlab, Maple, etc. on a PC.
A nicelydone 41CX/42S/15C (or some combination thereof)  with XYZT+L stack and a large Enter key  is the functionality that I think many or most here want. An alternate idea might be to support 71B BASIC programmability with a regular RPN calc 'front end' for directmode use.
In any case, it appears everyone is worried about which CPU or which LCD, etc. All these are relatively trivial decisions, and which are academically fun to make but which are kinda useless since any HP calc can be emulated on any reasonable 8bit microcontroller these days.
Y'all are thinking like EEs, where all problems are electronicrelated  which they often aren't. Packaging is key, and no one has addressed this for any manufacturability.
It will cost about the same to get a 40 key calc produced whether or not it has a fancy CPU.
The real issue in making this come to fruition is packaging and
keytop issues. These require a chunk of money for NRE, and since no one rationally will drop $50K min to get this started, choice of CPU is irrelevant as it's all an academic exercise.
Bill Wiese
San Jose CA
▼
Posts: 536
Threads: 56
Joined: Jul 2005
hi bill,
i agree with your points, probably all of them except that i have a slightly different take on the CPU. i have forgotten where my 48 is, but still use my 15c daily.
because CPUs are now cheap, makers think we want CAS, as you point out, this is mistaken because for anything even slightly complicated people will use their PC. i am typing this message on a PC only about twice the size of a 48  but it can run a full up CAS and can display results in hires. this is not the realm for calculators.
my take on the CPU is that cheap performance should be deployed in other ways for pocket devices. this october, i plan to give a talk at the HPCC conference in london UK, on a new way to calculate. right now i have only some rough notes, but i do have some working software.
without giving too much away at this time, i want to show how you can go right back to basics with artihmetic itself and redo it another way. the result is a pocket calculator (im using the 50g platform as my example HW) that performs numerical calculation, not at all a CAS, without error. for example, punch in sin(60!), it displays, 0.949360891195. im also hoping to show how to perform numerical integration without error which would be interesting.
its what i think calculators shoule be like rather than simply piling on more and more features.
▼
Posts: 302
Threads: 34
Joined: Aug 2007
That sounds like a very interesting project. Yet another reason why I think many people will buy the OpenRPN hardware to develop ideas like your own and have a platform that will run it.
Hugh Evans
Posts: 255
Threads: 59
Joined: Jul 2007
I've been reading this thread about a better HP calculator and what pops in my head is how complex the RPL machines have become. I'm not a programmer but I can't get my head around all the things a 49g+ or a 50g can do.
If I were to design a calculator, I would want it to have different layers a functionality. The first layer would be a simple scientific calculator without programmability that would give a beginner easy access to just what he needs.
The second layer would have simple programming included so that when a user is ready, they can experiment with that. The final layer would contain the full functionality of the calculator for the user who is ready for that.
I know this sounds rather simplistic, but I think the first step in a new calculator is to make it very useful to a new owner right from the start. The steep learning curves of present calculators make it difficult for a beginner to find the calculator useful. It also doesn't help that HP's documentation is so poor.

for example, punch in sin(60!), it displays, 0.949360891195.

Here's an example. I punched sin(60!)into my 49g+ (Revision #2.09) and got 0.342020143326. I don't have my 50g (also #2.09) with me to check but why the difference? I tried both in RPN and ALG and got the same answer.
I find that very frustrating.
Gerry
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
I made this suggestion to HP at the last HHCC conference. RPL is too complex for the average user, but it is darned nice for the calculator geek. So have an interface that "unfolds" in front of the user. The first layer is a basic scientific or financial, perhaps, with somewhat limited functionality. Unfold that, and you have keystroke programmability, ala the 42S, but updated. Next you have User RPL, or something like it. Each of these layers can interact with the one below it, or the one above if it is enabled. So, for example, the RPN programming can call the RPL if that is turned on.
But the points made by others in this thread are well taken. It's hard for me to see how to implement that without switching keyboards. The new TIs do that, so it isn't impossible. But it's very likely to add to the baseline cost. Since nobody can come up with the costs projected for simpler designs, it's doubtful this pipe dream would be feasible.
I'm fascinated by hugh steer's teaser, however. A reinvention of the calculator is more likely to come from that direction than from any hardware innovations.
Regards, Howard
Posts: 1,792
Threads: 62
Joined: Jan 2005
Quote:
It also doesn't help that HP's documentation is so poor.
 for example, punch in sin(60!), it displays, 0.949360891195. 
Here's an example. I punched sin(60!)into my 49g+ (Revision #2.09) and got 0.342020143326. I don't have my 50g (also #2.09) with me to check but why the difference? I tried both in RPN and ALG and got the same answer.
I find that very frustrating.
I don't have an HP49G+ or its documentation available, but that's a really bad example. First of all, the angular mode makes a difference in the result. Secondly, "60 factorial" has more than 12 digits that precede the string of 14 trailing zeroes. So, the correct result is theoretically achievable only in exact mode.
My HP49G in exact mode will return 0.34202014333 as the sine of "60 FACT" degrees. However, so do all my Saturnbased 12digit HP's lacking exact mode.
The HP49G correctly returns 0 in exact mode for MOD(60!, 360), as 60! = 60*6*[an integer product of the remaining terms]. So, zero is the correct answer for sine, which is achievable if MOD were internally performed in degree mode using 360. Either the internal MOD or the SIN calculation does not utilize the full precision of exactmode integers.
The HP42S, lacking exact mode, returns 160 for MOD(60!, 360), which must be based upon the limit of precision available: (60! / 1E68) / 360 yields a full 12digit integer (231,138,530,909); MOD (60!, 360) yields a result of 160, which does not change as 60! is divided by powers of 10 that are lower than 68. The sine of 160 degrees is indeed 0.342020143326.
Please see this thread:
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv017.cgi?read=109071#109071
Edited: 31 May 2007, 1:35 a.m. after one or more responses were posted
▼
Posts: 230
Threads: 11
Joined: Jan 1970
This is very interesting. I wonder what mathematical trick you use to calculate sin(60!) apart from having PI in ROM (or recalculating it) to lots of significant digits. I understand that if we can do sin(N) with N a big integer the case of sin(X) with X a big real number is simple. Thanks for sharing if possible.
▼
Posts: 727
Threads: 43
Joined: Jul 2005
My guess would be that, in exact mode, there are a few specialcase checks for numbers like 60 degrees (mod 360); that check would have to be performed *before* converting the angle to radians.
Free42 performs such checks, but only for multiples of 90 degrees or 100 grads (SIN, COS, >REC), and for multiples of 45 degrees or 50 grads (TAN). However, note that getting cases like sin(60!) right requires arbitraryprecision math.
 Thomas
▼
Posts: 230
Threads: 11
Joined: Jan 1970
60! is not 60 degrees or a multiple thereof, it is exactly (60!*180/PI) degrees. The fractional part of this number is very hard to find with only 15digits PI. The trick is was I was asking for.
Posts: 3,229
Threads: 42
Joined: Jul 2006
I suspect Hugh was talking radians in his original message. Using wcalc, I get his answer in radians and 0 in degrees mode.
 Pauli
▼
Posts: 536
Threads: 56
Joined: Jul 2005
indeed!
my point is simply that there should be a handheld calculator for manual calculation that has no exact mode or nonexact mode, whatever, which is simple to use and doesn't have special modes that either gives the right answer or tells you it can't do it with no wrong answers.
i think that's a reasonable thing to ask.
Posts: 305
Threads: 17
Joined: Jun 2007
Quote: I don't have an HP49G+ or its documentation available, but that's a really bad example. First of all, the angular mode makes a difference in the result. Secondly, "60 factorial" has more than 12 digits that precede the string of 14 trailing zeroes. So, the correct result is theoretically achievable only in exact mode.
My HP49G in exact mode will return 0.34202014333 as the sine of "60 FACT" degrees. However, so do all my Saturnbased 12digit HP's lacking exact mode.
The HP49G correctly returns 0 in exact mode for MOD(60!, 360), as 60! = 60*6*[an integer product of the remaining terms]. So, zero is the correct answer for sine, which is achievable if MOD were internally performed in degree mode using 360. Either the internal MOD or the SIN calculation does not utilize the full precision of exactmode integers.
My HP49G has old firmware, version 1.05; I've never updated it.
When I calculate 60 FACT on it in exact and degrees mode, I get 8320987...00000; when I then press SIN, I get SIN(8320987...000000). I have to then do >NUM to get it to return .342020143326. It's apparently converting the many digits of 60! to approximate mode before calculating SIN.
I get the same behavior in exact and radians mode. If I do 60 FACT SIN, I get SIN(8320987...000000). Doing >NUM then returns 8.40001652835E2.
On the other hand, on the HP49g+, in exact and degrees mode, if I do 60 FACT SIN, I get 0. The HP49g+ is apparently doing a 360 MOD in exact mode before passing the result to the SIN function.
If I do 60 FACT SIN in exact and radians mode, I get SIN(8320987...000000), the same as the HP49G.
If I switch to degrees mode with SIN(8320987...000000) still on the stack and do >NUM, I get .342020143326. In this case, the 360 MOD isn't done in exact mode before executing the SIN function; apparently the SIN function's own internal, approximate mode 360 MOD is done.
Posts: 302
Threads: 34
Joined: Aug 2007
Amen. The electronics are the easy and cheap part to produce, since tooling costs, etc. don't exist. The bulk of the work I do on OpenRPN is finding and in some cases developing manufacturing processes to cut down on startup costs.
If we wanted to just get these things into production immediately, it would cost at least $50k to get the ball rolling. My goal is to cut that number drastically, or produce a few prototypes and license it to a bigger company that thinks the product is worthwhile (this could be one of the smartest moves HP was made in decades).
Hugh
▼
Posts: 308
Threads: 26
Joined: Jul 2007
Frankly,
We should just talk to Kinpo and do a 'prototype' run for 'market investigation'.
Use an existing kinpo calc and we do our own firmware  just port over 41C emulator etc.
Frankly a nonprogrammable shirtpocket sized TI25X with 4level RPN, large enter key, hex/binary/dec conversion & logic functions and PV/FV/i/PMT/n functionality would be a very useful device.
Bill Wiese
San Jose CA
▼
Posts: 302
Threads: 34
Joined: Aug 2007
Actually, I may give that idea a shot. If they can produce machines using my designs and specifications that's all that matters.
