Are there any "great" calculators being made NOW?



#43

Just curious... are there really any great scientific calculators being made, HP or otherwise? The only thing I have against the 48 series and later HP, is the size. I prefer a calculator I can always have with me. But I have one none-the-less. Gone are the days of the 15C where scientifics fit in the pocket.

But, are there any currently made scientific calculators (HP or otherwise) that you would consider "great" in the tradition of the 15C (assuming you agree that it was a great model)?

Edited: 5 Aug 2006, 12:50 p.m.


#44

You just need some of those "cargo pants" with the great big pockets. %^)


#45

While current calculators are not all that great but I have no problem with their sizes. The classic series are just about as big as say the new 50G. The 41 with a card reader is also very big. Besides, the new calcs run a lot longer on a set of batteries compared with the classic, woodstock or spice series. So portability is not a problem with the current crop of calculators.

#46

I'm not sure about now, but Richard Ottosen and I are trying to get into the business within the next year or two. Actually we'll be offering our first product in September, but it doesn't have the same sort of industrial design as a "normal" calculator. It's sort of a proof of concept.


#47

Prey tell more please...


#48

Although it's not completely up to date, the basic information about it and photos are in Richard Ottosen's paper from HHC 2005:

http://www.brouhaha.com/~eric/hpcalc/hhc2005/hhc-hw10.pdf

When I showed it last year, the only firmware running on it was a hardware diagnostic. Now it is actually running microcode from the 21 and 25, with more models to follow soon.

The intent is to eventually manufacture calculators with a more conventional industrial design. Richard Ottosen's laminated laser-cut case is clever and didn't require expensive tooling, but it is expensive to produce and may not be as mechanically rugged as a normal injection-molded ABS case.


#49

Whoa, you're making the enclosures by laying-up and gluing laser cut plastic? I'm positive you can have the same parts injection molded in ABS by emachineshop. Send me your drawings and I will gladly put it into emachineshop's CAD software (I'm already very familiar with it).

Also, you should use something other than those suface mount tactile buttons. Gold-plated tactile domes from Snaptron would be ideal.

Just say the word and I will be more than happy to help cut production costs and convert your designs into emachineshop's required format.

What is your estimated cost per unit right now? Or if you'd like to discuss that in private send me an e-mail, I'll treat your correspondence with complete confidentiality. I just want to make sure you get a good deal and don't feel like you have to compromise quality.

Best Regards,
Hugh

PS- I can't wait to buy one of these!


#50

Seems like there is a fair amount of interest in making a new (old) calculator. Witness this thread, the recent scam about 15c (and others) which generated a deal of interest. The HP-67CX hoax which did likewise. The OpenRPN project. The bring back the 15C petition. The 15C memory upgrade thread.

Mightn't it make sense for the various groups to pool efforts somehow? I'd be willing to put some effort in...

- Pauli

PS: I'd be very interested in buying one of these too.

Edited: 7 Aug 2006, 11:47 p.m.


#51

The *fix core along with the two hardware platforms by OpenRPN will provide an ideal basis for many calculators. Among the first classic models recreated using the *fix core will likely be the 15c, 42s, 11c, and 32sii. A port of Free42 to our HW would not suprise me.

If HP's I.P. departmemt will give Eric an official release for their un-copyrighted software (I know this sounds like overkill, but I'm not risking anything). I would *love* to work out a deal with Eric to distribute his emulators and ROM dumps with OpenRPN machines. If nothing else I will gladly give him early access to one of our development kits so he can sell his emulator and ROMs as a third-party add-on.

In a nutshell what I'm saying is that OpenRPN will give everyone in the community what they want. Better than old HP quality, rugged waterproof enclosure, 200MHz fully-static ARM9 MCU, Ultra-high contrast FSTN grayscale dot-matrix LCD, 512KB SRAM, 16MB Flash, CF/MMC expansion, USB/RS232/IrDA/I2C, tactile gold-plated steel domes rated to >5 million cycles, black nitrile rubber boot for excellent grip in your hands or on desktops, 4xAAA batteries, glare resistant LCD glass cover, color scheme optimized for human vision and high contrast in low light conditions, etc.

Again, an embedded electronics PCB design expert could get OpenRPN going MUCH faster. At the moment I'm concerned that I may end up reosting to paying for this service. Is there anyone out there who is willing to help? I'll try the one volunteer we've had again, but he's hard to get ahold of.

The real question here are:
*Eric, would you like to use our hardware in your next generation of emulator-based machines?
*Chris, would one of our landscape models with all of the 15c's functions implimented in *fix and all of the keyboard labels (including laser etched key labels backfilled with appropriately colored resin). Be suitable for your cause?
*Everyone else, for $100 USD (includes batteries, packaging, complete manual, CD-ROM, connectivity cable, and custom molded-in labels at no extra cost) do the OpenRPN landscape and portrait models sound like what you would like? Or, to rephrase, are they what you think HP should be producing at this point in time?

Thanks to everyone in advance for your input. I want to help related projects whenever possible. I have worked hard since founding OpenRPN to prevent any schizms in development. My belief is that OpenRPN is our only hope for high standards in quality and design in calculators for the forseeable future. Neither HP or TI will want to compete with us... They may want to buy us, but we're not selling.

Regards,
Hugh


#52

Hello Hugh,

From my chair sitting and doing nothing, I must say your efforts command great praise. No criticism can come from people like me who don't contribute.

Richard and Eric's work is amazing.

I am in line for any product vaguely looking like R&E's or what you describe.
I hope you think of a way to patch existing models to take care of possible bugs in the firmware. Something like Flash reprogramming would reassure people that they don't end up with a new kind of paperweight.

I think there are about one hundred people for whom price is not a big factor. Past this, your machine will have to work correctly.

#53

Quote:
*Everyone else, for $100 USD (includes batteries, packaging, complete manual, CD-ROM, connectivity cable, and custom molded-in labels at no extra cost) do the OpenRPN landscape and portrait models sound like what you would like? Or, to rephrase, are they what you think HP should be producing at this point in time?

I think HP is doing a pretty good job with the 50g (I haven't held one in my hand yet, but what I hear sounds very encouraging), so I don't know that I would say that OpenRPN is something *they* should be producing... But, having said that, OpenRPN sounds like an excellent prospect in its own right; it could complement HP's product line, rather than replace it. $100 for a powerful, solid, customizable calculator sounds like an incredible deal!

Where can I find the OpenRPN wiki? I'm interested in finding out how to develop for this machine... Assuming there is a development system already (something gcc/g++-based, I expect)? And how about debugging -- will there be a simulator, or a remote debugger perhaps?

- Thomas


#54

I would think that having too customizeable of a calculator, in general, would be a bad business move for HP/TI. Their business plan is sustainable only because they can release new calculators (HP50g, or that whole new line of TI calculators for example) and convince people that they need a new calculator (and thus need to spend another $120).

If they were to release a calculator that was fully customizeable, fully upgradeable, and fully a (temporary) end solution, they would have a much harder time convincing someone that they need a better one (or maybe have a hard time coming up with a better one every year or so).

This would probably cause their business model to go from selling a good number frequently to selling a lot now and later (maybe like a 12c model) It would probably also turn the calculator division more into a calculator accessory and software (for features on your calculator) division, which would be interesting.

However, for a 3rd party to do this; one that has no desire to make millions, is another story.

Best of luck!

-Ben

#55

Hugh,

To answer the "everyone else" part of the question:

Yes, I will gladly buy one of your calcs if it includes the *fix core and decent I/O in the USD 100-150 region with the kind of packaging you describe.


As a user - and not a collector - the *fix is a strong incentive for me to program the solutions I use at work (ie bean-counter programs).

However, i will not buy any calculator with an ENTER key shorter than 1,5cm width :-)

My best wishes for success.

Etienne

#56

Quote:
If HP's I.P. departmemt will give Eric an official release for their un-copyrighted software

Not likely. I tried for nine years to get them to grant me permssion to redistribute them only for NONCOMMERCIAL purposes. I spoke to three different calculator division directors. They all thought it was a fine (or at least OK) idea in principle. Two of them said that they'd have their legal departments draw up a license agreement, but it never happened. One of them was just too busy (which was entirely understandable).

Even though the ROMs were not copyrighted (based on my own research into the matter), I'd rather have had HP's official permission and blessing to use them for noncommercial purposes. But after nine years of trying to get that, I gave up and decided to publish Nonpareil with the ROM images under my own copyright.

Since I don't have a license agreement with HP limiting it to noncommercial use, various people were eventually able to convince me that I should offer commercial products.

Quote:
I know this sounds like overkill, but I'm not risking anything

Understandable. Failing getting a license from HP, the best you could do would be to get legal opinions from one or more attorneys who specialize in copyright law. I have not done this yet, but might in the future.

I would actually rather develop my own high-quality calculator firmware from scratch. If our initial efforts are successful, I'll do that (possibly leveraging code from OpenRPN if the license is suitable). The current plans for using the original HP ROM code is a matter of expedience, and in the case of the 41 and 12C, trying to maintain 100% compatability. For the 41, it's nice to be able to use synthetic programming and mcode with full compatability, which would be very hard to achieve with from-scratch reimplementation. And for the 12C, the numerical analysis necessary to develop new algorithms to match the accuracy of the 12C TVM under all conditions seems quite daunting (which is why I recently asked if anyone had TVM torture test cases).

I'm certainly willing to discuss leveraging the OpenRPN hardware platform, and I think Richard would be as well, though I haven't yet discussed it with him. The $100 retail price is far lower than Richard and I are targetting for our early products, but would certainly result in much better sales.

Quote:
Among the first classic models recreated using the *fix core will likely be the 15c, 42s, 11c, and 32sii

There are potential legal issues regarding the 32SII. I'd steer clear of that one. The others should be fine.

Eric


#57

Don't you just love HP's IP department? I'm willing to bet they would even try to deny licensing expired patents!

Looks like we'll stick to using the *fix core for developing RPN machines. For anyone who isn't already aware of our plans at OpenRPN, the *fix core contains the most basic set of commands possible from which all other commands can be built. The *fix language is essentially the RPL command set, less symbolics for now, but with the ability to parse postfix (RPN/RPL), infix (Algebraic), and prefix (Lisp) in a program and additionally, decompile to any syntax for editing, although internally they will be store in postfix.

Aside from the complete *fix command set, the *fix core will also be used to impliment the RPN command set of the 42s. Of course, we hope to see many more machines duplicated using the *fix core. After all, it's purpose is to be a great tool to develop calculators with relative ease and minimal pain.

Please take a look at our Sourceforge page. We desperately need more programmers, at the moment we have only two who are active. I have made numerous attempts to contact hughsteers, since he did a great job on the BCD library we use and generally speaking knows calculation algorithms very well. I hope he is well, and perhaps one day might be willing to help. Eric, if you're at all interested I'm sure you've learned a frightening amount about calculator algorithms given the amount of reverse engineering you have undertaken. Understanding more of the intricacies of how calculator ROMs have been written in the past would speed our progress up immeasurably.

As soon as our code reaches the beta stage of development it will start being distributed as a cross-platform development and test utility featuring a mock-up of the hardware and emulation of the ARM9 MCU.

Here are a few areas we especially need help in:
<> C++ Programmers: Help write the *fix core... if you aren't comfortable writing *fix you can even help by proofreading and checking for errors as well as making sure the code is documented to within an inch of its' life.
<> RPL experts: Presently your work will involve more consulting than anything else. As things progress, you will be able to impliment commands in *fix itself and help to design tests for the command set.
<> Embedded electronics expert/PCB designer: Select components, aid in creating specifications for custom parts. Create PCB layouts designed for ease of assembly, repairs, and testing. Access to PCB prototyping equipment at work would be a huge plus! We have one volunteer thus far, but if anyone does this for a living your extpertise would pay of big-time and quickly.
<> Forth and Lisp Programmers: Both of these languages have heavy influences on RPL, and hence *fix. Often, extra insight into these languages helps the *fix development process.
<> eCos expert: Port eCos to the Sharp LH7A400 MCU and verify it will work properly with all of our selected hardware. Optimize where necessary.
<> Cross-Platform GUI programmer: Make a demonstration/development program for both calculator models integrating the *fix core, ARMulator, Arithmetic libraries, an easy to use keyboard command mapping utility, and accurate fully-functional electronic mock-ups of each calculator model (even including the proper resolution, contrast, and dot-pitch of their respective LCDs). If it's not too difficult a basic configuration tool should be made to make each calculator appear at its' real size on screen. The GUI should include features to save keyboard command layouts, save states, load *fix and RPN commands, new versions of the *fix core, and applications written in other programming languages.

I'm sure I will think of more as soon as I post, but I will also move this big help wanted ad to OpenRPN.org as soon as Chad has it functioning again... Which reminds me:

<> Webmaster: maintain and host postnuke webpage and uniwakka (wiki) documentation site for www.openrpn.org. Must have a background in network security and keep daily backups of the site. A fast cable modem connection with a static IP is enough to get the job done, but if you have something more substantial and are willing to share a little bandwidth we would appreciate it.

Best Regards,
Hugh

PS- Eric, I get in touch with you via e-mail. I think we should collaborate and make even more really great calculators. In the meantime I want to make sure you don't get killed by the production costs for that current enclosure of yours! I have plenty of room in my email box, please send sketches or CAD drawings of your enclosure design(s) to me and I'll see what I can do to help.


#58

You've got mail. 8)


#59

Thanks Howard,

From my initial inspection I would definitely hold off on production using this design. I'm moving everything over to SolidEdge where I can work with the design and hepoefully cut down the number of plastic parts to around 2 or 3. The overall design is good, but the implimentation will cost a fortune in machine time and construction (which will be a QC nightmare).

I should be able to have something for you within the next few days. Thanks again for the drawings. I want you guys to succeed on your first effort so that we can collaborate on the 2nd generation.

Best regards,
Hugh

#60

Quote:
<> RPL experts: Presently your work will involve more consulting than anything else. As things progress, you will be able to impliment commands in *fix itself and help to design tests for the command set.

We're pretty well at the stage of command implementation now. The core has most of what is necessary already. Apart from a few stability issues, I'm finding implementation of commands in *fix to be relatively straightforward. There are a few conventions yet to be defined but nothing too serious.

There are some problems: we don't have a long real type which will probably prove necessary. The BCD arithmetic has weird rounding properties due to the way it is implemented which will either need investigation or re-implementation.

We will also need some numerical analyists to supervise algorithm selection, implemtation and testing.


When I've no calculator to hand, I pull up *fix for quick calculations on my laptop which indicates a degree of stability in *fix or a degree of instability in me or both :-)


- Pauli


#61

Quote:
The BCD arithmetic has weird rounding properties due to the way it is implemented which will either need investigation or re-implementation.

In case you're referring to the effects of base-10000, that is, numbers have 25 to 28 decimal digits of precision depending on their exponent: I have modified the BCD20 library in Free42 so that it always rounds to 25 decimal digits, thus making it behave more like a true decimal library.


I sent those patches, plus fixes for a few unrelated bugs, to Hugh Steers; they haven't been merged into the BCD20 distribution on the voidware home page yet (and presumably not in OpenRPN either, although I haven't checked this). I'd be happy to provide diffs against the OpenRPN code base, if desired; or, you could inspect the Free42 source package yourself to make sure it does what you require.

(Another issue is the fact that the BCD20 transcendental functions are implemented using standard-precision arithmetic. It is impossible to get results that are accurate to the full 25 digits this way; the implementation should be changed to use a wider BCDFloat type internally, to provide "guard digits". This wider type would also be useful to improve the accuracy of matrix operations and such.)

- Thomas

Edited: 10 Aug 2006, 8:04 a.m.


#62

Quote:
In case you're referring to the effects of base-10000, that is, numbers have 25 to 28 decimal digits of precision depending on their exponent: I have modified the BCD20 library in Free42 so that it always rounds to 25 decimal digits, thus making it behave more like a true decimal library.

Yes, this was my main concern.

There is also the relative immaturity of the package.


Has anybody looked at this one or know of others?

http://www2.hursley.ibm.com/decimal/#decNumber

At least superficially it looks reasonable and fairly comprehensive.


Quote:
I'd be happy to provide diffs against the OpenRPN code base,...

I guess this would be useful :-)


Quote:
(Another issue is the fact that the BCD20 transcendental functions are implemented using standard-precision arithmetic. It is impossible to get results that are accurate to the full 25 digits this way; the implementation should be changed to use a wider BCDFloat type internally, to provide "guard digits". This wider type would also be useful to improve the accuracy of matrix operations and such.)

Hence the need for longer floating point types for internal use.


Regards,

- Pauli


#63

There is also the relative immaturity of the [BCD20] package.

It's been in use in Free42 for almost 6 months now... Hundreds of Free42 users can't be wrong. ;-)

I guess [diffs] would be useful :-)

OK, I'll compile a set of patches against starfix-0.1.1.tar.gz to bring it in line with the BCD20 version in Free42. I'll email it to you shortly.

Hence the need for longer floating point types for internal use.

Modifying BCDFloat so that it uses a wider mantissa (and possibly also a wider exponent) is not too difficult. Most of the code was written with just such modifications in mind, although a few hard-coded dependencies on the 7-digit variation have crept in.


Fixing the transcendentals is a bit harder, since the Taylor series will have to be evaluated to a few more terms, and all the hard-coded constants need to be replaced with wider versions.


The good news is that this is mostly an implementation detail and won't affect any code that's built on top of BCD20.

- Thomas

#64

Paul, I sent the patches to your sourceforge email address.

- Thomas


#65

Thomas, thanks for that. These changes are in the repository now.

- Pauli

#66

On the flip side, could OpenRPN benefit from Richard's hardware design ? That seems to be the current stumbling block, the enclosure design is going well as is the software...

I don't think we *need* a 200MHz processor to do what we want.


- Pauli


#67

Everything is going great with my enclosure designs. Just be patient, the final result will be worth it.

Our use of laser cutting is as limited as possible (strictly keyboard labels to be backfilled with precisely colored resin, thus producing custom double-shot molded-in labeled keys and fascia).

Regarding the 200MHz MCU: Yes, 200MHz would be overkill. But the processor is fully static, meaning we can throttle it to whatever clock speed we want and conserve loads of power. Very few chips that are integrated enough for our needs exist, and tend to be ARM9 based units, which use smaller processes, less power, and are therefore capable of much higher clock speeds. Most of the time we should be able to get away with running it between 33MHz (20.6mA) and 66MHz (41.3mA).

Edited: 9 Aug 2006, 9:44 a.m.

#68

Richard already got it quoted by emachineshop, and it was much more expensive, which is why he came up with the lamination scheme.

What's wrong with the tact buttons?

I'd rather use domes in future models, but I haven't found a good, inexpensive source. But I hadn't heard of Snaptron either, so I'll check it out. Thanks!

We'll start taking orders at the HHC conference; I'll post a link to the information here once it's available.

Thanks,
Eric


#69

Could you send me a copy of the CAD files you're working with for your enclosure? emachineshop has some quirky software, and I've learned most of the tricks to keeping price down. I'd love to have a crack at it.

The main poblem with tact' buttons is that they are big and have short lifespans. Snaptron makes great tactile domes, and can even put them on custom adhesive sheets. They also offer gold plating... All at reasonable prices.


Snaptron


Edited: 9 Aug 2006, 9:46 a.m.


#70

Hugh:

Quote:
Could you send me a copy of the CAD files you're working with for your enclosure? emachineshop has some quirky software, and I've learned most of the tricks to
keeping price down. I'd love to have a crack at it.

Thanks for the offer. The design is not stable right now but I hope to have an upgraded design done in a few weeks. If I am satisfied with the Laser-cut prototypes, I will send you a copy of the files.

I am not sure that the files will do you any good. They are in CorelDRAW format. CorelDRAW seems to want to export circles as all of their line segments and emachineshop uses a single object for circles. The last time I tried to import the CorelDRAW files into emachineshop, it couldn't handle the large number of segments.


Quote:
The main poblem with tact' buttons is that they are big and have short lifespans. Snaptron makes great tactile domes, and can even put them on custom adhesive sheets. They also offer gold plating... All at reasonable prices.

What kind of pricing have you gotten for domes on the adhesive carrier? Tact switches are about $0.15 each in reel quantities (thousands).

There are advantages and disadvantages to both the dome switches and the tact switches.

The dome switches are likely cheaper than the tact switches and don't need the extra step of surface mounting parts on both sides of the PCB. They do however require a custom adhesive carrier to align them on the PCB. In addition, the PCB will probably need to have gold plating on top of nickel plating to get the long life that the keyboard needs. Replacing a dome or repairing its contact pad on the PCB is difficult.

Tact switches don't need a special PCB but, as mentioned above, do need special assembly steps. Another problem with the tact switch is that cleaning the PCB after soldering is harder. Tact switches that withstand all of the cleaning processes are more expansive than the ones that don't. I trust the maker of tact switches to know more about designing a reliable switch than I could do using domes.

Tact switches are available in sizes similar to the domes. They have typical life specifications of about 500,000 actuations. However, if a tact switch does fail, it is easy to replace.

Here are some small tact switches:

http://www.mouser.com/catalog/626/1183.pdf

The SKRWAA is about 0.150" square and 0.015" high. It has a life of 500,000 actuations.

The SKRRAB is about 0.30" square and 0.030" high. It has a life of 3,000,000 actuations.


-- Richard


#71

Richard,

Please just send me what you have. I don't see any complex curves or anything and if I can find a solution for you (I'm 100% positive that I can) with emachineshop it will save you an enourmous amount of labor and cash. It doesn't matter to me that the design isn't ready/stable, and I can interpret from corelDRAW.

Just please send them, any changes I make we remain your intellectual property and I won't shar your work with anyone else. There, I'm under an NDA now. Please give me a chance to help you guys out!

Regards,
Hugh

#72

After comment and feedback from the Forum I've been investigating using SD type cards for Rom Pac instead of USB. The SD flash card has the advantage of being low on power consumption and small - but really its too big. So I looked at the next 'new thing' - Transflash. This small card comes in at 256Mb and up. The SD looks like a monster next to it !!

Of course it was interesting pluging a transflash into the SD carrier into the PC Card holder to read it.

If you follow the links you see that it is one quarter the size of the Rom pac and paper (OK Card) thin. I've sourced a pcb surface mount carrier for it (push/click spring loaded etc) in Taiwan and have been playing with some samples. Photo's at :

http://web.mac.com/mark_murphy/iWeb/Site%202/HP%20ROM%20PAC.html

Next need to figure out smallest SMD Pic to interface to it and figure out how to simulate Magcard/tape etc - Eric any hints much appreciated.

Reading Richard Ottosen's great DIY article - I was reminded that size is all - that's small size! Although the Transflash won't get to 8Gb of CF (Yet!!) it's the small size that I find remarkable.


#73

Hi Mark,

your project is pretty impressive! Do you think you can build the modules from scratch, or do you need to slaughter a module to get the contacts and the housing?

I wish you project success!

Klaus

#74

Quote:
I've sourced a pcb surface mount carrier for it (push/click
spring loaded etc)

You may find something here to make your prototyping easier:

http://www.sparkfun.com/commerce/product_info.php?products_id=544

Also, Mouser has mini-SD connectors made by Alps. Alas, they don't have the micro-SD connectors. Maybe they will in the future.


-- Richard


#75

Thanks Richard - I have a few samples to play with at the moment - using the SD Carrier in the picture in a standard MMD interface to 'play' with otherwise the damn things are too small - packaging is my final concern. Selecting a better Pic beyond the 18F252/452 series at the moment, but just getting used to FAT 16 etc on the MMC/SD. At least I can detect the card (part i of 4000). Will look to tie together stuff based on Diego's Clonex on the HP mainframe (god I love the terms those HP guys used) side with the FAT16 interface next - think this will take the bulk of the time - steep learning curve as usual so will be my years project I think.

You and Eric have done some amazing work - I had suggested 'gutting' some HP41's for the innards of the DIY that Eric and you have put together - its an amazing package to use - and hey don't the PC guys still effectively use the same form factor after 25 years - then you can focus on gettting the innards running n+1 times faster and add ports to the expansion port - all we really need is USB and a small flash card. Heck I'd even gut my mag card reader to add a small graphic Lcd like the Nokia 3310 one (see http://www.amontec.com/lcd_nokia_3310.shtml) as a peripheral to simulate the printer.

As an aside if anyone is interested I'm using the Mikroelektronika dev boards - very good and quite cheap and reliable.

#76

Eric; Remember - one is mine :-) See you at HHC. -db

#77

Please, specify the cost and if it can be sent in Italy, where I live.

I'd like to buy the both of models.

-- Antonio


#78

Final pricing has not been determined. I'm not sure whether shipment to Italy will be a problem. It depends on what certifications are required. We aren't prepared to spend a lot of money on that. And I have no idea what you should expect to pay in import duties or tariffs.

Edited: 15 Aug 2006, 12:58 p.m.


#79

Quote:
I'm not sure whether shipment to Italy will be a problem. It depends on what certifications are required. We aren't prepared to spend a lot of money on that. And I have no idea what you should expect to pay in import duties or tariffs.

If you plan to ship the devices as a commercial product for mass distribution, you need a certification of safety of use and compliance to the rules regarding radio band interference. This is required for the whole European Union.

The non-RF, battery operated devices are quite easy to certify, if you plan to do so:
You can find companies specialized in the details of the certification which will perform all the required steps for around 5000€. The requirement are quite similar to the FCC certification; the only issue is that, in the beginning of this year the EU introduced the RoHS - a regulation regarding the use of "hazardous" substances in electronic equipments, which imposes, among the other things, the use of lead-free soldering alloys and components.

The certification in not required in transaction between individuals, and even in transactions between commercial entities, items marked as non re-sellable or prototypes can be shipped without any need of certification.

The cost of the customs duty is 20% of the item declared value (if we are talking about a generic "electronic device" class), with a minimum of 5.5€; in some countries of the european union an extra 2-3€ "customs handling fee" may be required.


#80

Hallo!

Quote:
The certification in not required in transaction between individuals, and even in transactions between commercial entities, items marked as non re-sellable or prototypes can be shipped without any need of certification.

As far as I know, certification is also not required if the devices are sold as kits for self assembly. Packing the pcb and the housing in separate bags should do the trick. It even works with aeroplanes :-)

Greetings, Max


#81

Another related story : in some countries of EEC, a special fee is collected on houses only when you finish it.

The result ?

Most houses are never officially 'finished' in those countries. There is usually something hanging off the roof or something else missing to make it clear. Very strange.

#82

AFAIK there are no import duties, we routineley import goods from all over the world. The 20% may the the VAT (or sales tax) that is charged when shipping to individuals. Between companies its should not be a problem. I suggest to find a company who can handle the import and further distribution.

For the CE marking, this is a must when selling to individuals for finished products. Low voltage is easier on safety, but has the same rules on interference. Actually certification is not required, as long as there is a certificate stating that the device is compliant, and the person who signs is personally liable in case of problems. The cost for a so called CE quickscan is indeed about EUR 5000 (for low voltage safety and interence).

Also be aware of rules for RoHS (Reduction of Hazardous Substances) when marketing a product in Europe, that is important for component selection and the process (everything must be 'lead-free').

I am a proud Eropean, but sometimes the overkill in rules make business in electronics a bit difficult. Still the company I work for handles it without too much overhead.

Meindert

#83

Considering the very specific market niche your wonderful device is aimed to (I would celebrate a massive adoption of it, but I'm somehow skeptical), I don't think you will need to undergo an expensive and complex certification process for a small number of units, which you may sell FOB USA and let the customer care about shipping, duties, etc.

As many people here, because of my RPN fondness (specifically 25-41C); and also because of my technical background, I think your development is very, very valuable. Of course, I may buy a unit or more for myself when available. But from the point of view of international trade (customs, regulatory agencies, etc.) it may be closer to be seen as a PIC-based board with a plastic case, similar to a DIY or hobby project, with a not-so-high price (let's hope so!) and with small demand in number of units. Not a very different case from buying a nixie clock or a vintage calculator from e-Bay. (Is someone demanding CE or RoHS certifications on a HP-01?).

A small parcel shipment, or something like that, may be adequate, perhaps with advanced payment via credit card and some kind of insurance. UPS or couriers may be, some details may need to be adjusted. For me, I plan to visit the US just to pick my unit at the right time :-)

For Customs horror histories, I can assure I can contribute some (fortunately with a happy ending) which may surprise all of you. One of these days...

#84

I think I'll be thrown off this forum, especially since I was one of the early objectors and I think first to call the 33S' keyboard "chevron shaped", but...


... I also think that in later years, we may begin to think of the HP-33S as a great calculator, not just because it kept RPN alive, but has kept it well, too.

It has MANY functions, some of which many of us may never need or use. It has memory space for a user-modifiable equation library, all the constants you'll ever need from the inside back cover of your physics, chemistry, and engineering texts... and if not, you can easily calculate it yourself (with RPN, of course!) and store it in one of about twenty-five memory registers or write a decent sized program to do so.

Bugs? Everything has bugs... just ask owners of classic Jaguars, hard core players of Starfleet Command (it's still going on servers after lots of years, mind you!). Why, even fleas are victimized by even smaller ticks.

I don't get missed keypresses, and ever since HP exchanged my original model for the upgraded one with the more visible decimal point, it's really been a pleasure to use. It's got a convenient form factor, DOES FIT IN MANY OF MY SHIRT POCKETS, though without the rather nice case that offers a fair amount of shock protection (not that that's such a hot idea... women and kids make fun of you), and is lightweight, easily portable.

Cosmetics? I breeze right through that section of the department store. Sure, I'd prefer a case and keyboard that looks like a 34C, but hey, once you start working with it, it's ease of use and power allows you to easily forget what it looks like.

AND, those who are users of those lesser brands hesitate to borrow, or even not ask to borrow your calculator!


Possibly Related Threads...
Thread Author Replies Views Last Post
  Converting Great Circle Navigation from 41C to 42S Bill Triplett 11 1,418 11-13-2013, 07:24 AM
Last Post: Kimberly Thompson
  [HP-Prime] connector made with printer3D CompSystems 0 401 10-18-2013, 04:53 PM
Last Post: CompSystems
  prime programming / great circle formulae Geoff Quickfall 15 1,387 09-27-2013, 07:16 PM
Last Post: Kimberly Thompson
  Do You Think a Listing Error Was Made? Jim Johnson 13 1,464 09-04-2013, 09:23 AM
Last Post: Eddie W. Shore
  About changing or deleting content after replies were made Raymond Del Tondo 1 430 08-26-2013, 05:01 PM
Last Post: Massimo Gnerucci (Italy)
  Self-made WP-34s flashing cable? Victor Koechli 6 1,249 08-15-2013, 10:11 AM
Last Post: Les Wright
  Great news - Vicinno's HP 15C Scientific Calculator iPhone app is FREE now John 21 2,435 06-07-2013, 05:49 AM
Last Post: Mike (Stgt)
  Re-visiting the Great Calendar Race at HHC 2012 Gene Wright 0 384 12-01-2012, 07:02 PM
Last Post: gene wright
  Great white shark sighted in CL reef... Ángel Martin 7 864 10-26-2012, 11:35 AM
Last Post: Richard Wagoner
  Great Forum John W Kercheval 2 436 05-04-2012, 03:13 PM
Last Post: John W Kercheval

Forum Jump: